Re: ITS: scrotwm (already in Debian)
On Thu, Nov 10, 2011 at 10:13:04PM +0100, Niels Thykier wrote: [1] Strictly speaking the CFLAGS/LDFLAGS from should overrule the upstream ones if there are conflicts. Fixing that is left as an exercise to the reader. ;) Can’t think of a way of doing that without patching the Makefile. But then again, patching the Makefile is no big deal. If you are going to send a patch upstream anyway, you might as well make it possible to insert user *FLAGS after the upstream flags. ;) I ended up doing just that: I’ve introduced a MAINT_* version of all the variables, and changed the build rules so that the MAINT_* version is used just before the user–settable version. I’ve also noticed that the makefile snippet exporting the hardening build flags takes care of enabling optimization and handling DEB_BUILD_OPTIONS=noopt itself, which is nice. I will talk to upstream about enabling optimization by default. The updated package is up on mentors.debian.net, let me know what you think of it. Cheers. PS: No need to CC me, I’m subscribed to the list. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: ITS: scrotwm (already in Debian)
On 2011-11-11 11:22, Andrea Bolognani wrote: On Thu, Nov 10, 2011 at 10:13:04PM +0100, Niels Thykier wrote: Hi [...] If you are going to send a patch upstream anyway, you might as well make it possible to insert user *FLAGS after the upstream flags. ;) I ended up doing just that: I’ve introduced a MAINT_* version of all the variables, and changed the build rules so that the MAINT_* version is used just before the user–settable version. I’ve also noticed that the makefile snippet exporting the hardening build flags takes care of enabling optimization and handling DEB_BUILD_OPTIONS=noopt itself, which is nice. Indeed, unfortunately it comes at the price of a version Build-Depends on dpkg-dev (= 1.16.1~). You may be able to ditch it by using -include in d/rules, but then you have to handle noopt manually in case dpkg-dev (= 1.16.1~) is not available I will talk to upstream about enabling optimization by default. :) The updated package is up on mentors.debian.net, let me know what you think of it. Cheers. PS: No need to CC me, I’m subscribed to the list. Besides the issue mentioned above, it looks okay. I can add the B-D on dpkg-dev if you want (It will save you an upload to mentors). ~Niels -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ebdad74.90...@thykier.net
Re: ITS: scrotwm (already in Debian)
On Sat, Nov 12, 2011 at 12:19:16AM +0100, Niels Thykier wrote: I’ve also noticed that the makefile snippet exporting the hardening build flags takes care of enabling optimization and handling DEB_BUILD_OPTIONS=noopt itself, which is nice. Indeed, unfortunately it comes at the price of a version Build-Depends on dpkg-dev (= 1.16.1~). You may be able to ditch it by using -include in d/rules, but then you have to handle noopt manually in case dpkg-dev (= 1.16.1~) is not available How did I miss that? Great catch! A fixed package is available, as usual, from mentors.debian.net. Cheers. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: ITS: scrotwm (already in Debian)
On 2011-11-12 01:16, Andrea Bolognani wrote: On Sat, Nov 12, 2011 at 12:19:16AM +0100, Niels Thykier wrote: I’ve also noticed that the makefile snippet exporting the hardening build flags takes care of enabling optimization and handling DEB_BUILD_OPTIONS=noopt itself, which is nice. Indeed, unfortunately it comes at the price of a version Build-Depends on dpkg-dev (= 1.16.1~). You may be able to ditch it by using -include in d/rules, but then you have to handle noopt manually in case dpkg-dev (= 1.16.1~) is not available How did I miss that? Great catch! A fixed package is available, as usual, from mentors.debian.net. Cheers. Uploaded, thanks for your contribution. :) ~Niels -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ebe24d8.9090...@thykier.net
Re: ITS: scrotwm (already in Debian)
On 2011-11-10 17:08, Andrea Bolognani wrote: On Thu, Nov 10, 2011 at 12:56:57PM +0100, Niels Thykier wrote: Hi, As the subject suggests I am willing to sponsor the package. :) I’m glad to hear that! Hi, But before I do; have you considered enabling hardning flags in your package? A basic example of how to do it can be seen the attached patch[1]. Thanks for pointing that out. I’m looking at the documentation and at your patch, and I’m unsure about this bit %.so: %.c - $(CC) $(CFLAGS) -c -fpic -DPIC $+ -o $@ + $(CC) $(LDFLAGS) $(CFLAGS) -c -fpic -DPIC $+ -o $@ Are you positive $(LDFLAGS) is supposed to be passed to the compiler here? It is just creating an object file, so the linker should not be called by $(CC). I am indeed wrong. I assumed that the %.so: %.c rule implied it was a shared library and completely overlooked the -c argument. [...] I will patch the Makefile and send the patch upstream for inclusion in a future release. Is there a reason that the binaries are compiled without optimization[2]? As far as I can tell it is an oversight, because the osx Makefile includes an -O2 flag. However, if it is known to have issues with optimization on Linux platforms, a comment about that would be appreciated (bonus points for valid references to bugs against gcc :P). It’s almost certainly an oversight. [1] Strictly speaking the CFLAGS/LDFLAGS from should overrule the upstream ones if there are conflicts. Fixing that is left as an exercise to the reader. ;) Can’t think of a way of doing that without patching the Makefile. But then again, patching the Makefile is no big deal. If you are going to send a patch upstream anyway, you might as well make it possible to insert user *FLAGS after the upstream flags. ;) Thanks for your input, I’ll let you know when I have an updated package ready for review. Looking forward to seeing it. :) ~Niels -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ebc3e60.5040...@thykier.net
Re: ITS: scrotwm (already in Debian)
2011/11/10 Niels Thykier ni...@thykier.net On 2011-11-10 17:08, Andrea Bolognani wrote: On Thu, Nov 10, 2011 at 12:56:57PM +0100, Niels Thykier wrote: Hi, As the subject suggests I am willing to sponsor the package. :) I’m glad to hear that! Hi, But before I do; have you considered enabling hardning flags in your package? A basic example of how to do it can be seen the attached patch[1]. Thanks for pointing that out. I’m looking at the documentation and at your patch, and I’m unsure about this bit %.so: %.c - $(CC) $(CFLAGS) -c -fpic -DPIC $+ -o $@ + $(CC) $(LDFLAGS) $(CFLAGS) -c -fpic -DPIC $+ -o $@ Are you positive $(LDFLAGS) is supposed to be passed to the compiler here? It is just creating an object file, so the linker should not be called by $(CC). I am indeed wrong. I assumed that the %.so: %.c rule implied it was a shared library and completely overlooked the -c argument. [...] I will patch the Makefile and send the patch upstream for inclusion in a future release. Is there a reason that the binaries are compiled without optimization[2]? As far as I can tell it is an oversight, because the osx Makefile includes an -O2 flag. However, if it is known to have issues with optimization on Linux platforms, a comment about that would be appreciated (bonus points for valid references to bugs against gcc :P). It’s almost certainly an oversight. [1] Strictly speaking the CFLAGS/LDFLAGS from should overrule the upstream ones if there are conflicts. Fixing that is left as an exercise to the reader. ;) Can’t think of a way of doing that without patching the Makefile. But then again, patching the Makefile is no big deal. If you are going to send a patch upstream anyway, you might as well make it possible to insert user *FLAGS after the upstream flags. ;) Thanks for your input, I’ll let you know when I have an updated package ready for review. Looking forward to seeing it. :) ~Niels -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ebc3e60.5040...@thykier.net Oh this is really nice, i'm glad to finally see that you got a sponsor. :-)
