Re: [Reproducible-builds] libibatis-java changed in testing: reproducible -> FTBFS
On Wed, Sep 30, 2015 at 11:26:39AM -0300, Miguel Landaeta wrote: > BTW, can another builds be retried? yes, every team member has a mean to schedule packages for building. > I was interested on retriggering jruby build since is tagged as FTBFS > since some days ago and I know for sure is not FTBFS. When I inspect > the log for the failed build I found out[1] an incomplete log file, so > I suspect it was also a disk space related problem as well. personally I don't think it's caused by ENOSCP, but I scheduled it anyway. The last build lasted 43213 seconds, and we timeout builds at 12 hours (with SIGTERM) and 12h6m with SIGKILL. so it reached the timeout and all those errors are from some java thinghy erroring out due to SIGTERM, imho. from a look at the past builds this seems to be started with the 1.7.22 upload: id nameversion suite architecture status build_datebuild_duration builder - -- -- -- --- -- - 24387 jruby 1.5.6-9 testing amd64 unreproducible 2015-03-26 15:22 1991 50111 jruby 1.5.6-9 testing amd64 unreproducible 2015-04-17 12:26 992 68362 jruby 1.5.6-10unstableamd64 unreproducible 2015-05-05 09:20 1096 73002 jruby 1.5.6-10testing amd64 unreproducible 2015-05-08 14:20 1361 11257 jruby 1.5.6-10unstableamd64 unreproducible 2015-06-03 03:31 1263 13163 jruby 1.7.19-1experiment amd64 FTBFS 2015-06-16 02:40 3 13473 jruby 1.7.19-1experiment amd64 unreproducible 2015-06-17 07:51 2791 13552 jruby 1.5.6-10testing amd64 unreproducible 2015-06-17 20:14 1125 13866 jruby 1.7.20.1-1 experiment amd64 FTBFS 2015-06-20 06:57 1428 14090 jruby 1.7.20.1-2 unstableamd64 unreproducible 2015-06-21 16:01 2630 14612 jruby 1.7.20.1-2 testing amd64 FTBFS 2015-06-28 11:36 18 16076 jruby 1.7.21-1unstableamd64 FTBFS 2015-07-11 02:49 157 beta/55072 16720 jruby 1.7.21-1testing amd64 FTBFS 2015-07-16 05:00 39 gamma/55754 18549 jruby 1.7.21-2unstableamd64 unreproducible 2015-07-29 22:09 7979zeta/23067 18852 jruby 1.7.21-2testing amd64 FTBFS 2015-08-01 12:01 60 zeta/23429 21071 jruby 1.7.21-2testing amd64 depwait 2015-08-13 22:28 19 alpha/60854 22091 jruby 1.7.21-2testing amd64 depwait 2015-08-21 23:58 32 gamma/62859 24007 jruby 1.7.21-2testing amd64 depwait 2015-09-03 15:50 34 gamma/65105 24398 jruby 1.7.21-2unstablearmhf FTBFS 2015-09-05 15:04 19278 armhf_3/325 24548 jruby 1.7.21-2unstablearmhf FTBFS 2015-09-06 18:41 16542 armhf_1/459 25272 jruby 1.7.21-2testing amd64 depwait 2015-09-10 19:49 45 amd64_3/753 26175 jruby 1.7.21-2unstableamd64 unreproducible 2015-09-16 10:09 2602amd64_8/1634 26537 jruby 1.7.21-2unstableamd64 FTBFS 2015-09-17 22:35 2768amd64_4/3308 26629 jruby 1.7.22-1unstableamd64 FTBFS 2015-09-18 00:34 43213 amd64_6/3043 26771 jruby 1.7.22-1unstablearmhf FTBFS 2015-09-18 22:49 25378 armhf_2/587 27150 jruby 1.7.21-2testing amd64 FTBFS 2015-09-20 01:32 44709 amd64_3/2590 28098 jruby 1.7.22-1testing amd64 depwait 2015-09-24 23:24 234 amd64_13/1021 28121 jruby 1.7.22-1testing amd64 FTBFS 2015-09-25 00:09 12191 amd64_9/2831 Everything I said can be true for unstable, but not for testing, since the failure there happens only in the second build with tests errors: 3354 files, 19543 examples, 52878 expectations, 5 failures, 4 errors -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri
Re: [Reproducible-builds] libibatis-java changed in testing: reproducible -> FTBFS
On Wed, Sep 30, 2015 at 11:26:39AM -0300, Miguel Landaeta wrote: > BTW, can another builds be retried? yes, every team member has a mean to schedule packages for building. > I was interested on retriggering jruby build since is tagged as FTBFS > since some days ago and I know for sure is not FTBFS. When I inspect > the log for the failed build I found out[1] an incomplete log file, so > I suspect it was also a disk space related problem as well. personally I don't think it's caused by ENOSCP, but I scheduled it anyway. The last build lasted 43213 seconds, and we timeout builds at 12 hours (with SIGTERM) and 12h6m with SIGKILL. so it reached the timeout and all those errors are from some java thinghy erroring out due to SIGTERM, imho. From a look at the past builds this seems to be started with the 1.7.22 upload: id nameversion suite architecture status build_datebuild_duration builder - -- -- -- --- -- - 24387 jruby 1.5.6-9 testing amd64 unreproducible 2015-03-26 15:22 1991 50111 jruby 1.5.6-9 testing amd64 unreproducible 2015-04-17 12:26 992 68362 jruby 1.5.6-10unstableamd64 unreproducible 2015-05-05 09:20 1096 73002 jruby 1.5.6-10testing amd64 unreproducible 2015-05-08 14:20 1361 11257 jruby 1.5.6-10unstableamd64 unreproducible 2015-06-03 03:31 1263 13163 jruby 1.7.19-1experiment amd64 FTBFS 2015-06-16 02:40 3 13473 jruby 1.7.19-1experiment amd64 unreproducible 2015-06-17 07:51 2791 13552 jruby 1.5.6-10testing amd64 unreproducible 2015-06-17 20:14 1125 13866 jruby 1.7.20.1-1 experiment amd64 FTBFS 2015-06-20 06:57 1428 14090 jruby 1.7.20.1-2 unstableamd64 unreproducible 2015-06-21 16:01 2630 14612 jruby 1.7.20.1-2 testing amd64 FTBFS 2015-06-28 11:36 18 16076 jruby 1.7.21-1unstableamd64 FTBFS 2015-07-11 02:49 157 beta/55072 16720 jruby 1.7.21-1testing amd64 FTBFS 2015-07-16 05:00 39 gamma/55754 18549 jruby 1.7.21-2unstableamd64 unreproducible 2015-07-29 22:09 7979zeta/23067 18852 jruby 1.7.21-2testing amd64 FTBFS 2015-08-01 12:01 60 zeta/23429 21071 jruby 1.7.21-2testing amd64 depwait 2015-08-13 22:28 19 alpha/60854 22091 jruby 1.7.21-2testing amd64 depwait 2015-08-21 23:58 32 gamma/62859 24007 jruby 1.7.21-2testing amd64 depwait 2015-09-03 15:50 34 gamma/65105 24398 jruby 1.7.21-2unstablearmhf FTBFS 2015-09-05 15:04 19278 armhf_3/325 24548 jruby 1.7.21-2unstablearmhf FTBFS 2015-09-06 18:41 16542 armhf_1/459 25272 jruby 1.7.21-2testing amd64 depwait 2015-09-10 19:49 45 amd64_3/753 26175 jruby 1.7.21-2unstableamd64 unreproducible 2015-09-16 10:09 2602amd64_8/1634 26537 jruby 1.7.21-2unstableamd64 FTBFS 2015-09-17 22:35 2768amd64_4/3308 26629 jruby 1.7.22-1unstableamd64 FTBFS 2015-09-18 00:34 43213 amd64_6/3043 26771 jruby 1.7.22-1unstablearmhf FTBFS 2015-09-18 22:49 25378 armhf_2/587 27150 jruby 1.7.21-2testing amd64 FTBFS 2015-09-20 01:32 44709 amd64_3/2590 28098 jruby 1.7.22-1testing amd64 depwait 2015-09-24 23:24 234 amd64_13/1021 28121 jruby 1.7.22-1testing amd64 FTBFS 2015-09-25 00:09 12191 amd64_9/2831 Everything I said can be true for unstable, but not for testing, since the failure there happens only in the second build with tests errors: 3354 files, 19543 examples, 52878 expectations, 5 failures, 4 errors -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri
Re: [Reproducible-builds] Building packages in the *past* (!!)
On Wed, Sep 30, 2015 at 10:57:20AM +0100, Chris Lamb wrote: > > There is a minimum of sanity that we should assume on the autobuilders, > > Agree in principle.. > > > namely, that packages are built on a date which is later than the one > > in the last changelog entry. > > .. but why should this matter? In fact, there's a fairly strong argument > to be made that if the package does something weird in this case then > there's something far deeper wrong or broken with it - and therefore it > would be advantageous to know about it simply from a QA point of view. No. There is nothing wrong or broken in base-files, and the current tests are making it *gratuitously* to fail. Please *follow* the link I posted before and see it for yourself. If the (simplified for this discussion) standard find debian/tmp -newermt '$(BUILD_DATE)' | xargs touch --date='$(BUILD_DATE)' is not going to work anymore, then there is literally *no* easy way to differentiate between files which have been created during the build process and files that come from upstream and we want their timestamp to be kept untouched. If we put constraints on maintainers and packages that are beyond what it is reasonable, nobody will take us seriously. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Usefulness of periodic reproducible builds e-mails
Hi, Am 30.09.2015 um 12:30 schrieb Holger Levsen: > Hi, > > (mostly ignoring the rest as this has been addressed already.) > > On Dienstag, 29. September 2015, Markus Koschany wrote: >> I understand that everything is still in development. However I don't >> think a public mailing list is a suitable testbed. My preferred solution >> would be to make receiving such e-mails opt-in. Everyone who wants to >> get informed by e-mail may subscribe to this feature. I personally >> prefer and regularly check DDPO because it is quite, very informative >> and can be used on demand. The only other option I can think of is to >> filter pkg-java mails. > > I think you still misunderstand: you, the java maintainers, already opted-in. > > What I then proposed was to change the notification system to allow > individual > email addresses to be subscribed to anything (and not just packages per se as > it is now) and to limit the notifications to unstable. > > But it still remains, that you (the team) opted in activly. > > If you as a team prefer, we can easily unsubscribe you now. We have never discussed this before as a team. I vote for unsubscribing pkg-java because of the issues that were pointed out already. Regards, Markus signature.asc Description: OpenPGP 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] Usefulness of periodic reproducible builds e-mails
Hi, On Dienstag, 29. September 2015, Santiago Vila wrote: > Are we really spamming people with this? > (spam = unsolicited bulk email) no, we dont. please read https://reproducible.debian.net/index_notify.html cheers, Holger signature.asc Description: This is a digitally signed message part. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Building packages in the *past* (!!)
> There is a minimum of sanity that we should assume on the autobuilders, Agree in principle.. > namely, that packages are built on a date which is later than the one > in the last changelog entry. .. but why should this matter? In fact, there's a fairly strong argument to be made that if the package does something weird in this case then there's something far deeper wrong or broken with it - and therefore it would be advantageous to know about it simply from a QA point of view. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Building packages in the *past* (!!)
Hi, Quoting Chris Lamb (2015-09-30 11:57:20) > > There is a minimum of sanity that we should assume on the autobuilders, > > Agree in principle.. > > > namely, that packages are built on a date which is later than the one > > in the last changelog entry. > > .. but why should this matter? In fact, there's a fairly strong argument to > be made I'd like to hear that "strong argument" because I fail to come up with one. > that if the package does something weird in this case then there's something > far deeper wrong or broken with it - and therefore it would be advantageous > to know about it simply from a QA point of view. I would not find it unreasonable if a build would fail if some of the software that is run either during compilation or testing stages detects that some of the files they are working on have a timestamp from the future. So the questions are: - do you want to file bugs against software that cannot work with timestamps from the future? - Why is it a bug if software cannot work with timestamps from the future? - What is the real world problem that is fixed by this? - Is there a use case where you would like to build your software with your clock set back to an older timestamp? - Having the complexities of timezones in mind I can totally imagine that there exists bugs that let your package not be built at a certain point in the past but I do not see how *all* software that cannot be built in the past will also have a general QA problem which has to be fixed in the future. Thus, if you build in the past you might also end up with build failures that are not meaningful. - Which QA scenario do you have in mind which would not also be checked when building in the future instead? Personally, I find it very likely that there exists software that cannot handle timestamps from the future because for that software it could easily hint that something in the runtime environment is obviously wrong and has to be fixed. cheers, josch signature.asc Description: 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] Building packages in the *past* (!!)
> I would not find it unreasonable if a build would fail if some of the > software that is run either during compilation or testing stages detects > that some of the files they are working on have a timestamp from the future. I didn't consider the mtime case carefully enough. I agree with you. (I would still stick by the general principle of "torture testing" aggressively though for the reasons I expoused, however.) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Building packages in the *past* (!!)
Hi. Are we building packages in the *past* now?: https://reproducible.debian.net/rb-pkg/unstable/amd64/base-files.html There is a minimum of sanity that we should assume on the autobuilders, namely, that packages are built on a date which is later than the one in the last changelog entry. So please *don't* build packages in the past. If we have to choose two very different dates (yes, of course we should do that to ensure reproducibility), try now and two years and two months later, for example (that would ensure that both the year and the month are different). Thanks. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Usefulness of periodic reproducible builds e-mails
Le 30/09/2015 13:00, Markus Koschany a écrit : > We have never discussed this before as a team. I vote for unsubscribing > pkg-java because of the issues that were pointed out already. I did request the notifications for the team, but I didn't really expect so many false positives. Sorry for the trouble. Markus (and the others), do you think it's ok to keep the notifications if they are limited to unstable ? Or would you prefer disabling them completely until the build environment stabilizes? Emmanuel Bourg ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] package uploaded to our repo
debhelper_9.20150811.0~reproducible5.dsc has just been uploaded to https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Usefulness of periodic reproducible builds e-mails
On Wed, Sep 30, 2015 at 02:27:18PM +0200, Emmanuel Bourg wrote: > > Markus (and the others), do you think it's ok to keep the notifications > if they are limited to unstable ? Or would you prefer disabling them > completely until the build environment stabilizes? I think there is value in receiving these notifications, they provide timely feedback about the status of our packages. Maybe we can setup a mailing list for this, something like pkg-java-bui...@lists.alioth.debian.org? (we already have pkg-java-commits, for example). I also don't mind filtering the reproducible reports in my email client if there is not other alternatives, of course. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche 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] libibatis-java changed in testing: reproducible -> FTBFS
On Tue, Sep 29, 2015 at 03:04:31PM +, Mattia Rizzolo wrote: > > I'm very sorry about those particular emails. > The last two days we had sever issues with the build host that cause a > really big bunch of FTBFS due to ENOSPC. > All the affected packages are already queued up for rebuilding, but it > takes time to rebuild all of them (FYI, currently there are more than > 750 build in the queue only for this, used to be ~1000 this morning). No worries, I understand. BTW, can another builds be retried? I was interested on retriggering jruby build since is tagged as FTBFS since some days ago and I know for sure is not FTBFS. When I inspect the log for the failed build I found out[1] an incomplete log file, so I suspect it was also a disk space related problem as well. Cheers, 1. https://reproducible.debian.net/rbuild/unstable/amd64/jruby_1.7.22-1.rbuild.log -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche 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] Usefulness of periodic reproducible builds e-mails
Am 30.09.2015 um 16:15 schrieb Mattia Rizzolo: [...] > This wouldn't work with the current implementation, which is emailing > $p...@packages.debian.org. Anyway, I received a suggestion of setting up > a new PTS keyword, so then people can go and subscribe there, maybe > using the team facility of the new tracker to subscribe to the whole lot > (i beliebe it works that way?). This is what I had in mind too. I would prefer such an implementation over the current state. Just let interested people (humans) subscribe to this feature with their private e-mail address. I still think that DDPO is sufficient but if the others feel we need the same information via e-mail then I would prefer only FTBFS reports in unstable. Markus signature.asc Description: OpenPGP 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] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
On 2015-09-28, Paul Kocialkowski wrote:
> Le jeudi 24 septembre 2015 à 09:05 -0700, Vagrant Cascadian a écrit :
>> I think the use of "time = mktime(time_universal);" is where the problem
>> lies:
>
> […]
>
>> According to the mktime manpage:
>>
>>The mktime() function converts a broken-down time structure,
>>expressed as local time, to calendar time representation.
>>
>> So my interpetation is that it's taking the UTC time and converts it
>> into local time using the configured timezone... not sure what would be
>> a viable alternative to mktime.
>
> That seems to make sense. Come to think of it, it probably was not
> necessary to call gmtime in the first place: if SOURCE_DATE_EPOCH is
> always in UTC, we should be able to stick that as-is in the time
> variable. At best, gmtime + mktime (assuming mktime working in UTC)
> would give us back the same timestamp.
>
> What do you think? Please let me know if I'm wrong.
This patch on top of 2015.10-rc4 seems to resolve the issue for me:
Index: u-boot/tools/default_image.c
===
--- u-boot.orig/tools/default_image.c
+++ u-boot/tools/default_image.c
@@ -108,8 +108,6 @@ static void image_set_header(void *ptr,
fprintf(stderr, "%s: SOURCE_DATE_EPOCH is not valid\n",
__func__);
time = 0;
- } else {
- time = mktime(time_universal);
}
} else {
time = sbuf->st_mtime;
It still checks for the validity of SOURCE_DATE_EPOCH using gmtime, but
doesn't call mktime at all, just re-uses the value set from
SOURCE_DATE_EPOCH.
live well,
vagrant
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
[Reproducible-builds] Your message to Pbuilder-maint awaits moderator approval
Your mail to 'Pbuilder-maint' with the subject pbuilder changed in unstable: FTBFS -> unreproducible Is being held until the list moderator can review it for approval. The reason it is being held: Message has implicit destination Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.alioth.debian.org/cgi-bin/mailman/confirm/pbuilder-maint/4e74d1db2c8ac4449a5df95619e28b37de2899ec ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
