Re: annocheck: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3
On 2024-05-10 06:41, Miro Hrončok wrote: Hello, when we build Python 3.13 with -O3 https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3 I see the following annocheck problem: Hardened: /usr/bin/python3.13: MAYB: test: fortify, reason: -D_FORTIFY_SOURCE=2 detected, expected -D_FORTIFY_SOURCE=3 (lto) Looks like an annobin issue; do you you have build logs someone can look at? The C flags have: -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -O3 Is -D_FORTIFY_SOURCE=3 not comaptible with -O3? Do I need to do somethign about this? _FORTIFY_SOURCE (any level) should work perfectly with -O (any level). Thanks, Sid -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: When to close CVE's
On Fri, Jan 20, 2023 at 8:54 AM Richard Shaw wrote: > > So is it when a build is complete in Rawhide? Or must *ALL* active releases > get the "fix"? > It depends on the severity of the CVE. For High severity ones it makes sense to fix in all active releases, less so for Medium/Low CVEs. hth Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: -Wp,-D_FORTIFY_SOURCE=3 and other compiler flags stored in Python
On Mon, Jan 16, 2023 at 1:40 PM Miro Hrončok wrote:
>
> Hello folks,
> this recent Fedora change:
>
> https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
>
> Made me think:
>
> Which compiler flags we need to store in Python and which can we omit?
>
> In order to make Python extension modules binary compatible with Python,
> Python
> saves the compiler flags at compile-time and reuses them when building
> extension modules.
>
> Historically, we had troubles with this approach because some of the flags are
> unusable without redhat-rpm-config, annobin etc.
>
> As a result, there are now 2 compiler flags macros available for RPM:
> %{build_cflags} and %{extension_cflags} (same for ldflags etc.).
> While Python itself is built with %{build_cflags}, it saves
> %{extension_cflags}
> in sysconfig.
>
> The flags differ like this:
>
> $ diff -u <(rpm --eval '%build_cflags' | tr ' ' '\n') <(rpm --eval
> '%extension_cflags' | tr ' ' '\n') | grep ^-
> --flto=auto
> --ffat-lto-objects
> --specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> --specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>
> $ diff -u <(rpm --eval '%build_ldflags' | tr ' ' '\n') <(rpm --eval
> '%extension_ldflags' | tr ' ' '\n') | grep ^-
> --specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> --specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
>
> (There are also some other differences wrt
> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects but
> those are apparently harder to get from outside of a real build.)
>
> The current set of flags from Python can be obtained by:
>
> >>> sysconfig.get_config_var('CFLAGS')
> '-Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -fexceptions -g
> -grecord-gcc-switches -pipe -Wall -Werror=format-security -U_FORTIFY_SOURCE
> -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
> -fstack-protector-strong -m64 -mtune=generic -fasynchronous-unwind-tables
> -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O2
> -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3
> -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -D_GNU_SOURCE -fPIC -fwrapv -O2 -fexceptions -g -grecord-gcc-switches -pipe
> -Wall -Werror=format-security -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE
> -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -fstack-protector-strong
> -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
> -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv'
> >>> sysconfig.get_config_var('LDFLAGS')
> '-Wl,-z,relro -Wl,--as-needed -Wl,-z,now-Wl,--build-id=sha1 -g
> -Wl,-z,relro -Wl,--as-needed -Wl,-z,now-Wl,--build-id=sha1 -g'
>
>
> I wonder if other flags should be removed as well.
>
> Isn't Python built e.g. with -Werror=format-security or -Wsign-compare binary
> compatible with extension modules built without it?
None of the warning flags should impact ABI or for that matter, even codegen.
> What about FORTIFY_SOURCE and others?
It won't impact ABI, i.e. python could be built with _FORTIFY_SOURCE
and modules without, or vice versa.
> Is there a compiler flags expert here who could help me determine what flags
> could (or even should) be removed from %{extension_*flags}?
>
If it is for distribution packages then I reckon the flags should be
as close as possible for the mere reason of consistency within the
distribution. If they're used for custom built modules (e.g. through
a tool that python auto-generates to build modules), then a very small
subset of the above flags would be necessary to retain binary
compatibility; you should be able to remove most of it.
Sid
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Coro] PR #3: Use _fortify_level
siddhesh commented on the pull-request: `Use _fortify_level` that you are following: `` Actually since this is only for arm, I wonder if we could simply drop that whole block. `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Coro/pull-request/3 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: -D_FORTIFY_SOURCE defined but value is too low [-Werror]
On Mon, Jan 16, 2023 at 1:05 PM Daniel P. Berrangé wrote: > > I'm getting the strange error in $SUBJECT in an upstream CI job that > is targetting Fedora rawhide. I'm guessing it is something related to > the recent changes to set the _FOTIFY_SOURCE value to 3 instead of > 2, but not sure what. > > What I'm finding especially bizarre is that I can't reproduce it on > rawhide myself, despite using the exact same package versions and > base container. > > I can't even figure out which particular component is emitting this > error message string. My only thought is that perhaps it could be > ccache related, since upstream CI has ccache enabled and the cache > is preserved across CI pipelines. That could explain why I can't > reproduce myself. > > My app has a config.h file used by all sources that does > > #if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > # define _FORTIFY_SOURCE 2 > #endif > > but the -D_FORTIFY_SOURCE=3 set by RPM in CFLAGS on the gcc command > line ought to override this fine. > > $ gcc -Ilibvirt-glib/libvirt-glib-1.0.so.0.4000.0.p -Ilibvirt-glib > -I../libvirt-glib -I. -I.. -I/usr/include/glib-2.0 > -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4 > -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch > -std=gnu99 ...snip many -Wxxx flags... -fexceptions > -fasynchronous-unwind-tables -fipa-pure-const -fstack-protector-strong -O2 > -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe > -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 > -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 > -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection > -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC > -pthread '-DLOCALEDIR="/usr/share/locale"' '-DDATADIR="/usr/share"' > -DLIBVIRT_GLIB_BUILD -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_48 > -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_48 -MD -MQ > libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o -MF > libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o.d -o > libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o -c > ../libvirt-glib/libvirt-glib-error.c > ../libvirt-glib/libvirt-glib-error.c: error: -D_FORTIFY_SOURCE defined but > value is too low [-Werror] > cc1: all warnings being treated as errors > > So does anyone know what this error message would be coming from, and more > importantly how to make it go away :-) I've seen this happen with ccache is in use[1], which flips the defines around, causing _FORTIFY_SOURCE to be undefined. I've posted a fix to redhat-rpm-config[2] to remedy this in the default flags to work around the reordering; the additional -U was redundant anyway. Sid [1] https://bugzilla.redhat.com/show_bug.cgi?id=2160275 [2] https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/237 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[rpms/perl-Coro] PR #3: Use _fortify_level
siddhesh opened a new pull-request against the project: `perl-Coro` that you are following: `` Use _fortify_level `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-Coro/pull-request/3 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Thu, Jan 12, 2023 at 6:38 PM Jakub Jelinek wrote: > But at least you don't need both -U_FORTIFY_SOURCE and > -Wp,-U_FORTIFY_SOURCE, one of them is enough. And the latter I think > better gets through libtool and other tools; especially if you put it > into a single -Wp, option together with the redefinition... Uhmm, I could have sworn that I had needed -Wp,-U... for the -Wp-D... and -U for the -D when I was fixing the test builds but you're right, simply -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3 appears to work for both -D_FORTIFY_SOURCE=2 as well as -Wp,-D_FORTIFY_SOURCE=2. I'll test this some more and post a PR for redhat-rpm-config. Thanks, Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Thu, Jan 12, 2023 at 12:41 PM Jakub Jelinek wrote: > > I've filed a ccache bug. It looks like ccache is moving the compiler > > arguments around, causing one of the -U_FORTIFY_SOURCE to the end. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2160275 > > Why we do have those -U_FORTIFY_SOURCE and -Wp,-U_FORTIFY_SOURCE options > in there at all? Previously we just had -Wp,-D_FORTIFY_SOURCE=2 > and I think just changing it to -Wp,-D_FORTIFY_SOURCE=3 is more than enough. > If you think some programs are adding -D_FORTIFY_SOURCE=2 to their *FLAGS > make vars etc., then perhaps -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 > But having both -U_FORTIFY_SOURCE and -Wp,-U_FORTIFY_SOURCE seems completely > pointless to me. A number of packages have -D_FORTIFY_SOURCE=2 in their default build flags, which was fine before because the redefinition didn't actually change the value of the macro. That unfortunately fails with -D_FORTIFY_SOURCE=3 since the macro now gets redefined to a different value, resulting in a compile time warning. As a result we need to undefine any previous macro definition and define it to 3. There were more than 20 packages IIRC and asking the upstreams to change for this didn't make sense, but I'm happy to explore other ideas, if any. Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Wed, Jan 11, 2023 at 4:43 PM Siddhesh Poyarekar wrote: > On Wed, Jan 11, 2023 at 4:37 PM Siddhesh Poyarekar > wrote: > > > > On Wed, Jan 11, 2023 at 3:05 PM Michel Alexandre Salim > > wrote: > > > Just `mock -r fedora-rawhide-x86_64 ./*.src.rpm` > > > > > > I have these additional knobs in ~/.config/mock.cfg: > > > > > > > > > config_opts['plugin_conf']['ccache_enable'] = True > > > config_opts['plugin_conf']['ccache_opts']['max_cache_size'] = '10G' > > > > > > # False: build from Koji, e.g. to grab packages just put into Rawhide > > > # config_opts['mirrored'] = False > > > > > > > OK I see the warning now. Let me dig deeper. > > So if you want the quick answer to unblock you, it is ccache; I > disabled it and the warning went away. That should help you get your > -Werror going. I'll look closer at why that's happening. I've filed a ccache bug. It looks like ccache is moving the compiler arguments around, causing one of the -U_FORTIFY_SOURCE to the end. https://bugzilla.redhat.com/show_bug.cgi?id=2160275 Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Wed, Jan 11, 2023 at 4:37 PM Siddhesh Poyarekar wrote: > > On Wed, Jan 11, 2023 at 3:05 PM Michel Alexandre Salim > wrote: > > Just `mock -r fedora-rawhide-x86_64 ./*.src.rpm` > > > > I have these additional knobs in ~/.config/mock.cfg: > > > > > > config_opts['plugin_conf']['ccache_enable'] = True > > config_opts['plugin_conf']['ccache_opts']['max_cache_size'] = '10G' > > > > # False: build from Koji, e.g. to grab packages just put into Rawhide > > # config_opts['mirrored'] = False > > > > OK I see the warning now. Let me dig deeper. So if you want the quick answer to unblock you, it is ccache; I disabled it and the warning went away. That should help you get your -Werror going. I'll look closer at why that's happening. Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Wed, Jan 11, 2023 at 3:05 PM Michel Alexandre Salim wrote: > Just `mock -r fedora-rawhide-x86_64 ./*.src.rpm` > > I have these additional knobs in ~/.config/mock.cfg: > > > config_opts['plugin_conf']['ccache_enable'] = True > config_opts['plugin_conf']['ccache_opts']['max_cache_size'] = '10G' > > # False: build from Koji, e.g. to grab packages just put into Rawhide > # config_opts['mirrored'] = False > OK I see the warning now. Let me dig deeper. Thanks, Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Wed, Jan 11, 2023 at 1:15 PM Michel Alexandre Salim wrote: > The warning seems to happen only in mock, the Koji build is clean: > https://koji.fedoraproject.org/koji/taskinfo?taskID=96015653 > > Let me paste the root.log and build.log from the local build (I'm now > working on upgrading a second package that uses -Werror, so on that the > FORTIFY_SOURCE issue actually fails the build - will have to locally > test against fedora-37-x86_64 instead of Rawhide for now). > > build.log: https://paste.centos.org/view/ea89a51c > root.log: https://paste.centos.org/view/c25c9b3f Can you tell me how you're doing the mock build? With my fedora 37 laptop a `fedpkg mockbuild` went through just fine for rubberband and I don't see any of the superfluous annobin messages: https://paste.centos.org/view/86ec6416 If I find a way to reproduce this I could figure out why annobin is behaving that way. Thanks, Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Wed, Jan 11, 2023 at 12:45 PM Michel Alexandre Salim wrote: > Is this supported yet? I'm doing a build of rubberband for Rawhide, and > every file generates this warning: > > ../src/test/TestStretcher.cpp: warning: -D_FORTIFY_SOURCE defined but > value is too low Yes the change is in, it even broke systemd once ;) Could you please share the full build log? That looks like an annobin warning, which may suggest an annobin bug but maybe something else is wrong. Thanks, Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)
On Wed, Jan 11, 2023 at 6:25 AM Vít Ondruch wrote: > > > Dne 11. 01. 23 v 12:16 Vít Ondruch napsal(a): > > So shouldn't there be some policy for revoting? E.g.: > > > > > > ~~~ > > > > If revote is initiated (by somebody?), the revote is going to be > > announced on devel(-announce) and can happen as soon as in one week. > > > > ~~~ > > > > > > Also, I am not quite sure who and how initiated the revote. Maybe the > policy should be about initiating the revote instead. E.g. if I disagree > with some FESCo decision and I think it should be revoted, I would > announce my intention to initiate the revote on devel(-announce). That came up in yesterday's FESCO meeting, so hopefully at least that workflow hole will be plugged: https://meetbot.fedoraproject.org/fedora-meeting/2023-01-10/fesco.2023-01-10-17.00.log.html Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]
On Tue, Jan 10, 2023 at 7:17 PM Fabio Valentini wrote: > Speaking for myself, the only way in which the _FORTIFY_SOURCE change > impacted my opinion on -fno-omit-frame-pointers is that it made me > think about it again, and that the level of scrutiny myself - and > other members of FESCo - had given that change, had been > disproportionate. The _FORTIFY_SOURCE change really shouldn't even have prompted a discussion on the frame pointers change, let alone a reflection because there is absolutely nothing in common there. Especially in the context of scrutiny level; one is a security change that has no broad slowdown and another is a developer experience change that is shown to have a broad slowdown (characterized by minor or major depending on which side of the aisle you stand on). > And you might like it or not, I had just changed my > mind on the topic since we had the first vote. I wish you had spoken up sooner then, using the _FORTIFY_SOURCE change as the opportunity to speak up not only confused the whole thing, it also makes it harder to convince that the change of mind came independently. Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)
On Tue, Jan 10, 2023 at 4:31 PM Zbigniew Jędrzejewski-Szmek wrote: > That description assumes that FESCo members are preschoolers who are > easy to trick and also need to be reminded who said what every day. > That's certainly not the case. The objections against the proposal > were made very clearly and they certainly weren't forgotten over a few > days. Those objections also didn't *change* over those few days, so > repeating them wouldn't actually change anything. They don't need to be preschoolers; it's not that hard to manufacture an opinion among well informed adults, even unintentionally by just having a lot of conviction about it. The seeds for the revote were placed in the _FORTIFY_SOURCE=3 change discussion and throughout the discussion, repeated explanations of why the proposals are not comparable were ignored, instead of which the focus seemed to be on driving consensus towards getting a revote on the frame pointer proposal and trying to paint the tools team's position as being duplicitous. In the _FORTIFY_SOURCE=3 ticket one of the FESCo voters (who also drove the revote FWIW) took a hard negative stand only because they perceived a double standard on performance, which had, by then, already been debunked a couple of times in the devel thread. While he did change his vote to +1 later, he appeared to do so only after other members voiced their support. If that's not influencing narrative then I don't know what is. Multiple other FESCo voters, when voting for the _FORTIFY_SOURCE proposal, talked about the frame pointer proposal, again clearly indicating that there is a cross-influence. Finally, another voting member commented, this time on the re-vote ticket[1], again indicating that the reason for the revote is the misdirection in the _FORTIFY_SOURCE proposal discussion. Christian did make an impassioned plea on the re-vote ticket for the case of frame pointers and it's perfectly understandable if that was a turning point for those who changed their vote (and please say it if that was what it was; I'd disagree but that's a different matter then) but the thing is, that plea needs counterarguments and further discussion and there was no opportunity for that to happen. Even then, the only reason why the revote happened at all was because of the persistent misdirection in the _FORTIFY_SOURCE proposal. > Speaking for myself, I heard the objections from various sides, and I > think I understand them. In particular I think that the objections from > the compiler team are based on correct evaluation of the effect of the > change. But that evaluation is hyperfocused on benchmark performance and > doesn't look at the needs of the whole ecosystem. I think that the > advantages of the proposal and the gains I hope will be realized outweigh > the drawbacks. Ack, I respect that even if I don't agree with the conclusion. Thanks, Sid [1] https://pagure.io/fesco/issue/2923#comment-833708 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)
On Tue, Jan 10, 2023 at 3:05 AM Zbigniew Jędrzejewski-Szmek wrote: > Exactly, you're just confirming what I wrote above. > > A "vote being rigged" means that either the people who should be allowed to > vote > couldn't, or that people who are not allowed to vote did, or that voters were > tricked or forced to vote differently, or that votes were miscounted. What's being alleged is that many members were tricked into changing their vote by using the false narrative about _FORTIFY_SOURCE proposal getting an unfair pass despite performance concerns (which *I* hypothesized months ago and I later dispelled, in the end even quoting benchmark results for it) and creating the impression that the toolchain team is being duplicitous about the performance question. Further trickery involved rushing the vote, claiming that it had to be done soon to meet the mass rebuild deadline; too bad if those who had strong objections earlier weren't around to put their comments on record. In that context the vote could in fact be considered rigged. If the voting members could come out and clarify exactly why they changed their vote, it would make things a lot clearer. Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)
On Mon, Jan 9, 2023 at 5:53 PM Kevin Kofler via devel
wrote:
> * It made wrong assumptions about the performance impact of
> _FORTIFY_SOURCE=3, which, compared to the already existing (!)
> _FORTIFY_SOURCE=2, appears to actually have NO performance impact at all
> (!), only compared to no _FORTIFY_SOURCE at all.
Your larger point is correct (and what I've been talking about too)
but for the sake of accuracy: there is no known overhead due to
_FORTIFY_SOURCE=2 either AFAIK; there's one publicly available
analysis[1] that shows a minor speedup (!) in ffmpeg due to
_FORTIFY_SOURCE=2. The ~1.3% overhead I mentioned was for
"-fstack-protector-strong -fstack-clash-protection
-D_FORTIFY_SOURCE={2,3} -D_GLIBCBXX_ASSERTIONS" and IMO it should
mainly be attributed to -fstack-protector-strong
-fstack-clash-protection and perhaps -D_GLIBCXX_ASSERTIONS.
Thanks,
Sid
[1] https://zatoichi-engineer.github.io/2017/10/06/fortify-source.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Tue, Dec 6, 2022 at 10:41 AM Siddhesh Poyarekar wrote: > > On Tue, Dec 6, 2022 at 10:26 AM Gary Buhrmaster > wrote: > > > > On Tue, Dec 6, 2022 at 3:16 PM Siddhesh Poyarekar > > wrote: > > > > > My full comment in that blog post is: > > > > > > "We need a proper study of performance and code size to understand the > > > magnitude of the impact created by _FORTIFY_SOURCE=3 additional > > > runtime code generation. However the performance and code size > > > overhead may well be worth it due to the magnitude of improvement in > > > security coverage." > > > > The key word is *MAY*. That is not considered > > to be a conclusion supported by the evidence > > presented (at least in any scientific paper I > > have reviewed). > > I have added a performance note[1] in the proposal. SPEC2000 and SPEC2017 results with _FORTIFY_SOURCE=2 vs _FORTIFY_SOURCE=3 show practically no difference in performance. I have updated the wiki to note this and the fact that this should alleviate any concerns of a general slowdown. However I do request package maintainers to report any slowdown they experience due to building with _FORTIFY_SOURCE=3 so that we get a better understanding. Always happy to help keep performance up to par even as we improve security mitigations. Thanks, Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
[Responding from alias that's actually registered to devel@] On Thu, Dec 8, 2022 at 8:25 AM Siddhesh Poyarekar wrote: > > On Mon, Dec 5, 2022 at 3:04 PM Ben Cotton wrote: > > > > On Mon, Dec 5, 2022 at 2:58 PM Ben Cotton wrote: > > > > > > * Release engineering: Mass rebuild required > > > > Please file a ticket with Release Engineering if you haven't already. > > Done and quoted in the proposal. > > > > == Contingency Plan == > > > * Contingency mechanism: (What to do? Who will do it?) If too many > > > packages are found to be broken at runtime, the default for > > > fortification will be left at `_FORTIFY_SOURCE=2` for Fedora 38. > > > Change owner will do this in `redhat-rpm-config` > > > > > > * Contingency deadline: Beta freeze > > > > Would a full mass rebuild be required to invoke the contingency > > mechanism, or would we just need to rebuild affected packages? In > > either case (but definitely if a full mass rebuild is required), I'm > > concerned that this contingency deadline is too late in the schedule. > > Branch day (2023-02-07) seems like it would be a better fit. > > I've fleshed out the contingency section a bit to make the contingency > plan more conservative as you suggested. > > Thanks, > Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Wed, Dec 7, 2022 at 3:15 PM Andrii Nakryiko wrote: > > > On Tue, Dec 6, 2022 at 12:56 PM Andrii Nakryiko > > > > > I don't think the two are comparable at all, neither in terms of > > potential performance impact (register pressure across an entire > > program vs at specific API call points in some unique cases) nor in > > terms of the benefits it provides. > > It's irrelevant if they are comparable. This is a system-wide change that has > potential to cause performance regression. By how much -- not clear. > Hand-waiving such concerns is extremely disappointing in the face of the > scrutiny given to https://pagure.io/fesco/issue/2817. So, please get > inspiration from that proposal and do benchmarks. > You're basically making a political statement, so I'll just leave that bit for FESCO to deal with. Thanks, Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Tue, Dec 6, 2022 at 12:56 PM Andrii Nakryiko wrote: > > On Tue, Dec 6, 2022 at 10:06 AM Gary Buhrmaster > > > > > My full comment in that blog post is: > > > > "We need a proper study of performance and code size to understand the > > magnitude of the impact created by _FORTIFY_SOURCE=3 additional > > runtime code generation. However the performance and code size > > overhead may well be worth it due to the magnitude of improvement in > > security coverage." > > > > To elaborate, I think the performance and code size study is an > > interesting academic concern, but the magnitude of improvement > > justifies whatever little performance impact this may introduce and it > > should not be a blocker for the improvement. > > It's interesting how now it's just an academic concern. Please hold yourself > to at least the standards set for https://pagure.io/fesco/issue/2817 in terms > of benchmarking and persuading everyone that performance degradation across > entire ecosystem is not a concern. > I don't think the two are comparable at all, neither in terms of potential performance impact (register pressure across an entire program vs at specific API call points in some unique cases) nor in terms of the benefits it provides. Thanks, Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Tue, Dec 6, 2022 at 10:26 AM Gary Buhrmaster wrote: > > On Tue, Dec 6, 2022 at 3:16 PM Siddhesh Poyarekar wrote: > > > My full comment in that blog post is: > > > > "We need a proper study of performance and code size to understand the > > magnitude of the impact created by _FORTIFY_SOURCE=3 additional > > runtime code generation. However the performance and code size > > overhead may well be worth it due to the magnitude of improvement in > > security coverage." > > The key word is *MAY*. That is not considered > to be a conclusion supported by the evidence > presented (at least in any scientific paper I > have reviewed). I have added a performance note[1] in the proposal. Thanks, Sid [1] https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags#Performance_note ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Tue, Dec 6, 2022 at 10:06 AM Gary Buhrmaster wrote: > > On Tue, Dec 6, 2022 at 12:47 PM Siddhesh Poyarekar > wrote: > > > Overall even if there is a miniscule performance overhead, I > > reckon the reward is much higher. > > I am curious how you can claim there is only a > minuscule performance overhead without doing > any benchmarks? > > I am not claiming the overheads are high, I > don't know, but I know enough to trust that > when you (yourself) said in the article: > >"We need a proper study of performance >and code size to understand the magnitude >of the impact" > > that you are making a very clear statement > that you believe that such a study is needed. > > If you do not believe that that statement > is correct, will you be issuing a correction > to the posted article saying that such a study > is no longer needed? My full comment in that blog post is: "We need a proper study of performance and code size to understand the magnitude of the impact created by _FORTIFY_SOURCE=3 additional runtime code generation. However the performance and code size overhead may well be worth it due to the magnitude of improvement in security coverage." To elaborate, I think the performance and code size study is an interesting academic concern, but the magnitude of improvement justifies whatever little performance impact this may introduce and it should not be a blocker for the improvement. > And without any benchmarks, the proposal > should acknowledge explicitly that some > unknown performance penalty may be seen, > and needs to be accepted as a trade-off for > security reasons (some may be fine with that, > others less so, but that is a different debate > to have). Sure, I could add that as a comment in the proposal. Thanks, Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Tue, Dec 6, 2022 at 9:55 AM Siddhesh Poyarekar wrote: > > On Tue, Dec 6, 2022 at 8:14 AM Siddhesh Poyarekar wrote: > > > Please provide a proper "how to test" section, I cannot fix what I cannot > > > test or compare results when I have no idea what I am seeing. > > > > > > Actually, last time I heard about number of packages, it was around 50k > > > (not source, build result), and as I stated, > > > Ruby is missing, and so are quite a few dependent packages that should > > > have GCC involved somewhere: > > > ~~~ > > > $ dnf repoquery --whatrequires "*libruby.so*" --disablerepo="*" > > > --enablerepo="fedora" 2>/dev/null | grep -v "i686" | uniq | wc -l > > > 115 > > > ~~~ > > > > > > If we also filter rubygem-* packages that depend on the *libruby.so* (and > > > most probably contain a binary extension written in C/C++ that links to > > > Ruby), I get 68 packages. > > > When I search "All x86_64" for "ruby" I get 28 packages. That is... not > > > adding up. > > > > Yeah, I have missed packages; I had looked at revdeps glibc-devel, > > which turned out around 9k packages, of which 6k had any > > _FORTIFY_SOURCE use at all. I can redo with *all* packages and > > generate a report. > > I checked again and it looks like ruby had failed in that mass > rebuild[1] but I can't see the logs anymore; they've probably been > garbage collected. I reckon it was one of those with a transient > failure that I reran by hand later. I'm going to run a full rebuild > anyway (should take about 8 days, about 23k source packages AFAICT) > and will share the results here. To be clear, ruby *builds* successfully[1] with _FORTIFY_SOURCE=3, it just didn't build successfully when running the metrics. Sid [1] https://copr.fedorainfracloud.org/coprs/siddhesh/mpb.41/builds/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Tue, Dec 6, 2022 at 8:14 AM Siddhesh Poyarekar wrote: > > Please provide a proper "how to test" section, I cannot fix what I cannot > > test or compare results when I have no idea what I am seeing. > > > > Actually, last time I heard about number of packages, it was around 50k > > (not source, build result), and as I stated, > > Ruby is missing, and so are quite a few dependent packages that should have > > GCC involved somewhere: > > ~~~ > > $ dnf repoquery --whatrequires "*libruby.so*" --disablerepo="*" > > --enablerepo="fedora" 2>/dev/null | grep -v "i686" | uniq | wc -l > > 115 > > ~~~ > > > > If we also filter rubygem-* packages that depend on the *libruby.so* (and > > most probably contain a binary extension written in C/C++ that links to > > Ruby), I get 68 packages. > > When I search "All x86_64" for "ruby" I get 28 packages. That is... not > > adding up. > > Yeah, I have missed packages; I had looked at revdeps glibc-devel, > which turned out around 9k packages, of which 6k had any > _FORTIFY_SOURCE use at all. I can redo with *all* packages and > generate a report. I checked again and it looks like ruby had failed in that mass rebuild[1] but I can't see the logs anymore; they've probably been garbage collected. I reckon it was one of those with a transient failure that I reran by hand later. I'm going to run a full rebuild anyway (should take about 8 days, about 23k source packages AFAICT) and will share the results here. Thanks, Sid [1] https://copr.fedorainfracloud.org/coprs/siddhesh/mpb.41/builds/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Tue, Dec 6, 2022 at 5:45 AM Jakub Jelinek wrote: > > On Tue, Dec 06, 2022 at 11:13:38AM +0100, Vitaly Zaitsev via devel wrote: > > On 05/12/2022 20:58, Ben Cotton wrote: > > > Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to > > > improve mitigation of security issues arising from buffer overflows in > > > packages in Fedora. > > > > AFAIK, _FORTIFY_SOURCE=3 enables runtime checks for every mem*() function > > call. This should result in significant performance degradation. > > That is misunderstanding. > The way _FORTIFY_SOURCE works is that say for memcpy if the destination > has known upper bound on size (__builtin_object_size (dst, 0) returns > something other than ~(size_t)0), then __memcpy_chk is used instead of > memcpy, unless the compiler can prove that the length will always fit into > that destination (in that case it is folded back to (builtin) memcpy). > So, "every" is definitely not the case. In many cases nothing is known > about the size of the destination, and in a lot of cases it is provable that > no overflow will happen. To add to this, I twiddled the macros to make sure that even if the sizes are not known, we can infer safety from ranges of values that they could have. For example if the destination object size in memcpy is known to be at least 1024 bytes and the write size is known to be at most 64 bytes, the copy is deemed safe at compile time. > > To proposal owner: add information about potential performance degradation, > > including benchmark results. > > Deferring that to Siddhesh, I haven't done that benchmarking myself. I haven't run any benchmarks because (1) the magnitude of coverage is immense, making a small performance impact (IMO) worthwhile and (2) other distributions have enabled _FORTIFY_SOURCE=3 by default for nearly a year without any reports of performance degradation from their users and (3) the code size tests show negligible impact. However if it is considered a blocker by FESCO, I'll be happy to run a benchmark they suggest to post numbers. Thanks, Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Tue, Dec 6, 2022 at 4:05 AM Richard W.M. Jones wrote: > > On Tue, Dec 06, 2022 at 01:35:04AM +0100, Jaroslav Prokop wrote: > > On 12/5/22 20:58, Ben Cotton wrote: > > > > The core change to bring in this mitigation is to change the default > > build flags in `redhat-rpm-config` so that packages build by default > > with `-Wp,-D_FORTIFY_SOURCE=3`. There are packages (e.g. `systemd`) > > that do not interact well with `_FORTIFY_SOURCE` and will also need a > > workaround to downgrade fortification to level 2. The change will also > > include this override. > > > > How come systemd gets an exception? If it is a security option, it should be > > enabled everywhere. > > I don't believe the proposal is that everyone *has* to use this (or at > least, I hope not). Even existing _FORTIFY_SOURCE=2 is optional. I'd > like to know what the problems are that affect systemd however. Yes, I intend it to be the same as _FORTIFY_SOURCE=2. In fact, I'm thinking of a %fortify_level macro override that allows packages to override this without fiddling directly with cflags. Thanks, Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Mon, Dec 5, 2022 at 10:20 PM Gary Buhrmaster wrote: > > On Mon, Dec 5, 2022 at 10:53 PM Neal Gompa wrote: > > > It has a similar impact that turning back on frame pointers would. > > > > Cf. > > https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#the_gains_of_improved_security_coverage_outweigh_the_cost > > > > That article explicitly states: > "We need a proper study of performance and code size to understand > the magnitude of the impact" > > I look forward to seeing the results of that proper study before > this is even considered for approval (since, after all, one of the > strong push-backs for -fno-omit-frame-pointer was performance). Besides the point that the two are not comparable, code size results are in the sheet I linked to in the proposal; there's no negative impact. The feature has been enabled by default in OpenSUSE for nearly a year and there have been no noticeable performance issues reported there either. IMO the magnitude of improvement is such that a benchmark shouldn't be a blocker for this feature, but if that's what FESCO insists, I'll be happy to run whatever benchmark they suggest. Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Mon, Dec 5, 2022 at 7:35 PM Jaroslav Prokop wrote: > Default C and C++ compiler flags to build packages in Fedora currently > includes `-Wp,-D_FORTIFY_SOURCE=2`, which enables fortification of > some functions in glibc, thus providing some mitigation against buffer > overflows. Since glibc 2.34 and GCC 12, there has been a new > fortification level (`_FORTIFY_SOURCE=3`) which improves the coverage > of this mitigation. > > The core change to bring in this mitigation is to change the default > build flags in `redhat-rpm-config` so that packages build by default > with `-Wp,-D_FORTIFY_SOURCE=3`. There are packages (e.g. `systemd`) > that do not interact well with `_FORTIFY_SOURCE` and will also need a > workaround to downgrade fortification to level 2. The change will also > include this override. > > How come systemd gets an exception? If it is a security option, it should be > enabled everywhere. It's an unfortunate (although hopefully temporary) exclusion, see this issue for more context: https://github.com/systemd/systemd/issues/22801 In summary, systemd uses malloc_usable_size in a way that it's discouraged, which results in behaviour that's undefined by the standard, which is now caught out by the compiler. We're hoping to convince the systemd community to fix this so that we can actually build it with fortification. > I do not see benefit in a security change that ignores PID 1 process, Do you mean that factually or rhetorically? I've shared statistics of improvement in the proposal, surely improvements to packages like bash, sudo and coreutils would count for something :) > If the feature, on the GCC side, is not 100% done. > How do I tell a difference of a bug with the _FORTIFY_SOURCE which I will > ignore and a bug with my package? _FORTIFY_SOURCE=3 has been enabled on OpenSUSE for nearly a year. If it causes a crash in your package, it's extremely likely that your package has a bug. > I do not have the knowledge or the time to be able to say that GCC generated > the wrong machine code and therefore it is not a bug with my package. > If my program was not complaining before the change and is now complaining > with the change, I am opting out of the change, and filing a bug against GCC > on Fedora. > > I assume that by the package providing the exception, packagers get to choose > themselves and we do not need to go through FESCO > to disable a security feature? I think they should have to, but that's something for FESCO to decide. _FORTIFY_SOURCE is not a new feature, the new level is just better at catching bugs. Significantly better. > == Benefit to Fedora == > > [https://docs.google.com/spreadsheets/d/1nPSmbEf3HVB91zI8yBraMqVry3_ILmlV2Z5K7FZeHZg/edit?usp=sharing > Analysis of packages] in Fedora rawhide indicate that the improvement > of mitigation coverage is on average over 2.4x, in some cases > protecting more than half of the fortified glibc calls in the target > application. > > This change will thus harden Fedora to a significant extent, thus > making it a more secure distribution out of the box. > > > 1) Is there some complete source for all these findings? If google sheets > cannot handle all the "raw data" as noted in the comment, > maybe it is the wrong medium. I've literally posted the raw data in the sheets, please take a look. > 2) What does *anything* on that google sheet mean. I have managed to figure > out, from the article, that bos and bdos correspond to level 2 and 3 of > _FORTIFY_SOURCE. > However, total of /.*/? Violated accesses? Segfaults? Then followed by "Sum > of total". For rubygem-ffi, this reaches into hundreds while "bdos" is 2. > That is the only sum I can make, with the data provided. > I am no wiser from looking at it, what do the data mean? I've mentioned this in the article, but it's a compile-time statistic of the number of success of __builtin_object_size vs __builtin_dynamic_object_size, using the fortify-metrics plugin: https://github.com/siddhesh/fortify-metrics The numbers you should be looking at are the "coverage" columns, which tells you what percentage of the calls were successful. For rubygem-ffi, the fortification is negligible regardless of whether it is built at _FORTIFY_SOURCE=2 or _FORTIFY_SOURCE=3. This means that it is unaffected by this change. > 3) I cannot speak to much else than Ruby, I do not see ruby in neither the > failures or "All x86_64". Should we attempt to test it ourselves? That's odd, thanks for pointing out. > Please provide a proper "how to test" section, I cannot fix what I cannot > test or compare results when I have no idea what I am seeing. > > Actually, last time I heard about number of packages, it was around 50k (not > source, build result), and as I stated, > Ruby is missing, and so are quite a few dependent packages that should have > GCC involved somewhere: > ~~~ > $ dnf repoquery --whatrequires "*libruby.so*" --disablerepo="*" > --enablerepo="fedora" 2>/dev/null | grep
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Mon, Dec 5, 2022 at 5:53 PM Neal Gompa wrote: > > On Mon, Dec 5, 2022 at 3:17 PM Gary Buhrmaster > wrote: > > > > On Mon, Dec 5, 2022 at 7:58 PM Ben Cotton wrote: > > > > > > https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags > > > > > > > It is my vague recollection (I could easily be wrong, so > > correct me as appropriate) that _FORTIFY_SOURCE=3 > > adds some runtime overhead that did not apply in > > previous levels. > > > > If that is correct, has the potential performance impact > > been evaluated and documented somewhere? And, if > > correct, the change proposal should probably be modified > > to mention the potential performance impacts. > > It has a similar impact that turning back on frame pointers would. > > Cf. > https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#the_gains_of_improved_security_coverage_outweigh_the_cost > > I'm extremely displeased now, as the toolchain team basically told us > they wouldn't accept register pressure on x86_64 and then turned > around and made a proposal that does the same thing. Apparently > quality of life improvements for developers and real-time tracing > (e.g. making bpftrace useful) isn't worth it, but this is. > > I want a really good justification for not doing both at the same time > if we're going to accept this. They're only similar to the extent of potentially having a performance impact. One may improve debugging experience while the other improves security mitigation coverage by a factor of 2.4x in the average case and 5-10x in some key cases. They're apples and butter chicken. Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add _FORTIFY_SOURCE=3 to distribution build flags (System-Wide Change proposal)
On Mon, Dec 5, 2022 at 3:17 PM Gary Buhrmaster wrote: > > On Mon, Dec 5, 2022 at 7:58 PM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags > > > > It is my vague recollection (I could easily be wrong, so > correct me as appropriate) that _FORTIFY_SOURCE=3 > adds some runtime overhead that did not apply in > previous levels. > > If that is correct, has the potential performance impact > been evaluated and documented somewhere? And, if > correct, the change proposal should probably be modified > to mention the potential performance impacts. There is indeed a theoretical concern over performance due to size expressions vs constants, but none have been reported in practice. OpenSUSE and Gentoo (at least) have had _FORTIFY_SOURCE=3 enabled by default for nearly a year and there haven't seen any reports of performance degradation. Besides, the magnitude of mitigation coverage is *immense*. For example with bash, where only 3% of the calls were fortified, now nearly half of the calls are fortified. Likewise, sudo has gone from about 1% to nearly half. Note that it doesn't mean that all those new calls have an additional overhead; the compiler and glibc can also detect which of these accesses are always safe and it simplifies the calls to the regular ones. Overall even if there is a miniscule performance overhead, I reckon the reward is much higher. Just ask the folks over at OpenSUSE, they've uncovered a bunch of bugs over the last year thanks to this feature. I did a code size analysis though (since it's a much clearler problem to analyze) and funnily, _FORTIFY_SOURCE=3 ended up *reducing* code size by a tiny bit on average. Very few packages saw code size increases beyond 1%, most were in the nearly negligible range. The numbers are in the Google spreadsheet I linked to in the proposal, under the "size summary" tab. Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: hardened memory allocate port to linux-fedora system for secutiry
On Sat, Aug 27, 2022 at 9:14 AM Carlos O'Donell wrote: > (2) Switching the default vs. improving the default. > A third option (or maybe it's an improvement to the default?), since the choice of allocators seems to come up consistently, could be to consider seriously (and is likely not a trivial project) the idea of making it easier to switch allocators. However to echo what Timothée said, there's value in packaging hardened_malloc for Fedora to make it available to users. It's much too early to start talking about switching defaults IMO. Sid ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Uninitialized variables and F37
On Mon, May 16, 2022 at 7:18 PM Mark Wielaard wrote: > > Hi Steve, > > On Wed, 2022-05-11 at 22:35 -0400, Steve Grubb wrote: > > On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote: > > > Are you going to take this idea forward and make a formal change proposal > > > for Fedora to set -ftrivial-auto-var-init=zero by default in its default > > > RPM build flags ? > > > > I've connected with the gcc folks and we will file a proposal in the near > > future. > > I am not a fan, because I think this mainly hides bugs. But also > because the original change proposal made it sound like we don't have > any other way to find and fix these kind of bugs. While a little > analysis of your examples showed we can find and fix 100% of these > issues with the existing gcc and analysis tools. > > So my counter proposal would probably be to enforce -Werror and running > all package test-suites under valgrind. But maybe others won't like > that "solution". OK, running all package testsuites under valgrind may be overkill but we should certainly build towards coverage that resembles that. > If you do propose this again could you at least make clear it's another > tool in the toolbox, not a replacement, and that the other tools do > work, and are trusted (if you pay attention to them). Then at least we > could have a honest discussion why (and in which circumstances) each of > the tools might or might not work/catch an issue. And if we > may/can/should require packagers to pay more attention to compiler > warnings and/or running analysis tools over the sources they package. We should capture the impact of this on analysis tools and perhaps document ways to achieve the full benefit of valgrind when debugging packages. The ideal would be a rawhide-debug (or f37-build-debug, etc) target that disables trivial-auto-var-init and maybe also some other flags to improve debuggability, but that could be a separate proposal. Thanks, Siddhesh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: libc_malloc_debug.so vs .so.0 in glibc 2.34
On Tue, Aug 24, 2021 at 1:28 PM Richard W.M. Jones wrote: > Thanks - I made this change to nbdkit: > > https://gitlab.com/nbdkit/nbdkit/-/commit/8972831aa2a32d4b5820465d37c1827eb76450e4 > > Will the .0 ever change? I can't see a reason for it to ever change; I'd say it's unlikelier than the .6 in libc.so.6 changing. Siddhesh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: libc_malloc_debug.so vs .so.0 in glibc 2.34
[cursed email aliases!] On Tue, Aug 24, 2021 at 10:42 AM Siddhesh Poyarekar wrote: > > On Tue, Aug 24, 2021 at 2:52 AM Richard W.M. Jones wrote: > > Anyway this is not the reason why I'm writing this email on Fedora > > devel list. In the Fedora package we have: > > > > $ rpm -qf /usr/lib64/libc_malloc_debug.so > > glibc-devel-2.34-1.fc35.x86_64 > > $ rpm -qf /usr/lib64/libc_malloc_debug.so.0 > > glibc-2.34-1.fc35.x86_64 > > > > I'm wondering why it was decided to put the symlink and the file in > > the two different packages? > > > > Is it intended that end users use: > > > > LD_PRELOAD=/usr/lib64/libc_malloc_debug.so.0 # (1) > > This one is correct. > > > or > > > > LD_PRELOAD=/usr/lib64/libc_malloc_debug.so # (2) > > > > If it's (1) then that is a file, so why bother with the symlink? > > I have an open bug and PR to resolve this: > > https://bugzilla.redhat.com/show_bug.cgi?id=1985048 > https://src.fedoraproject.org/rpms/glibc/pull-request/37 > > I waited because we were too close to the mass rebuild and then it > fell off my plate, sorry :/ > > > If it's (2) then that's a symlink to (1), so why have the possibility > > of installing only the glibc package thus getting only the file > > /usr/lib64/libc_malloc_debug.so.0 which is not useful on its own? > > > > Also is this feature intended for developers (glibc-devel) or everyone > > (glibc)? (My preference is "everyone" - we've found that asking bug > > reporters to enable MALLOC_CHECK_ in an ad hoc way can be a good way > > to see if a bug is a memory corruption problem.) > > The intent is to separate debugging from core functionality to improve > security and performance (and make it easier for us to improve malloc > in future but that's unrelated in this context), so it will likely end > up in glibc-utils (that's where mtrace is) or its own package. That > will give administrators the option to remove libc_malloc_debug.so.0 > from the system. We (i.e. glibc package maintainers) are yet to agree > on the right place for this, mainly due to forgetting about it after > the mass rebuild. > > Siddhesh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Why doesn't iconv know ISO-8859-2 in rawhide?
On Fri, Jun 25, 2021 at 10:47 AM Zdenek Dohnal wrote: > Aha, it seems the rawhide buildroot from 6/23 still contained glibc with > recommends on new package and not hard requires. Sorry yes, we haven't done a build yet. I expect one to come out next week with this fix and the fix for some other breakages. > I've explicitly added glibc-gconv-extra as a buildrequires for vim now - > although as you told it is unnecessary right now, I guess it is a good > thing to track what the package actually needs (dependencies can change > with time, as I found out painfully over the years :D ). I've got a releng ticket[1] out to pull glibc-gconv-extra into the minimal buildroot so that we can weaken the dependency again. That way every package won't have to explicitly mention this dependency. Thanks, Siddhesh [1] https://pagure.io/releng/issue/10176 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fwd: glibc gconv package split
On Tue, Jun 22, 2021 at 3:56 PM Miro Hrončok wrote: > > On 22. 06. 21 4:48, Siddhesh Poyarekar wrote: > > This may result in testing failures when > > applications try to test uncommon character set conversions. The fix > > to get that working again is to add a build dependency on > > glibc-gconv-extra. > > Could you please add "glibc-gconv-extra" provide to glibc on older Fedoras > (and > if at all possible, RHELs), so we can add the BuildRequires without worrying > about backwards compatibility? Thanks for your help with this Miro, I did intend to add support to older versions later. However I've reverted this change for now in response to concerns raised about compatibility. The package split stays but it is a Requires now instead of a Recommends so there should be functionally no difference compared to how it was before. We'll give it another shot later, once we've taken a better look at (and handled) all the things we need to fix before making the dependency a weak one. Thanks, Siddhesh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Fwd: glibc gconv package split
[Fixing up my mailing list settings and re-sending] Hello, Apologies for the delayed announcement but as of glibc-2.34.9000-13.fc35, the glibc package has been split to create a new package glibc-gconv-extra to hold most converter modules into a separate package. The common converters such as those for UTF-*, ISO8859-1, ISO8859-15 and CP1252 remain in the core package. This change allows users that do not have use for the extra modules to save space as well as harden their systems; many of the infrequently used modules have historically had bugs with security impact. glibc-gconv-extra is recommended by glibc, so a regular update or default installation should pull in glibc-gconv-extra and there should be no noticeable change unless a user explicitly removes glibc-gconv-extra at some point. One user visible problem we discovered[1][2] was that buildroots do not install weak dependencies because of which glibc-gconv-extra goes missing from them. This may result in testing failures when applications try to test uncommon character set conversions. The fix to get that working again is to add a build dependency on glibc-gconv-extra. Please file bugs against glibc for any other issues you come across in charset conversions due to this split. We'll be happy to help resolve them. Siddhesh [1] https://bugzilla.redhat.com/show_bug.cgi?id=1973663 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1974466 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: sys/timeb.h removed in Rawhide?
> It's going to come back because its removal breaks compatibility with > the 2001 POSIX standard. But I expect there will be plenty of > deprecation warnings around it. It should be back now in -12.fc34, which is currently building. Siddhesh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Has glibc just removed some symbols?
> See https://koschei.fedoraproject.org/package/ocaml-dune?collection=f34 > Can the change be reverted until we can figure out exactly which > packages will have to be rebuilt? I've got a build going with that and a couple of other patches reverted. -12.f34 should unbreak this. This really shouldn't ever happen with glibc, so we'll have to figure out a way to allow static linking of older object files alongside this deprecation. Siddhesh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Should we stop stripping static libraries?
On Tuesday 15 November 2016 08:03 PM, Adam Jackson wrote: > One does not build _programs_ with/out -g. One builds objects, and > links objects into programs. Sorry I did not word that correctly - I do know that emitting debuginfo is a compile time operation but I wanted to make the case that when linking objects, the linker should be aware of whether debuginfo was requested or not at compile time to maintain consistency about the presence of debuginfo in objects. On thinking about this further though, the linker won't be able to do this automatically and it would need a hint from the compiler in some form or the other and I can't think of a sane way to do that, so I withdraw my objection. It would be nice however to make a note of this somewhere in the release notes. Thanks, Siddhesh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Should we stop stripping static libraries?
On Monday 14 November 2016 02:18 PM, Florian Weimer wrote: > Do you suggest that gcc should invoke ld with -S, unless gcc was invoked > with some -g flags or -s? Ideal behaviour would be to make ld smarter about debuginfo but I don't know if that is doable, so this should do. >> Otherwise we need to fix the linker to not include debug symbols first. > > Is this really necessary? It's not the way ld currently works. It is necessary because the idea of unexpectedly finding debuginfo in their binaries when one did not ask for it is counter-intuitive. > I think specifying -s if you want a binary without debugging information > is an acceptable workaround. It may be, but the default would be counter-intuitive. Siddhesh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Should we stop stripping static libraries?
On Friday 11 November 2016 12:46 AM, Florian Weimer wrote: > We currently call /usr/lib/rpm/brp-strip-static-archive from > %__os_install_post. This removes debugging symbols from static (.a) > libraries. > > Is this really a good idea? Due to this, glibc copies libc.a to > glibc-debuginfo, so that you can get a link with debugging symbols by > specifying “-static -L/usr/lib/debug/usr/lib64“ (potentially with > unintended side effects). I would like to get this to work by default. > > If developers does not want debugging symbols and static libraries have > them, they can link with -s, or strip the linked object. What happens if a program built without -g is linked to the libc.a with debug symbols? If it does the right thing by not including debug symbols then I think your suggestion is the right way forward. Otherwise we need to fix the linker to not include debug symbols first. Siddhesh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Requiring package test instructions
On Wed, Jul 13, 2016 at 01:23:04PM -0400, Przemek Klosowski wrote: > I think the functionality you're talking about (checking correctness of bug > fixes, etc) should be left to the original bug reporters. After all, they > raised the issue so they are invested in the result. Agreed. > Automation of those checks is tricky: bugzilla does ask for 'steps to > reproduce' and actual vs. expected results but we'd have to really come up > with a better technology to translate that into automated test cases. It's > something that looks desirable and even doable, but not quite easy. Oh no, that is not what we're aiming for. We are aiming for a set of automated *sanity tests* that run for every update. Over time maybe we could add regression tests to it that can't be added to the upstream testsuite for some reason (requiring root privs for example, much easier to do in a vm), but for now sanity tests will have to do. Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Requiring package test instructions (was: Re: Too fast karma on Bodhi updates)
On Tue, Jul 12, 2016 at 11:52:45PM -0700, Adam Williamson wrote: > FWIW, as someone who is working on this, I don't think we can > realistically aim to do distribution-level automated testing with per- > package granularity. We actually have all the bits in place to do > something like that if we wanted to - I could have some kind of PoC > using existing openQA tests in a week or so - but I just kinda don't > think it's the way to go. > > I think a more profitable angle at the distribution level is to define > what it is we actually think a distribution should do, and test whether > updates change *those* things. That's an appropriate and manageable > level of automated testing that we can actually achieve. Agreed, the automated tests are an ideal that we have set for ourselves as the glibc team and it doesn't actually plug into the distribution's goals for QE. The only real relationship with the distribution is that we want to leverage the infrastructure to do our automated tests so that we don't have to set up our own on sourceware or wherever else. > But from the perspective of the Fedora QA team, I don't think the best > thing we could do with our time is, you know, draw up a big list of > packages and start working down it, writing automated tests for one > package at a time. If we started doing that we might make some sort of > vaguely noticeable dent by, oh, say, 2026 or so. ;) Heh, no, the 'someone' I talked about would be one of us glibc maintainers or maybe some poor soul who thinks it would be a great project to dive into, not Fedora QE. We have been a bit lazy about it so far because (in addition to the fact that we don't have volunteers yet) a lot of the distribution level tests are reasonable sanity checks for glibc. Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Requiring package test instructions (was: Re: Too fast karma on Bodhi updates)
On Tue, Jul 12, 2016 at 10:26:20PM -0700, Adam Williamson wrote: > It would not be 'a lot of work', it would be a gigantic, totally > unsustainable burden. I honestly think you're shooting *way* too high > here. Even with all the recent volunteers, we have like a couple dozen I agree it is a massive task, which is why it hasn't gotten off the ground for glibc over the last year. However I remain optimistic that someone someday will do at least a fraction of the automation :) Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Requiring package test instructions (was: Re: Too fast karma on Bodhi updates)
On Tue, Jul 12, 2016 at 09:12:25PM -0700, Gerald B. Cox wrote: > Instead of concentrating on testers, what about the packagers who don't > even test their > applications before throwing them over the wall to bodhi. I've seen > packages that didn't even > get past a simple dnf requisite test because the requires statement in the > spec file was > screwed up. Now we have packagers blaming bodhi because they can't read > the instructions, > or assuming that a tester hasn't adequately tested a package because it was > just released > by bodhi (ignoring the fact that a tester could have gotten that same > package days ago from > koji). > > As others have already pointed out bodhi was never intended to be a robust > testing system. > It was intended to give the packager a high level indication of whether or > not there are issues. There is > nothing wrong with "generally functional". At least you're getting some > feedback. > If you're concerned about the quality of the testing, then simply raise the > karma limit, or turn off the auto push. I came back to clarify after thinking about it a bit more, but you beat me to it :) Devel and testing are not two sides and I realize that my initial tone seems to indicate that, so I take that back. I fully accept the idea that developers need to document ways to test their application. However at the same time, there is currently a reasonably high barrier to becoming a packager for Fedora and it might not be a bad idea to have something similar for QE. An individual wanting to get started in Fedora packaging has to prove their competence and understanding of the packaging guidelines by commenting on package review requests in addition to submitting their own package for review. There is a side door to this in the form of co-maintainership but that too is gated by a Fedora contributor. What I am looking for is a mechanism similar to that for testing. Maybe one way to do this would be to allow everyone to comment but restrict karma rights only to individuals who are in a specific group and then have that group gated by a testing mentor. This in itself will give plenty of opportunity for mentoring. > If you start putting up barriers to people providing feedback you'll soon > find you have none. Which would > you rather have, an idea that many people have installed your package and > haven't noticed any issues or > a nice complicated test plan that no one bothers to run and you are left > with no feedback. If anything, if > there is a test script, that script should be run by the packager BEFORE > they send their application to > bodhi. That would be more helpful. Barriers to entry for any engineering task should be sufficiently high that it does not grossly compromise on quality. Developers not using the automatic testing framework is obviously their fault, but that is a conversation for a different thread. Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Requiring package test instructions
On Tue, Jul 12, 2016 at 09:23:26PM +0200, Reindl Harald wrote: > nonsense - it's enough to give a sign that a potential fix don't break > things wich worked before Your point is valid without saying 'nonsense', so please be a bit more civil. I can live with a karma +1 for sanity tests if testing feedback actually describes what they did. "Looks good to me" may describe anything from a full set of sanity tests to finding the update web page visually appealing. Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Requiring package test instructions (was: Re: Too fast karma on Bodhi updates)
On Tue, Jul 12, 2016 at 03:45:54PM -0700, Adam Williamson wrote: > Bodhi works at the source package level, not binary package level. I think Jon's point was with respect to the scope of testing. With glibc (or libstdc++ that Jon would be concerned with), an ideal set of sanity tests would cover the library as well as its development files*. It will be a lot of work for each tester though. We had talked about using tunir or taskatron to automate some of it last year, but I don't think there has been any progress on that front. Siddhesh * Well with glibc it would be library, devel, locales, networking and boot, to begin to name a few things. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Requiring package test instructions (was: Re: Too fast karma on Bodhi updates)
On Tue, Jul 12, 2016 at 12:16:59PM -0700, Adam Williamson wrote:
> This is setting far too high a bar for a project like Fedora. We take
> the feedback we can get, we are not in a position to demand all update
> testers perform comprehensive testing of all possible facets of an
> update. It is always important to bear in mind that Bodhi is a system
> designed to do the best we can to provide some moderate level of update
> quality checking, it has never been intended or expected that Bodhi
> feedback is of professional-level quality and comprehensiveness.
But then we're setting the bar too low by allowing *anyone* to set
karma for the sake of it. You might as well just let developers push
packages to stable if they're 'confident' about it. If volume of
contributions is a concern then I think we need to look at other ways
to promote that without compromising on quality.
If setting the initial bar is too much then we need a way to put in
control mechanisms (and maybe have a mentorship program) when we see
a pattern of incorrect behaviour.
> Note that *only* responses to 'generally functional' are actually used
> to calculate the karma score. All the other feedback items have no
> relevance to scoring or any kind of actual technical gating mechanism,
> they are purely informational to the update submitter at this point in
> time. If 'generally functional' had no +1, it would be impossible for
> any update ever to be auto-pushed or pushed ahead of the 'waiting
> period', because no update could ever get a positive karma score.
... which is not enough. The definition of 'generally functional' is
vague, as all of us agree and we have seen examples of that being
misused in the past. Requiring devel to document their packages is
one step forward and requiring testers to provide more detailed
feedback on what they tested (so that devel can decide if that is
sufficient) should be the step after that.
> We can also allow customization at the package level ('all updates for
> package foo must get a +1 for test case bar') or update level ('don't
> push this update stable unless there's +2 for RHBZ #123456'). There's
> actually an initial implementation of this in current Bodhi, but I
> haven't seen many packagers using it. In most cases, none of the
This is what I am looking for.
Siddhesh
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Requiring package test instructions (was: Re: Too fast karma on Bodhi updates)
On Tue, Jul 12, 2016 at 11:38:01AM -0700, Adam Williamson wrote: > This isn't really correct, because there is no simple relationship > between 'bugs claimed to be fixed actually are fixed' and 'update > should be released'. Both of these are possible: > > 1) an update which fixes the bugs it claims to fix, but should *NOT* be > released > 2) an update which does not fix all the bugs it claims to fix, but > *SHOULD* be released > > An example of 1) is an update which claims to fix a minor bug, and > does, but creates a *major* bug. e.g., fixes a typo in the package > description, but causes the app not to run at all. This update should > be given -1 karma (negative response to 'Is the update generally > functional?'), not +1. > > An example of 2) is an update which claims to provides a critical > security fix and a trivial bug fix, and *does* fix the security issue, > but the trivial bug fix doesn't work. This update should be given +1 > karma (positive response to 'Is the update generally functional?'), not > -1. Sure, and I said nothing to contradict that. A good test involves verification of fixes *and* regression tests, not one or the other. However using lack of regression tests as an excuse for not verifying fixes (and more importantly, still leaving positive feedback) is not acceptable. The points you mention go into intricacies of testing feedback whereas I am talking about the very basics. > This is in fact *why*, in Bodhi 2.0, there are separate feedback > entries for each individual bug listed by the update - so testers can > separate 'does or does not fix bug X' feedback from 'update generally > works' feedback. > > It is possible (in my opinion) for a tester to reasonably provide 'Is > the update generally functional?' feedback without actually checking > all or even any of the claimed bug fixes, and I've done this myself > quite often. It can quite often be difficult (if the bug is in a very > complex use case) or impossible (if the bug is specific to e.g. a piece > of hardware you don't own) to check bug fixes. Sure, such feedback is very useful, but I don't think it should be accompanied by a karma +1. The 'update generally functional' should only have options of karma 0 and -1 IMO. Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Requiring package test instructions (was: Re: Too fast karma on Bodhi updates)
On Tue, Jul 12, 2016 at 09:49:14AM -0700, Adam Williamson wrote: > To be clear, the idea would be to have general-purpose instructions for > basic functionality testing of each package, not requiring new 'how to > test' text to be written for every individual package update, > specifically tailored to the changes in that update. It is a good idea in general, but lack of such instructions is not an excuse for not performing the one implicit set of test cases in most updates: verifying fixes to bug reports attached to the update. If a tester does not know how to do that, then they should not be giving karma at all, regardless of whether or not there is documentation on sanity tests for the package. Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: New implementation of pthread condition variables in rawhide
On Fri, May 22, 2015 at 06:21:43PM +0530, Siddhesh Poyarekar wrote: No, these are different. This problem was introduced in 2.21.90-7.fc23. The actual bug is much older and was hidden and only Of course, I meant 2.21.90-8.fc23. It worked correctly on 2.21.90-7. Siddhesh pgppya46NMMZs.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New implementation of pthread condition variables in rawhide
On Fri, May 22, 2015 at 02:39:11PM +0200, Dominik 'Rathann' Mierzejewski wrote: On Friday, 22 May 2015 at 06:57, Siddhesh Poyarekar wrote: Hi, The latest glibc in rawhide (2.21.90-13.fc23) has a new implementation for pthread condition variable functions (pthread_cond_wait, pthread_cond_timedwait, etc.). If you experience any weird locking issues or bugs that can be attributed to pthread_cond_* functions potentially misbehaving, please cc one of us (Carlos, Torvald or me) in the bug so that we can check if it is a bug in the new implementation. Could you take a look at: https://bugzilla.redhat.com/show_bug.cgi?id=1219646 https://bugzilla.redhat.com/show_bug.cgi?id=1223055 https://bugzilla.redhat.com/show_bug.cgi?id=1222551 These seem to be related. No, these are different. This problem was introduced in 2.21.90-7.fc23. The actual bug is much older and was hidden and only made obvious by a recent fix. I'm working on it. Siddhesh pgpbDD5O6hPn2.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
New implementation of pthread condition variables in rawhide
Hi, The latest glibc in rawhide (2.21.90-13.fc23) has a new implementation for pthread condition variable functions (pthread_cond_wait, pthread_cond_timedwait, etc.). If you experience any weird locking issues or bugs that can be attributed to pthread_cond_* functions potentially misbehaving, please cc one of us (Carlos, Torvald or me) in the bug so that we can check if it is a bug in the new implementation. Thanks, Siddhesh pgp3baiATRQF2.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Roaming, and libresolv being stuck in the 1980's mindset
On Sat, Apr 18, 2015 at 01:49:57PM -0600, Philip Prindeville wrote: If you go back through the previous glibc bugs, you'll find: https://sourceware.org/bugzilla/show_bug.cgi?id=984 from 2005 which was closed out as RESOLVED, WONTFIX with the text: There is a solution, already implemented. Use nscd and nscd -i hosts in the script that rewrites your resolv.conf (or nsswitch.conf etc.). Yes, that has been the upstream stance since quite some time now, so I don't know if filing a fresh bug would change that. You could however start a discussion upstream (libc-alpha at sourceware dot org) and make a case for the resolver to watch for changes in resolv.conf. Problem with that is that no one seems to have gravitated towards this solution, and I don't blame them. It adds an extra layer of complexity and makes debugging issues that much more murky. A simpler fix is to grab mtime from stat()ing _PATH_RESCONF each time through res_query() and see if it's changed since the last time. Perhaps caching the inode # also and checking that, since an older version of the file might have been renamed as /etc/resolv.conf. That is conceptually simple, but expensive, since you'll be adding syscalls to every lookup. One may argue that it is not much overhead for a network lookup since the latter will still take up a bulk of the time, but it is an added cost nevertheless. Siddhesh pgpWfuCOBPQ4C.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: glibc fix to allow instlangs to really work -- too late for f22?
On Wed, Mar 18, 2015 at 11:53:50AM +, Peter Robinson wrote: In the cloud and docker images, we've been carrying horribly hacks (really, horrible) to strip this out ofter the fact. The new fix would let us get the same effect the right way. I'm told that this is a low-risk change and does not affect the rest of glibc. So, the question -- I guess mostly for FESCo, but in general -- is: should we get this in before the beta, or should it wait for F23? How long has it been in F-23? About a week and we found some rpm build dependency issues that we fixed yesterday. The patch is fairly non-intrusive, so if it breaks too much, we can revert it fairly easily. Also, it only touches the locale-archive generation code which is Fedora-only and does not affect any functionality provided by the library itself. Siddhesh pgp_yYMus4xnf.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Self introduction: Jonathan Wakely
On Fri, Mar 06, 2015 at 01:34:36PM +, Jonathan Wakely wrote: I'm also the author of one package included in Fedora, pstreams-devel, so would be happy to help with the packaging for that. Great, you could apply for co-maintainership: http://fedoraproject.org/wiki/Package_maintainer_policy#Co-Maintainership I'm looking forward to contributing to Fedora, after getting so much enjoyment and benefit from it for so long. Welcome! Siddhesh pgpJbMT7egdtl.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Request for testers: glibc update to work around Intel TSX errata microcode_ctl problems.
On Fri, Sep 26, 2014 at 08:53:59PM +0200, Hans de Goede wrote: I've just tested the F-21 update for this, and I'm afraid that the problem is still present there. I've also regenerated my initrd to make sure that that included the new glibc too, but that did not help. Do you still see crashes in systemd within pthread code or is it something else? The update should have disabled lock elision completely, so if it SIGILLs on haswell, it ought to SIGILL on everything, which it doesn't. Either way, an early microcode update is indeed the best way out, so if that works, we could just drop the glibc update. But it would be great to know what's actually going wrong so that if it's something in glibc even with elision disabled, we can get that fixed. Siddhesh pgpFnqDgd1McE.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The GNU C Library will be rebased in F21 to match glibc 2.20.
On Thu, Jul 31, 2014 at 02:13:44PM +0100, Peter Robinson wrote: The fact that a core library that's stability is critical to the distribution as a whole doesn't bother to adhere to this and while having gone through the hoops of putting in a feature change basically then proceeded to completely ignore the requirements of said process (ie they dumped a bunch of stuff on the wiki and haven't bothered to revisit it and update it since) is some what pathetic in my mind. As an upstream policy, glibc does not break ABI[1] and we've tried to adhere to this ever since I started contributing to glibc (which is ~2 years ago). Any ABI break that happens is a bug and the ABI impact Carlos talks about is mainly due to such bugs being discovered in rawhide, which again is not very often. Siddhesh [1] We did unknowingly break ABI in S/390 in 2.19 and that will likely be fixed in 2.20 and require at least a partial rebuild (perl and its modules), but you would have needed the mass rebuild even if we would have directly introduced a 2.20 release. pgprcStwQW61j.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The GNU C Library will be rebased in F21 to match glibc 2.20.
On Thu, Jul 31, 2014 at 03:06:00PM +0100, Richard W.M. Jones wrote: However the previous problem(s -- multiple) was glibc using non-Rawhide for integration testing, especially just while we were trying to stablise Fedora for a release: https://lists.fedoraproject.org/pipermail/devel/2011-October/158440.html https://lists.fedoraproject.org/pipermail/devel/2011-October/158662.html We're absolutely not going to rebase master in non-rawhide. Our intention is to get glibc 2.20 release out before Fedora turns beta. But 2.20 is a stable branch, right? So this shouldn't be a concern now. Yes, it is in what we call, a slushy freeze right now. Changes going in are mostly regression fixes and other fixes that should not have any generated code impact. There is however one change that the s/390 folks will find painful - s/390 broke ABI in 2.19 without a proper justification and that is now going to be reverted in 2.20 (and in 2.19, but we don't really care about 2.19 right now). Siddhesh pgpgggXFB1pMe.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The GNU C Library will be rebased in F21 to match glibc 2.20.
On Thu, Jul 31, 2014 at 09:03:45AM -0400, Rahul Sundaram wrote: Yes. My concern is that glibc is using Rawhide as their continuous integration sandbox to shake out bugs as opposed to doing it elsewhere and just taking care of integration of releases when they are ready. If this viewed as a gap that needs to be fixed, that's fine for now. CI is indeed a gap that needs to be fixed, but rebasing in rawhide isn't nearly as fatal as it seems. The upstream glibc commit policy is quite stringent in that every commit is required to pass an extensive (but obviously not exhaustive) testsuite and as a result it is usually safe (as safe one would consider rawhide) to rebase from the latest commit. I've been doing regular rebases for a while now (almost a year AFAICT) and IIRC we have had just one serious problem last week where i686 boxes got bricked. In the end it was found to be a gcc bug that miscompiled some code in glibc. That said, we still need a nicer way to back out from a broken glibc update into the previous known-to-work glibc similar to how the kernel does it and not need a rescue disk for it. Siddhesh pgp5Wopct9rZT.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The GNU C Library will be rebased in F21 to match glibc 2.20.
On Wed, Jul 30, 2014 at 03:36:34PM -0400, Matthew Miller wrote: The changes in the rebase should be minor since we've been tracking master the whole time. I remember a similar process causing problems in Rawhide earlier and Jared Smith talking with the glibc team to ensure that only regular releases hit rawhide. The problem with that approach is that lots of bugs go unnoticed until very late in rawhide, resulting in those bugs being caught and fixed only post-release. Besides, this process is different in principle from the earlier one because the earlier process simply cut the latest master into a Fedora release just days before Fedora went gold. In the current process the glibc release Fedora gets is decided well in advance, that is when the Fedora release branch is cut from rawhide. Combine that with the fact that glibc upstream freezes weeks before it releases and you'll see that the glibc release that makes it into a Fedora release is eventually well tested in rawhide *and* is not ancient. It would be nice if we're careful in staging ABI changes in the glibc master into Rawhide so it doesn't break. (Possibly something we can do with Taskotron?) ABI changes are a minor problem with respect to glibc because as a principle, we don't break ABI. That is, any ABI breakages that happen are usually bugs. We try to ensure that with a basic ABI checker in the glibc testsuite and in future we'll be looking to enhance our ABI checking capabilities. Taskotron (based on a quick read from the wiki) seems to be a good framework for this. The bigger problem is bugs that brick your system because unlike kernel, there is currently no way to simply reboot into an older known-to-work glibc. We had one such situation last week and IIRC the last such situation before that was close to two years ago, so while it is serious, it is not frequent. That said, we're also thinking of ways to recover from such botched updates. Siddhesh pgpyJdhttHzjA.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS failover solution needed, nscd?
On Fri, Apr 25, 2014 at 06:51:26PM -0400, Chuck Anderson wrote: I'm starting a new thread to clarify and emphasize the problem I'm actually trying to solve. Here is the problem restated as I posted it to the dns-operations list: - Is it really expected that the first DNS server listed in /etc/resolv.conf should never go down? Operationally speaking, who can actually rely on listing multiple nameservers in /etc/resolv.conf and using libc's failover mechanism in any kind of production server? Because the failover behavior in libc is atrocious--each new or existing process has to re-do the failover after timing out, and even long-running processes have to call res_init() to re-read resolv.conf. That is because glibc does not maintain a system-wide record of this and for good reason. nscd does, but is not feature-complete (no round-robin for example). Siddhesh pgpQM6EwS6R6q.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: prelink performance gains
Resending since the last attempt bounced. On Wed, Oct 16, 2013 at 03:21:31PM +0530, Siddhesh Poyarekar wrote: On Tue, Oct 15, 2013 at 10:27:36PM +0200, Reindl Harald wrote: Do you really run gnome-open --help 1000 times per reasonable unit of time (or ever)? Please stop using bogus comparisons and highly contrived tests. They do nothing to help your argument. This isn't totally invalid. I assume that some shell scripts with tight loops are the only thing that actually benefits from prelinking today. People write those, unfortunately. it is - they are *not* loading a lot of dynmaic linked libraries It is spawning a program a bunch of times, which results in program load time becoming all the more relevant. Shell scripts that spawn multiple programs in tight loops are not exactly uncommon, so please don't pretend that they don't exist. [harry@srv-rhsoft:~]$ ldd /usr/bin/bash linux-vdso.so.1 = (0x7fffc9764000) libtinfo.so.5 = /lib64/libtinfo.so.5 (0x7f99b21aa000) libdl.so.2 = /lib64/libdl.so.2 (0x7f99b1fa6000) libc.so.6 = /lib64/libc.so.6 (0x7f99b1be4000) /lib64/ld-linux-x86-64.so.2 (0x7f99b23ee000) I'm attaching a deliberately badly written script which should be fairly representative, alas. I can' benchmark it right now because the system isn't idle, but if someone else wants to have a go at it, be my guest. if you *only* can measure it if your system is *idle* than you have what we called maske dby noise already in this thread and that is *not* significant You haven't understood the point of the statement - a benchmark measurement is reliable only if the 'before' and 'after' measurements are done in identical conditions. In that context, an idle system is the ideal pre-condition. That point has nothing to do with whether the performance improvement is evident when the system is under any amount of load. Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [coreutils] require glibc-devel to prevent broken links in coreutils info manual (#959697)
On Fri, May 17, 2013 at 11:25:31AM +0100, Daniel P. Berrange wrote: Well, I don't think glibc info doc has only developer-targetted info - that's the issue - there are more things useful to regular experienced users (like regexps info, locales info). In that case, glibc maintainers need to re-consider their claim that it is only material for developers put it in glibc-common or a glibc-docs package instead of the -devel package I felt that the bug was closed prematurely. All of us (Ondrej, myself and Carlos) live in three different time zones and a communication lag is expected. Some time should have been allowed for all of us to come to a consensus. I don't think depending on glibc-devel is a good idea either and I made that clear on the bugzilla (again now). Carlos also seems willing to explore the idea of a glibc-docs in the interim, while we figure out how to split libc.info into separate user and developer documentation nodes. Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Seeking primary maintainer for LLVM
On Mon, Feb 25, 2013 at 11:49:49AM +0700, Michel Alexandre Salim wrote: - - Refactorig LLVM's build system to properly use versioned shared objects. I note that other distributions, and BSD, are still using static linking, so we appear to be the only ones attempting to package LLVM properly. - - Dealing with Clang breaking when GCC is updated, and compatibility issues with secondary architectures Thanks to Jens for doing the 3.2 update -- and others who've been contributing packaging patches. Let me know if you're interested, and I'll release the package then. I've never looked at llvm internals before, but it would be a fun challenge for me. I can take it up if you're OK with things being broken occasionally while I figure things out. Of course, if someone else who has a clue wants to take it up, I'd like it if I could co-maintain. Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning LibRaw and gource
Hi, I don't have enough bandwidth to do anything useful with them any more, so I'm orphaning them. LibRaw is a dependency for shotwell and gource is, well, pretty neat. Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning eog
Hi, I took eog over when it was orphaned last time, since I though I could work on it some more. I never got around to anything but a couple of bug reports though and I don't think I'm really going to get around to it in the future either, so I'll just orphan it again so that someone who is really interested (or the desktop team, who probably should have been owning it in the first place and I shouldn't have just butted in that way) can pick it up. -- Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
License change in LibRaw due to inclusion of demosaic packs
Hi, I got a request to include demosaic packs into the LibRaw build to support some digital cameras: https://bugzilla.redhat.com/show_bug.cgi?id=760638 With this inclusion, the LibRaw package will have a GPLv3+ license since the demosaic packs are released under GPLv2+ and GPLv3+. Currently only shotwell seems to be using LibRaw and it should be ok with this change since it is GPLv2+. Thanks, Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
LibRaw rebase in rawhide
Hi, I have rebased LibRaw in rawhide to 0.14.3. There is now a shared library with this version, so it is recommended that packages that were linking against LibRaw statically, now do so dynamically. -- Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
vala 0.11 broke shotwell build in rawhide
Hi, The upstream shotwell does not build with vala 0.11.* since there are a bunch of incompatible changes between vala-0.10.x and 0.11.x. Is there a plan to have a parallel installable vala-0.10.x in rawhide/f15? I can't see any other way to get shotwell built. I tried making changes to shotwell-0.8.0 code to get it to build with vala, but in the end the vala compiler ends up crashing. Bug report here: https://bugzilla.redhat.com/show_bug.cgi?id=667490 -- Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vala 0.11 broke shotwell build in rawhide
On Wed, Jan 05, 2011 at 07:31:13PM +, Peter Robinson wrote: Well as vala generates C code the current version should continue to function until shotwell 0.9.x comes out and adds support for the newer vala and it can be compiled or a patch appears in head that we can apply to 0.8.x https://bugzilla.redhat.com/show_bug.cgi?id=667490 I already have a patch; see the bugzilla above. The problem is that the patch crashes vala. -- Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: vala 0.11 broke shotwell build in rawhide
On Thu, Jan 06, 2011 at 08:03:20AM +0530, Siddhesh Poyarekar wrote: On Wed, Jan 05, 2011 at 07:31:13PM +, Peter Robinson wrote: Well as vala generates C code the current version should continue to function until shotwell 0.9.x comes out and adds support for the newer vala and it can be compiled or a patch appears in head that we can apply to 0.8.x https://bugzilla.redhat.com/show_bug.cgi?id=667490 I already have a patch; see the bugzilla above. The problem is that the patch crashes vala. Ahh, please ignore this. I saw your comment on the bugzilla now. Is there any documentation that describes these API changes? valadoc.org seems to have vala 0.10.x related documentation. -- Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: End of life in bugzilla, how to reopen?
On Tue, Dec 07, 2010 at 05:45:58PM +0100, Andreas Tunek wrote: How do I reopen the bug? Previously in the bug report I stated that this affects F14 as well (not F13), but I can not change the version. Do I have to file a new bug? I have reopened it for you. -- Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates to static library packages
On Sat, Nov 13, 2010 at 11:38:50PM +, Michel Alexandre Salim wrote: I'd say do try a rebuild of affected packages yourself, and notify the maintainers only in case there is a breakage and coordinate on what to do (otherwise they'd get an unpleasant FTBFS report). That was helpful, thank you :) -- Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Updates to static library packages
Hi, I maintain LibRaw, which is only a static library -- upstream has rejected the idea of maintaining dynamic libs since they would have to take care of ABI compatibility across releases. I wanted to know if there are any other only-static libraries out there and how they maintainers manage releases. I had packaged this to build Shotwell 0.6.x but I understand there are a couple of other apps too that build against this now. Do i have to keep track of all of them and coordinate releases with them, i.e. announce an update, have them test and then push a build? Or do I just go ahead and build in rawhide and then wait for someone to complain? Thanks, Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Build on dist-git for F-14: FAILED: GenericError: Build already exists
On Thu, Aug 05, 2010 at 08:53:17PM +0200, Michael Schwendt wrote:
On Fri, 6 Aug 2010 00:17:23 +0530, Siddhesh wrote:
Hi,
I'm trying to build gource for F-14 and I get the following error:
2382335 build (dist-f14-updates-candidate,
/gource:94e27ff92af9990ba724746702f7e34c50af0ae1): open
(x86-10.phx2.fedoraproject.org) - FAILED: GenericError: Build already
exists (id=188463, state=COMPLETE): {'name': 'gource', 'task_id': 2382335,
'pkg_id': 9935, 'epoch': None, 'completion_time': None, 'state': 0,
'version': '0.27', 'owner': 1323, 'release': '1', 'id': 188463}
0 free 0 open 1 done 1 failed
http://koji.fedoraproject.org/koji/buildinfo?buildID=188463
You don't use %{?dist} in your Release value, and the 0.27-1 build
is already done. There can be only one build with that version-release.
Doh! I knew it was something very trivial; thanks for pointing out. I
accidentally removed it while changing release numbers from the
previous beta release.
Also, probably an unrelated question, but aren't tags added to the scm
anymore with the build? I expected a 0.27 tag to be added to master,
but that did not happen.
It's not done yet. Where you want tags, you could use:
git tag $(fedpkg verrel)
git push --tags
Thanks,
Siddhesh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaned packages (was Re:)
On Thu, Jul 01, 2010 at 01:07:02PM -0400, Toshio Kuratomi wrote: libart_l...@fedoraproject.org, liboil-ow...@fedoraproject.org, librs...@fedoraproject.org Bcc: Subject: A few orphaned desktop/graphics packages Reply-To: The following packages related to graphics and the desktop have been orphaned by Behdad:: 'eog', 'gthumb', 'libart_lgpl', 'liboil', 'librsvg2' I'll take eog. -- Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
LibRaw: Library for reading RAW files obtained from digital cameras
Hi, I have packaged LibRaw since it is needed to build Shotwell trunk. Review Request link here: https://bugzilla.redhat.com/show_bug.cgi?id=602279 Anyone trying to build Shotwell will need this and gexiv2, which has also been packaged: https://bugzilla.redhat.com/show_bug.cgi?id=599097 -- Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
