Re: depending on libssl1.0-dev, buildd fails to find it
On Sun, Dec 18, 2016 at 01:55:16AM +, Sean Whitton wrote: > Hello Christian, > > On Sat, Dec 17, 2016 at 05:40:49PM +0100, Christian Seiler wrote: > > On 12/17/2016 04:49 PM, Daniel Pocock wrote: > > > In my reSIProcate control[1] file, I included the following: > > > > > > Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ... > > > > > > pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2] > > > > > > In the buildd[3] report, it says that libssl-dev is uninstallable on > > > every platform, it doesn't appear to try libssl1.0-dev > > > > > > Is buildd sensitive to the order of the dependencies when multiple > > > options are given? Or is there some other glitch here? > > > > sbuild will always use the first alternative of build > > dependencies. If you're doing this to make backporting easier, > > then I'm afraid that won't work - you'll have to manually > > change the B-D for backports. > > Do you know why sbuild is ignoring alternative build-deps? As Arno hinted at, it's to have reliable builds. A transient inability to install the first arm of an alternation should caused a dep-wait state, not building with the alternate Build-Depends. Now, backports are a different story because they use a different resolver which will pull in alternates. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: depending on libssl1.0-dev, buildd fails to find it
Hello Christian, On Sat, Dec 17, 2016 at 05:40:49PM +0100, Christian Seiler wrote: > On 12/17/2016 04:49 PM, Daniel Pocock wrote: > > In my reSIProcate control[1] file, I included the following: > > > > Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ... > > > > pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2] > > > > In the buildd[3] report, it says that libssl-dev is uninstallable on > > every platform, it doesn't appear to try libssl1.0-dev > > > > Is buildd sensitive to the order of the dependencies when multiple > > options are given? Or is there some other glitch here? > > sbuild will always use the first alternative of build > dependencies. If you're doing this to make backporting easier, > then I'm afraid that won't work - you'll have to manually > change the B-D for backports. Do you know why sbuild is ignoring alternative build-deps? -- Sean Whitton signature.asc Description: PGP signature
Bug#848520: ITP: curvesapi -- Java implementation of mathematical curves defined over a set of control points
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: curvesapi Version : 1.05 Upstream Author : Dustin Spicuzza * URL : https://github.com/virtuald/curvesapi * License : BSD-3-clause Programming Lang: Java Description : Java implementation of mathematical curves defined over a set of control points Implementation of various mathematical curves that define themselves over a set of control points. The API is written in Java. The curves supported are: Bezier, B-Spline, Cardinal Spline, Catmull-Rom Spline, Lagrange, Natural Cubic Spline, and NURBS. This library is a new dependency of libapache-poi-java > 3.14. It'll be maintained by the Java Team.
Bug#848518: ITP: python-pgpy -- OpenPGP (Pretty Good Privacy) RFC 4880 implementation in Python
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor * Package name: python-pgpy Version : 0.4.0 Upstream Author : Michael Greene * URL : https://github.com/SecurityInnovation/PGPy * License : BSD Programming Lang: Python Description : OpenPGP (Pretty Good Privacy) RFC 4880 implementation in Python PGPy offers a pure-Python implementation of the OpenPGP standard, as described in RFC 4880 and subsequent specifications. It can be used as a toolkit for building OpenPGP-compatible applications and libraries in Python.
Bug#848509: ITP: libbio-coordinate-perl -- BioPerl modules for working with biological coordinates
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: libbio-coordinate-perl Version : 1.7.1 Upstream Author : Heikki Lehvaslaiho * URL : http://search.cpan.org/dist/Bio-Coordinate/ * License : Perl Programming Lang: Perl Description : BioPerl modules for working with biological coordinates The Bioperl project is a coordinated effort to collect computational methods routinely used in bioinformatics into a set of standard CPAN-style, well-documented, and freely available Perl modules. . Since BioPerl version 1.7 several modules where split into separate projects. This package provides the Bio::Coordinate module for working with biological coordinates. Remark: Due to the the refactoring of BioPerl which has split out several modules the package libbio-graphics-perl does not build from source any more (see #848105). I have verified that this build issue can be fixed if libbio-coordinate-perl is available. The package will be maintained by the Debian Med team at https://anonscm.debian.org/git/debian-med/libbio-coordinate-perl.git
Re: contacting all bug reporters for a package?
On Sat, 17 Dec 2016, Wouter Verhelst wrote: > On Thu, Dec 15, 2016 at 10:51:49AM -0600, Don Armstrong wrote: > > That was me; sorry about that. Presumably you got all of the copies > > because they were to different aliases which eventually ended up hitting > > you. > > That reminds me of #784131. Is it possible to implement something along > those lines? It would be possible; it's not exactly trivial, just because the routine which figures out who to send a message to doesn't pass that information back up... but there's no intrinsic reason why it couldn't be done. It's not a super high priority for me right this second, though, so if someone else wants it fast, patches accepted. -- Don Armstrong https://www.donarmstrong.com Le temps est un grand maître, dit-on; le malheur est qu'il soit un maître inhumain qui tue ses élèves. Time is a great teacher, but unfortunately it kills all its pupils. -- Hector Berlioz
Bug#848501: ITP: jmork -- Mork database parser for Java
Package: wnpp Severity: wishlist Owner: Ingo Bauersachs * Package name: jmork Version : 1.0.5 Upstream Author : Ingo Bauersachs * URL : https://github.com/ibauersachs/jmork * License : EPL-v1.0 Programming Lang: Java Description : Mork database parser for Java Mork is the database format for the address book of Mozilla Thunderbird. It contains the contacts details in a rather weird and undocumented encoding format and parsing outside of any Mozilla product is always on a best-effort basis. jmork is a Java implementation of a Mork parser and an experimental writer. It is being used by e.g. Jitsi to search for contacts when creating a call.
Re: [RFC] Enabling bindnow by default in dpkg-buildflags?
Hi, 2016-12-17 10:17 GMT+01:00 Julien Cristau : > On Sat, Dec 17, 2016 at 09:20:40 +0100, Bálint Réczey wrote: > >> >> >> Considering that we are already in the transition freeze I suggest >> >> >> going with enabling bindnow for all architectures in dpkg and >> >> >> for Stretch+1 the responsibility of setting some hardening flags >> >> >> could be transferred to gcc. >> >> >> IMO this is not a transition because the change does not affect >> >> >> package interdependencies. >> >> > >> >> > Is there any update on this? >> > >> > I've not seen any reply from the release team, no. And as explicitly >> > mentioned before multiple times now, this has the potential to impact >> > the release by introducing subtle and possibly hard to spot errors at >> > *run-time*, which might be triggered by simple a upload or a binNMU w/o >> > the maintainer being in the loop and knowing they have enabled bindnow. >> > So I want the release team to be involved in ACKing this potentially >> > release breaking change. >> >> I would like to kindly ask the Release Team to share its position on the >> bindnow question since Guillem don't seem to let this move forward >> without that. >> > That is very much not happening for stretch. This is a bit terse and a bit late but DD-s are still free to enable bindnow per package in the next 7 days. Affected packages: https://lintian.debian.org/tags/hardening-no-bindnow.html Thanks, Balint
Re: depending on libssl1.0-dev, buildd fails to find it
On 12/17/2016 04:49 PM, Daniel Pocock wrote: > In my reSIProcate control[1] file, I included the following: > > Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ... > > pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2] > > In the buildd[3] report, it says that libssl-dev is uninstallable on > every platform, it doesn't appear to try libssl1.0-dev > > Is buildd sensitive to the order of the dependencies when multiple > options are given? Or is there some other glitch here? sbuild will always use the first alternative of build dependencies. If you're doing this to make backporting easier, then I'm afraid that won't work - you'll have to manually change the B-D for backports. Regards, Christian
Re: depending on libssl1.0-dev, buildd fails to find it
Daniel Pocock writes: > In my reSIProcate control[1] file, I included the following: > > > Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ... > > > pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2] > > In the buildd[3] report, it says that libssl-dev is uninstallable on > every platform, it doesn't appear to try libssl1.0-dev > > Is buildd sensitive to the order of the dependencies when multiple > options are given? Or is there some other glitch here? Yes, sbuild only tries the first alternative, IIRC to keep the results reproducible. -- Arto Jantunen
depending on libssl1.0-dev, buildd fails to find it
In my reSIProcate control[1] file, I included the following: Build-Depends: ... , libssl-dev (<< 1.1) | libssl1.0-dev (>= 1.0.0), ... pdebuild correctly builds it for sid with libssl1.0-dev from openssl1.0[2] In the buildd[3] report, it says that libssl-dev is uninstallable on every platform, it doesn't appear to try libssl1.0-dev Is buildd sensitive to the order of the dependencies when multiple options are given? Or is there some other glitch here? Regards, Daniel 1. https://sources.debian.net/src/resiprocate/1:1.11.0~alpha8-1/debian/control/ 2. https://packages.qa.debian.org/o/openssl1.0.html 3. https://buildd.debian.org/status/package.php?p=resiprocate&suite=sid
Bug#848138: ITP: openfortivpn
Package: wnpp Followup-For: Bug #848138 Owner: Dimitri Papadopoulos * Package name: openfortivpn Version : 1.2.0 Upstream Author : Adrien Vergé * URL : https://github.com/adrienverge/openfortivpn * License : GPL-3 with SSL exception Description : Client for PPP+SSL VPN tunnel services
Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
On Sat, 2016-12-17 at 09:45 +0100, Wouter Verhelst wrote: > Yes, but that still says: Ack. > I think a proper procedure should involve a script that: > > - is packaged in Debian; Ack. > - checks whether the hardware it's running on has all the hardware > requirements for the new architecture apt show arch-test > - is properly tested to work in (almost) all situations; jenkins.d.n would be the place to put full-system cross-grading tests. piuparts would be the place to put per-package cross-grading tests. > - is a properly supported way to move from one ABI to another. What do you mean by "properly supported"? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
On Sat, Dec 17, 2016 at 09:45:01AM +0100, Wouter Verhelst wrote: > On Thu, Dec 15, 2016 at 11:19:34AM +0800, Paul Wise wrote: > > On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote: > > > > > One way in which the need to keep armel around would be reduced is if we > > > could somehow upgrade from armel machines to armhf ones, without > > > requiring a reinstall. > > > > There is a script for that here: > > > > https://wiki.debian.org/CrossGrading Considering my inept attempts to make such a script, this one is way too fragile to actually use. In my experience, you need to semi-manually (dpkg -i) convert the transitively-essential set, as otherwise apt will either throw its hands up or propose "remove world" as a solution. > Yes, but that still says: > > A full backup is also strongly recommended Duh. That'd be true even if it was a supported, well-tested operation. > I think a proper procedure should involve a script that: > > - is packaged in Debian; I doubt we can make one and have it in unstable before Xmas (the NEW freeze). > - checks whether the hardware it's running on has all the hardware > requirements for the new architecture (i.e., in case of armel to > armhf, can support the ARM ABI required by armhf; or in case of i386 > to amd64, is a processor that supports the x86_64 ABI), and produces a > proper error message in case the required support isn't there; Done! This is exactly what "arch-test" is for. > - is properly tested to work in (almost) all situations; Ha ha ha! > - is a properly supported way to move from one ABI to another. > > We currently don't have anything remotely like the above, and I think we > should. Here's my very early WIP: https://github.com/kilobyte/crossgrade It does only a bunch of checks, compares versions, builds and installs the essential set but doesn't go anywhere further. It also tries to reinvent the wheel in order to be resilient wrt partially aborted upgrades, I now realize I could have considered apt-perl libraries "essential" so they'd always work. And it's not like crossgrading is easily possible anyway: Unpacking libpam-modules:amd64 (1.1.8-3.3) ... dpkg: error processing archive /tmp/apt-dpkg-install-afa8lY/0-libpam-modules_1.1.8-3.3_amd64.deb (--unpack): trying to overwrite shared '/usr/share/man/man8/pam_exec.8.gz', which is different from other instances of package libpam-modules:amd64 At least my recovery code works properly, and after manual dpkg --force-overwrite /var/cache/apt/archives/libpam-modules_1.1.8-3.3_amd64.deb it resumes and succeeds until the end of implemented part. Then there is the multiarch interpreter problem. > [1] save that, I think, at the time multiarch didn't exist yet. Yes, > this was an "interesting" experience :-) Even for release architectures, binNMU versions are often not in sync. When you want something second-class (most of my crossgrading at home was to and from x32), multiarch works only in theory not practice. Meow! -- Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ./configure --host=zx-spectrum --build=pdp11
Bug#848400: ITP: kakoune -- Vim-inspired, selection-oriented code editor
Package: wnpp Severity: wishlist Owner: Peter Pentchev * Package name: kakoune Version : 0~2016.12.15.1.37fd41c-1 Upstream Author : Maxime Coste * URL : https://github.com/mawww/kakoune * License : UNLICENSE Programming Lang: C++ Description : Vim-inspired, selection-oriented code editor Kakoune is a code editor heavily inspired by Vim; as such most of its commands are similar to vi’s ones, and it shares Vi’s "keystrokes as a text editing language" model. Kakoune can operate in two modes, normal and insertion. In insertion mode, keys are directly inserted into the current buffer. In normal mode, keys are used to manipulate the current selection and to enter insertion mode. Kakoune has a strong focus on interactivity, most commands provide immediate and incremental results, while still being competitive (as in keystroke count) with Vim. Kakoune works on selections, which are oriented, inclusive range of characters; selections have an anchor and a cursor character. Most commands move both of them, except when extending selection where the anchor character stays fixed and the cursor one moves around. signature.asc Description: PGP signature
Re: [RFC] Enabling bindnow by default in dpkg-buildflags?
On Sat, Dec 17, 2016 at 09:20:40 +0100, Bálint Réczey wrote: > >> >> Considering that we are already in the transition freeze I suggest > >> >> going with enabling bindnow for all architectures in dpkg and > >> >> for Stretch+1 the responsibility of setting some hardening flags > >> >> could be transferred to gcc. > >> >> IMO this is not a transition because the change does not affect > >> >> package interdependencies. > >> > > >> > Is there any update on this? > > > > I've not seen any reply from the release team, no. And as explicitly > > mentioned before multiple times now, this has the potential to impact > > the release by introducing subtle and possibly hard to spot errors at > > *run-time*, which might be triggered by simple a upload or a binNMU w/o > > the maintainer being in the loop and knowing they have enabled bindnow. > > So I want the release team to be involved in ACKing this potentially > > release breaking change. > > I would like to kindly ask the Release Team to share its position on the > bindnow question since Guillem don't seem to let this move forward > without that. > That is very much not happening for stretch. Cheers, Julien
Re: contacting all bug reporters for a package?
On Thu, Dec 15, 2016 at 10:51:49AM -0600, Don Armstrong wrote: > That was me; sorry about that. Presumably you got all of the copies > because they were to different aliases which eventually ended up hitting > you. That reminds me of #784131. Is it possible to implement something along those lines? -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)
On Thu, Dec 15, 2016 at 11:19:34AM +0800, Paul Wise wrote: > On Thu, Dec 15, 2016 at 1:40 AM, Wouter Verhelst wrote: > > > One way in which the need to keep armel around would be reduced is if we > > could somehow upgrade from armel machines to armhf ones, without > > requiring a reinstall. > > There is a script for that here: > > https://wiki.debian.org/CrossGrading Yes, but that still says: A full backup is also strongly recommended as this procedure is still very much work in progress. Reinstalling is still the safer option. You have been warned! I think a proper procedure should involve a script that: - is packaged in Debian; - checks whether the hardware it's running on has all the hardware requirements for the new architecture (i.e., in case of armel to armhf, can support the ARM ABI required by armhf; or in case of i386 to amd64, is a processor that supports the x86_64 ABI), and produces a proper error message in case the required support isn't there; - is properly tested to work in (almost) all situations; - is a properly supported way to move from one ABI to another. We currently don't have anything remotely like the above, and I think we should. [1] save that, I think, at the time multiarch didn't exist yet. Yes, this was an "interesting" experience :-) -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
Re: [RFC] Enabling bindnow by default in dpkg-buildflags?
Hi Guillem, 2016-12-17 3:14 GMT+01:00 Guillem Jover : > On Wed, 2016-12-14 at 14:05:44 +0100, Bálint Réczey wrote: >> 2016-12-13 9:29 GMT+01:00 Bálint Réczey : >> > 2016-11-27 23:11 GMT+01:00 Bálint Réczey : >> >> 2016-11-23 2:30 GMT+01:00 Guillem Jover : >> >>> My mine concern is and has always been that bindnow changes the >> >>> run-time behavior (instead of the build-time one) and could break >> >>> things such as dlopen() on shared libraries or plugins and similar. >> >>> And detecting problems becomes harder, and reverting this change >> >>> iff we notice that it breaks too much might imply rebuilding an >> >>> unspecified number of packages. So in a way it feels kind of like >> >>> a transition? >> >>> >> >>> OTOH Ubuntu seems to have been enabling not only PIE and bindnow by >> >>> default in gcc for a long time, but also relro, stack-protector and >> >>> fortify. Which would seem to imply this might not break that much? >> >>> (I'm not sure why we are not enabling all those in gcc in Debian >> >>> too, but that's probably a different conversation to have if at all.) >> >> >> >> Lucas already performed the archive-wide rebuild with bindnow >> >> enabled by dpkg and we have not observed breakages specific to >> >> bindnow. IMO this is mostly due to packages already disabling >> >> bindnow through dpkg-buildflags. > > But you didn't do the requested archive-wide autopkgtest run (because > "it was hard"), and even though the coverage is not great it would > be better than nothing. Requested in this case because bindnow changes > the *run-time* behavior, which is not visible or noticable in normal > circumstances by just *building* packages. I'm surprised you raise the autopkgtest run question. Have you missed my email about this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835146#12 2016-10-10 14:06 GMT+02:00 Balint Reczey : > Dear Guillem, > > On Tue, 23 Aug 2016 00:14:25 +0200 Balint Reczey > wrote: > ... >> Dear Guillem, >> >> As a continuation of the discussions [1][2] on debian-devel I'm >> attaching the simple patch that implements enabling the bindnow >> hardening flags. >> >> I'm continuing with the rebuild/autopkgtest tests according to >> the Dpkg FAQ, hence the moreinfo tag. > > The rebuild (with PIE and bindnow enabled) resulted ~1000 FTBFS > cases from which all seem to be related to enabling PIE by > default [3]. > > ~70 of the filed related bugs [4] are still open. > > Since the rebuild was run with tests enabled this seems to be a > good indication that we can expect very few breakages from > enabling bindnow by default. > > Running autopkgtest would need more work as AFAIK there is no > automated method for doing it like rebuilds [5]. > > I'm wondering if you find the autopkgtest round necessary for > this change. You never answered, but I thought you read the whole bug history. I asked for clarification then because the on 13 Aug you added the following line to dpkg FAQ which does not seem to be a strong requirement: * For flags that change run-time semantics, ideally an additional run of the autopkgtest for packages that ship them (although this cannot be deemed conclusive as our coverage is not great yet). ( https://wiki.debian.org/Teams/Dpkg/FAQ?action=diff&rev1=28&rev2=29 ) I would say it would have been really nice to provide a feedback about your position two months ago because I could set up something to run the aforementioned autopkgtest run in addition to the archive wide rebuild which included all build-time tests, but you can still add your answer to the bug report. > >> >> Considering that we are already in the transition freeze I suggest >> >> going with enabling bindnow for all architectures in dpkg and >> >> for Stretch+1 the responsibility of setting some hardening flags >> >> could be transferred to gcc. >> >> IMO this is not a transition because the change does not affect >> >> package interdependencies. >> > >> > Is there any update on this? > > I've not seen any reply from the release team, no. And as explicitly > mentioned before multiple times now, this has the potential to impact > the release by introducing subtle and possibly hard to spot errors at > *run-time*, which might be triggered by simple a upload or a binNMU w/o > the maintainer being in the loop and knowing they have enabled bindnow. > So I want the release team to be involved in ACKing this potentially > release breaking change. I would like to kindly ask the Release Team to share its position on the bindnow question since Guillem don't seem to let this move forward without that. Thanks, Balint > > I guess this is "The current PIE situation is already an unholy mess" > (which I'll cover in another mail), so let's make the mess bigger > approach to releasing the distribution… > >> > We are running out of time... >> >> I have uploaded a dpkg NMU with bindnow enabled to DELAYED/10 >> according to current NMU rules. If the Release Team increases the >> severity of #835146 it can reac
