Re: Orphaned packages to be retired (Java packages in 3 weeks)

On Wed, Mar 13, 2019, 07:42 Alexander Bokovoy wrote: > On ke, 13 maalis 2019, Fabio Valentini wrote: > >On Tue, Mar 12, 2019, 22:37 Mikolaj Izdebski wrote: > > > >> On Tue, Mar 12, 2019 at 12:17 PM Dominik 'Rathann' Mierzejewski > >> wrote: > >> > > >> > On Tuesday, 12 March 2019 at 12:02, Miko

gcc again only on i686 and f29+ hidden symbol cpu_model referenced by dso

Hi, Today [1] , I have updated libprojectM package with new autotools builds (developer changed etc). It builds fine in F28 on i686 but not in F29 or newer. After read [2] it exactly the same problem, only added -shared fix the build, not -lgcc etc ... I tried build on i686 with [3] but confi

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

On 13/03/2019 03:27, Huzaifa Sidhpurwala wrote: On 3/12/19 5:40 PM, Vít Ondruch wrote: Will it help to mitigate issues such as: https://bugzilla.redhat.com/show_bug.cgi?id=1284684 This is related to the following change which was made in Fedora 23: https://fedoraproject.org/wiki/Changes/Hard

Re: Orphaned packages to be retired (Java packages in 3 weeks)

Hi, On 12-03-19 11:38, 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, please do so now with a proper reason: https://fedoraproject.org/wiki/How_

Re: Blocking criteria proposal for F30+: Printing

On 3/12/19 11:28 PM, Chris Murphy wrote: > On Tue, Mar 12, 2019 at 2:53 AM Zdenek Dohnal wrote: >> IMHO Stephen meant it as driverless 'driver' or IPP everywhere enabled >> printer, since 'generic IPP driver' does not exist. > OK. > >>> What supports IPP Everywhere out of the box? >>> >>> Any comp

Re: Orphaned packages to be retired (Java packages in 3 weeks)

* Hans de Goede [13/03/2019 08:51] : > > A solution for this needs to be found and be in place *before* dropping > these packages not the otherway around. We've known the solution for months, now. If you (this is the generic you, not you specifically) want these packages to be in the distribution

Re: Orphaned packages to be retired (Java packages in 3 weeks)

On Tue, 2019-03-12 at 21:24 +0100, Mikolaj Izdebski wrote: > On Tue, Mar 12, 2019 at 3:11 PM Jakub Jelen > wrote: > > On Tue, 2019-03-12 at 13:43 +0200, Aleksandar Kurtakov wrote: > > > Hmm, > > > https://lists.fedoraproject.org/archives/list/java-de...@lists.fedoraproject.org/thread/MQMRQVENBLDRS

Re: gcc again only on i686 and f29+ hidden symbol cpu_model referenced by dso

* Sérgio Basto: > [3] > export LDFLAGS="%{?__global_ldflags} -shared" Not sure why you think this would work. It prevents the compiler from creating any executables at all. The problem is earlier, here: libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/i686-redhat-linux/9/../../.

Re: Updating Rawhide vs GPG keys

On 11/03/19 18:05 +0100, Jan Pokorný wrote: > On 11/03/19 15:01 +0100, Jan Pokorný wrote: >> On 11/03/19 12:31 +0100, Vít Ondruch wrote: >>> Can somebody please enlighten me, how to update Rawhide after branching >>> and not using --nogpgcheck? >> >> Good question; have observed this over several

Re: Orphaned packages to be retired (Java packages in 3 weeks)

Hi, On 3/13/19 9:45 AM, Emmanuel Seyman wrote: * Hans de Goede [13/03/2019 08:51] : A solution for this needs to be found and be in place *before* dropping these packages not the otherway around. We've known the solution for months, now. If you (this is the generic you, not you specifically

Re: Issue with an update, need advice Re: [Fedora Update] [comment] papirus-icon-theme-20190302-1.fc30

On mardi 12 mars 2019 08:11:47 CET Panu Matilainen wrote: > On 3/12/19 6:07 AM, Robert-André Mauchin wrote: > > > Hello, > > > > I have an issue with the update of papirus-icon-theme: in the new version, > > symlinks have replaced what was previously folders and dnf errors out on > > this: > >

Re: Orphaned packages to be retired (Java packages in 3 weeks)

On Wed, Mar 13, 2019 at 7:21 AM Fabio Valentini wrote: > Can you give us a minimal set of packages that is required to make sure > libreoffice etc. aren't caught up in the mass retirement? The minimal package set is the contents of javapackages-tools module, stream 201801. There are about 185 pa

Re: Updating Rawhide vs GPG keys

Dne 12. 03. 19 v 19:49 Kevin Fenzi napsal(a): > We need to revamp this entirely, and as luck would have it, we have a plan: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5UVGSBRLX352A4S2CBZ2CGBXPAGQTYKB/ I am afraid that this will not help in this situatio

Re: Updating Rawhide vs GPG keys

Ok, so the process which worked for me was: ~~~ $ sudo dnf update https://kojipkgs.fedoraproject.org/packages/fedora-repos/30/0.5/data/signed/cfc659b9/noarch/fedora-{gpg-keys,repos{,-rawhide}}-30-0.5.noarch.rpm $ sudo dnf update --enablerepo=rawhide fedora-gpg-keys --release 31 ~~~ But what

Re: Issue with an update, need advice Re: [Fedora Update] [comment] papirus-icon-theme-20190302-1.fc30

On mercredi 13 mars 2019 11:16:51 CET you wrote: > > It seems the lua part executed correctly as the folders got moved to > .rpmmoved but the rest of the transaction fails. > > Did I miss something? > > Thanks, > > Robert-André Ha nevermind, it seems I had missed a directory.

Re: Orphaned packages to be retired (Java packages in 3 weeks)

* Mikolaj Izdebski: > On Tue, Mar 12, 2019 at 4:42 PM Miroslav Suchý wrote: >> Alternative sum up: >> * People (not just Mikolaj) started using modules, while Koji cannot use >> modular repos. > > Incorrect. Koji (the software) *can* use modular repos. I know of more > than one installation of K

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

* Tom Hughes: > On 13/03/2019 03:27, Huzaifa Sidhpurwala wrote: > >> On 3/12/19 5:40 PM, Vít Ondruch wrote: >>> Will it help to mitigate issues such as: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1284684 >>> >> This is related to the following change which was made in Fedora 23: >> https:

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/HardenedCompiler > > == Summary == > By Default enable a few security hardening flags which are used with GCC. I'm strongly against this, the reasons have been explained multiple times. We have a

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

On 13/03/2019 11:11, Florian Weimer wrote: * Tom Hughes: On 13/03/2019 03:27, Huzaifa Sidhpurwala wrote: On 3/12/19 5:40 PM, Vít Ondruch wrote: Will it help to mitigate issues such as: https://bugzilla.redhat.com/show_bug.cgi?id=1284684 This is related to the following change which was ma

Re: Orphaned packages to be retired (Java packages in 3 weeks)

On Wed, Mar 13, 2019 at 11:59 AM Florian Weimer wrote: > > * Mikolaj Izdebski: > > > On Tue, Mar 12, 2019 at 4:42 PM Miroslav Suchý wrote: > >> Alternative sum up: > >> * People (not just Mikolaj) started using modules, while Koji cannot use > >> modular repos. > > > > Incorrect. Koji (the softw

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

On Wed, Mar 13, 2019 at 12:19 PM Jakub Jelinek wrote: > > On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/HardenedCompiler > > > > == Summary == > > By Default enable a few security hardening flags which are used with GCC. > > I'm strongly aga

Re: Orphaned packages to be retired (Java packages in 3 weeks)

* Mikolaj Izdebski: >> As far as I understand it, under the Koji model, one of the tags wins, >> and which one determines whether you get the Python 2 subpackage or the >> Python 3 subpackage. You cannot get both. You will need two or more >> buildroots for that. > > That used to be the case, bu

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

On Wed, Mar 13, 2019 at 12:38:02PM +0100, Dridi Boukelmoune wrote: > On Wed, Mar 13, 2019 at 12:19 PM Jakub Jelinek wrote: > > > > On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/HardenedCompiler > > > > > > == Summary == > > > By Default en

Re: Orphaned packages to be retired (Java packages in 3 weeks)

On Wed, Mar 13, 2019 at 12:49 PM Florian Weimer wrote: > > * Mikolaj Izdebski: > > >> As far as I understand it, under the Koji model, one of the tags wins, > >> and which one determines whether you get the Python 2 subpackage or the > >> Python 3 subpackage. You cannot get both. You will need t

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/HardenedCompiler > > == Summary == > By Default enable a few security hardening flags which are used with GCC. > > == Owner == > * Name: [[User:huzaifas|Huzaifa Sidhpurwala]] > * Email: huzai...@r

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

On 13/03/2019 12:00, Daniel P. Berrangé wrote: On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote: | 1 || -Wformat || Check calls to "printf" and "scanf", etc., to make sure that the arguments supplied have types appropriate to the format string specified, and that the conversions speci

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

On Wed, Mar 13, 2019 at 12:21:29PM +, Tom Hughes wrote: > On 13/03/2019 12:00, Daniel P. Berrangé wrote: > > On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote: > > > > > | 1 || -Wformat || Check calls to "printf" and "scanf", etc., to make > > > sure that the arguments supplied have t

/etc/yum.repos.d -> /etc/distro.repos.d

Hi, I am curious whether we can move our repo files from /etc/yum.repos.d to /etc/distro.repos.d In Fedora 31 we are going to wipe away last left overs of YUM, so it really does not have sense to keep `yum.repos.d`. DNF for ages parse config files from: {"/etc/yum.repos.d", "/etc/yum/repos

Re: /etc/yum.repos.d -> /etc/distro.repos.d

On Wed, Mar 13, 2019 at 8:39 AM Miroslav Suchý wrote: > > Hi, > I am curious whether we can move our repo files from > /etc/yum.repos.d > to > /etc/distro.repos.d > > In Fedora 31 we are going to wipe away last left overs of YUM, so it really > does not have sense to keep `yum.repos.d`. > > D

Re: /etc/yum.repos.d -> /etc/distro.repos.d

On 3/13/19 13:38, Miroslav Suchý wrote: Hi, I am curious whether we can move our repo files from /etc/yum.repos.d to /etc/distro.repos.d In Fedora 31 we are going to wipe away last left overs of YUM, so it really does not have sense to keep `yum.repos.d`. DNF for ages parse config files

[modularity] Bringing order to the confusing module stream and profile names

There are module streams named 'latest', 'stable', or 'master', but it's not quite clear what exactly those mean. Some modules even have the 'master' and the 'latest' streams at the same time which feels quite confusing. In a similar manner, there are various unclear profile names, too. Especially

Re: Downgrading glibc from Rawhide removed /bin/sh (!)

* Panu Matilainen: >> I had already raised the issue with the symbolic links upstream (as I >> said, my memory is failing), and feedback was not exactly positive: >> >> >> >> In fact, Siddhesh suggested using *more* symbolic links: >>

Re: /etc/yum.repos.d -> /etc/distro.repos.d

On Wed, Mar 13, 2019 at 1:42 PM Neal Gompa wrote: > > On Wed, Mar 13, 2019 at 8:39 AM Miroslav Suchý wrote: > > > > Hi, > > I am curious whether we can move our repo files from > > /etc/yum.repos.d > > to > > /etc/distro.repos.d Why not /etc/dnf/repos.d and a symlink for /etc/yum.repos.d? >

Re: /etc/yum.repos.d -> /etc/distro.repos.d

Dne 13. 03. 19 v 14:03 Dridi Boukelmoune napsal(a): > Why not /etc/dnf/repos.d and a symlink for /etc/yum.repos.d? Currently DNF reads both of them. So you will end with duplicate repositories, because DNF would see them twice. Miroslav ___ devel maili

Re: Updating Rawhide vs GPG keys

On Tue, Mar 12, 2019, at 2:50 PM, Kevin Fenzi wrote: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5UVGSBRLX352A4S2CBZ2CGBXPAGQTYKB/ > > How does this plan work with silverblue? Not sure... could use some > input from them. It's the same model for Fedora

Re: Orphaned packages to be retired (Java packages in 3 weeks)

On Tue, 2019-03-12 at 18:39 -0400, Christopher wrote: > Well, the packager experience I'm expecting in 3 weeks is: "almost > all > of my dependencies and BuildRequires are gone; I can't build > anything". > How much worse could it get than that? Fair. I don't think we anticipated the large migrati

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

On 3/13/19 6:52 AM, Jakub Jelinek wrote: Not to mention that -D__FORTIFY_SOURCE=2 rejects some valid C programs, so gcc would be no longer standard compliant (and e.g. glibc headers warn about it when used with -O0). +1, Wine breaks with fortify set to 2. I hope Huzaifa takes your opinion to h

Re: Chromium C++ help needed

I tried removing some of the compiler flags to see if I could identify what might be triggering this, and removing "-fno-delete-null-pointer-checks" seems to make this error vanish. Not sure if that helps or not, but hopefully, I can get this beast building without it. Thanks, Tom On Mon, Mar 11

Re: /etc/yum.repos.d -> /etc/distro.repos.d

Dne 13. 03. 19 v 13:50 Kalev Lember napsal(a): > Please don't, it's just pointless renaming that invalidates all end user > documentation and makes it harder for other programs such as packagekit > and gnome-software that all need to adopt for the new paths. Not exactly true. When documentaion st

Re: Chromium C++ help needed

On Wed, Mar 13, 2019 at 10:28:29AM -0400, Tom Callaway wrote: > I tried removing some of the compiler flags to see if I could identify what > might be triggering this, and removing "-fno-delete-null-pointer-checks" > seems to make this error vanish. -fno-delete-null-pointer-checks is certainly an

EPEL: Python34 moving to Python36

Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George, and several helpers have gotten nearly all of the python34 packages moves over to python36 in EPEL-7. They are being included in 6 Bodhi pushes because of a limitation in Bodhi for the text size of packages in an include. The c

Re: /etc/yum.repos.d -> /etc/distro.repos.d

On Wed, 13 Mar 2019 at 14:37, Miroslav Suchý wrote: > > Dne 13. 03. 19 v 13:50 Kalev Lember napsal(a): > > ..makes it harder for other programs such as packagekit > > and gnome-software that all need to adopt for the new paths. > Not exactly true. It's completely true, Kalev is spot on. GNOME Sof

Re: /etc/yum.repos.d -> /etc/distro.repos.d

Le mer. 13 mars 2019 à 13:39, Miroslav Suchý a écrit : > > Hi, > I am curious whether we can move our repo files from > /etc/yum.repos.d > to > /etc/distro.repos.d I don't see the point to "change" this directory for "pleasure" if it doesn't come with more features. Right now yum.repos.d shou

Re: /etc/yum.repos.d -> /etc/distro.repos.d

On Wed, Mar 13, 2019 at 7:50 AM, Kalev Lember wrote: Please don't, it's just pointless renaming that invalidates all end user documentation and makes it harder for other programs such as packagekit and gnome-software that all need to adopt for the new paths. Handling a rename is not exactly

Re: /etc/yum.repos.d -> /etc/distro.repos.d

On Wed, Mar 13, 2019 at 10:37 AM Miroslav Suchý wrote: > > Dne 13. 03. 19 v 13:50 Kalev Lember napsal(a): > > Please don't, it's just pointless renaming that invalidates all end user > > documentation and makes it harder for other programs such as packagekit > > and gnome-software that all need to

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

Daniel P. Berrangé wrote: > I wonder why this change is suggesting to add the flags if they > are already present in our current optflags ? Obviously because Fedora's packaged GCC is used in more use cases than just building Fedora packages, and Fedora's RPM macros aren't typically applied to the

Re: /etc/yum.repos.d -> /etc/distro.repos.d

On 3/13/19 4:03 PM, mcatanz...@gnome.org wrote: > On Wed, Mar 13, 2019 at 7:50 AM, Kalev Lember > wrote: >> Please don't, it's just pointless renaming that invalidates all end user >> documentation and makes it harder for other programs such as packagekit >> and gnome-software that all need to ado

Re: EPEL: Python34 moving to Python36

Hello, On Wed, Mar 13, 2019 at 3:37 PM Stephen John Smoogen wrote: > > Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George, > and several helpers have gotten nearly all of the python34 packages > moves over to python36 in EPEL-7. They are being included in 6 Bodhi > pushes becau

Sphinx and xindy

I have been working on an update for coq 8.9.0 in Rawhide. A mock build fails when building the documentation: Latexmk: applying rule 'makeindex CoqRefMan.idx'... Running 'internal xindy -L english -C utf8 -M sphinx.xdy -o "CoqRefMan.ind" "CoqRefMan.idx"' Latexmk: call

Re: Chromium C++ help needed

The odd thing is that this compiler flag is hardcoded into the build by the upstream. I'm wondering why Fedora hits this when no one else seems to. I mean, I'm fine to disable it, because the Chromium codebase is a tomb of horrors anyway, and if I have to sacrifice that flag to make it happy, so b

Re: Chromium C++ help needed

On Wed, Mar 13, 2019 at 12:49:35PM -0400, Tom Callaway wrote: > The odd thing is that this compiler flag is hardcoded into the build by the > upstream. I'm wondering why Fedora hits this when no one else seems to. > > I mean, I'm fine to disable it, because the Chromium codebase is a tomb of > hor

Re: Chromium C++ help needed

On Wed, Mar 13, 2019 at 11:53 AM, Jakub Jelinek wrote: calling methods on NULL pointers to objects etc. Chromium probably does this (or, at least, did in the past). Removing -fno-delete-null-pointer-checks could introduce Fedora-specific crashes. Michael

Re: Orphaned packages to be retired (Java packages in 3 weeks)

On Wed, Mar 13, 2019 at 10:07 AM Randy Barlow wrote: > > On Tue, 2019-03-12 at 18:39 -0400, Christopher wrote: > > Well, the packager experience I'm expecting in 3 weeks is: "almost > > all > > of my dependencies and BuildRequires are gone; I can't build > > anything". > > How much worse could it

Re: Chromium C++ help needed

On 13/03/2019 17:03, mcatanz...@gnome.org wrote: On Wed, Mar 13, 2019 at 11:53 AM, Jakub Jelinek wrote: calling methods on NULL pointers to objects etc. Chromium probably does this (or, at least, did in the past). Removing -fno-delete-null-pointer-checks could introduce Fedora-specific crash

Re: /etc/yum.repos.d -> /etc/distro.repos.d

Miroslav Suchý wrote: > I am curious whether we can move our repo files from > /etc/yum.repos.d > to > /etc/distro.repos.d Please, no. Sysadmins don't like having to change their habits, scripts and documents for no benefit because somebody renamed something just for the sake of renaming. Poin

Re: Orphaned packages to be retired (Java packages in 3 weeks)

On Wed, Mar 13, 2019 at 6:23 AM Mikolaj Izdebski wrote: > > On Wed, Mar 13, 2019 at 7:21 AM Fabio Valentini wrote: > > Can you give us a minimal set of packages that is required to make sure > > libreoffice etc. aren't caught up in the mass retirement? > > The minimal package set is the contents

Re: /etc/yum.repos.d -> /etc/distro.repos.d

mcatanz...@gnome.org wrote: > On Wed, Mar 13, 2019 at 7:50 AM, Kalev Lember > wrote: > > Also, I've heard rumours that dnf might get renamed back to yum in the > > future. > > Do the dnf developers know about this rumor...? In recent Fedora releases DNF has stopped complaining when it's invok

No builds of v8-314 for f30 and f31

Hello, I am wondering what is the status of v8-314. In koji there are some failed builds for f30. New builds are required because readline was updated to a new version, thus Fedora 29 version is not able to install. Error: nothing provides libreadline.so.7()(64bit) needed by v8-314-3.14.5.10-1

Re: /etc/yum.repos.d -> /etc/distro.repos.d

If anything of the like, /etc/dnf.repos.d makes more sense. These repos are not necessarily part of the distro. On March 13, 2019 11:46:12 AM EDT, Theodore Papadopoulo wrote: >On 3/13/19 4:03 PM, mcatanz...@gnome.org wrote: >> On Wed, Mar 13, 2019 at 7:50 AM, Kalev Lember >> wrote: >>> Please

Re: No builds of v8-314 for f30 and f31

On Wed, 2019-03-13 at 17:30 +, Samuel Rakitničan wrote: > Hello, > > I am wondering what is the status of v8-314. In koji there are some > failed builds for f30. New builds are required because readline was > updated to a new version, thus Fedora 29 version is not able to > install. > > Error

Re: [modularity] Bringing order to the confusing module stream and profile names

On Wed, Mar 13, 2019 at 8:55 AM Adam Samalik wrote: > > There are module streams named 'latest', 'stable', or 'master', but it's not > quite clear what exactly those mean. Some modules even have the 'master' and > the 'latest' streams at the same time which feels quite confusing. > > In a simila

Re: /etc/yum.repos.d -> /etc/distro.repos.d

On Wed, 13 Mar 2019 at 08:51, Kalev Lember wrote: > > Also, I've heard rumours that dnf might get renamed back to yum in the > future. > I just hope that dnf gets renamed to something easier. It doesn't stick as good as yum, apt or pacman. Anything other than yum will be a lot of work though. Orc

Re: Help us test FedoraReview on Python 3

On Fri, Mar 8, 2019 at 12:29 PM Miro Hrončok wrote: > > There is a FedoraReview port to Python 3 that needs real word testing by > packagers. > > When you use FedoraReview, please use the Python 3 port instead to help us > find > bugs. > > Instructions are at https://pagure.io/FedoraReview/pull-

Re: /etc/yum.repos.d -> /etc/distro.repos.d

On Wed, 2019-03-13 at 13:38 +0100, Miroslav Suchý wrote: > Hi, > I am curious whether we can move our repo files from > /etc/yum.repos.d > to > /etc/distro.repos.d > > In Fedora 31 we are going to wipe away last left overs of YUM, so it really > does not have sense to keep `yum.repos.d`. > >

Re: /etc/yum.repos.d -> /etc/distro.repos.d

Dridi Boukelmoune wrote: > Why not /etc/dnf/repos.d and a symlink for /etc/yum.repos.d? Please no, that will introduce it's own set of problems as well. -- Rex ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to deve

Re: Allowing Epoch to be reset between releases

> "ZJ" == Zbigniew Jędrzejewski-Szmek writes: ZJ> This doesn't sound convincing at all. I was not attempting to be convincing. ZJ> We *know* that people miss announcements all the time. Dropping ZJ> epochs would introduce yet another case where a "magical" step is ZJ> needed at a specific t

Re: Orphaned packages to be retired (Java packages in 3 weeks)

On 13. 03. 19 18:05, Christopher wrote: On Wed, Mar 13, 2019 at 10:07 AM Randy Barlow wrote: On Tue, 2019-03-12 at 18:39 -0400, Christopher wrote: Well, the packager experience I'm expecting in 3 weeks is: "almost all of my dependencies and BuildRequires are gone; I can't build anything". How

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

On 3/13/19 5:55 PM, Daniel P. Berrangé wrote: > On Wed, Mar 13, 2019 at 12:21:29PM +, Tom Hughes wrote: >> On 13/03/2019 12:00, Daniel P. Berrangé wrote: >>> On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote: >>> | 1 || -Wformat || Check calls to "printf" and "scanf", etc., to mak

Re: F31 System-Wide Change proposal: Enable Compiler Security hardening flags by default in G

On 3/13/19 5:30 PM, Daniel P. Berrangé wrote: > On Mon, Mar 11, 2019 at 01:56:14PM -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/HardenedCompiler >> >> == Summary == >> By Default enable a few security hardening flags which are used with GCC. >> >> == Owner == >> * Name: [[User

Re: Orphaned packages to be retired (Java packages in 3 weeks)

On Tue, 12 Mar 2019 at 06:53, Miro Hrončok wrote: > > You can build Java apps as modules, yes. > If we remove the mentioned packages from rawhide, it will be the only way to > build Java packages. How are the Java applications that come with C (JNI) extensions handled in the modules model? How do

Re: Help us test FedoraReview on Python 3

On Fri, 2019-03-08 at 12:28 +0100, Miro Hrončok wrote: > There is a FedoraReview port to Python 3 that needs real word testing > by packagers. > > When you use FedoraReview, please use the Python 3 port instead to > help us find > bugs. > > Instructions are at https://pagure.io/FedoraReview/pull

Re: EPEL: Python34 moving to Python36

Amazing work! I just wanted to ask if it was a bug that the Python v2 branch provided the following RPMs, but the Python v3.6 did not: - python36-requests-oauthlib - python36-oauthlib - python36-markdown - python36-pytest-runner Perhaps these ones just haven't been ported over yet? Thoughts? Here

Re: gcc again, only on i686 and f29+ hidden symbol cpu_model referenced by dso

On Wed, 2019-03-13 at 10:29 +0100, Florian Weimer wrote: > * Sérgio Basto: > > > [3] > > export LDFLAGS="%{?__global_ldflags} -shared" > > Not sure why you think this would work. It prevents the compiler > from > creating any executables at all. With -shared fixed this generation of binaries [

Re: [modularity] Bringing order to the confusing module stream and profile names

On Wed, 13 Mar 2019, Stephen Gallagher wrote: On Wed, Mar 13, 2019 at 8:55 AM Adam Samalik wrote: There are module streams named 'latest', 'stable', or 'master', but it's not quite clear what exactly those mean. Some modules even have the 'master' and the 'latest' streams at the same time whic

Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide

On Fri, Mar 8, 2019 at 9:08 PM Kaleb Keithley wrote: > > The epoch was inadvertently bumped (not by me) when ceph was rebased to 14.x > in f30/rawhide. It just occurred to me that this was a normal update when epoch was increased, right? Maybe what we need is to have koji for example refusing e