Re: Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same
On 2018-04-12 19:41, Holger Levsen wrote: > control: retitle -1 "buildd.d.o: binNMUs should be replaced by easy > no-change-except-d/changelog-uploads" > # I hope this is correct, realistic and accurate ;) > # if not, please fixup? > #thanks That can't be done on the wanna-build side, uploads to the archive needs to be signed. Time to reassign this bug to ftp.debian.org? Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups
On 2017-08-28 18:06, Adam Warner wrote: > On Sat, 2017-05-13 at 22:48 +0200, Aurelien Jarno wrote: > > On 2017-05-13 21:34, Aurelien Jarno wrote: > > > On 2017-05-13 17:52, Mattia Rizzolo wrote: > > > > On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote: > > > > > a) Has anything changed in the meantime? > > > > > > > > Yes: sbuild stopped repeating the changelog time taking it from > > > > the last > > > > entry, and will instead generate a new timestamp based on the > > > > current > > > > time: > > > > > > > > * For binNMUs, instead of copying the timestamp of the last > > > > changelog entry, > > > > generate a new one (closes: #843773) > > > > > > > > In version 0.73.0-1. > > > > > > And I am glad that after all that months with people talking about > > > the > > > issue, I finally got a detailed description of the issue and a > > > pointer > > > to the commit to backport. I'll work on that. > > > > The above change should now be deployed on most jessie based buildds, > > it's only missing on the buildds that are currently down. > > Original thread author here reporting to beware that some rsync data > corruption can still become apparent after all this time. > > It's been a while since I did a full rsync checksum test. Decided to do > one after a recent upgrade that includes clang 3.9 related files. These > are Debian systems that default to unstable BUT include all debian apt > sources including experimental/unstable/testing/stable/oldstable. > > I found these four corrupted files in my rsync backups: > > var/lib/dpkg/info/clang-3.9.md5sums > var/lib/dpkg/info/libclang-common-3.9-dev.md5sums > var/lib/dpkg/info/libclang1-3.9:amd64.md5sums > var/lib/dpkg/info/libllvm3.9:amd64.md5sums > > The latest packages were installed from this repository: > > Get:17 https://cdn-aws.deb.debian.org/debian unstable/main amd64 clang-3.9 > amd64 1:3.9.1-11 [37.3 MB] > Get:18 https://cdn-aws.deb.debian.org/debian unstable/main amd64 > libclang-common-3.9-dev amd64 1:3.9.1-11 [2,587 kB] > Get:19 https://cdn-aws.deb.debian.org/debian unstable/main amd64 libllvm3.9 > amd64 1:3.9.1-11 [11.4 MB] > Get:20 https://cdn-aws.deb.debian.org/debian unstable/main amd64 > libclang1-3.9 amd64 1:3.9.1-11 [5,896 kB] > These files haven't been built on a build daemon, but instead have been uploaded by the maintainer [1]. This is therefore not a buildd issue, the issue has been fixed there already with the upgrade to stretch. Aurelien [1] https://tracker.debian.org/news/866006 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups
On 2017-08-28 12:42, Aurelien Jarno wrote: > On 2017-08-28 12:33, Aurelien Jarno wrote: > > On 2017-08-28 18:06, Adam Warner wrote: > > > On Sat, 2017-05-13 at 22:48 +0200, Aurelien Jarno wrote: > > > > On 2017-05-13 21:34, Aurelien Jarno wrote: > > > > > On 2017-05-13 17:52, Mattia Rizzolo wrote: > > > > > > On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote: > > > > > > > a) Has anything changed in the meantime? > > > > > > > > > > > > Yes: sbuild stopped repeating the changelog time taking it from > > > > > > the last > > > > > > entry, and will instead generate a new timestamp based on the > > > > > > current > > > > > > time: > > > > > > > > > > > > * For binNMUs, instead of copying the timestamp of the last > > > > > > changelog entry, > > > > > > generate a new one (closes: #843773) > > > > > > > > > > > > In version 0.73.0-1. > > > > > > > > > > And I am glad that after all that months with people talking about > > > > > the > > > > > issue, I finally got a detailed description of the issue and a > > > > > pointer > > > > > to the commit to backport. I'll work on that. > > > > > > > > The above change should now be deployed on most jessie based buildds, > > > > it's only missing on the buildds that are currently down. > > > > > > Original thread author here reporting to beware that some rsync data > > > corruption can still become apparent after all this time. > > > > > > It's been a while since I did a full rsync checksum test. Decided to do > > > one after a recent upgrade that includes clang 3.9 related files. These > > > are Debian systems that default to unstable BUT include all debian apt > > > sources including experimental/unstable/testing/stable/oldstable. > > > > > > I found these four corrupted files in my rsync backups: > > > > > > var/lib/dpkg/info/clang-3.9.md5sums > > > var/lib/dpkg/info/libclang-common-3.9-dev.md5sums > > > var/lib/dpkg/info/libclang1-3.9:amd64.md5sums > > > var/lib/dpkg/info/libllvm3.9:amd64.md5sums > > > > > > The latest packages were installed from this repository: > > > > > > Get:17 https://cdn-aws.deb.debian.org/debian unstable/main amd64 > > > clang-3.9 amd64 1:3.9.1-11 [37.3 MB] > > > Get:18 https://cdn-aws.deb.debian.org/debian unstable/main amd64 > > > libclang-common-3.9-dev amd64 1:3.9.1-11 [2,587 kB] > > > Get:19 https://cdn-aws.deb.debian.org/debian unstable/main amd64 > > > libllvm3.9 amd64 1:3.9.1-11 [11.4 MB] > > > Get:20 https://cdn-aws.deb.debian.org/debian unstable/main amd64 > > > libclang1-3.9 amd64 1:3.9.1-11 [5,896 kB] > > > > > > > These files haven't been built on a build daemon, but instead have > > been uploaded by the maintainer [1]. This is therefore not a buildd > > issue, the issue has been fixed there already with the upgrade to > > stretch. > > More precisely the two latest changelog entries have the same date: > I have just filled a bug against ftp.debian.org for such packages to be rejected. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873489 Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Bug#873489: ftp.debian.org: please autoreject packages with tag latest-debian-changelog-entry-without-new-date
Package: ftp.debian.org Severity: normal Dear ftp-masters, dpkg-dev is using the latest Debian changelog entry to set the SOURCE_DATE_EPOCH environment variable and to clamp the mtime of files in the generated .deb packages. Therefore having the latest Debian changelog entry with either the same or even an older date as the entry before causes subtle bugs. Most notably it breaks backup systems as the content of the files change, but not the associated mtime. Fortunately the latest-debian-changelog-entry-without-new-date lintian tag is able to detect that. Please autoreject packages with such a lintian tag. Thanks, Aurelien ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups
On 2017-08-28 12:33, Aurelien Jarno wrote: > On 2017-08-28 18:06, Adam Warner wrote: > > On Sat, 2017-05-13 at 22:48 +0200, Aurelien Jarno wrote: > > > On 2017-05-13 21:34, Aurelien Jarno wrote: > > > > On 2017-05-13 17:52, Mattia Rizzolo wrote: > > > > > On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote: > > > > > > a) Has anything changed in the meantime? > > > > > > > > > > Yes: sbuild stopped repeating the changelog time taking it from > > > > > the last > > > > > entry, and will instead generate a new timestamp based on the > > > > > current > > > > > time: > > > > > > > > > > * For binNMUs, instead of copying the timestamp of the last > > > > > changelog entry, > > > > > generate a new one (closes: #843773) > > > > > > > > > > In version 0.73.0-1. > > > > > > > > And I am glad that after all that months with people talking about > > > > the > > > > issue, I finally got a detailed description of the issue and a > > > > pointer > > > > to the commit to backport. I'll work on that. > > > > > > The above change should now be deployed on most jessie based buildds, > > > it's only missing on the buildds that are currently down. > > > > Original thread author here reporting to beware that some rsync data > > corruption can still become apparent after all this time. > > > > It's been a while since I did a full rsync checksum test. Decided to do > > one after a recent upgrade that includes clang 3.9 related files. These > > are Debian systems that default to unstable BUT include all debian apt > > sources including experimental/unstable/testing/stable/oldstable. > > > > I found these four corrupted files in my rsync backups: > > > > var/lib/dpkg/info/clang-3.9.md5sums > > var/lib/dpkg/info/libclang-common-3.9-dev.md5sums > > var/lib/dpkg/info/libclang1-3.9:amd64.md5sums > > var/lib/dpkg/info/libllvm3.9:amd64.md5sums > > > > The latest packages were installed from this repository: > > > > Get:17 https://cdn-aws.deb.debian.org/debian unstable/main amd64 clang-3.9 > > amd64 1:3.9.1-11 [37.3 MB] > > Get:18 https://cdn-aws.deb.debian.org/debian unstable/main amd64 > > libclang-common-3.9-dev amd64 1:3.9.1-11 [2,587 kB] > > Get:19 https://cdn-aws.deb.debian.org/debian unstable/main amd64 libllvm3.9 > > amd64 1:3.9.1-11 [11.4 MB] > > Get:20 https://cdn-aws.deb.debian.org/debian unstable/main amd64 > > libclang1-3.9 amd64 1:3.9.1-11 [5,896 kB] > > > > These files haven't been built on a build daemon, but instead have > been uploaded by the maintainer [1]. This is therefore not a buildd > issue, the issue has been fixed there already with the upgrade to > stretch. More precisely the two latest changelog entries have the same date: | llvm-toolchain-3.9 (1:3.9.1-11) unstable; urgency=medium | | [ Sylvestre Ledru ] | * Remove the --no-discard-stderr option from help2man calls | * Also add a missing include in ftfbs-gcc.diff to fix a ftbfs | with gcc 7 | * clang was producing unusable binaries on armv5tel (Closes #873304) | Thanks to Adrian Bunk for the patch | * Disable -gsplit-dwarf when using gcc 7 for causing a linking issue | See https://bugs.llvm.org/show_bug.cgi?id=34140 (Closes: #853524) | | [ Gianfranco Costamagna, John Paul Adrian Glaubitz ] | * Add powerpcspe to latomic archs | | [ Katsuhiko Nishimra ] | * Ensure /usr/bin/g++-$(GCC_VERSION) exists (Closes: #871591) | | -- Sylvestre Ledru Sun, 18 Jun 2017 19:12:15 +0200 | | llvm-toolchain-3.9 (1:3.9.1-10) unstable; urgency=medium | | * Now that strech has been released, upload in unstable! | This is necessary for rust in unstable | * Try to fix some PATH_MAX on hurd | * Enable the verbose mode when trying to build libfuzzer | to detect potential issues in the path search | | -- Sylvestre Ledru Sun, 18 Jun 2017 19:12:15 +0200 That's the reason why the files ended-up with the same date but different content. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups
On 2017-05-13 21:34, Aurelien Jarno wrote: > On 2017-05-13 17:52, Mattia Rizzolo wrote: > > On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote: > > > a) Has anything changed in the meantime? > > > > Yes: sbuild stopped repeating the changelog time taking it from the last > > entry, and will instead generate a new timestamp based on the current > > time: > > > > * For binNMUs, instead of copying the timestamp of the last changelog > > entry, > > generate a new one (closes: #843773) > > > > In version 0.73.0-1. > > And I am glad that after all that months with people talking about the > issue, I finally got a detailed description of the issue and a pointer > to the commit to backport. I'll work on that. The above change should now be deployed on most jessie based buildds, it's only missing on the buildds that are currently down. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups
On 2017-05-13 17:52, Mattia Rizzolo wrote: > On Sat, May 13, 2017 at 03:44:57PM +0100, Chris Lamb wrote: > > a) Has anything changed in the meantime? > > Yes: sbuild stopped repeating the changelog time taking it from the last > entry, and will instead generate a new timestamp based on the current > time: > > * For binNMUs, instead of copying the timestamp of the last changelog entry, > generate a new one (closes: #843773) > > In version 0.73.0-1. And I am glad that after all that months with people talking about the issue, I finally got a detailed description of the issue and a pointer to the commit to backport. I'll work on that. > > b) Will this affect stretch? If so, what do we need to do now? It depends by wat you mean by "affect stretch". According to the version above, the buildds running stretch are not affected by the bug. So it mostly depends where the packages are built, not for which distribution. Cheers, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[no subject]
Bcc: Subject: Re: [buildd-tools-devel] Some Debian package upgrades are corrupting rsync "quick check" backups Reply-To: In-Reply-To: <148578965254.16460.821466934538220169@localhost> On 2017-01-30 16:20, Johannes Schauer wrote: > Hi, > > Quoting Holger Levsen (2017-01-30 14:58:33) > > On Mon, Jan 30, 2017 at 02:47:45PM +0100, Johannes Schauer wrote: > > > > b.) if thats the case, shall we scan all packages in sid for files which > > > > have the same timestamp+filename but different checksums and ask for > > > > binNMUs of those packages? > > > The version of sbuild used on the buildds probably doesn't bump the > > > timestamp > > > yet. At least the binNMU-ed packages on my system share the binNMU > > > changelog > > > timestamp with the timestamp of the last source upload. :) > > > > so it seems we should > > > > a.) get this fix deployed on all the buildds. (how?) > > b.) do the b.) above… (because AIUI this issue atm is only be noticed > > by those running unstable or stretch, while once stretch is released > > many > > more people will notice it…) > > I'm not involved in buildd development. I think Aurélien Jarno (CC) is > involved > as there are many commits from him in the respective sbuild git branch. > Possibly the right mailing is debian-dak@l.d.o but I'm not active there. The right contact point is wb-t...@buildd.debian.org or alternatively the mailing list wb-t...@lists.debian.org. > The buildds are running a custom version of sbuild with their own patches on > top. So I'd expect that once Stretch is released, they will rebase their > patches on top of sbuild from Stretch. We have merged all of our patches except one that disable the init script at the time of the Jessie release. The patches that have been added later in this branch are just cherry-picks from the master branch. Once Stretch is released, we'll indeed do the same process. > So as far as I understand Henrik's original message, their problem should be > fixed once packages start being built with sbuild from Stretch which happens > after the Stretch release. I don't know what is the issue you are talking about. If there is a patch available (preferably committed first to the master branch), we might be able to cherry-pick it. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#829738: tar: --no-recursion option is ignored when creating archives
On 2016-12-10 15:22, Anders Kaseorg wrote: > This seems to have been an intentional upstream change. --no-recursion > now applies only to the following options, until cancelled by a following > --recursion. > > http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20151012/003642.html > http://git.savannah.gnu.org/cgit/tar.git/commit/?id=2bd9c15391b0bd6ef0bff76aebf09cfb53003199 > > The upstream documentation is fixed in Git (post-1.29) to put > --no-recursion before -T -. > > http://git.savannah.gnu.org/cgit/tar.git/commit/?id=a2fd82f62285d647dac968108eee02457255eff7 Thanks for the info. I confirm that it works. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: misleading timestamps in binnmus
On 2016-11-10 11:33, Ian Jackson wrote:
> Cyril Brulebois writes ("Re: misleading timestamps in binnmus"):
> > Ian Jackson (2016-11-09):
> > > What version of sbuild do buildds run ? Ie, supposing that this is
> > > fixed in sbuild in stretch, will this be fixed on the buildds ? Or do
> > > we need to update jessie, or what ?
> >
> > sbuild on buildds uses a specific version of sbuild, for reasons I'm not
> > going to summarize. The base version is close to what's in jessie (see the
> > first lines of any build log which has “sbuild (Debian sbuild) 0.65.2”).
> ...
> > Repository seems to live under:
> > https://apt.buildd.debian.org/
>
> Thanks. When Johannes has decided exactly what the sbuild patch looks
> like in sid, I will take a look at the repo there and backport the
> change. In what form should I supply mhy update ? As an source+all
When it's done, just ping us with the commit number, we will backport it
in our branch and we will deploy it on the build daemons.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#829738: tar: --no-recursion option is ignored when creating archives
Package: tar Version: 1.29-1 Severity: important Recent versions of tar ignore the --no-recursion option when creating an archive. Here is a small example, where the file 'b' appears twice in the created tar: $ mkdir a $ touch a/b $ find a -print0 | tar -c --null -T - --no-recursion -f test.tar $ tar tvf test.tar drwxr-xr-x aurel32/aurel32 0 2016-07-05 16:15 a/ -rw-r--r-- aurel32/aurel32 0 2016-07-05 16:15 a/b -rw-r--r-- aurel32/aurel32 0 2016-07-05 16:15 a/b $ It seems to have been introduced by the following change in version 1.28-2: * patch from upstream to fix --files-from and recursive extract, closes: #800380 As this is the recommended way to create a tarball by the reproducible build team, this causes a lot of space waste in the debian archive and on the users disks. Note that this way of creating archive is also described in the tar documentation: http://www.gnu.org/software/tar/manual/html_node/recurse.html -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tar depends on: ii libacl1 2.2.52-3 ii libc62.23-1 ii libselinux1 2.5-3 tar recommends no packages. Versions of packages tar suggests: ii bzip21.0.6-8 pn ncompress pn tar-scripts ii xz-utils 5.1.1alpha+20120614-2.1 -- no debconf information ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Bug#806911: Bug#806911: Bug#806911: Second build on failures
On 2015-12-24 08:55, Holger Levsen wrote: > Hi, > > On Mittwoch, 23. Dezember 2015, Aurelien Jarno wrote: > > > I have to admit, I cannot follow: > > > - if this is fixed, why is 806911 still open? > > The "bug" is still there, just not triggerable anymore on amd64 and > > i386. > > ok > > > I use "bug" as when faking the kernel version to change the result > > of versions comparisons, one should expect the result of such > > comparisons to be wrong. > > Again, can't follow. Surely tests testing for kernel >= 3.0 will fail or is > that what you ment? Yes, it's exactly that. The glibc was configured with a minimum kernel set to 3.2. This allows to use the new features provided by the kernel without any compatibility code to emulate them. For that the libc first looks at runtime that the kernel is indeed at least 3.2. This is where it fails when using the uname26 personality, as with the default comparison method, 2.6.40 < 3.2. > > > - also, the hosts runs jessie and this is where we run linux64 on and > > > from, so how are changes in sid+testing relevant in our setup anyway? > > > (actually we run jessie, sometimes with jessie kernels and and on some > > > other hosts with bpo kernels or even never…) > > > > The host might runs jessie, but from the bug report I understood the > > bug happened in a testing or sid chroot. > > yes (with pbuilder chroots) > > > > - why did you 2.6._32_ mention at all, and not "2.6" (or maybe 2.6.56)? > > > > We lowered the minimum required kernel version to 2.6.32 instead of 3.2 > > on amd64 and i386. When comparing kernel versions with the uname26 > > personality, we have the following relations when the minimum kernel > > version is 2.6.32: > > - 3.x kernels aka 2.6.40+x > 2.6.32, this works > > - 4.x kernels aka 2.6.60+x > 2.6.32, this works > > > > However when the minimum kernel version is 3.2: > > - 3.x kernels aka 2.6.40+x < 3.2, this do not work > > - 4.x kernels aka 2.6.60+x < 3.2, this do not work > > I cant follow. Probably this is because I fully expect this to happen… but > somewhere in between I must be lost… or are you talking about build > requirements for libc itself? The check for at least a 3.2 kernel is something done at runtime in ld.so, hence the "FATAL: kernel too old" message you reported. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Bug#806911: Bug#806911: Second build on failures
On 2015-12-23 11:59, Holger Levsen wrote: > Hi Aurelien, > > On Dienstag, 22. Dezember 2015, Aurelien Jarno wrote: > > > nice! but this is not available yet in sid+testing yet, or is it? (or > > > maybe rather: what does "2.6.32 support" mean here???) > > I meant 2.6.32 kernel support, and it's already in testing and sid. > > I have to admit, I cannot follow: > > - if this is fixed, why is 806911 still open? The "bug" is still there, just not triggerable anymore on amd64 and i386. I use "bug" as when faking the kernel version to change the result of versions comparisons, one should expect the result of such comparisons to be wrong. > - also, the hosts runs jessie and this is where we run linux64 on and from, > so > how are changes in sid+testing relevant in our setup anyway? (actually we run > jessie, sometimes with jessie kernels and and on some other hosts with bpo > kernels or even never…) The host might runs jessie, but from the bug report I understood the bug happened in a testing or sid chroot. > - why did you 2.6._32_ mention at all, and not "2.6" (or maybe 2.6.56)? We lowered the minimum required kernel version to 2.6.32 instead of 3.2 on amd64 and i386. When comparing kernel versions with the uname26 personality, we have the following relations when the minimum kernel version is 2.6.32: - 3.x kernels aka 2.6.40+x > 2.6.32, this works - 4.x kernels aka 2.6.60+x > 2.6.32, this works However when the minimum kernel version is 3.2: - 3.x kernels aka 2.6.40+x < 3.2, this do not work - 4.x kernels aka 2.6.60+x < 3.2, this do not work > - and, finally, in conclusion, is it safe to enable building with "linux64 -- > uname2.6" again? On amd64 and i386 it should be safe. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Bug#806911: Second build on failures
On 2015-12-21 22:24, Holger Levsen wrote: > Hi Aurelien, > > On Montag, 21. Dezember 2015, Aurelien Jarno wrote: > > Also note that we have re-enabled 2.6.32 support on amd64 and i386, so > > you should not need any patch to get these architectures working. > > nice! but this is not available yet in sid+testing yet, or is it? (or maybe > rather: what does "2.6.32 support" mean here???) I meant 2.6.32 kernel support, and it's already in testing and sid. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Bug#806911: Second build on failures
On 2015-12-21 19:02, Holger Levsen wrote: > Hi, > > cc:ing the bug and thus leaving some more context… > > On Montag, 21. Dezember 2015, Vagrant Cascadian wrote: > > On 2015-12-21, Holger Levsen wrote: > > >> For now, relying on the fact that there are different actual kernels on > > >> various builds (4.x vs. 3.x) will hopefully be good enough to detect the > > >> issue that using "linux64 --uname-2.6" was trying to solve. > > > > > > yeah. what I don't like about this is that it forces us to do that. I > > > liked the flexibility using --uname-2.6 gave us… > > > > The impression I got was the patch implementation was rejected upstream, > > but in theory a better patch could be written. Aurelian wasn't planning > > on working on it. > > I've got the same impression. I still have it on my todo list, but with very low priority. So if someone wants to provide a patch, that would be welcome. Also note that we have re-enabled 2.6.32 support on amd64 and i386, so you should not need any patch to get these architectures working. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
