Hi Daniel,
On Donnerstag, 25. September 2014, Daniel Kahn Gillmor wrote:
Out of curiosity, why do we not need to run tests when rebuilding?
to speed up things when building hundreds of packages, as
https://jenkins.debian.net/view/reproducible does :)
The
r-b process *is* changing the way
package: wnpp
User: reproducible-builds@lists.alioth.debian.org
Usertags: infrastructure
X-Debbugs-CC: reproducible-builds@lists.alioth.debian.org
Hi,
please package git.debian.org/git/reproducible/misc.git - I mostly care about
having the diffp tool installable via apt-get, so maybe move this
Hi Daniel,
for those who are not on #debian-reproducible... :)
On Donnerstag, 25. September 2014, Daniel Kahn Gillmor wrote:
Out of curiosity, why do we not need to run tests when rebuilding? The
r-b process *is* changing the way things are built and occasionally
tweaking files after they're
Package: debbindiff
Version: 3
Hi,
https://jenkins.debian.net/job/reproducible_build_random_packages/160/console
failed with
+ timeout 15m /var/lib/jenkins/debbindiff.git/debbindiff.py --html
./asm2_2.2.3-6.debbindiff.html b1/asm2_2.2.3-6_amd64.changes
b2/asm2_2.2.3-6_amd64.changes
package: debbindiff
severity: minor
Hi,
debbindiff includes the current working directory in the output, this should
not be the case. Currently, when for example being started with
PWD=/var/lib/jenkins/jobs/reproducible_build_random_packages/workspace@2/tmp.7ZRphuBcIk
the output starts with:
are available :-)
cheers,
Holger
From 967c39aec480a18281c14c3c36cb8a191e3c30de Mon Sep 17 00:00:00 2001
From: Holger Levsen hol...@layer-acht.org
Date: Sat, 11 Oct 2014 14:30:46 +0200
Subject: [PATCH] Make debhelper.mk run dh_strip_nondeterminism, dh_fixmtimes
and dh_genbuildinfo
control: retitle -1 debbindiff sometimes runs forever
Hi,
On Sonntag, 5. Oktober 2014, Holger Levsen wrote:
debbindiff (from git 107ddcd62) on php-horde-syncml_2.0.4-2_amd64.changes
runs for ages, so I had to kill it. This is pretty annoying for running it
on the whole archive :)
debbindiff
Hi,
I've set up git hooks yesterday, so that git commit notifications are now also
send to the #debian-reproducible IRC channel.
There is just one repo left which I couldnt configure, as the hook has 755
perms and not 775.
zarvox, could you please chmod
-- Forwarded Message --
Betreff: reproducible builds
Datum: Donnerstag, 5. Februar 2015
Von: Andreas Beckmann a...@debian.org
An: Holger Levsen hol...@layer-acht.org
Hi Holger,
nice to see reproducible builds moving forward :-)
Are there plans to check experimental, too?
Anyway, I had
Hi Niko,
On Donnerstag, 22. Januar 2015, Niko Tyni wrote:
- the build system also embeds information about the build host, at
least the kernel version and hostname. Those need to be stripped too.
[...]
I assume varying uname et al. isn't actively tested yet?
no, not yet. and varying
Hi,
On Dienstag, 10. Februar 2015, Mattia Rizzolo wrote:
* you could use --buildresult b1/b2 and avoid copying the buildresult
around manually
Holger, we are doing something similar in the jenkins script, but I don't
get why.
I guess because I wasn't aware of that option when I wrote the
package: debian-faq
x-debbugs-cc: pbuilder-ma...@lists.alioth.debian.org,
reproducible-builds@lists.alioth.debian.org
version: 5.0.3
Hi,
debian-faq is among the very few packages (*) which leave build artifacts in
/var/cache/pbuilder/result after bulding the package with pbuilder.
from
package: debian-policy
affects: simutrans-pak128.britain
x-debbugs-cc: ans...@debian.org, reproducible-builds@lists.alioth.debian.org
Hi,
I've just noticed and filed #780724: simutrans-pak128.britain ftbfs if PATH
does not contain /usr/games which made me notice that PATH is not specified
in
package: simutrans-pak128.britain
x-debbugs-cc: reproducible-builds@lists.alioth.debian.org
Hi Ansgar,
as discussed on IRC, simutrans-pak128.britain fails to build if PATH does not
contain /usr/games, as this is the case when building with pbuilder.
On Sonntag, 15. März 2015, Holger Levsen wrote:
what's the setting of BINDMOUNTS in your pbuilderrc? I've added /sys and
/proc to it today, which fixed some of the FTBFS we saw, but now s3ql's...
not
signature.asc
Description
Hi Nikolaus,
On Samstag, 14. März 2015, Nikolaus Rath wrote:
I can also reproduce this with s3ql_2.11.1+dfsg-2.dsc pbuilding for
jessie.
Alright, I'm at a loss:
[..]
The current package (2.13+dfsg) builds just as fine.
what's the setting of BINDMOUNTS in your pbuilderrc? I've added /sys
package: pbuilder,qa.debian.org
x-debbugs-cc: nikol...@rath.org, reproducible-builds@lists.alioth.debian.org
User: debian...@lists.debian.org
Usertags: jenkins
Hi,
on jenkins.debian.net we're using pbuilder from wheezy in a wheezy environment
and noticed it fails to build some packages, eg s3ql
Hi Thorsten,
On Montag, 16. März 2015, Thorsten Glaser wrote:
Holger Levsen dixit:
on jenkins.debian.net we're using pbuilder from wheezy in a wheezy
environment
Do you mean pbuilder from jessie?
no, I ment wheezy.
as tests involving network fail
That’s deliberate. There may
package: cloud-init
version: 0.7.6~bzr976-2
severity: serious
User: reproducible-builds@lists.alioth.debian.org
Usertags: environment
x-debbugs-cc: reproducible-builds@lists.alioth.debian.org
Hi,
building the cloud-init package fails during package tests because the
hostname
reassign 780863 debbindiff
# stupid typo, sorry for the noice
Crashing with exit 1 is the real problem here. Maybe this should be changed,
so that exit 1 means trouble/crash, while exit 2 means unreproducible?
On Freitag, 20. März 2015, Holger Levsen wrote:
package: debbindinff
version: 10
Hi Nikolaus,
On Dienstag, 3. März 2015, Nikolaus Rath wrote:
I managed to get the logs yesterday, but right now it seems down again:
it seems you've found an unlucky time in terms of stability of the service,
usually it's up all the times...
did you try to reproduce the problem with
/2015-holger-levsen/
or this: https://lists.debian.org/debian-devel-announce/2015/02/msg7.html
Anyway and definitely, this is bullshit:
The
biggest such gap is that compilation and packaging processes aren't
reproducible. Trying to recreate these processes typically yields a
different
Hi,
this was orginally posted at
http://layer-acht.org/thinking/blog/20150307-reproducible-video/
The video from Lunar's and my talk Stretching out for trustworthy
reproducible builds [0] (follow this link if you're interested in the
slides) given at the recent FOSDEM is finally available for
Hi,
On Montag, 30. März 2015, Paul Wise wrote:
These seem like FTBFS that should be reported, so the package
maintainers patch out usage of the macros, especially as the plan was
to enable warnings for them by default eventually.
yes, they should be reported. thats why they are listed on
package: tracker.debian.org
x-debbugs-cc: reproducible-builds@lists.alioth.debian.org
Hi,
while you thankfully added links to unreproducible packages on
reproducible.debian.net you've also added links to packages which fail to
build from source there, as can for example be seen on
Hi Axel,
On Dienstag, 31. März 2015, Axel Beckert wrote:
So where is the difference between
* setting all files in a binary package to the time stamp defined by
the package's changelog entry, and
* running a build under a timezone defined by the package's changelog
entry -- or under
control: retitle -1 strip-nondeterminism: remove ar handler?
Hi,
As far as I understand this would be premature and we should just close this
bug...
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
___
Hi Axel,
thanks for this bug and caring about reproducible builds!
On Montag, 2. März 2015, Axel Beckert wrote:
Chris (or someone else from the reproducible builds project): Can you
please update the notes on
https://reproducible.debian.net/rb-pkg/sid/amd64/zsh.html to mention
that this is
Hi,
On Dienstag, 17. Februar 2015, Johannes Schauer wrote:
What you are saying is, that you wish the srebuild wrapper to be merged
into the sbuild executable so that it does the right thing when a
buildinfo file is present?
yes, I think that would be desirable. I also would like to see other
Hi Andreas,
thanks for your bug report!
On Mittwoch, 25. Februar 2015, Andreas Beckmann wrote:
just saw this while checking reproducability of nvidia-cuda-toolkit 6.5:
that made me curious:
root@jenkins:/var/lib/jenkins/userContent# rgrep
/usr/bin/dh_strip_nondeterminism line rbuild/
package: tracker.debian.org
x-debbugs-cc: reproducible-builds@lists.alioth.debian.org
Hi,
https://tracker.debian.org/pkg/racket shows in the action needed box a text
saying Does not build reproducibly during testing linking to
https://reproducible.debian.net/rb-pkg/racket.html which is rather
package: debbindiff
version: 12
Hi,
https://reproducible.debian.net/rbuild/unstable/amd64/axiom_20140801-6.rbuild.log
shows debbindiff failing in a new way:
Sat Mar 28 05:46:22 UTC 2015 - debbindiff 12 will be used to compare the two
builds now.
GC Warning: Repeated allocation of very large
user reproducible-builds@lists.alioth.debian.org
usertag 778571 + toolchain
thanks
Hi,
I like /usr/src/debian/$packagename-$random where $random are 4 or 8
alphanumberic characters, as there might be situations where one wants to
build the same package (+version+suite) simultaneously on the
Hi Ximin,
On Sonntag, 19. April 2015, Ximin Luo wrote:
The .dsc at the above link should have unstable in the changelog, I just
withheld from pushing this last commit to the git repo in case you wanted
me to make changes. I have done so now, though.
thanks.
When asking for sponsoring, please
Hi Juan,
On Dienstag, 28. April 2015, Jérémy Bobbio wrote:
A few comments on your patch submission so you can get better at it. :)
in that sense... :)
Source: mopidy
Version: 1.0.2
This is a Debian bug report, so you need to use the full version of the
Debian package—including the
Hi,
On Donnerstag, 30. April 2015, Reiner Herrmann wrote:
The documentation generated by javadoc includes a build dependent
timestamp.
The attached patch tells javadoc to not include a timestamp in the
documentation.
while this works, javadoc should really be taught not to include those
Hi Reiner,
On Freitag, 1. Mai 2015, Reiner Herrmann wrote:
I totally agree. :-)
While looking at this issue I saw that javahelper passes -notimestamp to
javadoc by default now. I don't think there are that many packages calling
javadoc directly. But of course the best would be if javadoc
Hi,
to better coordinate our work I think we should do regular team meetings on
IRC. The schedule should probably be monthly or bi-weekly, feedback much
welcome!
But first, please participate in the poll at
https://dudle.inf.tu-dresden.de/r6vub5gm/
so that we can find a date+time for the
Hi Ximin,
On Freitag, 17. April 2015, Ximin Luo wrote:
https://mentors.debian.net/package/flashproxy
Please can someone sponsor this new release, 1.7-3?
debian/changelog has UNRELEASED in the distribution field, please set this
to unstable (dch -r) and reupload. (and push to git...)
cheers,
Hi Ximin,
sorry for the late reply, I hoped someone else would have replied ealier and
with more substance than mine.
On Montag, 30. März 2015, Ximin Luo wrote:
The idea:
1. We have dh (and/or other tools) set a standard environment variable,
SOURCEDATE, according to the package's
Hi Juan,
thanks for your contributions! Here are some hints how to proceed...
On Donnerstag, 9. April 2015, Debian Wiki wrote:
The ReproducibleBuilds/TimestampsInDocumentationGeneratedByAsciidoc page
has been changed by jumapico:
[...]
New page:
DebianPts:asciidoc writes timestamps in HTML
Hi Juan,
(are you subscribed or do you need cc:s?)
On Donnerstag, 9. April 2015, Juan Picca wrote:
As Holger and Mattia suggest i update the wiki page to reflect that
the solution is actually a workarround.
thanks for that!
I hope in short send a patch to asciidoc for add an --use-utc-time
Hi,
(mostly a general comment, not so much about this issue.)
On Donnerstag, 9. April 2015, Mattia Rizzolo wrote:
A bug _with patch_
(Usually) bugs with patches are welcome, bugs without might be considered
annoying.
while I agree in general, I don't think bugs without patches are annoying.
package: kgb-bot
version: 1.33-2
x-debbugs-cc: reproducible-builds@lists.alioth.debian.org
Hi,
while rebuilding kgb-bot for reproducibility we noticed the testsuite hanging
forever as can be seen in
https://jenkins.debian.net/view/reproducible/job/reproducible_builder_zeta/2745/console
or
Hi,
(sorry for letting this undealt with for some weeks..)
On Mittwoch, 29. April 2015, Holger Levsen wrote:
true, but I still think we shouldn't mark known false ftbfs as ftbfs...
but:
we know how to exclude these false results (see the ftbfs pages on rb.d.n)
so we should only flag those
package: tracker.debian.org
x-debbugs-cc: reproducible-builds@lists.alioth.debian.org
Hi,
(this is somewhat a followup of #781517.)
please don't show a package as unreproducible and requiring action if its
reproducible in sid. For example, https://tracker.debian.org/pkg/pxz was made
Hi Alexander,
On Freitag, 5. Juni 2015, Alexander Couzens wrote:
-bash utils/abuild/abuild
+bash util/abuild/abuild
thanks! much appreciated! (even though I caught that one myself already.. :)
(yet another build has been started too, now with debug around the lines were
it (#4) strangely
Hi,
On Freitag, 5. Juni 2015, Daniel Kahn Gillmor wrote:
My vote is for SOURCE_DATE_UTC, and i agree with Brendan that we should
take the opportunity to define this as strictly and narrowly as possible
(i.e. end in a 'Z', none of the other offsets), so that people relying
on it know they're
Hi,
On Dienstag, 26. Mai 2015, Andrew Ayer wrote:
That said, I'm now concerned about how strip-nondeterminism interacts
with the package-contains-timestamped-gzip tag. At some point after
package-contains-timestamped-gzip was first proposed, we reproducible
builds folks decided that instead
Hi,
On Montag, 25. Mai 2015, Jérémy Bobbio wrote:
My guts say that until we need a custom repository for core packages
(e.g. dpkg), it's not worth being included in devscripts.
I respectfully disagree - I think it's even useful now, with our custom
repository. Developers want to test their
Hi Niels,
On Sonntag, 7. Juni 2015, Niels Thykier wrote:
I see no partial issue in setting this in either dh xor dh_auto_build,
provided it is one ENV for all tools (and not one for each tool).
Is the variable still actual? I vaguely remember seeing a mention of a
SOURCEDATE_UTC or
clone 786601 -1
reassign -1 locales-all
retitle -1 locales-all must not provide: locales if it doesnt provide the
same features
clone 786601 -2
reassign -2 jblas
retitle -2 jblas: ftbfs when locales-all is installed but not locales
thanks
Hi,
Hi,
On Donnerstag, 4. Juni 2015, Ximin Luo wrote:
https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-2
0150330/001317.html
for details. TL;DR is to have SOURCEDATE as an environment variable in
ISO8601 format.
It would be awesome for help2man to support this. At
Hi Daniel,
On Donnerstag, 4. Juni 2015, Daniel Kahn Gillmor wrote:
This patch makes it easier to point people at the list of variations
and the list of usertagged bugs. It also uses css to make the
targeted sections have a different header color (i'm happy for more
style-y people to improve
user reproducible-builds@lists.alioth.debian.org
usertag 789761 + infrastructure
thanks
On Mittwoch, 24. Juni 2015, you wrote:
Package: how-can-i-help
Version: 1
Severity: wishlist
As the reproducable is gaining seriuos tracktion, perhaps it would be an
idea to allow how-can-i-help to
Hi,
On Montag, 15. Juni 2015, John Crispin wrote:
just for the record here are some of the links that are relevant...
http://anonscm.debian.org/cgit/reproducible/dpkg.git/commit/?h=pu/reproduci
ble_buildsid=3373ffd07e016ae1a81d12cb246fc6787f0bdbe1
Hi,
sorry for replying so late... on the plus side, I've got a much clearer
picture now and I've implemented something similar, eg see
https://reproducible.debian.net/openwrt/
and/or
https://reproducible.debian.net/coreboot/
On the original subject of my mail: I have given up on this and will
Dear OpenWrt developers,
to quote https://reproducible.debian.net/openwrt/ ;-)
Reproducible builds enable anyone to reproduce bit by bit identical binary
packages from a given source, so that anyone can verify that a given binary
derived from the source it was said to be derived. There is a
Dear OpenWRT developers,
to quote https://reproducible.debian.net/openwrt/ ;-)
Reproducible builds enable anyone to reproduce bit by bit identical binary
packages from a given source, so that anyone can verify that a given binary
derived from the source it was said to be derived. There is a
Hi Reiner,
On Mittwoch, 17. Juni 2015, Reiner Herrmann wrote:
This message is coming from unsquashfs btw. (used to extract squashfs
images), not from debbindiff itself.
I don't think debbindiff can do much there, and I also haven't found
an option for unsquashfs to prevent trying to extrect
Hi Erik,
On Mittwoch, 17. Juni 2015, Erik Cederstrand wrote:
The build should be immune to the time of the build, of course. That's
fairly easy (e.g. use 'ar -D' consistently and leave DEBUG_FLAGS empty).
yup, easy, but this can mean some work. (Which usually can be shared among the
upstream
package: debbindiff
version: 22
User: reproducible-builds@lists.alioth.debian.org
Usertags: infrastructure
Hi,
from
https://jenkins.debian.net/view/reproducible/job/reproducible_openwrt/24/console
Tue 16 Jun 23:30:09 UTC 2015 - debbindiff 22+test1 found issues, please
investigate
Hi Vincent,
On Dienstag, 16. Juni 2015, Vincent Fourmond wrote:
Looks like you have configuration problems on the build machine:
thanks for notifiying us. The issue has been fixed and affected packages are
about to be rescheduled.
If you're packages havent been rebuildin 24h please do
On Donnerstag, 4. Juni 2015, Daniel Kahn Gillmor wrote:
If folks want to cross-link internally too, that would be great, but i
was just scratching my particular itch here :)
fair enough!
:)
signature.asc
Description: This is a digitally signed message part.
severity -1 important
# if this bug also happens in normal timezones, it should be serious...
thanks
Hi Alexandre,
thanks for caring about reproducible builds and filing bugs against your own
packages! :-)
Without further investigating #790844 looks very similar to #786694 and
#789495, the
Hi Alexandre,
On Samstag, 4. Juli 2015, Alexandre Detiste wrote:
thanks for caring about reproducible builds and filing bugs against your
own packages! :-)
I got conviced (and a bit entertained) by the talk at FOSDEM ;-)
hehe, nice!
I think that Mattia's guess was closer:
Quite some
severity 791410 serious
severity 791405 serious
signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Hi Reiner,
On Samstag, 4. Juli 2015, Reiner Herrmann wrote:
So I created a new usertag locale that can track this issue.
cool! :)
@ Holger or Mattia: Can you please add this to the job that
creates the graph? Thanks!
done, should be visible tomorrow.
cheers,
Holger
package: strip-nondeterminism
version: 0.008-1
severity: serious
affects: golang
User: reproducible-builds@lists.alioth.debian.org
Usertags: toolchain
Hi,
from
https://reproducible.debian.net/rbuild/unstable/amd64/golang_1.4.2-3.rbuild.log
make[1]: Leaving directory '/tmp/buildd/golang-1.4.2'
Hi Maxy,
On Freitag, 19. Juni 2015, Maximiliano Curia wrote:
In DebConf15, the largest BoF room will have space for a maximum of 45
people (and will have video coverage) and there will be a number of other
smaller rooms with space for 15 to 20 people, without video coverage.
We have quite a
severity 791410 serious # m17n-db: FTBFS due to missing Build-Conflicts:
locales-all
severity 791405 serious # fis-gtm: FTBFS due to missing Build-Conflicts:
locales-all
affects 788352 m17n-db
affects 788352 fis-gtm
thanks
signature.asc
Description: This is a digitally signed message part.
Hi,
On Montag, 18. Mai 2015, Holger Levsen wrote:
to better coordinate our work I think we should do regular team meetings on
IRC. The schedule should probably be monthly or bi-weekly, feedback much
welcome!
But first, please participate in the poll at
https://dudle.inf.tu-dresden.de
source: ruby-celluloid
version: 0.16.0-1
Severity: serious
User: reproducible-builds@lists.alioth.debian.org
Usertags: randomness
x-debbugs-cc: reproducible-builds@lists.alioth.debian.org
Hi,
While working on the “reproducible builds” effort [1], we have noticed
that ruby-celluloid sometimes
source: obnam
version: 1.8-1
Severity: serious
x-debbugs-cc: reproducible-builds@lists.alioth.debian.org
Hi Lars,
While working on the “reproducible builds” effort [1], we have noticed that
obnam fails to build from source:
[...]
running build_scripts
creating build/scripts-2.7
copying and
Hi,
On Samstag, 23. Mai 2015, Holger Levsen wrote:
Source: sbcl
Version: 2:1.2.11-2
Severity: serious
User: reproducible-builds@lists.alioth.debian.org
Usertags: environment
Hi,
While working on the “reproducible builds” effort [1], we have noticed
that sbcl fails to build from source
Hi Andreas,
(adding debian-qa@l.d.o to cc: and keeping full quote for the benefit of those
reading this via that list...)
On Sonntag, 21. Juni 2015, Andreas Beckmann wrote:
(please keep me Cc:ed, I'm not subscribed)
Hi,
while your are doing rebuilds to check reproducibility, maybe you
notfound 787675 4.0+nmu1
found 787675 0.4+nmu1
thanks
signature.asc
Description: This is a digitally signed message part.
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Hi,
On Montag, 3. August 2015, Vagrant Cascadian wrote:
Oops. Accidentally dropped it on one of the debian.net updates. Re-added
just now, got the ack that it was added, now just need to wait for DNS
propagation...
thanks!
(as you may notice, they're all CNAMEs with a consistant pattern,
dpkg_1.18.2.0~reproducible1.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Hi Dhole,
On Samstag, 8. August 2015, Dhole wrote:
This week I have [...]
(I think) you forgot to mention your blog post at
https://dhole.github.io/post/reproducible_builds_debian_gsoc2015_update_1/
which I found really nice + very interesting to read, especially the two
paragraphs
Hi,
so yesterday I tried to build
http://reproducible.alioth.debian.org/debian/dpkg_1.18.1.0~reproducible5.dsc
with pbuilder on sid/armhf and that failed _exactly_ like
https://reproducible.debian.net/rbuild/unstable/amd64/dpkg_1.18.1.0~reproducible5.rbuild.log
I then tried to build
Hi Vagrant,
On Samstag, 1. August 2015, Vagrant Cascadian wrote:
Added new machine...
wbq0-armhf-rb.debian.net:
Wandboard Quad, quad-core, 2GB ram, ~50GB SATA SSD
[...]
Holger, I've added access for you with the same key, so tear it up!
cool, thanks, done :)
btw, on my first git clone
Hi,
https://reproducible.debian.net/index_repositories.html now shows missing
armhf binaries too, so we can see which binNMUs we need to do...
Next thing to do: fix dpkg as described in
http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20150727/002569.html
You might also
Hi,
so on https://jenkins.debian.net/view/reproducible/ you can now see 12 armhf
related jobs, so there is a setup_pbuilder_testing,
setup_schroot_testing_debbindiff and a maintenance job for each of the four
armhf build hosts. IOW: remote job scheduling now works \o/
What's missing now to
Hi Vagrant,
On Dienstag, 28. Juli 2015, Vagrant Cascadian wrote:
I am subscribed to the list as of a few weeks ago.
ok cool!
yes, we either need to make sure to manually build there in future too,
or setup some autobuilders...
Would it be feasible to use the same machines for that?
yes,
Hi Guillem,
On Mittwoch, 5. August 2015, Guillem Jover wrote:
Ah, the problem is that the releases are being made directly from
git with dpkg-buildpackage.
indeed, that's how I've built.
The correct way to release dpkg is to
«make dist» and then build Debian packages from that tarball.
Hi,
On Montag, 3. August 2015, Ben Hutchings wrote:
See https://lists.debian.org/debian-kernel/2013/08/msg00267.html.
Thanks.
That seems to say that a.) only the kernel team can sign kernels, so no user
signed kernels?? and b.) only amd64, while I believe uefi arm mainboards are
there
Hi,
On Montag, 3. August 2015, Ben Hutchings wrote:
That sort of works as long as there's only one architecture we want to
do this for. But the ability to verify modules is useful in general so
I would like to turn that on for all architectures.
how is this going to work for builds on
Hi Vagrant,
On Samstag, 1. August 2015, Vagrant Cascadian wrote:
wbq0-armhf-rb.debian.net:
$ host wbq0-armhf-rb.debian.net
Host wbq0-armhf-rb.debian.net not found: 3(NXDOMAIN)
The others resolve just fine.
cheers,
Holger
signature.asc
Description: This is a digitally signed message
Hi Clint,
On Freitag, 31. Juli 2015, Clint Adams wrote:
I suggest comparing builds with and without the Recommends of the
Build-Depends installed.
I think thats out of scope for our project currently: buildds don't install
recommends, so we also don't install them.
It's probably still
dpkg_1.18.1.0~reproducible6.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
Hi,
On Dienstag, 4. August 2015, Holger Levsen wrote:
dpkg_1.18.1.0~reproducible6.dsc has just been uploaded to
https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain
and I've also managed to build this on armhf and upload these binaries too.
Vagrant's hint of adding the .dist
package: debbindiff
version: 53
Hi,
filing a bug as suggested on irc.
https://jenkins.debian.net/view/reproducible/job/reproducible_openwrt/53/consoleFull
showed these lines at the end:
/srv/reproducible-results/tmp.EAwfyuKo8f/b2/ar71xx
/srv/reproducible-results/tmp.EAwfyuKo8f/b1/ar71xx
Hi,
upon seeing this:
[18:37] - KGB-2- | (#debian-reproducible) debbindiff calls on
https://reproducible.debian.net/unstable/amd64/icedove or
https://jenkins.debian.net/job/reproducible_builder_epsilon/21466/console left
cruft, please help investigate and fix 788568
[18:39] -
Hi Mattia,
On Freitag, 24. Juli 2015, Mattia Rizzolo wrote:
you won't find anything on /tmp because we set TMPDIR on the debbindiff
call to a the temporary directory we delete just after the build.
do we delete this TMPDIR also when we notify about the problem and ask for
debugging it? If so
Hi Dhole,
thanks for your continious reports and cheers and kudos for all the nice work!
Besides thinking yay this sparked one question:
On Samstag, 25. Juli 2015, Dhole wrote:
[...]
I have also uploaded the package in our APT repository.
[...]
For next week I plan to send the ghostscript
Hi Steven,
On Montag, 20. Juli 2015, Steven Chamberlain wrote:
`mktemp freebsd-` on FreeBSD would result in random characters
being appended, resulting in freebsd-.v1adN6Qo as above.
`mktemp -d -t freebsd-` should replace the X's with random
characters, same as GNU
Hi,
so I made some progress on this: a.) there is a build host running freebsd
10.1 (called freebsd-jenkins.debian.net) now, on which the jenkins user from
jenkins.debian.net can login via ssh as jenkins user b.) besides the base
system it has screen git vim sudo denyhosts installed and c.)
Hi,
On Samstag, 18. Juli 2015, Chris Lamb wrote:
Fixed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792491
shouldn't we upload dpkg with that fix to our repo then?
cheers,
Holger
signature.asc
Description: This is a digitally signed message part.
Hi Paul,
sorry for the late reply.
On Samstag, 13. Juni 2015, Paul Kocialkowski wrote:
you've seen https://reproducible.debian.net/u-boot ?
This seems very minimalistic, but it's good to see U-Boot was given some
attention already!
:-)
but maybe you can explain why u-boot needs more
1 - 100 of 528 matches
Mail list logo
