Re: GCC 9 OpenMP issues

On Mon, Feb 11, 2019 at 07:17:25PM -0700, Orion Poplawski wrote: > Looks like GCC 9 is finally enforcing an OpenMP change: > > From https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00628.html Please see https://gcc.gnu.org/gcc-9/porting_to.html#ompdatasharing which documents what you can do and what

Re: Orphaned packages that will be retired (and everything will most likely burn)

I was talking to Petr Šabata some time ago and he told me that there will be some solution for getting modular packages in non-modular buildroot within month or two. On Tue, Feb 12, 2019 at 9:06 AM Aleksandar Kurtakov wrote: > > > On Tue, Feb 12, 2019 at 9:51 AM Ralf Corsepius > wrote: > >> On

Re: signing status

On Mon, Feb 11, 2019 at 10:35:55AM -0800, Kevin Fenzi wrote: > >> > >> * The mass rebuild happened and finished. > > > > Is there anywhere some summary stats about mass update? > > How many packages has been sent to rebuild vs those which rebuild failed? > > There is: > > https://kojipkgs.fedora

Re: Retire apiextractor?

Am 12.02.19 um 02:35 schrieb Richard Shaw: > Currently apiextractor is FTBFS[1] because all the test fail. > > It looking to see if there is a newer version that better supports gcc 9.0.x I > found this[2] which states that apiextrator was merged into shiboken. > > So can someone with more famil

Re: Orphaned packages that will be retired (and everything will most likely burn)

On 12/02/2019 07:22, Mikolaj Izdebski wrote: On Mon, Feb 11, 2019 at 11:19 PM Fabio Valentini wrote: I'm curious: What happens to modules when a package's master branch gets retired? Nothing. Modules will continue to exist and will continue to be delivered to users. But as I understand it t

Orphaning workrave

workrave has yet to gain support for Wayland. While it still works on X11 desktops, that is no longer the default for Workstation, and hence users keep filing bugs that it doesn't work, which I then just have to CLOSED UPSTREAM. If you want to take it nevertheless, the following F30FTBFS will nee

Re: Orphaned packages that will be retired (and everything will most likely burn)

Not in the buildroot. Default modules are available by default only for users and not in the buildroot. On Tue, Feb 12, 2019 at 10:01 AM Tom Hughes wrote: > On 12/02/2019 07:22, Mikolaj Izdebski wrote: > > On Mon, Feb 11, 2019 at 11:19 PM Fabio Valentini > wrote: > >> I'm curious: What happens

Re: Orphaned packages that will be retired (and everything will most likely burn)

So basically the module squad have managed to ensure that everything that relies on ant to build is going to have to modularise or else be forced out of the distribution then... Fortunately that only includes one thing of mine and that's just some java bindings that I can drop but forcing libreof

Re: signing status

On Tue, Feb 12, 2019 at 8:49 AM Jan Pazdziora wrote: > > On Mon, Feb 11, 2019 at 10:35:55AM -0800, Kevin Fenzi wrote: > > >> > > >> * The mass rebuild happened and finished. > > > > > > Is there anywhere some summary stats about mass update? > > > How many packages has been sent to rebuild vs thos

Re: Orphaned packages that will be retired (and everything will most likely burn)

* Tom Hughes [12/02/2019 09:15] : > > So basically the module squad have managed to ensure that everything > that relies on ant to build is going to have to modularise or else be > forced out of the distribution then... Once more with feeling: if you want ant as a package, all that is needed to ma

Re: Orphaned packages that will be retired (and everything will most likely burn)

On 12/02/2019 09:21, Emmanuel Seyman wrote: * Tom Hughes [12/02/2019 09:15] : So basically the module squad have managed to ensure that everything that relies on ant to build is going to have to modularise or else be forced out of the distribution then... Once more with feeling: if you want a

Re: Orphaned packages that will be retired (and everything will most likely burn)

Le 2019-02-12 10:21, Emmanuel Seyman a écrit : * Tom Hughes [12/02/2019 09:15] : So basically the module squad have managed to ensure that everything that relies on ant to build is going to have to modularise or else be forced out of the distribution then... Once more with feeling: if you wan

Re: F30 change, bootloaderspec by default

Le 2019-02-11 21:39, Chris Murphy a écrit : On Mon, Feb 11, 2019 at 1:14 PM Nicolas Mailhot wrote: That was during dnf update to the result of the latest rawhide mass rebuild, on two UEFI systems, one initially installed in september 2015, the other in january 2019, with whatever was most cur

Re: Orphaned packages that will be retired (and everything will most likely burn)

On Tue, Feb 12, 2019 at 10:17 AM Tom Hughes wrote: > So basically the module squad have managed to ensure that everything > that relies on ant to build is going to have to modularise or else be > forced out of the distribution then... > > Fortunately that only includes one thing of mine and that'

Re: gcc-c++ and libatomic -- link issues

On 11/02/19 12:20 +0100, Jakub Jelinek wrote: On Mon, Feb 11, 2019 at 12:14:10PM +0100, Florian Weimer wrote: * Jonathan Wakely: > On 08/02/19 19:56 -0600, Patrick Diehl wrote: >>Hi, >> >>I maintain the hpx package and it uses std:atomic and when I install >>gcc-c++ it seems that libatomic is n

Re: gcc-c++ and libatomic -- link issues

On Tue, Feb 12, 2019 at 09:49:23AM +, Jonathan Wakely wrote: > On that basis, why does gcc-c++ install libgomp and libgfortran? I think gcc-c++ doesn't require libgfortran, gcc-gfortran does. The reason to have libgomp in the dependencies was that it is a library that isn't explicitly used on

Re: Orphaned packages that will be retired (and everything will most likely burn)

On 12. 02. 19 10:47, Brian (bex) Exelbierd wrote: On Tue, Feb 12, 2019 at 10:17 AM Tom Hughes > wrote: So basically the module squad have managed to ensure that everything that relies on ant to build is going to have to modularise or else be forced out of t

Re: Orphaned packages that will be retired (and everything will most likely burn)

On Tue, Feb 12, 2019 at 11:03 AM Miro Hrončok wrote: > On 12. 02. 19 10:47, Brian (bex) Exelbierd wrote: > > > > > > On Tue, Feb 12, 2019 at 10:17 AM Tom Hughes > > wrote: > > > > So basically the module squad have managed to ensure that everything > > that relies

Re: Orphaned packages that will be retired (and everything will most likely burn)

On Tue, Feb 12, 2019 at 11:03 AM Miro Hrončok wrote: > > On 12. 02. 19 10:47, Brian (bex) Exelbierd wrote: > > > > > > On Tue, Feb 12, 2019 at 10:17 AM Tom Hughes > > wrote: > > > > So basically the module squad have managed to ensure that everything > > that relie

Re: Orphaned packages that will be retired (and everything will most likely burn)

On 12. 02. 19 11:43, Adam Samalik wrote:> (I know anyone can unbreak it by claiming the packages, but that's not the point here.) I might be missing something here, so excuse me if that's obvious, but wouldn't this happen without Modularity anyway? I mean, how does Modularity relat

Re: Orphaned packages that will be retired (and everything will most likely burn)

On 12/02/2019 10:43, Adam Samalik wrote: I might be missing something here, so excuse me if that's obvious, but wouldn't this happen without Modularity anyway? I mean, how does Modularity relate to packages being orphaned? Or is that because they have been moved out into modules and their main

Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

Hi everybody, In the past few weeks, it has come up regularly that future "module-only" packages are orphaned (and hence will soon be retired), and nobody stepped up to fix this issue - especially for non-leaf packages. I don't think fedora as a project has a solution for this yet. I propose to c

Re: Orphaned packages that will be retired (and everything will most likely burn)

On 12. 02. 19 11:46, Fabio Valentini wrote: (I know anyone can unbreak it by claiming the packages, but that's not the point here.) Miro, am I reading it correctly that the list below "Orphans (rawhide) (not depended on) (147):" is the list of orphan leaf packages? Yes. Also, if somebody ca

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

The Modularity Team works on enabling default modules to be present in the traditional buildroot. The work is tracked here: https://tree.taiga.io/project/modularity-wg/epic/12 We would love to contributions towards that. I'm willing to mentor anyone interested regarding Modularity. However, we mig

Re: Orphaned packages that will be retired (and everything will most likely burn)

On Tue, Feb 12, 2019 at 11:54 AM Tom Hughes wrote: > On 12/02/2019 10:43, Adam Samalik wrote: > > > I might be missing something here, so excuse me if that's obvious, but > > wouldn't this happen without Modularity anyway? I mean, how does > > Modularity relate to packages being orphaned? Or is t

[Bug 1675618] perl-Cache-Mmap: FTBFS in Fedora rawhide/f30

https://bugzilla.redhat.com/show_bug.cgi?id=1675618 Jan Pazdziora changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version|

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

On Tue, Feb 12, 2019 at 12:09 PM Adam Samalik wrote: > > The Modularity Team works on enabling default modules to be present in the > traditional buildroot. The work is tracked here: > https://tree.taiga.io/project/modularity-wg/epic/12 > > We would love to contributions towards that. I'm willin

Re: signing status

On Tue, Feb 12, 2019 at 09:19:03AM +, Peter Robinson wrote: > On Tue, Feb 12, 2019 at 8:49 AM Jan Pazdziora wrote: > > > > All of them failed on armv7hl, with some package (for example > > glibc-2.29-1.fc30.1.armv7hl.rpm) missing in the mock step. > > > > How should maintainers proceed in such

Re: Orphaned packages that will be retired (and everything will most likely burn)

On Tue, Feb 12, 2019 at 12:08 PM Miro Hrončok wrote: > > On 12. 02. 19 11:46, Fabio Valentini wrote: > >> (I know anyone can unbreak it by claiming the packages, but that's not the > >> point > >> here.) > > > > Miro, am I reading it correctly that the list below "Orphans (rawhide) > > (not depen

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

On Tue, Feb 12, 2019 at 12:15 PM Fabio Valentini wrote: > On Tue, Feb 12, 2019 at 12:09 PM Adam Samalik wrote: > > > > The Modularity Team works on enabling default modules to be present in > the traditional buildroot. The work is tracked here: > https://tree.taiga.io/project/modularity-wg/epic/

Re: Ownership of rogue

On Mon, Feb 11, 2019 at 08:08:38PM -0600, Wart wrote: > As per > https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package > > ...I will be taking ownership of the rogue package. I was actually the > maintainer for this package many years

Re: Orphaned packages that will be retired (and everything will most likely burn)

On Tue, Feb 12, 2019 at 12:16 PM Fabio Valentini wrote: > > On Tue, Feb 12, 2019 at 12:08 PM Miro Hrončok wrote: > > > > On 12. 02. 19 11:46, Fabio Valentini wrote: > > >> (I know anyone can unbreak it by claiming the packages, but that's not > > >> the point > > >> here.) > > > > > > Miro, am I

[Bug 1664030] perl-Class-DBI-Plugin-Type-0.02-35.fc30 FTBFS: tests fail with perl-DBD-SQLite-1.62-1.fc30

https://bugzilla.redhat.com/show_bug.cgi?id=1664030 --- Comment #2 from Petr Pisar --- Debian provided a fix in the bug report at CPAN. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-d

Re: Orphaned packages that will be retired (and everything will most likely burn)

On Tue, Feb 12, 2019 at 11:56 AM Tom Hughes wrote: > Java and everything java related (like ant) is now modular only > and has been orphaned in the non-modular rawhide. That's totally not true. There are about 1.4k source Java packages, but there are less that 200 modular Java source packages. No

Re: gcc-c++ and libatomic -- link issues

On 12/02/19 10:55 +0100, Jakub Jelinek wrote: On Tue, Feb 12, 2019 at 09:49:23AM +, Jonathan Wakely wrote: On that basis, why does gcc-c++ install libgomp and libgfortran? I think gcc-c++ doesn't require libgfortran, gcc-gfortran does. Ah yes, sorry. I ran 'mock -r fedora-rawhide-x86_64

Re: Orphaned packages that will be retired (and everything will most likely burn)

On 12/02/2019 11:46, Mikolaj Izdebski wrote: On Tue, Feb 12, 2019 at 11:56 AM Tom Hughes wrote: Java and everything java related (like ant) is now modular only and has been orphaned in the non-modular rawhide. That's totally not true. There are about 1.4k source Java packages, but there are l

Re: Orphaned packages that will be retired (and everything will most likely burn)

It won't help because you didn't take the build dependencies of ant/maven… On Tue, Feb 12, 2019 at 12:51 PM Fabio Valentini wrote: > On Tue, Feb 12, 2019 at 12:16 PM Fabio Valentini > wrote: > > > > On Tue, Feb 12, 2019 at 12:08 PM Miro Hrončok > wrote: > > > > > > On 12. 02. 19 11:46, Fabio V

[Bug 1675623] perl-File-MMagic-XS: FTBFS in Fedora rawhide/f30

https://bugzilla.redhat.com/show_bug.cgi?id=1675623 Petr Pisar changed: What|Removed |Added Status|NEW |CLOSED CC|

Re: F30 change: update mercurial to version 4.9

Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Feb 11, 2019 at 09:19:08AM -0500, Neal Becker wrote: >> I'm proposing to update to mercurial 4.9 for F30. > > What is the effect on those dependent packages? How many need > adjustments? > > Zbyszek tortoisehg for sure won't run until it is updated,

Re: F30 change, bootloaderspec by default

Hello Chris, Sorry for the late response but I was on vacation last week. On Sun, Feb 10, 2019 at 8:06 PM Chris Murphy wrote: > > On Wed, Feb 6, 2019 at 1:08 AM Javier Martinez Canillas > wrote: > > > > On Wed, Feb 6, 2019 at 5:28 AM Chris Murphy wrote: > > > > > > https://fedoraproject.org/wi

Re: Orphaned packages that will be retired (and everything will most likely burn)

Le 2019-02-12 11:43, Adam Samalik a écrit : I might be missing something here, so excuse me if that's obvious, but wouldn't this happen without Modularity anyway? I mean, how does Modularity relate to packages being orphaned? Or is that because they have been moved out into modules and their mai

Re: F30 change, bootloaderspec by default

Hello Nicolas, On Mon, Feb 11, 2019 at 1:41 PM Nicolas Mailhot wrote: > > Le 2019-02-10 20:05, Chris Murphy a écrit : > > On Wed, Feb 6, 2019 at 1:08 AM Javier Martinez Canillas > > > Between this feature for F30, and the F29 feature to hide the grub > > menu which comes with boot success+fail ma

Re: F30 change, bootloaderspec by default

On Mon, Feb 11, 2019 at 8:53 PM Chris Murphy wrote: > > On Mon, Feb 11, 2019 at 5:40 AM Nicolas Mailhot > wrote: > > [snip] > > > > FYI I had to rescue two EFI rawhide system this week-end borked by grub > > changes. As far as I could reconstruct: > > > > 1. the new grub needs the env file to b

Re: F30 change, bootloaderspec by default

Le 2019-02-12 13:32, Javier Martinez Canillas a écrit : Hi Javier I didn't get how it will break the symlink. You get a "environment block too small" on kernel update You type "environment block too small" in google because you want the update to work You get some ubuntu advice that says "

Re: F30 change, bootloaderspec by default

Hello Nicolas, On Tue, Feb 12, 2019 at 2:58 PM Nicolas Mailhot wrote: > > Le 2019-02-12 13:32, Javier Martinez Canillas a écrit : > Hi Javier > > > I didn't get how it will break the symlink. > > You get a "environment block too small" on kernel update > > You type "environment block too small" i

Re: Blocking criteria proposal for F30+: Printing

Hi, comments are in the text: On 2/11/19 9:17 PM, Stephen Gallagher wrote: > On Mon, Feb 11, 2019 at 2:24 PM Chris Murphy wrote: >> On Mon, Feb 11, 2019 at 9:58 AM Stephen Gallagher >> wrote: >>> Sorry that it's taken me so long to get back to this. >>> >>> I think the feedback on this has bee

Re: F30 change, bootloaderspec by default

On 12/02/2019 14:10, Javier Martinez Canillas wrote: I see, I would had thought that the advice would had been to use grub-editenv create instead. But still grub2-editenv create will only prevent removing the symlink, it won't help with the issue of the kernelopts variable not being set. We sho

Re: rpmlint: library-not-linked-against-libc (parts of Python stdlib, after gcc 9)

On Mon, 2019-02-11 at 18:47 +0100, Florian Weimer wrote > If you take the address of a local variable and pass the resulting > pointer to another function, the compiler will generate a call to > __stack_chk_fail, which lives in glibc. At build time, linking > against > glibc is required so that th

Re: rpmlint: library-not-linked-against-libc (parts of Python stdlib, after gcc 9)

* Marcel Plch: > On Mon, 2019-02-11 at 18:47 +0100, Florian Weimer wrote >> If you take the address of a local variable and pass the resulting >> pointer to another function, the compiler will generate a call to >> __stack_chk_fail, which lives in glibc. At build time, linking >> against >> glibc

Re: rpmlint: library-not-linked-against-libc (parts of Python stdlib, after gcc 9)

On Tue, 2019-02-12 at 15:35 +0100, Florian Weimer wrote: > * Marcel Plch: > > > On Mon, 2019-02-11 at 18:47 +0100, Florian Weimer wrote > > > If you take the address of a local variable and pass the > > > resulting > > > pointer to another function, the compiler will generate a call to > > > __sta

Re: rpmlint: library-not-linked-against-libc (parts of Python stdlib, after gcc 9)

* Marcel Plch: > So rather than: > "Python extension modules don't need to be linked against libc as they > are never actually loaded on their own, but rather from the Python > interpreter," > we can say: > "Some Python extension modules don't need to be linked against glibc > under such condition

Re: rpmlint: library-not-linked-against-libc (parts of Python stdlib, after gcc 9)

On Tue, 2019-02-12 at 15:52 +0100, Florian Weimer wrote: > * Marcel Plch: > > > So rather than: > > "Python extension modules don't need to be linked against libc as > > they > > are never actually loaded on their own, but rather from the Python > > interpreter," > > we can say: > > "Some Python e

Re: Fedora 30 Mass Rebuild

Anderson, Charles R wrote: > On Mon, Feb 04, 2019 at 03:48:59PM -0500, Mohan Boddu wrote: >> Per the Fedora 30 schedule[1] we started a mass rebuild for Fedora 30 >> on Jan 31st 2019. We did a mass rebuild for Fedora 30 for the changes >> listed in: >> >> https://pagure.io/releng/issue/8086 >> >

python-cherrypy vs python3-cherrypy - can we keep just one?

Hi python packagers, Could someone please help me understand why we have python-cherrypy and python3-cherrypy as two separate Fedora packages? https://src.fedoraproject.org/rpms/python-cherrypy https://src.fedoraproject.org/rpms/python3-cherrypy It seems to me that "python3-cherrypy" should be r

REMINDER: F30 Code complete (testable) deadline in one week

According to the Fedora 30 schedule[1], the deadline for Changes to be code complete (i.e. testable enough for beta) is Tuesday 19 February. At this time, all Changes should be testable and tracker bugs should be set to the MODIFIED state. For more information on this deadline, see the wiki[2]. [1

Orphaned package: python-rdflib

I no longer use python-rdflib, and I don't have the time to maintain it, so I've marked it as orphaned. Dave ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduc

Release fedpkg-1.36

Hi all, a new version fedpkg-1.36 is released. This is mostly a bugfix update with some improvements. Most notable changes are: support for flatpack namespace (flatpaks will be added as a separate namespace in Fedora dist-git) fedpkg update will work for containers Other changes, bugfix

Attempting to fix hyperscan FTBFS

Hi All, I am looking at the FTBFS for hyperscan[0] and need some assistance. From what I can tell it looks like this may be related to the --as- needed linker change. The reason I say it may be related to the linking change is I can build the 5.1.0 release against the fedora-29-x86_64 mock profil

Re: python-cherrypy vs python3-cherrypy - can we keep just one?

Hi, Am 12.02.19 um 18:35 schrieb Ken Dreyer: > Could someone please help me understand why we have python-cherrypy > and python3-cherrypy as two separate Fedora packages? That reason is recorded in the review request for python3-cherrypy: "Upstream are releasing separate tarballs for Python 2 an

Re: Attempting to fix hyperscan FTBFS

‐‐‐ Original Message ‐‐‐ On Tuesday, February 12, 2019 2:42 PM, jt wrote: > Hi All, > > I am looking at the FTBFS for hyperscan[0] and need some assistance. > From what I can tell it looks like this may be related to the --as- > needed linker change. > > The reason I say it may be re

Re: Attempting to fix hyperscan FTBFS

On 12/02/2019 20:42, jt wrote: I am looking at the FTBFS for hyperscan[0] and need some assistance. From what I can tell it looks like this may be related to the --as- needed linker change. Why do you think that? The koji log shows that it is failing because it is asking for pcre 8.41 and won

Re: Attempting to fix hyperscan FTBFS

Looking at the build log, it seems to be checking for 'libpcre = 8.41', but the build root has 8.43-RC1 which causes the build to error out. Pete 12.02.2019, 20:43, "jt" : > Hi All, > > I am looking at the FTBFS for hyperscan[0] and need some assistance. > From what I can tell it looks like this

Re: Attempting to fix hyperscan FTBFS

On Tue, 2019-02-12 at 21:06 +, Pete Walter wrote: > Looking at the build log, it seems to be checking for 'libpcre = > 8.41', but the build root has 8.43-RC1 which causes the build to > error out. > > Pete > > 12.02.2019, 20:43, "jt" : > > Hi All, > > > > I am looking at the FTBFS for hypers

Re: Attempting to fix hyperscan FTBFS

On Tue, 2019-02-12 at 16:13 -0500, jt wrote: > On Tue, 2019-02-12 at 21:06 +, Pete Walter wrote: > > Looking at the build log, it seems to be checking for 'libpcre = > > 8.41', but the build root has 8.43-RC1 which causes the build to > > error out. > > > > Pete > > > > 12.02.2019, 20:43, "jt

Re: F30 change, bootloaderspec by default

On Tue, Feb 12, 2019, 7:10 AM Javier Martinez Canillas > I see, I would had thought that the advice would had been to use > grub-editenv create instead. But still grub2-editenv create will only > prevent removing the symlink, it won't help with the issue of the > kernelopts variable not being set.

Re: Attempting to fix hyperscan FTBFS

12.02.2019, 21:16, "jt" : > On Tue, 2019-02-12 at 16:13 -0500, jt wrote: >>  On Tue, 2019-02-12 at 21:06 +, Pete Walter wrote: >>  > Looking at the build log, it seems to be checking for 'libpcre = >>  > 8.41', but the build root has 8.43-RC1 which causes the build to >>  > error out. >>  > >>

Re: Attempting to fix hyperscan FTBFS

12.02.2019, 21:16, "jt" : > On Tue, 2019-02-12 at 16:13 -0500, jt wrote: >>  On Tue, 2019-02-12 at 21:06 +, Pete Walter wrote: >>  > Looking at the build log, it seems to be checking for 'libpcre = >>  > 8.41', but the build root has 8.43-RC1 which causes the build to >>  > error out. >>  > >>

Re: Attempting to fix hyperscan FTBFS

> This log has "-mtune=option: not valid". I guess something has changed > here with gcc 9 that the cmake script doesn't like? I've tailored a patch for CMakeLists.txt to fix the build [1]. If you agree, I'll push to SCM (including update to v5.1.0) and build it. Björn [1] https://koji.fedor

Re: F30 change, bootloaderspec by default

On Tue, Feb 12, 2019 at 2:18 PM Chris Murphy wrote: > > In the short term it means any features depending on writing to grubenv from > pre-boot GRUB (as opposed to Linux user space GRUB tools), can only be > expected on UEFI (grubenv is always on FAT), or if on BIOS only with default > (automat

Re: F30 change, bootloaderspec by default

On Tue, Feb 12, 2019 at 2:34 PM Chris Murphy wrote: > > If grubenv can be change from pre-boot environment, we can't correctly > determine if boot has succeeded or failed. s/can/can't s/change/changed (grubenv can't be changed in certain custom partitioning cases e.g. /boot on Btrfs or /boot on

Re: Attempting to fix hyperscan FTBFS

On Tue, Feb 12, 2019, 16:35 Björn 'besser82' Esser < besse...@fedoraproject.org> wrote: > > This log has "-mtune=option: not valid". I guess something has changed > > here with gcc 9 that the cmake script doesn't like? > > > I've tailored a patch for CMakeLists.txt to fix the build [1]. If you >

Re: Attempting to fix hyperscan FTBFS

Am Dienstag, den 12.02.2019, 16:40 -0500 schrieb Jason Taylor: > > > On Tue, Feb 12, 2019, 16:35 Björn 'besser82' Esser < > besse...@fedoraproject.org> wrote: > > > This log has "-mtune=option: not valid". I guess something has > > changed > > > here with gcc 9 that the cmake script doesn't like?

Re: Orphaned packages that will be retired (and everything will most likely burn)

On Monday, 11 February 2019 at 18:12, Paolo Bonzini wrote: > On 11/02/19 17:57, Miro Hrončok wrote: > > The following packages are orphaned and will be retired when they > > are orphaned for six weeks, unless someone adopts them. If you know for > > sure > > that the package should be retired, plea

Re: GCC 9 OpenMP issues

On 2/12/19 1:02 AM, Jakub Jelinek wrote: On Mon, Feb 11, 2019 at 07:17:25PM -0700, Orion Poplawski wrote: Looks like GCC 9 is finally enforcing an OpenMP change: From https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00628.html Please see https://gcc.gnu.org/gcc-9/porting_to.html#ompdatasharing

plplot 5.14.0 coming to rawhide

I'm building plplot 5.14.0 for rawhide. This involves a soname bump. I'll be rebuilding the dependent packages when it's complete: gdl psfex scamp -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell La

Re: Policy regarding service preset enabled (e.g. performance co-pilot)

Hi, Georg Sauthoff writes: [...] > Yes, I'm asserting this and I already asserted it in my original mail. Sorry about that, it was a bug in the pcp spec file and how we were handling pmcd/pmlogger's configuration. Thanks for catching it! I've submitted a fedora update to fix this and disable l

Fedora Rawhide-20190212.n.1 compose check report

No missing expected images. Compose FAILS proposed Rawhide gating check! 5 of 47 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Unsatisfied gating requirements that could not be mapped to openQA tests: FAILED: compose.cloud.all Failed open

openmpi 3.1.3?

I'm thinking about trying to sneak in openmpi 3.1.3 before the f30 branch. My COPR rebuilds have been looking pretty good lately so I hope it will go fairly smoothly. Does anyone have any objections? I'm planning on starting tomorrow if not. - Orion -- Orion Poplawski Manager of NWRA Techn

Re: Orphaned packages to be retired

On Mon, Feb 11, 2019 at 5:44 PM Vít Ondruch wrote: > Dne 11. 02. 19 v 4:33 Jens-Ulrik Petersen napsal(a): > > I have to say I am not really enjoying this ongoing aggressive package > retirement process. > If packages are not broken and needed by other packages, then I don't see > why we are hurry

Re: Proposal: Stewardship Group / SIG for taking care of otherwise "module-only" packages

Fabio Valentini wrote: >In the past few weeks, it has come up regularly that future >"module-only" packages are orphaned (and hence will soon be retired), >and nobody stepped up to fix this issue - especially for non-leaf >packages. I don't think fedora as a project has a solution for this >yet. W