Re: Upgrade to F30 gone wrong

On 5/9/19 12:55 AM, Chris Murphy wrote: On Wed, May 8, 2019, 4:50 AM Panu Matilainen > wrote: Nicolas' point is that the rescue boot entry only works in a limited number of scenarios. I'm not sure which of three 'rescue' options is being discussed. gru

Re: Docker and user namespaces on F30

On Wed, 2019-05-08 at 19:09 +0200, Jun Aruga wrote: > > Which looks even stranger. > > > > I see we don't have the same version of docker. I have version > > 18.06.3, > > build d7080c1. Did you install docker from > > https://docs.docker.com/install/ ? > > Yes, for docker-ce I installed it from t

Re: On GCL and libselinux

* Jerry James: > Awhile back, I mentioned that GCL was building in mock on my local > machine, but was segfaulting on the koji builders. By dint of much > experimentation, I now know what is going on. For the enlightenment > of anybody who cares: > > - GCL is linked with libtirpc. > - libtirpc i

Re: On GCL and libselinux

On Sun, May 05, 2019 at 06:49:30PM -0600, Jerry James wrote: > Awhile back, I mentioned that GCL was building in mock on my local > machine, but was segfaulting on the koji builders. By dint of much > experimentation, I now know what is going on. For the enlightenment > of anybody who cares: > >

Re: Package with open and closed dual license

Andrew Toskin wrote: > Oh, sorry, I hadn't thought to try searching for previous threads about > VeraCrypt in particular. > > And, looking at it again, the dual license here is tricky, because it > looks like the old TrueCrypt files are still TrueCrypt-licensed, while the > new files are Apache-li

Re: I wish to stop maintaining python2-defusedxml

On 04. 05. 19 17:18, Miro Hrončok wrote: On 27. 04. 19 15:33, Miro Hrončok wrote: On 20. 04. 19 20:33, Miro Hrončok wrote: Only one package (fawkes-devenv) requires python2-defusedxml. It already has broken dependencies on mogodb-server and the source package (fawkes) doesn't build. fawkes-

dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

Hi, let's drop the requirement and ordering on systemd (as implemented by %systemd_requires) from packages which provide systemd units. I now filed [1], which removes the recommendation to use %systemd_requires. Quoting from that ticket: Nowadays systemd.rpm does a preset-all call when it is

Re: On GCL and libselinux

* Daniel P. Berrangé: > Though as Florian suggests, the better solution is to not have > the personality() call in main - have it called by malloc(), or > possibly a constructor function that's part of the object > providing the malloc replacement. The latter does not work because the ELF depend

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

On 5/9/19 9:00 AM, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > let's drop the requirement and ordering on systemd (as implemented by > %systemd_requires) from packages which provide systemd units. > > I now filed [1], which removes the recommendation to use %systemd_requires. > Quoting from that

Fedora rawhide compose report: 20190509.n.0 changes

OLD: Fedora-Rawhide-20190508.n.0 NEW: Fedora-Rawhide-20190509.n.0 = SUMMARY = Added images:5 Dropped images: 0 Added packages: 1 Dropped packages:0 Upgraded packages: 174 Downgraded packages: 0 Size of added packages: 126.50 KiB Size of dropped packages:0

Do you use Bodhi's REST API or Python bindings?

Greetings! Do you use Bodhi's REST API or Python bindings? If so, we are considering changing them and would like your feedback. You can reply off-list to me, or you can drop a comment here if you'd like to be involved: https://github.com/fedora-infra/bodhi/issues/3204 Thanks! signature.asc De

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

On Thu, May 09, 2019 at 09:19:32AM -0500, Mátyás Selmeci wrote: > On 5/9/19 9:00 AM, Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > > > let's drop the requirement and ordering on systemd (as implemented by > > %systemd_requires) from packages which provide systemd units. > > > > I now filed [1],

Re: Where are armv7hl, i686 and ppc64le Container tar.xz files?

Kevin and Clement, thanks for the explanation. I am looking forward to seeing the final compose. > So, likely we haven't had a armv7 fedora 30 compose recently, and so no one has updated it. The container sig would be the ones to ask here. Sure, I will subscribe the mailing list. > Yes I do the

Fedora Rawhide-20190509.n.0 compose check report

Missing expected images: Atomichost qcow2 x86_64 Atomichost raw-xz x86_64 Compose FAILS proposed Rawhide gating check! 5 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 13/146 (x86_64), 1/2 (arm) ID: 398345

cleaning up installation of systemd *user* units

Hi everyone, tl;dr: I submitted some PRs. If you didn't get a PR, feel free to ignore this. Otherwise read on for a lengthy explanation... We now have a round 100 user units packaged in Fedora, yay! Our packaging guidelines [1] specify that they should be packaged essentially in the same way as

Re: Upgrade to F30 gone wrong

On Thu, May 9, 2019 at 12:00 AM Panu Matilainen wrote: > > On 5/9/19 12:55 AM, Chris Murphy wrote: > > > > > > On Wed, May 8, 2019, 4:50 AM Panu Matilainen > > wrote: > > > > > > > > Nicolas' point is that the rescue boot entry only works in a limited > > numbe

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

On 5/9/2019 7:46 AM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 09, 2019 at 09:19:32AM -0500, Mátyás Selmeci wrote: On 5/9/19 9:00 AM, Zbigniew Jędrzejewski-Szmek wrote: Hi, let's drop the requirement and ordering on systemd (as implemented by %systemd_requires) from packages which provide

Intent to orphan python-pytest-testmon

Hey! I intent to orphan python-pytest-testmon. I no longer have use for it and it is a leaf package. Th package is usually low maintenance, except now it doesn't build with Python 3.8 yet. https://github.com/tarpas/pytest-testmon/issues/139 So my plan is to orphan it and eventually also reti

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

Am Donnerstag, den 09.05.2019, 10:21 -0700 schrieb Japheth Cleaver: > On 5/9/2019 7:46 AM, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, May 09, 2019 at 09:19:32AM -0500, Mátyás Selmeci wrote: > > > On 5/9/19 9:00 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > > Hi, > > > > > > > > let's drop the r

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

On Thu, May 9, 2019 at 1:57 PM Björn 'besser82' Esser wrote: > > Am Donnerstag, den 09.05.2019, 10:21 -0700 schrieb Japheth Cleaver: > > On 5/9/2019 7:46 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > On Thu, May 09, 2019 at 09:19:32AM -0500, Mátyás Selmeci wrote: > > > > On 5/9/19 9:00 AM, Zbigniew

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

On 09. 05. 19 16:19, Mátyás Selmeci wrote: On 5/9/19 9:00 AM, Zbigniew Jędrzejewski-Szmek wrote: Hi, let's drop the requirement and ordering on systemd (as implemented by %systemd_requires) from packages which provide systemd units. I now filed [1], which removes the recommendation to use %sys

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

On 09. 05. 19 19:21, Japheth Cleaver wrote: On 5/9/2019 7:46 AM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, May 09, 2019 at 09:19:32AM -0500, Mátyás Selmeci wrote: On 5/9/19 9:00 AM, Zbigniew Jędrzejewski-Szmek wrote: Hi, let's drop the requirement and ordering on systemd (as implemented by %

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

On Thu, May 09, 2019 at 08:12:15PM +0200, Miro Hrončok wrote: > On 09. 05. 19 19:21, Japheth Cleaver wrote: > >On 5/9/2019 7:46 AM, Zbigniew Jędrzejewski-Szmek wrote: > >>On Thu, May 09, 2019 at 09:19:32AM -0500, Mátyás Selmeci wrote: > >>>On 5/9/19 9:00 AM, Zbigniew Jędrzejewski-Szmek wrote: > >>>

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

On Thu, May 09, 2019 at 07:56:22PM +0200, Björn 'besser82' Esser wrote: > Am Donnerstag, den 09.05.2019, 10:21 -0700 schrieb Japheth Cleaver: > > On 5/9/2019 7:46 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > On Thu, May 09, 2019 at 09:19:32AM -0500, Mátyás Selmeci wrote: > > > > On 5/9/19 9:00 AM,

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

Miro Hrončok wrote: >> So long as EPEL (and Rawhide, tbh) are under the aegis of Fedora, it >> would be nice at least /some/ effort was made not to toss over >> incompatible changes, or a broad need for dist conditionals, across the >> package ecosystem with such cavilerity. > > It's called branc

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

On Thu, May 9, 2019 at 10:02 AM Zbigniew Jędrzejewski-Szmek wrote: > > Hi, > > let's drop the requirement and ordering on systemd (as implemented by > %systemd_requires) from packages which provide systemd units. > In general, I think this idea has some solid foundation. But I think it'd be dange

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

On Thu, May 09, 2019 at 04:56:25PM -0400, Neal Gompa wrote: > On Thu, May 9, 2019 at 10:02 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > Hi, > > > > let's drop the requirement and ordering on systemd (as implemented by > > %systemd_requires) from packages which provide systemd units. > > > > In

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

On Thu, May 9, 2019 at 2:40 PM Zbigniew Jędrzejewski-Szmek wrote: > Also, if for some reason I don't grok one absolutely needs to use the > exact same spec file for Fedora 31+ and EPEL7 (which is based on F19), > than keeping the dependency as it is now is also an option. One extra > unneeded dep

normaliz soname change

I'm building normaliz 3.7.2 for Rawhide. It changes the soname from libnormaliz.so.0 to libnormaliz.so.3. The only dependent package is polymake, which I am rebuilding. -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedor

Re: On GCL and libselinux

On Thu, May 9, 2019 at 3:23 AM Florian Weimer wrote: > I'm surprised that you can turn off ASLR for a running process. > Clearly, this can only be partially effective. I think the other bits > (adjusting the heap break) are what matters. You need to move that > initialization code into malloc it

Re: Package with open and closed dual license

Kevin Kofler wrote: > try tcplay, a BSD-licensed interoperable implementation that is > already packaged in Fedora. tcplay hasn't been maintained in a while. Upstream hasn't pushed any commits since 2014. https://github.com/bwalex/tc-play And the history of builds for new releases of Fedora h

Should I always create a dedicated stream branch for my module?

Hi all, I'm currently working on a module for sway. We basically just want to have a stream that always contains the latest version of sway (including all its dependencies), the same version that is also in rawhide (this stream should be named 'rolling' if I understand the guidelines correctly). I

Re: dropping %systemd_requires from most packages (guidelines change and mass package update proposal)

On 5/9/2019 4:14 PM, Nico Kadel-Garcia wrote: On Thu, May 9, 2019 at 2:40 PM Zbigniew Jędrzejewski-Szmek wrote: Also, if for some reason I don't grok one absolutely needs to use the exact same spec file for Fedora 31+ and EPEL7 (which is based on F19), than keeping the dependency as it is now

Re: Should I always create a dedicated stream branch for my module?

It is up to you. If the plan is always to have master in sync with your module stream, then you can keep master. If you want to retire sway from rawhide at some point, you would need to move to the stream branch. On Fri, May 10, 2019 at 8:25 AM Till Hofmann wrote: > Hi all, > > I'm currently wor