Re: New hardened build support (coming) in F16
On Mon, 2011-08-08 at 23:16 -0400, Steve Grubb wrote: > I think there should have been some discussion about this on the FESCO > request > I submitted. I have some concerns about what was implemented. Are there bz > filed for this or more discussion about it somewhere? most of the discussion happened via the weekly FESCo meetings, I believe, which are logged by meetbot - check http://meetbot.fedoraproject.org/fedora-meeting/ for the dates / times of fesco meetings. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: some locales crashes gnome-shell
On Mon, Aug 8, 2011 at 11:32 PM, Muayyad AlSadi wrote: > %A %Ol:%OM %p %OIis replaced by the hour (12-hour clock) using the locale's alternative numeric symbols. %OMis replaced by the minutes using the locale's alternative numeric symbols. it seems that Shell.util_format_date which relies on g_date_time_format () does not support those strftime formats see http://developer.gnome.org/glib/2.29/glib-GDateTime.html#g-date-time-format http://pubs.opengroup.org/onlinepubs/007908799/xsh/strftime.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: some locales crashes gnome-shell
please use the attached patch till we fix glib or fix mozilla https://bugzilla.redhat.com/show_bug.cgi?id=728889 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abiword
I've done rawhide. It seems I don't have the permissions to do a builld override even though I'm a proven packager and secondary arch maintainer. If you could submit the build-override for the package I'll rebuild abiword for f-16. Peter On Tue, Aug 9, 2011 at 6:30 AM, Johannes Lips wrote: > Just a quick note that I just built link-grammar for f17 and f16. So > abiword should be able to depend on it again! > > Johannes > -- > 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
Re: New hardened build support (coming) in F16
On 08/08/2011 06:23 PM, Adam Jackson wrote: > Once that's done (and redhat-rpm-config-9.1.0-15.fc16 has been gone > through updates), if you're using a %configure-style spec file, defining > the magic macro is all you have to do. The rpm macros will notice the > macro, and put the right magic into CFLAGS and LDFLAGS, and everything > is great and wonderful. I am not sure I understand the implications. If I compile my package which provides a daemon (=worth full relro) and few libraries with the magic macro, which defines LDFLAGS=-Wl,-z,now, all shared libraries from the build will get full relro too. What happens to applications, which link my libs? 1) will they start slower because of the relocations in the shared lib? 2) can they use prelink? Or should I hack Makefiles to use full relro only for daemons (and other security relevant binaries) and leave shared libs with partial relro only? Will be the daemon 'safe enough' if it consumes libraries with partial relro? -- Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Trouble with gnome-sound-applet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I've filed a bug for the control-center package (https://bugzilla.redhat.com/show_bug.cgi?id=729271) because I ran into a boring problem with gnome-sound-applet, which is part of that package, on my Xfce desktop. The gnome-sound-applet is autostarted everytime allthough I've removed its entry from gnome-session-properties and its link from ~/.config/autostart. So whats the best way to fix this problem until the package maintainer takes action? And as I wrote in that bug: I can not remove control-center because I need the gnome-bluetooth package which depends on control-center. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk5BED4ACgkQ/zGbOvPHkcJh1QD9EI5FTfc+XaRRvOYYUkGebOHz nHzYxjoEn3m1XS4WoIMA/jvYQqzJZ3ZcR1eDszXlJgFWBqQNW6vZNnEomq12WlJI =XV0u -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Mon, Aug 08, 2011 at 11:16:12PM -0400, Steve Grubb wrote: > This list is woefully incomplete. I would advocate a much larger list. For > example, sudo is a very important program that we make security claims about. > It is not on that list. Because it's SUID. > I think there should have been some discussion about this on the FESCO > request > I submitted. I have some concerns about what was implemented. Are there bz > filed for this or more discussion about it somewhere? We spent weeks discussing this. Where were you during the meetings? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Handle sonames
On Tue, Aug 9, 2011 at 12:42 AM, Jussi Lehtola < jussileht...@fedoraproject.org> wrote: > > > https://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering#Arch-specific_extensions_to_scripting_languages > > -- > Jussi Lehtola > Fedora Project Contributor > jussileht...@fedoraproject.org > Thanks, It solved the problem. -- Praveen Kumar http://fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Tuesday, August 09, 2011 07:51:07 AM Matthew Garrett wrote: > On Mon, Aug 08, 2011 at 11:16:12PM -0400, Steve Grubb wrote: > > This list is woefully incomplete. I would advocate a much larger list. > > For example, sudo is a very important program that we make security > > claims about. It is not on that list. > > Because it's SUID. ? Its one in the target group. > > I think there should have been some discussion about this on the FESCO > > request I submitted. I have some concerns about what was implemented. > > Are there bz filed for this or more discussion about it somewhere? > > We spent weeks discussing this. Where were you during the meetings? Taking RHEL6 through common criteria and FIPS-140, filing dozens of security bugs after studying some problems and sending patches. I am monitoring the FESCO ticket, but I don't monitor fedora-devel all the time because there are way too many arguments for my taste. Regardless, should there not have been some hint about anything on the ticket? I responded to any review request for the wiki page and such. My main concern is that the macro will be misapplied and overall performance will take a hit. I don't know how a macro can tell the intent of an application as it links it. There has not been a chmod so that it knows this is setuid and needs more protection. For example, if coreutils was built with this (and coreutils seems to be correct as is) because it has setuid programs, then would all apps get the PIE/Full RELRO treatment? If so, many of coreutils apps are called constantly by shell scripts. If this were used on tcpdump, would full relro leak to the libpcap? I suppose I could test this as soon as I set up a rawhide vm...but this is what concerns me about the approach. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 15 kernel 2.6.40-4 issues on EC2
Hi, In BoxGrinder we're seeing some issues when upgrading to latest kernel on AMI's, which was reported here: https://issues.jboss.org/browse/BGBUILD-289 You can see in that ticket full boot log (console log in AWS terms) from a started instance with newest kernel. Jeremy pointed out that the issue may be related to newest kernel: 2.6.40-4: [quote] I came across this issue searching for a possibly related problem. I had been running Fedora 15 on EC2 successfully using the 1.6 Boxgrinder AMI. Yesterday, I applied the latest updates, including kernel-2.6.40-4.fc15.x86_64 and added a boot entry in /boot/grub/menu.lst. On reboot, I saw similar messages in the console log to what was mentioned here. Attaching my boot EBS volume to another instance and changing the kernel back to kernel-2.6.38.8-35.fc15.x86_64 allowed my instance to boot normally. [/quote] Anyone can tell me more after reading the console log? TIA --Marek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Heads up: e2fsprogs-1.42-WIP-0702 pushed to rawhide
... now, finally, with more 64-bit-ness! >From Ted: > I've made the first WIP release of e2fsprogs 1.42. The primary purpose > is for people to test the 64-bit functionality and be confident that we > didn't introduce any 32-bit regressions. So in theory you can at least mfks & mount a 16T fs and beyond, if you'd like to test that. There was also enough surgery that testing it against older, smaller filesystems is welcomed too. Thanks, -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abiword
I've filed the following ticket https://fedorahosted.org/rel-eng/ticket/4873 and created an update for f16, forgot that this morning. I hope this was in line with the general guidelines of this process. Johannes On 08/09/2011 10:36 AM, Peter Robinson wrote: > I've done rawhide. It seems I don't have the permissions to do a > builld override even though I'm a proven packager and secondary arch > maintainer. > > If you could submit the build-override for the package I'll rebuild > abiword for f-16. > > Peter > > On Tue, Aug 9, 2011 at 6:30 AM, Johannes Lips > wrote: >> Just a quick note that I just built link-grammar for f17 and f16. So >> abiword should be able to depend on it again! >> >> Johannes >> -- >> 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
Re: New hardened build support (coming) in F16
On Tue, Aug 09, 2011 at 08:47:16AM -0400, Steve Grubb wrote: > On Tuesday, August 09, 2011 07:51:07 AM Matthew Garrett wrote: > > On Mon, Aug 08, 2011 at 11:16:12PM -0400, Steve Grubb wrote: > > > This list is woefully incomplete. I would advocate a much larger list. > > > For example, sudo is a very important program that we make security > > > claims about. It is not on that list. > > > > Because it's SUID. > > ? Its one in the target group. Yes. The list isn't intended to be exhaustive - it's already been made clear above that SUID applications should be covered. > > > I think there should have been some discussion about this on the FESCO > > > request I submitted. I have some concerns about what was implemented. > > > Are there bz filed for this or more discussion about it somewhere? > > > > We spent weeks discussing this. Where were you during the meetings? > > Taking RHEL6 through common criteria and FIPS-140, filing dozens of security > bugs after studying some problems and sending patches. I am monitoring the > FESCO ticket, but I don't monitor fedora-devel all the time because there are > way too many arguments for my taste. Regardless, should there not have been > some hint about anything on the ticket? I responded to any review request for > the wiki page and such. You can't bring a policy to FESCO, fail to turn up to any of the meetings and then be surprised if the enacted proposal doesn't perfectly match yours. The ticket was flagged "meeting" up until the point where it was closed which means it's under active consideration, and the meeting summaries posted to fedora-devel contained the various proposals and action items that we worked through. > My main concern is that the macro will be misapplied and overall performance > will take a hit. I don't know how a macro can tell the intent of an > application as it links it. There has not been a chmod so that it knows this > is setuid and needs more protection. For example, if coreutils was built with > this (and coreutils seems to be correct as is) because it has setuid > programs, > then would all apps get the PIE/Full RELRO treatment? If so, many of > coreutils > apps are called constantly by shell scripts. If this were used on tcpdump, > would full relro leak to the libpcap? I suppose I could test this as soon as > I > set up a rawhide vm...but this is what concerns me about the approach. The aim was to come up with a policy that is straightforward for maintainers to implement. Making it more complex for small performance benefits (coreutils applications may be called often, but they're also pretty tiny - have you actually measured a significant difference in real world cases?) increases the risk that someone will make a mistake and we'll ship code that's less secure than it was supposed to be. Like anything, it's a tradeoff. If it causes problems then we can tweak the implementation, and if you'd prefer you can think of this as a starting point. Nothing FESCO comes up with is set in stone. We'll be happy to modify the policy in response to technical feedback. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abiword
You do build overrides in bodhi now. Its a menu option on the left panel. Peter On Tue, Aug 9, 2011 at 2:18 PM, Johannes Lips wrote: > I've filed the following ticket > https://fedorahosted.org/rel-eng/ticket/4873 > and created an update for f16, forgot that this morning. > I hope this was in line with the general guidelines of this process. > > Johannes > On 08/09/2011 10:36 AM, Peter Robinson wrote: >> I've done rawhide. It seems I don't have the permissions to do a >> builld override even though I'm a proven packager and secondary arch >> maintainer. >> >> If you could submit the build-override for the package I'll rebuild >> abiword for f-16. >> >> Peter >> >> On Tue, Aug 9, 2011 at 6:30 AM, Johannes Lips >> wrote: >>> Just a quick note that I just built link-grammar for f17 and f16. So >>> abiword should be able to depend on it again! >>> >>> Johannes >>> -- >>> 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 > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
Steve Grubb wrote: > On Tuesday, August 09, 2011 07:51:07 AM Matthew Garrett wrote: > >> On Mon, Aug 08, 2011 at 11:16:12PM -0400, Steve Grubb wrote: >> >>> This list is woefully incomplete. I would advocate a much larger list. >>> For example, sudo is a very important program that we make security >>> claims about. It is not on that list. >>> >> Because it's SUID. >> > > ? Its one in the target group. > > > >>> I think there should have been some discussion about this on the FESCO >>> request I submitted. I have some concerns about what was implemented. >>> Are there bz filed for this or more discussion about it somewhere? >>> >> We spent weeks discussing this. Where were you during the meetings? >> > > Taking RHEL6 through common criteria and FIPS-140, filing dozens of security > bugs after studying some problems and sending patches. I am monitoring the > FESCO ticket, but I don't monitor fedora-devel all the time because there are > way too many arguments for my taste. Regardless, should there not have been > some hint about anything on the ticket? I responded to any review request for > the wiki page and such. > > My main concern is that the macro will be misapplied and overall performance > will take a hit. I don't know how a macro can tell the intent of an > application as it links it. The macro can't, but the maintainer can. The maintainer is presumably capable of, and responsible for, assessing whether her package would be a good candidate for this, and if so, testing builds done with the macro. Then if, performance is fine, on it goes. If performance sucks, it doesn't. -J > There has not been a chmod so that it knows this > is setuid and needs more protection. For example, if coreutils was built with > this (and coreutils seems to be correct as is) because it has setuid > programs, > then would all apps get the PIE/Full RELRO treatment? If so, many of > coreutils > apps are called constantly by shell scripts. If this were used on tcpdump, > would full relro leak to the libpcap? I suppose I could test this as soon as > I > set up a rawhide vm...but this is what concerns me about the approach. > > -Steve > -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On 08/09/2011 08:47 AM, Steve Grubb wrote: > My main concern is that the macro will be misapplied and overall performance > will take a hit. I don't know how a macro can tell the intent of an > application as it links it. There has not been a chmod so that it knows this > is setuid and needs more protection. For example, if coreutils was built > with this (and coreutils seems to be correct as is) because it has setuid > programs, then would all apps get the PIE/Full RELRO treatment? If so, many > of coreutils apps are called constantly by shell scripts. If this were used > on tcpdump, would full relro leak to the libpcap? I suppose I could test this > as soon as I set up a rawhide vm...but this is what concerns me about the > approach. I think invoking coreutils is a pretty bogus example since it's full of relatively small binaries which don't take long to relocate. That being said, you don't *have* to use the macro. If your package needs a more nuanced approach to PIE and relro, and needs choices to be made on a per-binary basis, that's fine. There are a couple of approaches you could use here, most obviously just writing your makefile to be aware of these requirements. You own your packages and their makefiles. Knock yourself out. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abiword
Ok, did that now. If you need any further action from my side, just let me know. Johannes On 08/09/2011 03:24 PM, Peter Robinson wrote: > You do build overrides in bodhi now. Its a menu option on the left panel. > > Peter > > On Tue, Aug 9, 2011 at 2:18 PM, Johannes Lips > wrote: >> I've filed the following ticket >> https://fedorahosted.org/rel-eng/ticket/4873 >> and created an update for f16, forgot that this morning. >> I hope this was in line with the general guidelines of this process. >> >> Johannes >> On 08/09/2011 10:36 AM, Peter Robinson wrote: >>> I've done rawhide. It seems I don't have the permissions to do a >>> builld override even though I'm a proven packager and secondary arch >>> maintainer. >>> >>> If you could submit the build-override for the package I'll rebuild >>> abiword for f-16. >>> >>> Peter >>> >>> On Tue, Aug 9, 2011 at 6:30 AM, Johannes Lips >>> wrote: Just a quick note that I just built link-grammar for f17 and f16. So abiword should be able to depend on it again! Johannes -- 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 >> -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Config-Auto-0.38.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Config-Auto: cf6fbd37e27726dd8373faa13a85e31f Config-Auto-0.38.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: New hardened build support (coming) in F16
Steve Grubb wrote:
> This is not the policy that I asked for.
Well, what Ajax described isn't a policy at all. It's a set of RPM macros
designed to make it easier to follow the (soon to be) policy. RPM macros can't
enforce the policy. Enforcement must be done elsewhere.
> When you make a PIE executable,
> you get ASLR which is good. But the way it does that is making a weakness
> in the executable for the relocations. It causes a new segment to be
> writable. So, you need full relro support when you do PIE to cover that
> new weakness.
As far as I can see that is what the new RPM macros do, provided that the
configuration script supports both CFLAGS/CXXFLAGS/FFLAGS and LDFLAGS, or that
the spec file inserts %{optflags} and %{__global_ldflags} in the right places.
If
you think the macros do something wrong, it might help if you point out where
the error is.
> What we want is this:
> 1) Everything is compiled with partial relro. Libraries, executables,
> daemons, setuid/setgid/setcap apps.
Everything will be, if LDFLAGS or __global_ldflags is used correctly. The
current policy already requires that "the applicable compiler flags set in the
system rpm configuration" be honored. If we want to be pedantic we should
perhaps change that to "compiler and linker flags".
> 2) Anything that is setgid/setuid/setcap/daemon also include the "now"
> flags and is PIE.
https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_flags
mentions daemons, suid and capabilities, so you want to add setgid to that,
correct?
Do you also mean that you want "should consider enabling" changed to "must
enable"?
> 3) Anything that is parsing data from untrusted sources should also have
> full relro/pie. That would be things like tcpdump/wireshark/firefox/evince
> /file/netpbm etc.
I believe that's what the "FESCo list side" on
https://fedoraproject.org/wiki/User:Kevin/DRAFT_When_to_use_PIE_compiler_flags
attempts to address. The etc is the hard part of course.
> 4) Anything that has pie, should should also have full relro, therefore we
> need to double check anything with PIE to make sure its really a good idea.
Detecting programs that have been built with PIE but without -z now is
obviously beyond the scope of the _hardened_build macro, but your rpm-chksec
sounds like a good tool.
> I sent an email to the fedora-test list last week announcing a program that
> can check any package or the whole distribution for compliance with this
> policy with the exception of rule #3 above. No idea how to make a heuristic
> for that. The program is located here:
>
> http://people.redhat.com/sgrubb/files/rpm-chksec
Perhaps that could be invoked automatically each time a package is built,
similarly to how /usr/lib/rpm/check-rpaths is used?
Björn Persson
signature.asc
Description: This is a digitally signed message part.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Tuesday, August 09, 2011 09:20:53 AM Matthew Garrett wrote: > > Taking RHEL6 through common criteria and FIPS-140, filing dozens of > > security bugs after studying some problems and sending patches. I am > > monitoring the FESCO ticket, but I don't monitor fedora-devel all the > > time because there are way too many arguments for my taste. Regardless, > > should there not have been some hint about anything on the ticket? I > > responded to any review request for the wiki page and such. > > You can't bring a policy to FESCO, fail to turn up to any of the > meetings I didn't fail to turn up to any of the meetings. I watched the issue and attended until it was approved. I then turned my attention to other things like how to scan a distribution to find packages that need updating. I posted a link to my script on the ticket. Just adding a global LDFLAGS accomplishes most of what is needed. The only issue left is when you have a daemon/setuid/setgid/setcap or something parsing untrusted media. Those are all the kind of packages that the maintainer should be skilled enough that they ought to know how to add flags since they would be attack vectors. > and then be surprised if the enacted proposal doesn't perfectly > match yours. The ticket was flagged "meeting" up until the point where > it was closed which means it's under active consideration, and the > meeting summaries posted to fedora-devel contained the various proposals > and action items that we worked through. I would rather have seen a macro added to auto tools to detect gcc support for this so that upstream developers can more easily add the support natively for all distributions. > > My main concern is that the macro will be misapplied and overall > > performance will take a hit. I don't know how a macro can tell the > > intent of an application as it links it. There has not been a chmod so > > that it knows this is setuid and needs more protection. For example, if > > coreutils was built with this (and coreutils seems to be correct as is) > > because it has setuid programs, then would all apps get the PIE/Full > > RELRO treatment? If so, many of coreutils apps are called constantly by > > shell scripts. If this were used on tcpdump, would full relro leak to > > the libpcap? I suppose I could test this as soon as I set up a rawhide > > vm...but this is what concerns me about the approach. > > The aim was to come up with a policy that is straightforward for > maintainers to implement. Making it more complex for small performance > benefits (coreutils applications may be called often, but they're also > pretty tiny - have you actually measured a significant difference in > real world cases?) The compiler folks objected to enable full relro/pie across the board, so I assume they know there is a penalty and we should heed their advice. > increases the risk that someone will make a mistake > and we'll ship code that's less secure than it was supposed to be. That is why I developed a lot of test scripts...so that we check the distribution for security issues. All you need to do is get an install everything setup, and run ./rpm-chksec --all it will grade all the installed packages to see if the comply (with the exception of the parses untrusted media use case). I also have a bunch of other test scripts here: http://people.redhat.com/sgrubb/security if you want to check the distro more. > Like anything, it's a tradeoff. If it causes problems then we can tweak > the implementation, and if you'd prefer you can think of this as a > starting point. Nothing FESCO comes up with is set in stone. We'll be > happy to modify the policy in response to technical feedback. OK. Thanks, -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Tue, Aug 09, 2011 at 10:17:29AM -0400, Steve Grubb wrote: > On Tuesday, August 09, 2011 09:20:53 AM Matthew Garrett wrote: > > You can't bring a policy to FESCO, fail to turn up to any of the > > meetings > > I didn't fail to turn up to any of the meetings. I watched the issue and > attended until it was approved. I then turned my attention to other things > like how to scan a distribution to find packages that need updating. I posted > a > link to my script on the ticket. Just adding a global LDFLAGS accomplishes > most of what is needed. The only issue left is when you have a > daemon/setuid/setgid/setcap or something parsing untrusted media. Those are > all the kind of packages that the maintainer should be skilled enough that > they ought to know how to add flags since they would be attack vectors. Which means I'm very unclear on what you're unhappy about. The implementation Adam provided is what we agreed on in the meetings. > > and then be surprised if the enacted proposal doesn't perfectly > > match yours. The ticket was flagged "meeting" up until the point where > > it was closed which means it's under active consideration, and the > > meeting summaries posted to fedora-devel contained the various proposals > > and action items that we worked through. > > I would rather have seen a macro added to auto tools to detect gcc support > for > this so that upstream developers can more easily add the support natively for > all distributions. We have a huge number of packages that aren't built with autotools. > > The aim was to come up with a policy that is straightforward for > > maintainers to implement. Making it more complex for small performance > > benefits (coreutils applications may be called often, but they're also > > pretty tiny - have you actually measured a significant difference in > > real world cases?) > > The compiler folks objected to enable full relro/pie across the board, so I > assume they know there is a penalty and we should heed their advice. And that's why we're not enabling it across the board. The impact it has on any given package will depend on the size of the binaries and the way they're called. If imposing it upon coreutils results in a real increase in execution time then coreutils should adopt a different approach to implementing this, but if there are no benchmarks showing that it's a problem then it's really not worth caring about. > > increases the risk that someone will make a mistake > > and we'll ship code that's less secure than it was supposed to be. > > That is why I developed a lot of test scripts...so that we check the > distribution for security issues. All you need to do is get an install > everything setup, and run ./rpm-chksec --all it will grade all the installed > packages to see if the comply (with the exception of the parses untrusted > media use case). Which is fine, and then someone does a build just before release and screws it up. Unless the checking is part of autoqa this simply isn't sufficient. There's a huge benefit to implementing it in the way that's easiest for maintainers. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
advice on libjpeg
Hello, One of the packages[2] I am trying to package requires libjpeg from the ijg[1]. Since fedora is using libjpeg-turbo, I wanted to know if libjpeg and libjpeg are installable in parallel? Should I package libjpeg as a build dep, or should I be trying to patch the source to use libjpeg-turbo? [1] http://libjpeg.sourceforge.net/ [2] http://ingenium.home.xs4all.nl/dicom.html -- Thanks, Regards, Ankur: "FranciscoD" http://fedoraproject.org/wiki/User:Ankursinha http://dodoincfedora.wordpress.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: advice on libjpeg
2011/8/9 Ankur Sinha : > Hello, > > One of the packages[2] I am trying to package requires libjpeg from the > ijg[1]. Since fedora is using libjpeg-turbo, I wanted to know if libjpeg > and libjpeg are installable in parallel? Should I package libjpeg as a > build dep, or should I be trying to patch the source to use > libjpeg-turbo? libjpeg-turbo claimed to be a drop-in replacement for libjpeg. If some incompatibilities does exist then I'd rather to invest some time in fixing application to recognize and build against libjpeg-turbo. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On 08/09/2011 10:17 AM, Steve Grubb wrote: > I didn't fail to turn up to any of the meetings. ... > I would rather have seen a macro added to auto tools to detect gcc support > for this so that upstream developers can more easily add the support natively > for all distributions. So you just failed to *participate* in the meetings then? This is an approach that should have been brought up in those discussions, not in a mailing list rant after the fact. > The compiler folks objected to enable full relro/pie across the board, so I > assume they know there is a penalty and we should heed their advice. We did heed their advice, which you'd know if you'd either a) read what ajax has said here, or b) actually participated in the meetings where we discussed this. -- Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New hardened build support (coming) in F16
On Tue, 2011-08-09 at 08:47 -0400, Steve Grubb wrote: > My main concern is that the macro will be misapplied and overall performance > will take a hit. That's a valid concern, but any hardened build would have this problem. I'm happy to talk about how the performance impact can be mitigated, but it seems unfair to blame a convenience macro for being convenient. > I don't know how a macro can tell the intent of an application as it > links it. There has not been a chmod so that it knows this is setuid > and needs more protection. Sure, but you can't possibly know suid-ness until %files time anyway. I was not attempting to enforce a policy here. I was attempting to make applying hardened build flags easy in the common case. This isn't an excuse for not using one's brain as a packager. I had hoped I had made that clear, and I did not intend to imply that this was the _only_ way to get a hardened build, but I apologize for being insufficiently precise. > For example, if coreutils was built with this (and coreutils seems to > be correct as is) because it has setuid programs, then would all apps > get the PIE/Full RELRO treatment? If so, many of coreutils apps are > called constantly by shell scripts. Yes, they would. coreutils might not be a suitable target for this flag. That's okay, coreutils is welcome to customize its build using something other than this convenience macro. > If this were used on tcpdump, would full relro leak to the libpcap? I'm not sure why you raise this concern in this particular context, since the semantics would be the same regardless of this macro. But since this detail is worth expanding on, let's ask the dynamic linker what happens. Prelink makes this harder than you might hope, but if I'm reading the scrolls right, LD_USE_LOAD_BIAS=0 effectively turns it off, and LD_DEBUG=reloc will show us the steps in relocation processing. So what does a normal execution look like? % LD_USE_LOAD_BIAS=0 LD_DEBUG=reloc /bin/ls /dev/null |& grep reloc 6762: relocation processing: /lib64/libattr.so.1 (lazy) 6762: relocation processing: /lib64/libpthread.so.0 (lazy) 6762: relocation processing: /lib64/libdl.so.2 (lazy) 6762: relocation processing: /lib64/libc.so.6 6762: relocation processing: /lib64/libacl.so.1 (lazy) 6762: relocation processing: /lib64/libcap.so.2 (lazy) 6762: relocation processing: /lib64/librt.so.1 (lazy) 6762: relocation processing: /lib64/libselinux.so.1 (lazy) 6762: relocation processing: /bin/ls (lazy) 6762: relocation processing: /lib64/ld-linux-x86-64.so.2 Note that libc and ld.so are not described as lazy. This is because they have been linked with -z now: % eu-readelf -a /lib64/libc.so.6 | grep BIND_NOW FLAGS BIND_NOW STATIC_TLS % eu-readelf -a /lib64/ld-linux-x86-64.so.2 | grep BIND_NOW BIND_NOW What if we were to force the issue? % LD_BIND_NOW=1 LD_USE_LOAD_BIAS=0 LD_DEBUG=reloc /bin/ls /dev/null |& grep reloc 6766: relocation processing: /lib64/libattr.so.1 6766: relocation processing: /lib64/libpthread.so.0 6766: relocation processing: /lib64/libdl.so.2 6766: relocation processing: /lib64/libc.so.6 6766: relocation processing: /lib64/libacl.so.1 6766: relocation processing: /lib64/libcap.so.2 6766: relocation processing: /lib64/librt.so.1 6766: relocation processing: /lib64/libselinux.so.1 6766: relocation processing: /bin/ls 6766: relocation processing: /lib64/ld-linux-x86-64.so.2 Cool, looks like that does what we would expect. But does the environment variable have a different effect than if the executable itself were marked DT_BIND_NOW? Well, let's try with a program that _is_ already -z now: % eu-readelf -a /usr/bin/ssh | grep BIND_NOW BIND_NOW % LD_USE_LOAD_BIAS=0 LD_DEBUG=reloc /usr/bin/ssh -V |& grep reloc 6790: relocation processing: /lib64/libpthread.so.0 (lazy) 6790: relocation processing: /lib64/libkeyutils.so.1 (lazy) 6790: relocation processing: /lib64/libkrb5support.so.0 (lazy) 6790: relocation processing: /lib64/libfreebl3.so (lazy) 6790: relocation processing: /usr/lib64/libsasl2.so.2 (lazy) 6790: relocation processing: /lib64/libnspr4.so (lazy) 6790: relocation processing: /lib64/libplc4.so (lazy) 6790: relocation processing: /lib64/libplds4.so (lazy) 6790: relocation processing: /usr/lib64/libnssutil3.so (lazy) 6790: relocation processing: /usr/lib64/libnss3.so (lazy) 6790: relocation processing: /usr/lib64/libsmime3.so (lazy) 6790: relocation processing: /usr/lib64/libssl3.so (lazy) 6790: relocation processing: /lib64/libc.so.6 6790: relocation processing: /lib64/libcom_err.so.2 (lazy) 6790: relocation processing: /lib64/libk5crypto.so.3 (lazy)
[PATCH] macros: Globally add --disable-silent-rules to configure
See attached.
From d24d382c325c8794c05bcb56b3820b15e4a67e55 Mon Sep 17 00:00:00 2001
From: Colin Walters
Date: Tue, 9 Aug 2011 10:42:06 -0400
Subject: [PATCH] macros: Globally add --disable-silent-rules to configure
Various projects have been adding AM_SILENT_RULES from Automake to
their Makefiles for "developer convenience"; the goal being that they
see warnings more easily.
Now really the right way to do this is to have a make wrapper (or an IDE)
that knows how to filter out warnings, but let's leave that aside for now.
But for debugging builds, we really need the full log data. Being
able to see exactly how e.g. libtool is being run helps a lot for
debugging link problems as an example.
---
macros |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/macros b/macros
index d7bf415..237e1f4 100644
--- a/macros
+++ b/macros
@@ -35,6 +35,7 @@
%{_configure} --build=%{_build} --host=%{_host} \\\
--program-prefix=%{?_program_prefix} \\\
--disable-dependency-tracking \\\
+ --disable-silent-rules \\\
--prefix=%{_prefix} \\\
--exec-prefix=%{_exec_prefix} \\\
--bindir=%{_bindir} \\\
--
1.7.6
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abiword
On Tue, 09 Aug 2011 15:40:58 +0200 Johannes Lips wrote: > Ok, did that now. If you need any further action from my side, just > let me know. Please note that I have a update with no link-grammar in as: https://admin.fedoraproject.org/updates/abiword-2.8.6-12.fc16 Please test and add karma. Also, please wait to rebuild with link grammar until after Alpha? If we boot this update out and add link-grammar and new abiword I fear it will not get into the compose in time. ;( kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Autodetecting insufficiently hardened builds (was: New hardened build support (coming) in F16)
Matthew Garrett wrote: > Unless the checking is part of autoqa this simply isn't > sufficient. There's a huge benefit to implementing it in the way that's > easiest for maintainers. The earlier a problem is detected, the cheaper it is to fix. If I have understood AutoQA right, it gets involved only after I submit a package to updates-testing. Even better, when possible, is to detect problems during the build, so that I notice them when I test-build locally and can fix them before I even commit the changes to Git. Some checks are already done at build time, and Steve's points 1, 2 and 4 look like they should be possible to detect at build time too. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Autodetecting insufficiently hardened builds (was: New hardened build support (coming) in F16)
On Tue, Aug 09, 2011 at 04:53:16PM +0200, Björn Persson wrote: > Matthew Garrett wrote: > > Unless the checking is part of autoqa this simply isn't > > sufficient. There's a huge benefit to implementing it in the way that's > > easiest for maintainers. > > The earlier a problem is detected, the cheaper it is to fix. If I have > understood AutoQA right, it gets involved only after I submit a package to > updates-testing. Even better, when possible, is to detect problems during the > build, so that I notice them when I test-build locally and can fix them > before > I even commit the changes to Git. Some checks are already done at build time, > and Steve's points 1, 2 and 4 look like they should be possible to detect at > build time too. Checking at build time is a developer aid, but doesn't prevent mistakes from slipping into the distribution. Having both would certainly be helpful. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Beats are open
The release notes beats for Fedora 16 are now open. If you are working on some new feature for Fedora 16 that should be included in the release notes, please consider heading on over to https://fedoraproject.org/wiki/Documentation_Beats select the appropriate beat for your feature, and write a little something. You don't need to be flowery, or excessively detailed. Docs team members will be editing the beat content when it gets converted to Publican. If you are working on a major feature listed in the feature pages, of course we will be taking the prose from that page. But often the release notes section is written very early, and by now you probably have a lot more to say. If you don't tell us about the great stuff you are working on, how can we tell the world? It only takes a few minutes, and we all could benefit from knowing what is coming up. Thanks --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, 2011-08-09 at 10:44 -0400, Colin Walters wrote: > See attached. Looks fine to me. The only reason I have to dislike it is the temptation for people to inspect build logs as a proof of what flags a package was built with (since the only sane thing is to store that in the binary itself, which the tools team is working on). But for debugging build failures this is great. You appear to be in provenpackagers, as far as I'm concerned feel free to commit. Also, props for using the devel list as a development list. I've had an off-list request for exposing just the hardening bits of the rpm macros as their own variables (to make it easier to build part of a package hardened, ie the coreutils case), so I'll probably be spinning another update to redhat-rpm-macros soon anyway. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15 kernel 2.6.40-4 issues on EC2
On Tuesday, August 09, 2011 07:52:56 AM Marek Goldmann wrote: > Hi, > > In BoxGrinder we're seeing some issues when upgrading to latest kernel on > AMI's, which was reported here: > > https://issues.jboss.org/browse/BGBUILD-289 > > You can see in that ticket full boot log (console log in AWS terms) from a > started instance with newest kernel. Jeremy pointed out that the issue may > be related to newest kernel: 2.6.40-4: > > [quote] > > I came across this issue searching for a possibly related problem. > > I had been running Fedora 15 on EC2 successfully using the 1.6 Boxgrinder > AMI. Yesterday, I applied the latest updates, including > kernel-2.6.40-4.fc15.x86_64 and added a boot entry in /boot/grub/menu.lst. > On reboot, I saw similar messages in the console log to what was mentioned > here. Attaching my boot EBS volume to another instance and changing the > kernel back to kernel-2.6.38.8-35.fc15.x86_64 allowed my instance to boot > normally. > > [/quote] > > Anyone can tell me more after reading the console log? > > TIA > > --Marek looks like selinux is wanting to relabel the filesystem and that is failing. Dennis signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
Adam Jackson writes: > On Tue, 2011-08-09 at 10:44 -0400, Colin Walters wrote: >> See attached. > Looks fine to me. The only reason I have to dislike it is the > temptation for people to inspect build logs as a proof of what flags a > package was built with (since the only sane thing is to store that in > the binary itself, which the tools team is working on). But for > debugging build failures this is great. What happens in packages using a (possibly old) autoconf script that doesn't recognize --disable-silent-rules? IMO it would be better to add this option to the %configure calls in packages where it's actually an issue (which is surely a small minority, unless Colin has got evidence to the contrary). regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
review swap
Already approved once. Just need a quick re-review of the rename and the added Obsoletes: Original Message Subject: package re-review needed — CloudFS name change to HekaFS Date: Mon, 08 Aug 2011 10:40:20 -0400 From: Kaleb S. KEITHLEY To: devel@lists.fedoraproject.org Re-review needed after package name change and added Obsoletes: bz: https://bugzilla.redhat.com/show_bug.cgi?id=675050 Spec URL: http://hekafs.org/dist/0.7/hekafs.spec SRPM URL: http://hekafs.org/dist/0.7/hekafs-0.7-7.fc15.src.rpm Thanks, -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, Aug 9, 2011 at 11:11 AM, Tom Lane wrote: > > What happens in packages using a (possibly old) autoconf script that > doesn't recognize --disable-silent-rules? Autoconf convention is to ignore unknown rules. And indeed, all that results is a warning: configure: WARNING: unrecognized options: --disable-silent-rules > IMO it would be better to add this option to the %configure calls > in packages where it's actually an issue (which is surely a small > minority, unless Colin has got evidence to the contrary). I actually did this in the GNOME build system originally (pattern match for bits in configure), but after some discussion on the Yocto list we decided there the warning was harmless. https://lists.yoctoproject.org/pipermail/poky/2011-March/004944.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
Tom Lane writes: > What happens in packages using a (possibly old) autoconf script that > doesn't recognize --disable-silent-rules? Autoconf-generated configure scripts generally ignore unknown --enable and --with options (newer versions give a warning). Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abiword
On Tue, Aug 9, 2011 at 3:51 PM, Kevin Fenzi wrote: > On Tue, 09 Aug 2011 15:40:58 +0200 > Johannes Lips wrote: > >> Ok, did that now. If you need any further action from my side, just >> let me know. > > Please note that I have a update with no link-grammar in as: > https://admin.fedoraproject.org/updates/abiword-2.8.6-12.fc16 > > Please test and add karma. Done > Also, please wait to rebuild with link grammar until after Alpha? > If we boot this update out and add link-grammar and new abiword I fear > it will not get into the compose in time. ;( I've built it. I won't add it as an update until you build progresses to stable. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abiword
On Tue, 9 Aug 2011 16:23:51 +0100 Peter Robinson wrote: ...snip... > > Please note that I have a update with no link-grammar in as: > > https://admin.fedoraproject.org/updates/abiword-2.8.6-12.fc16 > > > > Please test and add karma. > > Done Thanks! > > Also, please wait to rebuild with link grammar until after Alpha? > > If we boot this update out and add link-grammar and new abiword I > > fear it will not get into the compose in time. ;( > > I've built it. I won't add it as an update until you build progresses > to stable. Excellent. Thanks! > Peter kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15 kernel 2.6.40-4 issues on EC2
After looking into it I think the root issue is that the block devices are incorrectly named in new 2.6.40-4 kernel. I created an issue: https://bugzilla.redhat.com/show_bug.cgi?id=729340 --Marek On 9 sie 2011, at 17:02, Dennis Gilmore wrote: > On Tuesday, August 09, 2011 07:52:56 AM Marek Goldmann wrote: >> Hi, >> >> In BoxGrinder we're seeing some issues when upgrading to latest kernel on >> AMI's, which was reported here: >> >> https://issues.jboss.org/browse/BGBUILD-289 >> >> You can see in that ticket full boot log (console log in AWS terms) from a >> started instance with newest kernel. Jeremy pointed out that the issue may >> be related to newest kernel: 2.6.40-4: >> >> [quote] >> >> I came across this issue searching for a possibly related problem. >> >> I had been running Fedora 15 on EC2 successfully using the 1.6 Boxgrinder >> AMI. Yesterday, I applied the latest updates, including >> kernel-2.6.40-4.fc15.x86_64 and added a boot entry in /boot/grub/menu.lst. >> On reboot, I saw similar messages in the console log to what was mentioned >> here. Attaching my boot EBS volume to another instance and changing the >> kernel back to kernel-2.6.38.8-35.fc15.x86_64 allowed my instance to boot >> normally. >> >> [/quote] >> >> Anyone can tell me more after reading the console log? >> >> TIA >> >> --Marek > looks like selinux is wanting to relabel the filesystem and that is failing. > > Dennis > -- > 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
[Test-Announce] Fedora 16 Alpha Release Candidate 3 (RC3) Available Now!
As per the Fedora 16 schedule [1], Fedora 16 Alpha Release Candidate 3 (RC3) is now available for testing. Please see the following pages for download links and testing instructions. In general, official live images arrive a few hours after the install images: see the links below for updates. When they appear, the download directory should be the same as that for install images, except with the trailing "/Fedora/" replaced by "/Live/". Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Security Lab: https://fedoraproject.org/wiki/Test_Results:Current_Security_Lab_Test Ideally, all Alpha priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Alpha Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. task#23: Create Fedora 16 Alpha release candidate (RC) - live and traditional https://fedorahosted.org/rel-eng/ticket/4859 F16 Alpha Blocker tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=713560 F16 Alpha Nice-To-Have tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=713563 [1] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, 09 Aug 2011 16:44:31 +0200, Colin Walters wrote: > Various projects have been adding AM_SILENT_RULES from Automake to > their Makefiles for "developer convenience"; the goal being that they > see warnings more easily. It is inconvenient as one can no longer easily reproduce the compilation for various problems either of the toolchain itself or adjusting it when troubleshooting tools processing the output binaries. More reasons are listed in the follow Bug, package "kernel" already uses such mode, I got request for the normal verbose compilation WONTFIXed: https://bugzilla.redhat.com/show_bug.cgi?id=716563 Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, 09 Aug 2011 16:44:31 +0200, Colin Walters wrote: > the goal being that they see warnings more easily. You should make -Werror default instead, by compiling packages without -Werror various bugs creep in which would be much easier fixed before the compilation. Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, 2011-08-09 at 18:56 +0200, Jan Kratochvil wrote: > On Tue, 09 Aug 2011 16:44:31 +0200, Colin Walters wrote: > > the goal being that they see warnings more easily. > > You should make -Werror default instead, by compiling packages without -Werror > various bugs creep in which would be much easier fixed before the compilation. If you're volunteering to fix and/or paper over all the spurious warnings gcc and glibc introduce with every phase of the moon, then sure. Otherwise -Werror would essentially mean never shipping anything ever again. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, Aug 09, 2011 at 06:56:21PM +0200, Jan Kratochvil wrote: > On Tue, 09 Aug 2011 16:44:31 +0200, Colin Walters wrote: > > the goal being that they see warnings more easily. > > You should make -Werror default instead, by compiling packages without -Werror > various bugs creep in which would be much easier fixed before the compilation. Never, ever ship software with -Werror enabled. It's a development-only option. You have no idea what gcc will decide is a warning in future, so it's effectively a "Please break my build in six months" toggle. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, 09 Aug 2011 19:14:27 +0200, Adam Jackson wrote: > If you're volunteering to fix and/or paper over all the spurious > warnings gcc and glibc introduce with every phase of the moon, then > sure. Yes, I do it for my component, GDB has -Werror default in development phases upstream. It cleans up the code, it finds various minor bugs etc. > Otherwise -Werror would essentially mean never shipping anything > ever again. So the maintainers either care about the warnings - and then they should use -Werror - or they do not care about the warnings - and then it does not matter regarding warning messages which and how many of them can be found on the Koji server in the log files. Please decide. As always I guess it should be per maintainer / per package. Something like default -Werror with easy opt-out. And we can forget about hiding the compilation commands useful for toolchain troubleshooting. Thanks, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, 09 Aug 2011 19:16:54 +0200, Matthew Garrett wrote: > Never, ever ship software with -Werror enabled. I agree - for source distribution. Yes, GDB releases have -Werror turned off. > It's a development-only > option. You have no idea what gcc will decide is a warning in future, so > it's effectively a "Please break my build in six months" toggle. I believe -Werror is appropriate for .src.rpm as only .arch.rpm is what is being shipped to the real users. -Werror is only of concern to the package maintainer who should keep warnings under control. -Werror is probably the most easy way to keep them non-regressing. One can only argue -Werror is not appropriate for rpmbuild --rebuild by users. But they will see new warnings only in non-standardard distro/environment/configuration, such advanced users should be aware of everything how to deal with it anyway. Thanks, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On 08/09/2011 07:50 PM, Jan Kratochvil wrote: > On Tue, 09 Aug 2011 16:44:31 +0200, Colin Walters wrote: >> Various projects have been adding AM_SILENT_RULES from Automake to >> their Makefiles for "developer convenience"; the goal being that they >> see warnings more easily. > > It is inconvenient as one can no longer easily reproduce the compilation for > various problems either of the toolchain itself or adjusting it when > troubleshooting tools processing the output binaries. The quote is taken out of context. Please reread the whole message; this passage only reasons why various UPSTREAMS have chosen to use silent rules. The patch is all about globally enabling the verbose mode, exactly the same you were proposing in the kernel ticket. > More reasons are listed in the follow Bug, package "kernel" already uses such > mode, I got request for the normal verbose compilation WONTFIXed: > https://bugzilla.redhat.com/show_bug.cgi?id=716563 > > > Jan -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Does abrt work?
Here's what I got trying to use retrace server for crash of inkscape: Retrace job failed Analyzing crash data OK Initializing virtual root OK Generating backtrace Error Unable to chmod the executable (exited with 1) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, 09 Aug 2011 19:39:55 +0200, Kalev Lember wrote: > Please reread the whole message; this passage only reasons why various > UPSTREAMS have chosen to use silent rules. The patch is all about > globally enabling the verbose mode, exactly the same you were proposing > in the kernel ticket. OK, sorry, I agree, I withdraw my inappropriate comment. Well, at least the topic of -Werror has been highlighted. Thanks, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, Aug 09, 2011 at 07:34:48PM +0200, Jan Kratochvil wrote: > On Tue, 09 Aug 2011 19:16:54 +0200, Matthew Garrett wrote: > > It's a development-only > > option. You have no idea what gcc will decide is a warning in future, so > > it's effectively a "Please break my build in six months" toggle. > > I believe -Werror is appropriate for .src.rpm as only .arch.rpm is what is > being shipped to the real users. -Werror is only of concern to the package > maintainer who should keep warnings under control. -Werror is probably the > most easy way to keep them non-regressing. Adding an additional warning to gcc that triggers for a specific application doesn't make that application any more broken than it was before the warning was added. If a package fails to build in a mass rebuild because -Werror was enabled then that's additional work for several people to fix something that may not have ever actually been broken. Warnings are appropriate during development. -Werror may even make sense when packagers are performing local builds before upload. I just don't think there's any way that the improvement in quality it'd bring to the distribution outweighs the extra effort involved in maintaining it whenever the toolchain changes. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On 08/09/2011 07:19 PM, Jan Kratochvil wrote: > On Tue, 09 Aug 2011 19:14:27 +0200, Adam Jackson wrote: >> If you're volunteering to fix and/or paper over all the spurious >> warnings gcc and glibc introduce with every phase of the moon, then >> sure. > > Yes, I do it for my component, GDB has -Werror default in development phases > upstream. Yes, and gdb's best configuration feature is --disable-werrors, without which it was non-compilable almost everywhere. > It cleans up the code, it finds various minor bugs etc. Agreed, iff you are an upstream developer, otherwise not. In all other cases, it only causes minor issues (often negligible cosmetic stuff) being treated as errors, often causing Heisenbugs with each GCC/glibc release - Not worth mentioning the additional Heisenbugs you face when taking other OSes into consideration. >> Otherwise -Werror would essentially mean never shipping anything >> ever again. > > So the maintainers either care about the warnings - and then they should use > -Werror - or they do not care about the warnings - and then it does not matter > regarding warning messages which and how many of them can be found on the Koji > server in the log files. Please decide. I can only second what others already said: Switch off -Werror, unless you have too much time. > As always I guess it should be per maintainer / per package. Something like > default -Werror with easy opt-out. It often is not, but requires heavy modifications to a package. Something which often is beyond the skills of an occasional Fedora packager. > And we can forget about hiding the > compilation commands useful for toolchain troubleshooting. Well, ... are you sure your package has it's include paths and it's CFLAGS right? You won't see this class of bugs with AM_SILENT_RULES. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, 2011-08-09 at 19:19 +0200, Jan Kratochvil wrote: > On Tue, 09 Aug 2011 19:14:27 +0200, Adam Jackson wrote: > > If you're volunteering to fix and/or paper over all the spurious > > warnings gcc and glibc introduce with every phase of the moon, then > > sure. > > Yes, I do it for my component, GDB has -Werror default in development phases > upstream. It cleans up the code, it finds various minor bugs etc. I didn't say "for your component". > > Otherwise -Werror would essentially mean never shipping anything > > ever again. > > So the maintainers either care about the warnings - and then they should use > -Werror - or they do not care about the warnings - and then it does not matter > regarding warning messages which and how many of them can be found on the Koji > server in the log files. Please decide. I wasn't arguing for or against finding warnings. I was commenting on the ability to see build failures. Admittedly, you were initially responding to Colin, not myself. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [PATCH] macros: Globally add --disable-silent-rules to configure
On Tue, 09 Aug 2011 19:45:15 +0200, Matthew Garrett wrote: > If a package fails to build in a mass rebuild because -Werror was enabled > then that's additional work for several people to fix something that may not > have ever actually been broken. 99% of warnings will not lead to user visible bugs. Finding that remaining 1% of bugs (warnings) takes more than 100x time than to fix the warnings. I base by -Werror recommendation on this assumption, YMMV. > Warnings are appropriate during development. It also depends how much / if do you consider the packager to be also the package developer. > I just don't think there's any way that the improvement in quality it'd > bring to the distribution outweighs the extra effort involved in maintaining > it whenever the toolchain changes. The new warnings in toolchain intend to point at more problematic/buggy points in the code. It seems you disagree with my 99-1 assumption above, I agree I do not have such statistics proven anywhere. Thanks, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Unresponsive maintainer: cvsgraph
Kevin Fenzi scrye.com> writes: > Done. Still having no luck submitting this as an update via bodhi. I get: bojan does not have commit access to cvsgraph Anyone knows what else is required for a package to be submitted as an update? It seems that commit access on the branch is not sufficient. -- Bojan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
