Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)
Le 15 mai 2016 20:49:38 GMT+02:00, Niels Thykier a écrit : >Bálint Réczey: >> Hi, >> >> [...] >> > >Hi, > >> I think making PIE and bindnow default in dpkg (at least for amd64) >would be >> perfect release goals for Stretch. >> > >I support the end goal, but I suspect we should enable PIE by default >via GCC-6's new configure switch[1]. Assuming it does what I hope, >then >it will work better than enabling PIE via dpkg-buildflags. > > * The major issue with PIE by default is that it is not compatible > with -fPIC (and presumably also -static), which causes FTBFS or > broken ELF binaries. It will also break some package like ImageMagick... Documentation how to fix (without reverting default) is not usuable by upstream. So please improve documentation first. Bastien > >* Assuming the GCC option does what I hope, then it would automatically > disable PIE for irrelevant outputs. > >My assumption seems to be aligned with the approach taking by Ubuntu. > >> This would make Debian on par with Fedora and Ubuntu in that regard. >> > >FTR, Fedora seems to have some special logic for adding PIE only to >executables. > >> We briefly discussed that with Guillem in a related bug report: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812783#42 >> >> I think the next step could be an archive rebuild with the changed >defaults >> if we would like to pursue this: >> >https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Can_we_add_support_for_new_default_build_flags_to_dpkg-buildflags.3F >> >> I planned starting a discussion on debian-devel about PIE + bindnow, >> too, after checking >> all the packages which contain statically compiled binaries because >> they may need patching >> to disable PIE flags based on Lunar's post: >> https://people.debian.org/~lunar/blog/posts/aslr_now/ >> >> Cheers, >> Balint >> >>>[...] > >In summary: > > * I would welcome bindnow by default via dpkg-buildflags. > > * I would also love to have PIE as default for Stretch although I fear > dpkg-buildflags is the wrong approach for that particular flag. > >Thanks, >~Niels > >[1] https://gcc.gnu.org/gcc-6/changes.html > >"""The --enable-default-pie configure option enables generation of PIE >by default.""" -- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)
On 15.05.2016 23:10, Iustin Pop wrote: On 2016-05-15 21:45:55, Bálint Réczey wrote: Hi Niels, 2016-05-15 20:49 GMT+02:00 Niels Thykier : Bálint Réczey: Hi, [...] Hi, I think making PIE and bindnow default in dpkg (at least for amd64) would be perfect release goals for Stretch. I support the end goal, but I suspect we should enable PIE by default via GCC-6's new configure switch[1]. Assuming it does what I hope, then it will work better than enabling PIE via dpkg-buildflags. * The major issue with PIE by default is that it is not compatible with -fPIC (and presumably also -static), which causes FTBFS or broken ELF binaries. * Assuming the GCC option does what I hope, then it would automatically disable PIE for irrelevant outputs. My assumption seems to be aligned with the approach taking by Ubuntu. I agree that it would be the easier way and I also tried building packages with patched GCC 5 setting PIE as default with success, but we have a CTTE decision which says that we should set hardening flags through dpkg: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688 I'm not familiar with the history of that bug (272 updates!), so excuse my question, but: - that bug seems to have been opened in the context of custom patches to GCC, back in 2009-2012 - the CTTE seems to have made an informal decision (see last update #272) on that topic Would it make sense to re-evaluate that decision in the context of 2016, i.e. (if I understand correctly) no patching of GCC 6 needed? Just a quick ask to the CTTE asking if the decision is still valid given today's situation. indeed, this patch is now upstream, but still not that much used. Just discovered that it is not covering all front ends, see https://gcc.gnu.org/PR71072 for an example. I'm happy to see that the reproducible build maintainers took the issue of setting c/c++ timestamp values upstream, and encourage to do the same for any other default flags setting. I'm not a fan myself for turning on hardening flags in the compiler itself, but if you do that, then dpkg issues like https://bugs.debian.org/823869 need to be addressed (whether all obscure build systems picking these up, or not). Matthias
Bug#824554: ITP: pymacaroons -- Macaroon library for Python
Package: wnpp Severity: wishlist Owner: Colin Watson * Package name: pymacaroons Version : 0.9.2 Upstream Author : Evan Cordell * URL : https://github.com/ecordell/pymacaroons * License : Expat Programming Lang: Python Description : Macaroon library for Python Macaroons, like cookies, are a form of bearer credential. Unlike opaque tokens, macaroons embed caveats that define specific authorization requirements for the target service, the service that issued the root macaroon and which is capable of verifying the integrity of macaroons it receives. Macaroons allow for delegation and attenuation of authorization. They are simple and fast to verify, and decouple authorization policy from the enforcement of that policy. We're moving towards using this library for various authorization tasks at work (Canonical). While most of these uses are in contexts where we'd tend to use Python packaging directly, there are some situations where it would be useful to have a Debian package too. This depends on #781984. -- Colin Watson [cjwat...@debian.org]
Bug#824559: ITP: python-monascaclient -- Python bindings for the Monasca API
Package: wnpp Severity: wishlist Owner: James Page * Package name: python-monascaclient Version : 1.0.30 * URL : https://github.com/openstack/python-monascaclient * License : Apache 2.0 Programming Lang: Python Description : Python bindings for the Monasca API Monasca is a open-source multi-tenant, highly scalable, performant, fault-tolerant monitoring-as-a-service solution that integrates with OpenStack. It uses a REST API for high-speed metrics processing and querying and has a streaming alarm engine and notification engine. This package provides the Python API bindings for Monasca.
Re: Bug#824358: ITP: freerdp2 -- RDP client/server for Windows Terminal Services
close #824358 thanks HI Andreas, hi all, On Mo 16 Mai 2016 15:48:56 CEST, Mike Gabriel wrote: This bit is quite confusing as you just said upstream doesn't do releases. The don't do releases. Not yet. They did not have the concept of "major versions" really, before Bernhard pushed the other upstream dev(s) to introduce a major version bump to version 2.x.y and declare everything previous as 1.x.y. (There was a time when there was some 0.7.x and 0.9.x release IIRC, but that is ages ago). Since I have taken over package maintenance in of freerdp in Debian, I always received Git snapshot recommendations from Bernhard. I just heard back from Bernhard, that FreeRDP upstream discussed some sort of a release schedule for 2.0. There will be an ABI/API freeze around end of June / beginning of July 2016 for FreeRDP 2.0 and then there will also be a 2.0~rc1 upstream release. We (the people caring for Debian's freerdp package) will wait until then and then go the usual transition path for freerdp. I will close this bug now, because there won't be a freerdp2 package. Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de pgpFBix5LsShv.pgp Description: Digitale PGP-Signatur
Re: Which libstdc++ library?
> I have a package (dpuser [1]), that during execution may call the c++ > compiler g++ for some on-the-fly-generated C++ files that use the > standard C++ library. > > I am now curious on how I need to specify the runtime dependency from the > -dev library? The C++ compiler is probably just the "g++" package, but how do > I specify the corresponding stdc++ lib? Using libstdc++-5-dev is not > nice since it will break if the default gcc switches to version 6 (and > also if on some backport version 4 is required). Or is the correct > libstdc++-dev package automatically installed with g++? Seems so. $ apt-cache depends g++ g++ Depends: cpp Depends: gcc Depends: g++-4.9 Depends: gcc-4.9 Suggests: g++-multilib $ apt-cache depends g++-4.9 g++-4.9 Depends: gcc-4.9-base Depends: gcc-4.9 Depends: libstdc++-4.9-dev Depends: libc6 Depends: libcloog-isl4 Depends: libgmp10 Depends: libisl10 Depends: libmpc3 Depends: libmpfr4 Depends: zlib1g Suggests: g++-4.9-multilib Suggests: Suggests: libstdc++6-4.9-dbg $ apt-cache depends g++-5 g++-5 Depends: gcc-5-base Depends: gcc-5 Depends: libstdc++-5-dev Depends: libc6 Depends: libgmp10 Depends: libisl15 Depends: libmpc3 Depends: libmpfr4 Depends: zlib1g Suggests: g++-5-multilib Suggests: Suggests: libstdc++6-5-dbg -- Accept: text/plain, text/x-diff Accept-Language: eo,en,ru X-Keep-In-CC: yes X-Web-Site: sinsekvu.github.io
Fwd: Looking for an artwork coordinator
Weitergeleitete Nachricht Betreff: Looking for an artwork coordinator Weitersenden-Datum: Tue, 17 May 2016 17:41:46 + (UTC) Weitersenden-Von: debian-rele...@lists.debian.org Datum: Tue, 17 May 2016 19:41:32 +0200 Von: Cyril Brulebois Organisation: Debian An: debian-desk...@lists.debian.org Kopie (CC): paul...@debian.org Hi, Paul Tagliamonte was kind enough to coordinate the artwork selection process during the past release cycle, but would like someone else to step up for the stretch release cycle. If someone is interested in coordinating the call for artwork, and in organizing the vote/selection like that was done last time, this would be great. This would leave us time to get all relevant packages fixed to integrate the selected artwork, way before the freeze; the sooner, the better! (-boot@,-release@ in bcc for information.) KiBi. signature.asc Description: OpenPGP digital signature
Bug#824600: ITP: golang-gopkg-square-go-jose.v1 -- Javascript Object Signing and Encryption (JOSE) for Go
Package: wnpp Severity: wishlist Owner: Peter Colberg * Package name: golang-gopkg-square-go-jose.v1 Version : 1.0.2 Upstream Author : Square Inc * URL : https://github.com/square/go-jose * License : Apache-2.0 Programming Lang: Go Description : Javascript Object Signing and Encryption (JOSE) for Go The package supersedes the package golang-github-square-go-jose. The upstream maintainer started tagging releases, which resulted in a change of the Go import path from github.com/square/go-jose to gopkg.in/square/go-jose.v1. To comply with the Debian Go packaging policy, the source and binary packages are renamed accordingly. Once this package has been uploaded and all dependent packages updated, I will request the removal of golang-github-square-go-jose.
Bug#824601: ITP: golang-github-cheggaaa-pb -- simple console progress bar for Go
Package: wnpp Severity: wishlist Owner: Peter Colberg * Package name: golang-gopkg-cheggaaa-pb.v1 Version : 1.0.3 Upstream Author : Sergey Cherepanov * URL : https://github.com/cheggaaa/pb * License : BSD-3-clause Programming Lang: Go Description : simple console progress bar for Go The package supersedes the package golang-github-cheggaaa-pb. The upstream maintainer started tagging releases, which resulted in a change of the Go import path from github.com/cheggaaa/pb to gopkg.in/cheggaaa/pb.v1. To comply with the Debian Go packaging policy, the source and binary packages are renamed accordingly. Once this package has been uploaded and all dependent packages updated, I will request the removal of golang-github-cheggaaa-pb.
Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)
Hi! On Sun, 2016-05-15 at 21:45:55 +0200, Bálint Réczey wrote: > 2016-05-15 20:49 GMT+02:00 Niels Thykier : > > Bálint Réczey: > >> I think making PIE and bindnow default in dpkg (at least for amd64) would > >> be > >> perfect release goals for Stretch. > > > > I support the end goal, but I suspect we should enable PIE by default > > via GCC-6's new configure switch[1]. Assuming it does what I hope, then > > it will work better than enabling PIE via dpkg-buildflags. > > > > * The major issue with PIE by default is that it is not compatible > >with -fPIC (and presumably also -static), which causes FTBFS or > >broken ELF binaries. > > > > * Assuming the GCC option does what I hope, then it would automatically > >disable PIE for irrelevant outputs. > > > > My assumption seems to be aligned with the approach taking by Ubuntu. Right, I've been pondering about the same. And I also have to agree enabling PIE globally via dpkg-buildflags is not the right approach, and I'm not planning to enable that in dpkg for any normal arch. Because it would require hunting down all broken packages, and making them opt-out from using PIE, or making them opt-out from PIE in some parts of their build-system. It would also require a flag-day. For bindnow, the usual process from the dpkg FAQ would still apply. > I agree that it would be the easier way and I also tried building packages > with > patched GCC 5 setting PIE as default with success, but we have a CTTE > decision which says that we should set hardening flags through dpkg: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688 Meh, I'm not going to bother reading that bug report, but if that's what the decision really says, then that decision is just bogus… Thanks, Guillem
Re: PIE + bindnow for Stretch?(Re: Time to reevaluate the cost of -fPIC?)
On Tue, 2016-05-17 at 12:08:09 +0200, Matthias Klose wrote: > I'm not a fan myself for turning on hardening flags in the compiler itself, > but if you do that, then dpkg issues like https://bugs.debian.org/823869 > need to be addressed (whether all obscure build systems picking these up, or > not). That bug report is not relevant in its current form, as explained there. If the default changes in the Debian default compiler, then I'll just make the +pie option a no-op and change -pie to set -fno-PIE, so that the options are only added when they are expected. The difference with that request is that it would currently add -fno-PIE for most packages that do not change the default flags, which might break their build-systems. Thanks, Guillem
Re: Bug#824130: ITP: libgames-support -- Useful functionality shared among GNOME games
Hi! On Thu, 2016-05-12 at 17:39:57 +0200, Michael Biebl wrote: > Package: wnpp > Severity: wishlist > Owner: Michael Biebl > > * Package name: libgames-support > Version : 1.0.2 > Upstream Author : Michael Catanzaro > * URL : https://wiki.gnome.org/Apps/Games > * License : LGPL-3+ > Programming Lang: Vala > Description : Useful functionality shared among GNOME games > > Code shared between GNOME games. > > This package will be maintained with the pkg-gnome team. Hmm that's a very unfortunate and generic name for a project that is apparently GNOME-specific? Of course other desktops, such as KDE have committed the same sin but… :( Thanks, Guillem
Re: Debian i386 architecture now requires a 686-class processor
Hi! On Tue, 2016-05-10 at 19:17:15 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > On Saturday 07 May 2016 13:23:30 Ben Hutchings wrote: > > Last year it was decided to increase the minimum CPU features for the > > i386 architecture to 686-class in the stretch release cycle. This > > means dropping support for 586-class and hybrid 586/686 > > processors[1].(Support for 486-class processors was dropped, somewhat > > accidentally, in squeeze.) > > > > This was implemented in the Linux kernel packages starting with Linux > > 4.3, which was uploaded to unstable in December last year. > > I guess the answer is "no", but just to be sure: does this means that i386 > supported processors need to implement SSE2? I suppose this is related to unconditional SSE2 requirement in new Qt libraries, (bugs #792594, #794739), for which I thought I had clarified the conditions and for which I've provided patches already, but also for which I'm not willing to sign the CLA. This means that Qt and any application using those specific bits, will not run at all (silently) in Stretch on any AMD-based i386 CPUs, nor on older Intel ones, which I'd assume is a pretty big percent of the i386 park. I think the same is affecting Chromium, which I'll need to fix too. I've got local packages for the Qt Declarative stuff which I could publish if there's demand. Thanks, Guillem
⤴️🌐
Sent from my iPhone
