On Mon, Jun 3, 2019 at 10:51 AM Sérgio Basto wrote:
>
> Hi,
> These removed python2 packages are breaking upgrade path
>
> 1- when you remove python2-foo , you should add to main package
> Obsoletes: python2-foo
If I may suggest, *absolutely not*. "Obsoletes: python2-foo"
specifically means that
Dne 03. 06. 19 v 13:00 Kamil Dudka napsal(a):
>> Now I'm working on signal SIGTERM handling and I would like to kill all
>> processes related to the main mock process.
>> What do you think is it a good
>> idea to kill all processes, or do we want to kill the main process only?
>> And what about SI
Dne 27. 05. 19 v 11:34 Florian Weimer napsal(a):
> I'm investigating whether it makes sense to switch to a scheme where the
> glibc locale data is built from source, during package installation,
> based on the langpack configuration system. This is similar to what
> Debian does.
I cannot comment
On 6/4/19 9:56 AM, Daniel Mach wrote:
Dne 31. 05. 19 v 2:15 Pavel Raiskup napsal(a):
On Thursday, May 30, 2019 10:38:25 AM CEST Miroslav Suchý wrote:
Dne 29. 05. 19 v 23:52 Josh Boyer napsal(a):
If we did this, wouldn't it make it very difficult to use tools like
mock on RHEL / CentOS 7 to bui
Hello.
I plan to retire python-marrow-mailer and python-marrow-util packages.
python-marrow-util is archived upstream [0] without replacement and it's
incompatible with Python 3.8 [1]. python-marrow-mailer is also inactive
in upstream (last commit from december 2016) [2].
marrow-mailer depen
The python2-foo removed packages be added to the fedora-obsoletes package.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-c
A few weeks ago I noticed that borgbackup bundles some libraries and copied
some external code effectively changing the license of the final executable
code.
This change was not announced upstream so it went unnoticed when updated
versions of borgbackup were pushed to Fedora's git.
I just fixed
Hi,
I've been having some issues with LMDB on i686/s390x when building
python-zarr and its dependants. I filed a bug report [1], but the
maintainer suggested asking here to get more reach. I have replicated
my original message from the report below:
The documentation for LMDB [2] states that the
On 04/06/2019 10:03, Elliott Sales de Andrade wrote:
I have narrowed this down to the mmap call at [6] which attempts to
map the backing file into memory. AFAICT, the mapped size is far below
the RAM on the build machine as well as far below the normal 32-bit VM
limit. So I don't know why the ca
Hi,
I've had some issues with tests for xtl not working on
ppc64le/armv7hl. These tests work fine on Fedora 29, but fail on 30+
[1]. Unfortunately, koschei does not check these platforms, but I'm
fairly certain these started failing when gcc was updated to 9.0.0.
Upstream is also suspicious that t
On Tuesday, June 4, 2019 9:33:33 AM CEST Miroslav Suchý wrote:
> Dne 03. 06. 19 v 13:00 Kamil Dudka napsal(a):
>
> >> Now I'm working on signal SIGTERM handling and I would like to kill all
> >> processes related to the main mock process.
> >>
> >> What do you think is it a good
> >>
> >> idea
Hi,
I started update process in rawhide to update all Qt modules to 5.12.3 and
later I will rebuild all packages depending on Qt private stuff. You may
experience build failures until the whole update process is done, which should
be hopefully tomorrow.
Regards,
Jan
_
On Tue, 2019-06-04 at 03:25 -0400, Nico Kadel-Garcia wrote:
> If I may suggest, *absolutely not*. "Obsoletes: python2-foo"
> specifically means that it includes and provides "python2-foo"
> functionality,
No , on update just force remove of python2-foo , doesn't provide it .
instead dnf broken dep
On Tue, Jun 4, 2019 at 3:26 AM Nico Kadel-Garcia wrote:
>
> On Mon, Jun 3, 2019 at 10:51 AM Sérgio Basto wrote:
> >
> > Hi,
> > These removed python2 packages are breaking upgrade path
> >
> > 1- when you remove python2-foo , you should add to main package
> > Obsoletes: python2-foo
>
> If I may
* Marek Marczykowski-Górecki:
> I'd like to request unretire osslsigncode[1]. Originally it was retired
> because of being abandoned upstream, but now there is an actively
> maintained fork[2] with major release half a year ago and last commit
> less than 2 months ago. As I understand[3], original
On Tue, Jun 4, 2019 at 8:16 AM Florian Weimer wrote:
>
> * Marek Marczykowski-Górecki:
>
> > I'd like to request unretire osslsigncode[1]. Originally it was retired
> > because of being abandoned upstream, but now there is an actively
> > maintained fork[2] with major release half a year ago and l
On Tue, Jun 04, 2019 at 08:20:50AM -0400, Neal Gompa wrote:
> On Tue, Jun 4, 2019 at 8:16 AM Florian Weimer wrote:
> >
> > * Marek Marczykowski-Górecki:
> >
> > > I'd like to request unretire osslsigncode[1]. Originally it was retired
> > > because of being abandoned upstream, but now there is an
Hello,
I have run fedora-rawhide-build-pipeline
https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-build-pipeline/detail/fedora-rawhide-build-pipeline/4426/pipeline/
that failed in the
cloud-image-compose
stage, something which (I be
Is there a form of weak dependency which is installed when available,
but not automatically re-installed on each update?
If all the optional components are back after an update, that means that
it's quite hard to maintain a minimal system installation.
Thanks,
Florian
On Tue, Jun 04, 2019 at 03:28:12PM +0200, Jan Pazdziora wrote:
>
> Hello,
>
> I have run fedora-rawhide-build-pipeline
>
>
> https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-build-pipeline/detail/fedora-rawhide-build-pipeline/4426/pipeline/
>
On Tue, Jun 4, 2019, 15:30 Florian Weimer wrote:
> Is there a form of weak dependency which is installed when available,
> but not automatically re-installed on each update?
>
> If all the optional components are back after an update, that means that
> it's quite hard to maintain a minimal system
On 04. 06. 19 15:28, Florian Weimer wrote:
Is there a form of weak dependency which is installed when available,
but not automatically re-installed on each update?
If all the optional components are back after an update, that means that
it's quite hard to maintain a minimal system installation.
On Tue, Jun 4, 2019 at 9:30 AM Florian Weimer wrote:
>
> Is there a form of weak dependency which is installed when available,
> but not automatically re-installed on each update?
>
> If all the optional components are back after an update, that means that
> it's quite hard to maintain a minimal s
On Tue, Jun 4, 2019 at 3:29 PM Jan Pazdziora wrote:
>
> Hello,
>
> I have run fedora-rawhide-build-pipeline
>
>
> https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/fedora-rawhide-build-pipeline/detail/fedora-rawhide-build-pipeline/4426/pipeline/
>
> that failed in the
* Neal Gompa:
> On Tue, Jun 4, 2019 at 9:30 AM Florian Weimer wrote:
>>
>> Is there a form of weak dependency which is installed when available,
>> but not automatically re-installed on each update?
>>
>> If all the optional components are back after an update, that means that
>> it's quite hard
On Sun, 2 Jun 2019 at 15:14, Miro Hrončok wrote:
> On 31. 05. 19 16:10, Fabio Valentini wrote:
> > On Thu, May 30, 2019 at 8:19 PM Adam Jackson wrote:
> >>
> >> Since I was looking at a copy of the F30 repo for amd64, here's a list
> >> of a bunch of packages whose dist tag suggests they haven't
Dne 04. 06. 19 v 15:48 Neal Gompa napsal(a):
> he's aware that it's possible and some work could be
> done to support this depending on demand for the feature.
I do demand this feature :)
I would love to see "dnf mark" command to utilize for this. Something like: dnf
mark soft-remove
I.e. remove
On Tue, Jun 4, 2019, 15:59 Stephen John Smoogen wrote:
>
>
> On Sun, 2 Jun 2019 at 15:14, Miro Hrončok wrote:
>
>> On 31. 05. 19 16:10, Fabio Valentini wrote:
>> > On Thu, May 30, 2019 at 8:19 PM Adam Jackson wrote:
>> >>
>> >> Since I was looking at a copy of the F30 repo for amd64, here's a l
Germano Massullo wrote:
>A dubt about XDG_CURRENT_DESKTOP. Since boinc-client runs as a service
>with its own user, I don't think it will be able to read
>XDG_CURRENT_DESKTOP defined in other users sessions. Therefore IMHO I
>need another kind of solution
So the question isn't what desktop the use
Il giorno mar 4 giu 2019 alle ore 17:31 Björn Persson
ha scritto:
> So the question isn't what desktop the user is using, but rather what
> desktops, if any, other users on the machine are using.
Well when I started the thread I had not thought that BOINC client
service is running on a confined u
On Tue, 2019-06-04 at 15:53 +0200, Florian Weimer wrote:
> * Neal Gompa:
>
> > On Tue, Jun 4, 2019 at 9:30 AM Florian Weimer wrote:
> > > Is there a form of weak dependency which is installed when available,
> > > but not automatically re-installed on each update?
> > >
> > > If all the optional
On Tue, Jun 4, 2019, 18:03 Adam Williamson
wrote:
> On Tue, 2019-06-04 at 15:53 +0200, Florian Weimer wrote:
> > * Neal Gompa:
> >
> > > On Tue, Jun 4, 2019 at 9:30 AM Florian Weimer
> wrote:
> > > > Is there a form of weak dependency which is installed when available,
> > > > but not automatica
On Tue, Jun 4, 2019 at 12:06 PM Fabio Valentini wrote:
>
> On Tue, Jun 4, 2019, 18:03 Adam Williamson wrote:
>>
>> On Tue, 2019-06-04 at 15:53 +0200, Florian Weimer wrote:
>> > * Neal Gompa:
>> >
>> > > On Tue, Jun 4, 2019 at 9:30 AM Florian Weimer wrote:
>> > > > Is there a form of weak depende
Germano Massullo skrev:
>Il giorno mar 4 giu 2019 alle ore 17:31 Björn Persson
> ha scritto:
>> Have you confirmed that you're able to query another user's desktop session
>> once
>> you know which desktop it is?
>
>I cannot read XDG_CURRENT_DESKTOP of other users. I am actually
>wondering if ch
* Adam Williamson:
> As a side note, if your goal is "to maintain a minimal system
> installation", perhaps what you might want is to be able to configure
> dnf to simply *never* install weak (Recommends) or very weak (Suggests)
> dependencies. IIRC, this is configurable on SUSE - you can set this
On Tue, 2019-06-04 at 19:06 +0200, Florian Weimer wrote:
> * Adam Williamson:
>
> > As a side note, if your goal is "to maintain a minimal system
> > installation", perhaps what you might want is to be able to configure
> > dnf to simply *never* install weak (Recommends) or very weak (Suggests)
>
OLD: Fedora-Rawhide-20190603.n.0
NEW: Fedora-Rawhide-20190604.n.0
= SUMMARY =
Added images:7
Dropped images: 15
Added packages: 5
Dropped packages:9
Upgraded packages: 101
Downgraded packages: 0
Size of added packages: 21.81 MiB
Size of dropped packages
On 6/4/19 11:27 AM, Neal Gompa wrote:
The option can also be set in dnf.conf (--setopt= maps to options that
you can set there.:) )
This is one option, but it hides them entirely. I would like an option that still
shows possible weak dependencies without installing them. Example:
--setopt=i
Missing expected images:
Atomichost raw-xz x86_64
Atomichost qcow2 x86_64
Compose FAILS proposed Rawhide gating check!
1 of 47 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 14/146 (x86_64), 1/2 (arm), 2/24 (i386)
ID
Miroslav Suchý wrote:
> I would love to see "dnf mark" command to utilize for this. Something
> like: dnf mark soft-remove I.e. remove the package and does not install it
> again unless something pull it back using hard "Requires".
Why would we require explicit marking? There is no technical reaso
Florian Weimer wrote:
> Does it sense to reopen bug 1699672, in light of this development?
It would also make sense to get the upstream issue:
https://github.com/openSUSE/libsolv/issues/168
reopened.
Kevin Kofler
___
devel mailing list -- devel@
On Tue, Jun 4, 2019 at 5:36 PM Kevin Kofler wrote:
>
> Florian Weimer wrote:
> > Does it sense to reopen bug 1699672, in light of this development?
>
> It would also make sense to get the upstream issue:
> https://github.com/openSUSE/libsolv/issues/168
> reopened.
>
That will not get reopened, be
Jason L Tibbitts III wrote:
> One problem is that I don't think anyone wants to see any quantifiable
> regression in overall package size. Spins still struggle to fit within
> fixed media sizes as the package set grows ever larger.
The RPM compression method is pretty irrelevant to Spin sizes bec
Florian Weimer wrote:
> Is there a form of weak dependency which is installed when available,
> but not automatically re-installed on each update?
The only workaround for that broken DNF behavior that packagers can in some
cases use at this time is to use boolean Supplements instead of a simple
On Mon, Jun 3, 2019 at 7:01 PM Jason L Tibbitts III wrote:
>
> > "PM" == Panu Matilainen writes:
>
> PM> Note that rpm doesn't support parallel zstd compression, and while
> PM> it does for xz, that's not even utilized in Fedora.
>
> Doing parallel xz compression has a surprising cost in comp
45 matches
Mail list logo
