Re: OpenSSL 1.1.0
Hi, On Fri, Nov 04, 2016 at 11:58:44PM +0200, Adrian Bunk wrote: > You could enforce that no Qt-using package uses the wrong OpenSSL by > adding libssl1.0-dev dependencies to libqt4-dev and qtbase5-dev. How can I handle the case of a package which uses both qt and curl? The latter already switched to OpenSSL 1.1. Jan
Bug#843969: ITP: goiardi -- A Chef server written in Go, able to run entirely in memory, with optional persistence with saving the in-memory data to disk or using MySQL or Postgres as the data storage
Package: wnpp Severity: wishlist Owner: Jordi Mallach * Package name: goiardi Version : 0.11.0+git20161027.4.7d585ad-1 Upstream Author : Jeremy Bingham * URL : https://github.com/ctdk/goiardi * License : Apache-2.0 Programming Lang: Go Description : A Chef server written in Go Goiardi is an implementation of the Chef server written in Go. It can either run entirely in memory with the option to save and load the in-memory data and search indexes to and from disk, drawing inspiration from chef-zero, or it can use MySQL/MariaDB or PostgreSQL as its storage backend.
Bug#843970: ITP: ufo-core -- Library for high-performance, GPU-based computing
Package: wnpp Severity: wishlist Owner: picca * Package name: ufo-core Version : 0.11.0 Upstream Author : matthias.vogelges...@kit.edu * URL : http://ufo.kit.edu/ * License : LGPL-3+ Programming Lang: C, Python Description : Library for high-performance, GPU-based computing The UFO data processing framework is a C library suited to build general purpose streams data processing on heterogeneous architectures such as CPUs, GPUs or clusters. It is extensively used at the Karlsruhe Institute of Technology for Ultra-fast X-ray Imaging (radiography, tomography and laminography). . A gobject-instrospection binding is also provided to write scripts or user interfaces.
Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)
On Fri, 11 Nov 2016, Christoph Biedl wrote: > a proof of concept for all this (I can resist, though). The apt programs > could obfuscate their request behaviour, the TLS layer could add random > padding of data and time, but I doubt this would help much. AFAIK, the TLS layer *does* bit-stuffing and random padding, but it cannot do that to the point it would help the problem at hand, and still be usable. Bitstuffing TLS to the point it could (maybe) deal with the Debian archive is the wrong solution for the problem anyway, so I won't expand on this. -- Henrique Holschuh
Re: Crowd funding campaign to package browserify in debian
On Tuesday 01 November 2016 02:01 PM, Pirate Praveen wrote: > We shifted out focus to grunt from browserify realizing grunt is needed > by more packages. Final update before the fund raising closes in about 20 hours https://poddery.com/posts/2734574 Summary: all new dependencies are completed (4 including grunt are pending upload waiting for update to node-lodash, node-async, node-which and node-glob). We have already completed 19 days of work (120 new packages and 8 updates). We raised only half the target and completed close to the same amount of work. Gitlab Inc is our big backer contributing 1000 USD. Those of you who missed he campaign can still contribute at https://igg.me/at/debian-browserify signature.asc Description: OpenPGP digital signature
Re: OpenSSL 1.1.0
Hi,
(Cc to Alessandro because this causes issues with libcurl)
On Wed, Nov 02, 2016 at 09:15:13PM +0100, Kurt Roeckx wrote:
> I don't think having libssl1-1-dev vs libssl1.0-dev is going to
> make much differences in the end. The build conflicts will always
> have to be sorted out.
Well I think it makes a difference:
With libssl-dev silently switching to OpenSSL 1.1, packages get
recompiled with the new version, but the maintainers may be unaware that
this causes compatibility issues.
I have a concrete example:
It seems like the package zurl is broken by libcurl3 being linked with
OpenSSL 1.1.
This means the binary package zurl 1.7.0-1 works fine with libcurl3
7.50.1-1, but fails to connect to https URLs when libcurl3 is upgraded
to 7.51.0-1.
(It also works with curl 7.51.0-1 recompiled with OpenSSL 1.0, so I'm
quite sure it's actually caused by the OpenSSL transition.)
So, in short, upgrading libcurl3 breaks existing binary packages.
According to our policy, that means a SONAME change would be necessary.
("Every time the shared library ABI changes in a way that may break
binaries linked against older versions of the shared library, the SONAME
of the library and the corresponding name for the binary package
containing the runtime shared library should change.")
But the way the OpenSSL transition was communicated, Alessando probably
didn't expect that the change would cause an ABI change.
How do we handle this?
For this single package, zurl, I could recompile with OpenSSL 1.1. This
seems to work, but I'm not sure if there are hidden issues, as zurl also
links to qt5, which is built against libssl1.0-dev.
But who knows which other packages are silently broken the same way?
Jan
Re: OpenSSL 1.1.0
On Fri, Nov 11, 2016 at 01:23:31PM +0100, Jan Niehusmann wrote: > Hi, > > But who knows which other packages are silently broken the same way? At least something like that also came up with xmltooling. It's probably caused by this: curl_easy_setopt(easy, CURLOPT_SSL_CTX_FUNCTION, &sslCtxFunction_cb); You get an SSL_CTX from OpenSSL 1.1 and you call an OpenSSL 1.0 function with that handle. And libcurl really shouldn't have been exposing such functions directly. If something like that is really needed libcurl should have made a proper wrapper. PS: Is there a reason zurl implements it's own hostname validation checking an doesn't just use libcurls? Kurt
Bug#843986: ITP: ruby-ya2yaml -- An UTF8 safe YAML dumper.
Package: wnpp Severity: wishlist Owner: Micah Anderson * Package name: ruby-ya2yaml Version : 0.31 Upstream Author : Akira FUNAI * URL : http://rubyforge.org/projects/ya2yaml/ * License : MIT Programming Lang: Ruby Description : An UTF8 safe YAML dumper. Ya2YAML is "yet another to_yaml". It emits YAML document with complete UTF8 support (string/binary detection, "\u" escape sequences and Unicode specific line breaks). I plan to maintain this package in the ruby-pkg-extras team, it is needed for some dependencies for other packages.
Re: OpenSSL 1.1.0
On Fri, Nov 11, 2016 at 03:15:09PM +0100, Kurt Roeckx wrote: > At least something like that also came up with xmltooling. > It's probably caused by this: > curl_easy_setopt(easy, CURLOPT_SSL_CTX_FUNCTION, &sslCtxFunction_cb); > > You get an SSL_CTX from OpenSSL 1.1 and you call an OpenSSL 1.0 > function with that handle. And libcurl really shouldn't have been > exposing such functions directly. If something like that is > really needed libcurl should have made a proper wrapper. Yes, I agree that libcurl shouldn't expose such functions. But it does, and it's to late to change that. By exposing that function, SSL_CTX became part of curl's ABI. So by linking to a different OpenSSL version with a different representation of SSL_CTX, curl indeed changed its ABI and must change SONAME, right? Jan
Bug#843990: ITP: node-tmatch -- Match an object against a "pattern" object - Node.js module
Package: wnpp Severity: wishlist Owner: "Jérémy Lal" * Package name: node-tmatch Version : 3.0.0 Upstream Author : Isaac Z. Schlueter (http://blog.izs.me/) * URL : https://github.com/isaacs/tmatch#readme * License : ISC Programming Lang: JavaScript Description : Match an object against a "pattern" object - Node.js module This module checks weter a value matches a given pattern. A pattern is an object with a set of fields that must be in the test object, or a regular expression that a test string must match, or any combination thereof. . Node.js is an event-based server-side JavaScript engine.
Bug#843992: ITP: ruby-knife-acl -- Knife plugin to manupulate Chef server access control lists
Package: wnpp Severity: wishlist Owner: Stefano Rivera * Package name: ruby-knife-acl Version : 1.0.3 Upstream Author : Seth Falcon , Jeremiah Snapp * URL : https://github.com/chef/knife-acl * License : Apache-2.0 Programming Lang: Ruby Description : Knife plugin to manupulate Chef server access control lists
Re: OpenSSL 1.1.0
On viernes, 11 de noviembre de 2016 16:05:49 ART Jan Niehusmann wrote: > On Fri, Nov 11, 2016 at 03:15:09PM +0100, Kurt Roeckx wrote: > > At least something like that also came up with xmltooling. > > It's probably caused by this: > > curl_easy_setopt(easy, CURLOPT_SSL_CTX_FUNCTION, &sslCtxFunction_cb); > > > > You get an SSL_CTX from OpenSSL 1.1 and you call an OpenSSL 1.0 > > function with that handle. And libcurl really shouldn't have been > > exposing such functions directly. If something like that is > > really needed libcurl should have made a proper wrapper. > > Yes, I agree that libcurl shouldn't expose such functions. But it does, > and it's to late to change that. > > By exposing that function, SSL_CTX became part of curl's ABI. > > So by linking to a different OpenSSL version with a different > representation of SSL_CTX, curl indeed changed its ABI and must > change SONAME, right? That or switching it's B-D to libssl1.0-dev to avoid the breackage, but yes, you are right. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
Bug#844010: ITP: deepnano -- DeepNano is alternative basecaller for Oxford Nanopore MinION reads based on deep recurrent neural networks.
Package: wnpp Severity: wishlist Owner: "Çağrı ULAŞ" X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org * Package name: deepnano Upstream Author : Vladimir Boza * URL : https://bitbucket.org/vboza/deepnano/ * License : (BSD-3-clause) Programming Lang: (C++, Python) Description : DeepNano is alternative basecaller for Oxford Nanopore MinION reads based on deep recurrent neural networks.
missing -dbgsym packages on uploads by maintainer(s)
there are a bunch of package which were missing -dbgsym packages on their arch upload. The buildd built them on the remaining architectures. Here are a few examples: - missing on amd64: aptly, meep, xdelta3 - missing on i386: chasen, cronutils, maildrop my understanding is that those are built and automatically added to the changes file so they have to uploaded unless they are removed manually. Is there maybe a loophole? Is there anything we can/should do once such a package is found except binNMU it each time? Sebastian
Bug#844022: ITP: node-marked-man -- Markdown to man page conversion - Node.js
Package: wnpp Severity: wishlist Owner: "Jérémy Lal" * Package name: node-marked-man Version : 0.1.5 Upstream Author : Jérémy Lal * URL : https://github.com/kapouer/marked-man * License : Expat Programming Lang: JavaScript Description : Markdown to man page conversion - Node.js This module adds groff output support to node-marked. It provides an easy way to maintain man pages in a markdown format (with gfm flavor by default). . Node.js is an event-based server-side JavaScript engine
Bug#844023: ITP: node-marked-man -- Markdown to man page conversion - Node.js
Package: wnpp Severity: wishlist Owner: "Jérémy Lal" * Package name: node-marked-man Version : 0.1.6 Upstream Author : Jérémy Lal * URL : https://github.com/kapouer/marked-man * License : Expat Programming Lang: JavaScript Description : Markdown to man page conversion - Node.js This module adds groff output support to node-marked. It provides an easy way to maintain man pages in a markdown format (with gfm flavor by default). . Node.js is an event-based server-side JavaScript engine
Bug#844030: ITP: node-tap-parser -- Test anything protocol stream parser - Node.js module
Package: wnpp Severity: wishlist Owner: "Jérémy Lal" * Package name: node-tap-parser Version : 3.0.3 Upstream Author : James Halliday (http://substack.net) * URL : https://github.com/substack/tap-parser * License : Expat Programming Lang: JavaScript Description : Test anything protocol stream parser - Node.js module This module parses tap-formatted input as a stream of JavaScript objects. It is mainly used to extend tap reporters in various test setups. . Node.js is an event-based server-side JavaScript engine. This module is a dependency of latest node-tap / node-tap-mocha-reporter. It is also a dependency of many other softwares using tap, is well maintained and popular.
Re: Building architecture:all packages
Nikolaus Rath wrote... > Just fix it in "bar", and don't bother worrying about the right > severity? If it was that simple ... The maintainers of "bar" haven't reacted to the bug report for a few months although it contains a clear statement the current state breaks the build of other packages. And in general I include patches into my bug reports, but the "bar" package is rather big, some 400 kLOC. I have a vague idea of what precisely is supposed to happen. Also I already spent some time to find the change. The last hours I've been playing with gcov to find differing code paths taken, so far no avail. Still, I might get this sorted out. However, this incident raised a second, more generic question: Is this an acceptable state? If John wants to rebuild packages like "foo", he cannot simply use his preferred architecture. The build may fail, then he has to start trying other ones until success. I don't consider this a satisfying situation. On the other hand I can understand Debian maintainers wern't very happy to learn a bug in the toolchain of a doorstopper architecture causes FTBFS there for one of their packages, which might even result in a removal from testing. So I was looking whether there is a consensus about this. If not, I wouldn't mind if this ends in a guideline (seems a bit to much in detail for Debian policy) about packages that solely build arch:all binary packages. Like: They must be buildable at least on certain architectures, I called them "mostly used architectures" in my first mail. I would strongly suggest that list should not solely consist of amd64. Christoph signature.asc Description: Digital signature
Re: Building architecture:all packages
Paul Wise wrote... > On Fri, Nov 11, 2016 at 7:32 AM, Christoph Biedl wrote: > > > Other suggestions? > > Include information about which packages/issues you are talking about. How would this affect your assesment of the situation? In my feeling, revealing the pakages' names would give the story some kind of blaming. That's not my intention. Christoph signature.asc Description: Digital signature
Re: OpenSSL 1.1.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi there, Am 02.11.2016 um 21:15 schrieb Kurt Roeckx: > I don't think having libssl1-1-dev vs libssl1.0-dev is going to > make much differences in the end. The build conflicts will always > have to be sorted out. thats the point where I rushed into another problem, monitoring-plugins isn't compatible with openssl 1.1[1]. So you might argue just to link against libssl1.0-dev. The issue is that monitoring-plugins makes massive use of other libraries. When now installing libssl1.0-dev all packages build against libssl1-1-dev will be removed. The first lib I spotted was libpq-dev, I expect more to follow. This means now I can hope to get openssl 1.1 support (under pressure) for monititoring-plugins and every lib works hopefully well with it. When no openssl 1.1 support will be available, I can try to depend on libssl1.0-dev, but can not build all plugins that was shiped with jessie . This doesn't look like a smooth move for monitoring-plugins. Just my 2 cents, Jan. [1] https://bugs.debian.org/844031 - -- Never write mail to , you have been warned! - -BEGIN GEEK CODE BLOCK- Version: 3.12 GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V- PS PE Y++ PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y - --END GEEK CODE BLOCK-- -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYJkZbAAoJEAxwVXtaBlE+bAEP/RNEI7EXv5BNIo/y3Yo9acI/ 4kK6XwLbAUUcQSuyVtFgz4kiqiQsfk/X8gwwvLFEFZ0UNZCOCslv/2/2bJs6vnRX lQ60l3g/OGdZ72O0qVnrLDfVm28oIqoxuKW8zpoYP5hFAnvFzSWgw0AFPv7BfbPS nHvVc8KJ6KkRJEFofcDBcA0oO88XoAG47JXA2YhS7WWE4yKkBm/Hvhv4z3FSTa3a z6qhv9aSINyHXsSnIqyuy8kVwIzBMSbB70Nn0DSKu93PHgWxlgmOXopUCBlUgkeC i5FxxxZ4W4kDnlrrBH7ctjeHBkIWRBX6LUCogQ9x/sCPjIvipBzfvA+LxYQkmoIx HBmKQshaeMAkEnwIQhv4l3jSpUVAedZr4/bfE7dyxKtZBWTiaOKTr62kMKzIWU6O XdB5/FbRzSFSXXl+KzxR1l9R6H/vAn1PH16X+3ZBkJdapTGOHsx4q8lYQVwvHCfi yo6GNdEPVds095pci5+LRj8yeDURP2Mp3xQX7t49AEg3BafznnB37LXyOWev8ZSr gd83huZO/yYvktoptTLWQ1t2x/KJSwQ2m5yk/Jj6AMPQN43LzdqO1USAbHrflYON NEi4DcXktkHCBahbfPP6eRyObO5KTLK10z6bFjRtpX3TmXm1O9g7jTMt6zQPYKUH 77/7+ON5vJrKMS5CgaXv =vEi+ -END PGP SIGNATURE-
Re: missing -dbgsym packages on uploads by maintainer(s)
On 2016-11-11 22:38 +0100, Sebastian Andrzej Siewior wrote: > there are a bunch of package which were missing -dbgsym packages on > their arch upload. The buildd built them on the remaining architectures. > Here are a few examples: > - missing on amd64: aptly, meep, xdelta3 > - missing on i386: chasen, cronutils, maildrop > > my understanding is that those are built and automatically added to the > changes file so they have to uploaded unless they are removed manually. Or if they have not been created in the first place, such when the package has been built with a debhelper version prior to 9.20151219. > Is there anything we can/should do once such > a package is found except binNMU it each time? Unconditionally throwing away any binary packages the maintainer uploads and always building them on the buildds would help, as has been discussed for at least 12 years[1]. Cheers, Sven 1. https://lists.debian.org/debian-security/2004/09/msg00014.html
Re: missing -dbgsym packages on uploads by maintainer(s)
On Fri, Nov 11, 2016 at 10:38:27PM +0100, Sebastian Andrzej Siewior wrote: > there are a bunch of package which were missing -dbgsym packages on > their arch upload. The buildd built them on the remaining architectures. > Here are a few examples: > - missing on amd64: aptly, meep, xdelta3 And coreutils. I'm happy that at last we have something resembling a proper build infrastructure but it looks like it's still a long road. What stops us from throwing away .debs from maintainers starting tomorrow? -- WBR, wRAR signature.asc Description: PGP signature
Re: missing -dbgsym packages on uploads by maintainer(s)
On Sat, Nov 12, 2016 at 03:53:39AM +0500, Andrey Rahmatullin wrote: > What stops us from throwing away .debs from maintainers starting tomorrow? The need of being able to upload .debs for bootstrapping reasons? Sure, if dak's going to implement some override mechanism there should really be no problem. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: missing -dbgsym packages on uploads by maintainer(s)
On Sat, Nov 12, 2016 at 03:53:39AM +0500, Andrey Rahmatullin wrote: > On Fri, Nov 11, 2016 at 10:38:27PM +0100, Sebastian Andrzej Siewior wrote: > > there are a bunch of package which were missing -dbgsym packages on > > their arch upload. The buildd built them on the remaining architectures. > > Here are a few examples: > > - missing on amd64: aptly, meep, xdelta3 > And coreutils. > I'm happy that at last we have something resembling a proper build > infrastructure but it looks like it's still a long road. > > > What stops us from throwing away .debs from maintainers starting tomorrow? The machinery for arch:all binaries is still incomplete: * it supports only packages buildable on amd64, there are some which require a specific host[1] arch * wanna-build(?)'s resolution of arch-specific build-depends is buggy. For example, my package arch-test wants, among others: binutils-x86-64-linux-gnu [!amd64 !i386 !x32] which is a no-op on amd64, properly recognized as such by dpkg-dev, debuild, sbuild, pbuilder, etc, yet the package never gets picked for autobuilding. Both of the above can be worked around by a binary upload. On the other hand, there's currently no incentive to find a real solution. Meow! [1]. Using the sane kernel or cmake nomenclature, not autotools one where an armhf build on an amd64 host wants --build=amd64 --host=armhf. -- A true bird-watcher waves his tail while doing so.
Re: Building architecture:all packages
On Sat, Nov 12, 2016 at 6:32 AM, Christoph Biedl wrote: > How would this affect your assessment of the situation? The details matter, without them I don't think any assessment is useful. > In my feeling, revealing the packages' names would give the story some kind of > blaming. That's not my intention. I don't think mentioning package names is blaming, but I understand not everyone takes it that way. When mentioning the details you could be more explicit that your intention is not to blame anyone. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Building architecture:all packages
On Fri, Nov 11, 2016 at 7:32 AM, Christoph Biedl wrote: > implies "src:foo" must build on *all* architectures In general, Debian does not define the build architecture for any package, no matter what the Architecture of the package is. In practice, arch:all packages must build on either amd64 (arch:all buildds run that), or an architecture developers are able to build the package from. In practice, arch:any packages must build on one of the Debian/ports arches (for the arch:any buildds), or on an architecture developers are able to cross-build the package from. Generally, we much prefer to have builds happen on the buildds than on developer machines though. We currently do not have any cross-building buildds AFAIK, although there is the rebootstrap stuff. https://wiki.debian.org/HelmutGrohne/rebootstrap Obviously, it would be great if we could build arch:all packages on any arch, native build on any arch and cross-build from any arch to any other arch, but the world isn't an ideal place and neither is Debian. IIRC there are mechanisms on the buildds to deal with arch:any builds that don't work on some architectures. -- bye, pabs https://wiki.debian.org/PaulWise
Re: missing -dbgsym packages on uploads by maintainer(s)
On Sat, Nov 12, 2016 at 12:58:13AM +0100, Adam Borowski wrote: > The machinery for arch:all binaries is still incomplete: > * it supports only packages buildable on amd64, there are some which require > a specific host[1] arch We (Ubuntu) discussed this with Debian ftpmaster/buildd-admin types a while back and came to an agreement that we'd accept a Build-Indep-Architecture .dsc field, which you'd typically write as e.g. "XS-Build-Indep-Architecture: arm64" in debian/control; so this is at least specified, and we implemented it in Launchpad in February 2015. https://bugs.launchpad.net/launchpad/+bug/217427 has details and links to code. I guess this never got followed through in dak, although there are a couple of packages in unstable that use it anyway. (I wasn't in the actual discussion, so my belief that it was a discussion with ftpmaster/buildd-admin is at second hand and from memory, but I'm reasonably sure ...) Of course we have more incentive to deal with this kind of thing, since Launchpad won't accept binary uploads from anyone. We deal with bootstrapping by having a very small set of people who can (with some effort) inject binaries as extra build-dependencies for nominated builds, but that's very much an exceptional process. > * wanna-build(?)'s resolution of arch-specific build-depends is buggy. For > example, my package arch-test wants, among others: > binutils-x86-64-linux-gnu [!amd64 !i386 !x32] > which is a no-op on amd64, properly recognized as such by dpkg-dev, > debuild, sbuild, pbuilder, etc, yet the package never gets picked for > autobuilding. Possibly a dose-builddebcheck bug, though it could certainly be in the fairly complex wanna-build integration with dose-builddebcheck (https://anonscm.debian.org/cgit/mirror/wanna-build.git/tree/bin/wanna-build#n1846 and the various functions it calls). -- Colin Watson [cjwat...@debian.org]
Re: What to do when a maintainer is blocking maintenance for stretch?
Hi!
On Wed, 2016-11-09 at 12:12:43 +, Ian Jackson wrote:
> Peter Colberg writes ("What to do when a maintainer is blocking maintenance
> for stretch?"):
> > Improving the package would require significant changes that are not
> > appropriate for a minimal NMU. With the maintainer not responding to
> > anything other than MIA requests to retain their maintainer status,
> > is there any other way to get the package back in shape for stretch?
>
> The advice from Emilio to upload your proposed big changes to
> DELAYED/10 is probably good.
Yes. Or fill the bug reports with patches. Or find someone who knows the
maintainer who can perhaps mediate. Or bring it over to debian-devel. And
probably report it again to MIA. :)
> In theory you should ask the Technical Committee to depose the
> maintainer.
Peter, I'd urge you to not invoke the tech-ctte (pretty much never, but
even less so in cases like this!).
Using the tech-ctte for human disputes is the Thunderdome approach to
conflict resolution. The show will be bloody and messy with lots of
chainsaws, iff the contender(s) get out of the dome at all, they will
surely carry scars, and you might or might not get a winner, after
all Tina Turner is the one who will decide who wins anyway…
Regards,
Guillem
Re: Building architecture:all packages
On Thu, Nov 10, 2016 at 08:52:15PM -0800, Nikolaus Rath wrote: > On Nov 11 2016, Christoph Biedl wrote: > > b) This is a serious issue as John D. Rebuilder should be free to choose > >on which architecture to build "src:foo". > > > > Personally, I tend to b) since > > > > * there is no sane way for the maintainer to tell the world which > > architecture should be used to rebuild this package. The .buildinfo > > file will solve this, still > > * it is certainly rather unfriendly to expect John to have a box for > > that particular architecture just to be able to do the rebuilding. > > That's a good theoretical argument. But in practice, I think the subset > of architectures for which bar works correctly will always include > amd64, and John D. Rebuilder will have access to such a box for sure. We know this not to have been the case in the past. https://bugs.launchpad.net/launchpad/+bug/217427 mentions the cases of palo (hppa), openhackware (powerpc), and openbios-sparc (sparc). (People often suggest cross-compiling for this, and that can certainly be a good solution in some cases, but please bear in mind that in the general case that still only reduces the problem to "can only build on architectures where somebody's uploaded the necessary cross tools".) There is currently one package in the Debian archive (pixfrogger) that declares "Build-Indep-Architecture: i386" in its .dsc because, even though it builds an architecture-independent binary package, building it requires a package that's only available on 32-bit architectures. See https://bugs.debian.org/534063. Conceivably this particular case could be handled by Multi-Arch: foreign, but requiring (re)builders to have a suitable multi-arch setup available raises the bar for them and would certainly considerably complicate buildd infrastructure. As I allude to in https://lists.debian.org/debian-devel/2016/11/msg00457.html, I think the best answer is for Debian's buildd infrastructure to follow through on implementing Build-Indep-Architecture. I'm not sure how this interacts with Debian's decision to make Architecture: all buildds separate entities, since that means it isn't just a matter of setting a "build the arch-indep portion as well" flag when a particular buildd takes a build; but it should still be doable somehow. -- Colin Watson [cjwat...@debian.org]
Re: missing -dbgsym packages on uploads by maintainer(s)
Hi, Quoting Colin Watson (2016-11-12 03:58:04) > On Sat, Nov 12, 2016 at 12:58:13AM +0100, Adam Borowski wrote: > > * wanna-build(?)'s resolution of arch-specific build-depends is buggy. For > > example, my package arch-test wants, among others: > > binutils-x86-64-linux-gnu [!amd64 !i386 !x32] which is a no-op on amd64, > > properly recognized as such by dpkg-dev, debuild, sbuild, pbuilder, etc, > > yet the package never gets picked for autobuilding. > > Possibly a dose-builddebcheck bug, though it could certainly be in the > fairly complex wanna-build integration with dose-builddebcheck > (https://anonscm.debian.org/cgit/mirror/wanna-build.git/tree/bin/wanna-build#n1846 > and the various functions it calls). it doesn't seem to be a dose-builddebcheck bug. Consider the following Packages file: --%<-- Package: build-essential Architecture: amd64 Version: 1 -->%-- And the following Sources file: --%<-- Package: foo Architecture: any Version: 1 Build-Depends: binutils-x86-64-linux-gnu [!amd64 !i386 !x32] -->%-- Then dose-builddebcheck with amd64 as the build and host architecture will happily find a solution (which doesn't include binutils-x86-64-linux-gnu): $ dose-builddebcheck --explain --successes --deb-native-arch=amd64 Packages Sources output-version: 1.2 native-architecture: amd64 report: - package: foo version: 1 architecture: any type: src status: ok installationset: - package: foo version: 1 architecture: any type: src - package: build-essential version: 1 architecture: amd64 binary-packages: 2 source-packages: 1 broken-packages: 0 $ echo $? 0 I tried the same in a Debian stable chroot and dose-builddebcheck succeeds as well. Quickly skimming the code I cannot see where the error could come from. wanna-build seems to use Dpkg::Deps::deps_parse to do the architecture filtering as it should in the filterarch function. Thanks! cheers, josch signature.asc Description: signature
Re: missing -dbgsym packages on uploads by maintainer(s)
On Sat, Nov 12, 2016 at 12:58:13AM +0100, Adam Borowski wrote: > > What stops us from throwing away .debs from maintainers starting tomorrow? > > The machinery for arch:all binaries is still incomplete: Fine, what stops us from throwing away arch:!all .debs? -- WBR, wRAR signature.asc Description: PGP signature
Re: [buildd-tools-devel] Bug#843773: Bug#843773: misleading timestamps in binnmus
Hi, Quoting Ximin Luo (2016-11-10 18:13:00) > Holger Levsen wrote: > > On Thu, Nov 10, 2016 at 08:59:48AM -0200, Johannes Schauer wrote: > > > One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every > > > binNMU to a package. > > > > > > Any other ideas? > > set SOURCE_DATE_EPOCH to the creation time of that changelog.$arch > > entry? > I'm tending towards the latter suggestion because it's simpler. There's no > need to stick to a +1 second scheme etc, and it might mislead people into > thinking they can do calculations with this - such as reversing the original > timestamp of the sourceful-upload. maybe I'm misunderstanding the problem but for the sake getting a better picture, let me write a summary of the conversation so far: Currently, buildds (using sbuild) create binNMU changelog entries by copying the date from the last changelog entry. See for example libghc-yesod-auth-oauth-dev. 16 binNMUs and the same timestamp is used for all of them. In his original post, Ian complains that despite the package version being incremented, the file mtimes are not. This is because we now use the timestamp from the latest changelog entry for the mtimes of the binary package contents so that the binary packages become reproducible. If we want to have later mtimes for the files in binNMU binary packages compared the ones in the last version, then the question becomes: which mechanism should we use to set this timestamp? I do not think that reproducibility is an issue here. No matter which mechanism we choose to determine the timestamp of the new changelog entry, that timestamp will be recorded in the Binary-Only-Changes field of the generated .buildinfo file. The content of that field can then be used by package builders to generate the new debian/changelog which in turn means that at the time that dpkg-buildpackage is run, SOURCE_DATE_EPOCH will be set to a deterministic value: the value of the last changelog entry which we obtain from the Binary-Only-Changes field. Back to the question of how we should determine the initial timestamp for the new binNMU. One way would be to just use the timestamp of the time at which the binNMU changelog entry is created by sbuild on the buildds. The problem with this approach is, that binNMUs will be done at slightly different times on each architecture and thus a different changelog timestamp will be used per architecture. This does not cause Multi-Arch:same file conflicts because of the changelog itself because these are stored in architecture-specific paths for binNMUs (if dh_installchangelogs is used). Instead, file conflicts might be created from files with content that depends on SOURCE_DATE_EPOCH. Because each architecture will generate their own timestamp, SOURCE_DATE_EPOCH will be different on each. If the content of shared files depends on the set timestamp, then these packages will not be co-installable anymore. One solultion to this problem would be to mandate that files shared across Multi-Arch:same binary packages must be independent of SOURCE_DATE_EPOCH but that might impose too much of a burden of writing and then maintaining the appropriate patches for upstreams that refuse to become independent of SOURCE_DATE_EPOCH. Moving the architecture-invariant but SOURCE_DATE_EPOCH dependent files to Architecture:all packages is not a solution either because we might want the packages containing these files be able to transport their architecture to their dependencies. Thus I think it would be best if the changelog timestamp for the same binNMU version would be equal across all architectures. One way to achieve this would be by using a unified scheme to generate the timestamps, for example by incrementing the original timestamp by one second for each binNMU. Another way to achieve this would be to require a timestamp to be supplied (or generated) every time a binNMU is scheduled. That timestamp would then be passed to all buildds and be used by sbuild to generate the new entry in debian/changelog. What do you think? Thanks! cheers, josch signature.asc Description: signature
Re: missing -dbgsym packages on uploads by maintainer(s)
On 11/12/2016 08:10 AM, Andrey Rahmatullin wrote: > On Sat, Nov 12, 2016 at 12:58:13AM +0100, Adam Borowski wrote: >>> What stops us from throwing away .debs from maintainers starting tomorrow? >> >> The machinery for arch:all binaries is still incomplete: > Fine, what stops us from throwing away arch:!all .debs? Actually, there could be another option: - by default, throw away all binary debs on uploads - there is a special field in the .changes file (automatically set by buildds) to tell dak to keep the debs e.g. Keep-Binaries: yes That way people can still upload in cases where the current build infrastructure fails, but in the vast majority of cases where that's not a problem this wouldn't happen. And for packages where this does fail, just add the field to d/control (with XC- prefix), so you don't need to think about that at each upload. Thoughts? Regards, Christian
