Harden_all_packages_with_position-independent_code + guile modules

In rawhide building the gnutls guile bindings fails, and that's related to the new hardening flags being enabled with [0]. The failure is quite peculiar since the loading of a dynamic module fails [1] which already is position independent. Could someone explain what do the new flags in rawhide do (

libdwarf build failure with hardened builds

Does anybody have any clue what's going on here: https://kojipkgs.fedoraproject.org//work/tasks/8137/9208137/build.log It's an update to libdwarf, but the actual cause appears to be that it doesn't like the new hardened build options. It's a glibc symbol that it seems to be complaing about t

lrzip license correction

lrzip package license tag was corrected from (GPLv2+ and GPLv3+ and Public Domain) to (GPLv2+ and GPLv3+ and MIT and Public Domain). -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org

libproj soname bump

It appears the soname of libproj was changed in rawhide yesterday, so any dependencies will need to be rebuilt. I'm taking care of mapnik now. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/list

Re: mpich 3.1.4 in rawhide - soname changes

On 11.03.2015 20:51, Orion Poplawski wrote: I updated mpich 3.1 to 3.1.4 in rawhide. I wouldn't have thought this would make a difference, but apparently upstream decided to rename libraries (libmpich.so.12 -> libmpi.so.12) and drop a sub-library (libopa.so.1), apparently not having any underst

Re: Issue with yum/systemd?

On Wed, Mar 11, 2015 at 08:23:43PM -0700, Dave Johansen wrote: > On Wed, Mar 11, 2015 at 6:40 AM, Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl> wrote: > > > On Tue, Mar 10, 2015 at 08:15:38PM -0700, Dave Johansen wrote: > > > On Tue, Mar 10, 2015 at 7:53 PM, Dave Johansen > > > wrote: > > >

Complicated RPM dependency generator question

libguestfs.spec overrides the RPM internal dependency generator in order to add a very specific and rather narrow set of automated dependencies to a single sub-package. The spec file has: Source1: libguestfs-find-requires.sh %global _use_internal_dependency_generator 0 %global __find_

Re: Why -mtune=atom?

Am 12.03.2015 um 14:02 schrieb Florian Weimer: The default CFLAGS set by RPM include “-mtune-atom”. Why? I doubt Atom CPUs are Fedora's primary target. It's not even a documented GCC option. There is such a wide variety of CPUs under this label that it's not even clear what it would mean. I

Why -mtune=atom?

The default CFLAGS set by RPM include “-mtune-atom”. Why? I doubt Atom CPUs are Fedora's primary target. It's not even a documented GCC option. There is such a wide variety of CPUs under this label that it's not even clear what it would mean. If it's better than “-mtune=generic” or the GCC def

Re: Why -mtune=atom?

On Thu, Mar 12, 2015 at 1:02 PM, Florian Weimer wrote: > The default CFLAGS set by RPM include “-mtune-atom”. That's for i686 only > Why? I doubt Atom CPUs are Fedora's primary target. It's not even a > documented GCC option. There is such a wide variety of CPUs under this > label that it's n

Re: mpich 3.1.4 in rawhide - soname changes

On 12 March 2015 at 09:51, Sandro Mani wrote: > > On 11.03.2015 20:51, Orion Poplawski wrote: > >> I updated mpich 3.1 to 3.1.4 in rawhide. I wouldn't have thought this >> would >> make a difference, but apparently upstream decided to rename libraries >> (libmpich.so.12 -> libmpi.so.12) and drop

Re: mpich 3.1.4 in rawhide - soname changes

On 12.03.2015 14:25, Martyn Foster wrote: On 12 March 2015 at 09:51, Sandro Mani > wrote: On 11.03.2015 20:51, Orion Poplawski wrote: I updated mpich 3.1 to 3.1.4 in rawhide. I wouldn't have thought this would make a difference, but

Re: Harden_all_packages_with_position-independent_code + guile modules

On 2015-03-12, Nikos Mavrogiannopoulos wrote: > In rawhide building the gnutls guile bindings fails, and that's related > to the new hardening flags being enabled with [0]. The failure is quite > peculiar since the loading of a dynamic module fails [1] which already > is position independent. [...

Re: Why -mtune=atom?

- Original Message - > The default CFLAGS set by RPM include “-mtune-atom”. > > Why? I doubt Atom CPUs are Fedora's primary target. It's what's used in many lower price tablets, all-in-ones and laptops. I would think it fits with the "enthusiast" target. > It's not even a > documente

Re: Complicated RPM dependency generator question

What I've done here is to write a custom internal dependency generator, using the documentation here: http://www.rpm.org/wiki/PackagerDocs/DependencyGenerator Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: htt

Re: Why -mtune=atom?

On Thu, Mar 12, 2015 at 2:02 PM, Florian Weimer wrote: > The default CFLAGS set by RPM include “-mtune-atom”. > > Why? I doubt Atom CPUs are Fedora's primary target. It's not even a > documented GCC option. There is such a wide variety of CPUs under this > label that it's not even clear what it

Re: Why -mtune=atom?

Florian Weimer (fwei...@redhat.com) said: > The default CFLAGS set by RPM include “-mtune-atom”. > > Why? I doubt Atom CPUs are Fedora's primary target. It's not even a > documented GCC option. There is such a wide variety of CPUs under this > label that it's not even clear what it would mean.

Re: openQA live image testing: ready for merge?

On Thu, 2015-03-12 at 08:34 -0400, Josef Skladanka wrote: > Some preliminary feedback: > > = openqa_fedora = > > == _do_install_and_reboot.pm == > > Please delete the "anaconda_install_finish" needle, if it is unused. Don't recall that one off the top of my head (I'm on a bus, on my laptop) - I

Re: Harden_all_packages_with_position-independent_code + guile modules

On Thu, 2015-03-12 at 13:45 +, Petr Pisar wrote: > On 2015-03-12, Nikos Mavrogiannopoulos wrote: > > In rawhide building the gnutls guile bindings fails, and that's related > > to the new hardening flags being enabled with [0]. The failure is quite > > peculiar since the loading of a dynamic m

Re: Harden_all_packages_with_position-independent_code + guile modules

On 12/03/15 14:41, Adam Jackson wrote: On Thu, 2015-03-12 at 13:45 +, Petr Pisar wrote: However I can add my recent story: After hardening perl, loading a DSO by perl failed. I believe the reason was the DSO had an undefined symbol which was not defined in any SO_NEEDed libraries. But becau

Re: Harden_all_packages_with_position-independent_code + guile modules

On Thu, Mar 12, 2015 at 7:49 AM, Tom Hughes wrote: > On 12/03/15 14:41, Adam Jackson wrote: >> >> On Thu, 2015-03-12 at 13:45 +, Petr Pisar wrote: >>> >>> >>> However I can add my recent story: After hardening perl, loading a DSO >>> by perl failed. I believe the reason was the DSO had an unde

Re: Why -mtune=atom?

On 12 March 2015 at 07:02, Florian Weimer wrote: > The default CFLAGS set by RPM include “-mtune-atom”. > > Why? I doubt Atom CPUs are Fedora's primary target. It's not even a > documented GCC option. There is such a wide variety of CPUs under this > label that it's not even clear what it woul

Re: Harden_all_packages_with_position-independent_code + guile modules

On 03/12/2015 04:39 PM, Moez Roy wrote: On Thu, Mar 12, 2015 at 7:49 AM, Tom Hughes wrote: On 12/03/15 14:41, Adam Jackson wrote: We may want to revisit this, honestly. +1 I believe most of the issues should get resolved on its own after the mass rebuild of all the packages. Rel-Eng will

Re: wxGTK C++ ABI issues

On Tue, 10 Mar 2015 17:48:33 -0600 Orion Poplawski wrote: > On 02/19/2015 08:15 AM, Jakub Jelinek wrote: > > On Thu, Feb 19, 2015 at 04:12:43PM +0100, Frantisek Kluknavsky > > wrote: > >> a list of things that usually break with each new gcc (like > >> fortran modules) would be nice to avoid a lo

Re: Harden_all_packages_with_position-independent_code + guile modules

On Thu, Mar 12, 2015 at 02:49:03PM +, Tom Hughes wrote: > On top of which there seems, despite a number of questions posted here since > the change went live, very little assistance from the proposal owners with > fixing packages that have been broken by it. I do not see much value in repeati

Re: Why -mtune=atom?

On 03/12/2015 04:56 PM, Stephen John Smoogen wrote: > On 12 March 2015 at 07:02, Florian Weimer wrote: > >> The default CFLAGS set by RPM include “-mtune-atom”. >> >> Why? I doubt Atom CPUs are Fedora's primary target. It's not even a >> documented GCC option. There is such a wide variety of C

Re: Harden_all_packages_with_position-independent_code + guile modules

On 12/03/15 17:14, Till Maas wrote: On Thu, Mar 12, 2015 at 02:49:03PM +, Tom Hughes wrote: On top of which there seems, despite a number of questions posted here since the change went live, very little assistance from the proposal owners with fixing packages that have been broken by it.

Tracking bug for issues with using the Hardened Flags (Fails to Build, segfaults etc.)

Hello, If your package is one of the packages affected with the hardening change (F23/rawhide), please block: [Bug 1199775] Tracking bug for issues with using the Hardened Flags (Fails to Build, segfaults etc.) - https://bugzilla.redhat.com/show_bug.cgi?id=1199775 If you decide to add '%undefin

Re: Harden_all_packages_with_position-independent_code + guile modules

On Thu, Mar 12, 2015 at 05:26:43PM +, Tom Hughes wrote: > Well I haven't figured out how to fix libdwarf (see message this morning) > nor do I have any idea what I should do next to try and figure it out. > > So unless I ignore the "rawhide first" rule it seems I can't update that for > F22 u

Re: Harden_all_packages_with_position-independent_code + guile modules

On Thu, Mar 12, 2015 at 10:41:49AM -0400, Adam Jackson wrote: > We may want to revisit this, honestly. The actual proposal was just to > build executables as PIE, right? Forcing -z now is a bit more than > maybe was expected. Yes, if it is causing problems in a majority of packages, I agree tha

Re: libdwarf build failure with hardened builds

On Thu, Mar 12, 2015 at 1:46 AM, Tom Hughes wrote: > Does anybody have any clue what's going on here: > > https://kojipkgs.fedoraproject.org//work/tasks/8137/9208137/build.log > > It's an update to libdwarf, but the actual cause appears to be that it > doesn't like the new hardened build options

Re: mpich 3.1.4 in rawhide - soname changes

Sandro Mani writes: >> openmpi seems to be using >> >> /usr/lib64/openmpi/bin/ >> /usr/lib64/openmpi/lib/ >> >> so perhaps the "mpich" option is better than a generic "mpi"? >> > Yes, and this is the way it was before. I'd say this is just an > oversight in mpich-modules.patch [1], @MPILIBNAME@ c

Re: Harden_all_packages_with_position-independent_code + guile modules

On 03/12/2015 06:14 PM, Till Maas wrote: On Thu, Mar 12, 2015 at 02:49:03PM +, Tom Hughes wrote: On top of which there seems, despite a number of questions posted here since the change went live, very little assistance from the proposal owners with fixing packages that have been broken by i

Re: libdwarf build failure with hardened builds

On Thu, Mar 12, 2015 at 10:55 AM, Moez Roy wrote: > On Thu, Mar 12, 2015 at 1:46 AM, Tom Hughes wrote: >> Does anybody have any clue what's going on here: >> >> https://kojipkgs.fedoraproject.org//work/tasks/8137/9208137/build.log >> >> It's an update to libdwarf, but the actual cause appears t

Re: Harden_all_packages_with_position-independent_code + guile modules

On 12/03/15 17:48, Till Maas wrote: On Thu, Mar 12, 2015 at 05:26:43PM +, Tom Hughes wrote: Well I haven't figured out how to fix libdwarf (see message this morning) nor do I have any idea what I should do next to try and figure it out. So unless I ignore the "rawhide first" rule it seems

Re: Attempting to contact unresponsive maintainers - smizrahi and pknirsch

On Thu, 5 Mar 2015 07:11:09 -0700 Kevin Fenzi wrote: > Greetings, we've been told that the email addresses > for these package maintainers are no longer valid. I'm starting the > unresponsive maintainer policy to find out if they are still > interested in maintaining their packages (and if so, h

Re: __attribute__((alias(foo))) and the hardening flags

On Wed, Mar 11, 2015 at 11:25 AM, Moez Roy wrote: > When I set the target to f21 it fails on the test: Yes, the gfan update I have prepared addresses test failures, among other things. Regards, -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://

Re: __attribute__((alias(foo))) and the hardening flags

On Wed, Mar 11, 2015 at 10:54 AM, Moez Roy wrote: > The hardening config was committed on February 19. > > Can you rebuild cddlib for rawhide (it shows February 11?) > https://koji.fedoraproject.org/koji/packageinfo?packageID=7095 It has been rebuilt with the hardening flags but, alas, gfan still

Google Code and Gitorous shutting down: update upstream URLs please

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, As you might have heard, Google Code and Gitorious are both going to be closed: Google Code on January 25th, 2016[1] and Gitorious on May 2015[2]. We have some packages in Fedora that use either of those as homepage. To give an overview of the

Re: __attribute__((alias(foo))) and the hardening flags

Jerry James wrote: > Since they contain identical > symbols, the bundled polylmake version renames all of the symbols in > the GMP-enabled version to have "_gmp" suffixes. We did likewise, but > to support applications that only want the GMP-enabled version

dnf and yum works different

Hi guys, I don't know if this is the right list to expose that doubt. Recently, I run "dnf update", then "yum update", and I notice that yum detect 2 packages ("fros-recordmydesktop-1.0-5.fc21.noarch" and, from adobe repo, "flash-plugin-11.2.202.451-release.x86_64"). The case was present on two

Re: dnf and yum works different

Hi On Thu, Mar 12, 2015 at 9:46 PM, Adrian Soliard wrote: > > Recently, I run "dnf update", then "yum update", and I notice that yum > detect 2 packages ("fros-recordmydesktop-1.0-5.fc21.noarch" and, from > adobe repo, "flash-plugin-11.2.202.451-release.x86_64"). > The case was present on two di

Re: Why -mtune=atom?

On 03/12/2015 06:16 PM, Florian Weimer wrote: I looked at GCC, and -mtune=atom is actually -mtune=bonnell, and there is now -mtune=silvermont. Bay Trail and Avoton/Rangeley, the current SoC families, belong to Silvermont, not Bonnell. Well, to reach the largest possible user-groups, you need to

Re: Harden_all_packages_with_position-independent_code + guile modules

On 03/12/2015 05:06 PM, Ralf Corsepius wrote: Well, all I can say, building rawhide packages (esp. C++) seems to have evolved into a lottery and rendered working one Fedora packages into an adventure. E.g. I am facing packages which one day build, but fail to build the other day. Today, I have