[Reproducible-builds] Ръчно изработени сувенири от метал през целия август -20%
Здравейте, Нашата компания е производител на изделия от дърво. Всеки от нашите артикули е продукт на творчеството и майсторските умения на нашите занаятчии. БЕЗПЛАТНА ДОСТАВКА за всяка поръчка над 50 лв. с опция за преглед преди плащане. Подарък ИЗНЕНАДА за поръчки над 100 лв. Разгледайте още от нашите предложения на www.oreshak.bg Храна от Балкана ПромоцииКутии шах и табла Комплекти шах и табла Аксесоари за шах и таблаПрофесионален шахмат Ножове от България Медни съдове Сувенири от метал Бъклици и бурета Стойки и кутии за вино Аксесоари за ловни трофей Кутии за аксесоари Ръчно изработени чинии от дърво Сувенири от дърво Кухненски аксесоари от дърво Керамика от Орешак Медни икони и пластики Икони с дърворезба и пластики Битова тъкан Сувенири от дърво на бяла заготовка Рамки за снимки Преоценени продукти OUTLET Ръчно произведени в село Орешак, общ. Троян - България www.oreshak.bg – онлайн магазин за шахове, табли, медни икони, дърворезби, кухненски аксесоари, изделия от мед и метал и още много сувенири и подаръци. Посетете ни и се уверете сами - www.oreshak.bg Съгласно закона за електронна търговия Чл. 6, ал. 1 Ви уведомяваме, че е възможно това да е непоискано търговско съобщение. То е еднократно изпратено писмо до Вашия e-mail адрес, който е взет от публичното пространство. Извиняваме се за причиненото неудобство, ако сме Ви притеснили с нашето предложение. Ако не желаете да получавате съобщения от "Oreshak", моля кликнете ТУК ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#793922: polymake: please make the build reproducible
Source: polymake
Version: 2.14-2
Severity: wishlist
Tags: patch
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 polymake could not be built reproducibly.
The attached patch removes randomness from the build system caused by
Perl hash order. Once applied, polymake can be built reproducibly in
our reproducible toolchain.
[1]: https://wiki.debian.org/ReproducibleBuilds
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diff --git a/perllib/Polymake/Configure.pm b/perllib/Polymake/Configure.pm
index 8f87e49..03e9824 100644
--- a/perllib/Polymake/Configure.pm
+++ b/perllib/Polymake/Configure.pm
@@ -268,7 +268,7 @@ sub write_conf_vars {
no strict 'refs';
my ($pkg, $conf)=@_;
- foreach my $var (@{"$pkg\::make_vars"}, @{"$pkg\::make_export_vars"}) {
+ foreach my $var (sort @{"$pkg\::make_vars"}, sort
@{"$pkg\::make_export_vars"}) {
if (defined (my $value=${"$pkg\::$var"})) {
if ($pkg ne __PACKAGE__ && $var =~ /(?:flags|libs)/i) {
print $conf "$var := $value \${$var}\n";
@@ -279,7 +279,7 @@ sub write_conf_vars {
}
if (my @export=grep { defined(${"$pkg\::$_"}) }
@{"$pkg\::make_export_vars"}) {
- print $conf "export ", join(" ", @export), "\n";
+ print $conf "export ", join(" ", sort @export), "\n";
}
}
###
@@ -288,13 +288,13 @@ sub write_config_command_line {
my ($conf, $options, $allowed_with, $vars, $ext_failed)=@_;
if (defined $vars) {
- while (my ($item, $value)=each %$vars) {
+ while (my ($item, $value)=sort each %$vars) {
$value="'$value'" if $value =~ /[\s(){}\[\]\$]/;
print $conf " $item=$value";
}
}
- while (my ($item, $value)=each %$options) {
+ while (my ($item, $value)=sort each %$options) {
if ($value eq ".none.") {
unless ($ext_failed && $ext_failed->{$item}) {
print $conf " --without-$item";
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] proposal: store information in one place instead of multiple ones
Hi, here are several questions I have which, for me boil down to information being duplicated and stored in different locations, leading to possible confusion for contributors and added work when adding new bugs and issues: 1. Why is the set of bts usertags different from the set of r-b issues? The bts usertags seem to be way more broad. For example there is the usertag "timestamps" which matches many issues. It is currently impossible get a machine readable mapping from bug number to the issue it fixes because the usertags are much too broad. A solution would be to ditch the current usertags and use the issue names instead. This would allow a one-to-one mapping between issue and bug number. What is the utility of the current usertags? Are they used for anything? Currently I'd rather say that it's confusing to have a package associated with two disjunct sets of tags: the usertags and the issues. Why is that useful? Another helpful thing would be if the bug subject line wasn't as generic (ie. if it was not just verbatim copied from the template) but that's another problem. 2. Why does packages.yml store the bug number(s) for each package? This information can easily retrieved from the bts and then will also not be outdated. packages.yml easily lags behind the actual bts information if not regularly updated by someone. 3. Why are the issues explained in issues.yml *and* in the wiki? There should be one canonical place to describe them because currently, any new issue that is identified requires to edit multiple resources and then link between the two. This not only requires more work when creating the issue but when looking up issues it is also unclear which resource is the authoritative one and which one will give the desired information. Instead, the information should be stored in one place only. So my proposal is: 1. Instead of using the current usertags "toolchain", "infrastructure", "timestamps" and so on, use issue names instead. Since each bugs can have multiple usertags, the old tags could even be kept and the issue names be added in addition. Since packages.yml exists, much of this conversion could probably be even automated (except for packages with more than one bug open for them). Sometimes, reproducibility problems only affect a single package and in that case it would create too much overhead to create a new issue for it. But in that case, why not just create a dummy issue just for the purpose to associate this kind of bugs to the reproducible builds team? 2. Do not add bug numbers to packages.yml. The bts already stores the information which source package has which bugs by the reproducible builds team. 3. Use the wiki only to describe issues and ditch issues.yml. The advantages are that the Debian wiki offers a much richer syntax and is also editable by everybody in Debian and not only the reproducible builds team. 4. After this is done, it is hard to say why the notes.git is useful in the first place. The content of issues.yml is described in the Debian wiki and the bug numbers are stored in the bts. One last task of packages.yml would probably be to store some tiny notes for packages for which there doesn't exist a bug. But I'd say to also move these notes into the bts. I think that filing a bug about a package's unreproducibility should be done even without having a fix for it. In fact many packages with such bugs exist simply for the reason that at the time the bug was filed, jenkins did less checks than it does now, so the patch which is currently in the bts does not make the package fully reproducibly anymore. Furthermore, storing these notes in the bts might make the package maintainer aware of the issue and gives them a chance to comment on these notes. I would say it gives maintainers more incentive to react on the issue themselves that way. On IRC the following problems were raised: - "you cannot grep packages.yml if it's in the bts because query-ing it takes ages" * true, but then just cache it. In fact, that's what you are already doing semi-manually in the notes.git by running the clean-notes script over it. So instead of having to wait until somebody runs clean-notes and then does `git add packages.yml && git commit && git push` from time to time, how about automating this process and then publishing a fully machine generated packages.yml which can then be grepped? - "there is more information in packages.yml than in the bts" * true, and i think that's a bug. By having this information in packages.yml and through that on reproducible.d.n, you are not informing the maintainer of the package about the little info you just found analyzing their package for reproducibility issues. Instead, I think you should file a bug and write the small information
Re: [Reproducible-builds] ARM build machines
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, totally. > > yes, we need to make some changes to our infrastructure as well: > > > > - add scheduling for armhf > > - have jenkins jobs to prepare pbuilder chroots for armhf on these > > machines - add support for building on remote machines > > - integrate the armhf build results into the web ui > > Regarding scheduling, I think we'll need a *lot* more nodes to get real > archive coverage, or maybe selectively schedule packages for builds that > are known or suspected to have architecture-specific divergence (e.g. > builds different packages on different architectures). /me nods, though I'm not too worried about this: a.) we should start with unstable only b.) some delay (in armhf) is acceptable as long as amd64 is build soon after uploads (and we can schedule interesting armhf packages manually too) c.) I'm sure we can add more nodes easily. I also have idling arm hw > Network isn't amazingly fast, but there's a squid-deb-proxy on the local > network for package caching with ~40GB for the cache, and it could be > expanded if needed. that's totally cool! You'll need to tell the name of that proxy eventually :-) > > yes, we need access. Preferedly root/sudo, else user ssh access (account > > name holger for me please) and we need a jenkins users with a quite > > liberal sudoers.d... > Will give you access and free reign to set up as you wish. :) cool, thanks! 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] [U-Boot, v2] Reproducible U-Boot build support, using SOURCE_DATE_EPOCH
On Sun, Jul 26, 2015 at 06:48:15PM +0200, Paul Kocialkowski wrote: > In order to achieve reproducible builds in U-Boot, timestamps that are defined > at build-time have to be somewhat eliminated. The SOURCE_DATE_EPOCH > environment > variable allows setting a fixed value for those timestamps. > > Simply by setting SOURCE_DATE_EPOCH to a fixed value, a number of targets can > be > built reproducibly. This is the case for e.g. sunxi devices. > > However, some other devices might need some more tweaks, especially regarding > the image generation tools. > > Signed-off-by: Paul Kocialkowski Applied to u-boot/master, thanks! -- Tom 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] ARM build machines
On 2015-07-28, Holger Levsen wrote: > do you need to be cc:ed? I am subscribed to the list as of a few weeks ago. > On Montag, 27. Juli 2015, Vagrant Cascadian wrote: >> So I set about trying to patch u-boot and test reproducibility myself, >> only to discover that the reproducible toolchain didn't include arm >> packages... > > 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? >> I've currently got two up and running, but it sounds like there's more >> work to do on the backend to integrate with jenkins and other >> infrastructure... > > yes, we need to make some changes to our infrastructure as well: > > - add scheduling for armhf > - have jenkins jobs to prepare pbuilder chroots for armhf on these machines > - add support for building on remote machines > - integrate the armhf build results into the web ui Regarding scheduling, I think we'll need a *lot* more nodes to get real archive coverage, or maybe selectively schedule packages for builds that are known or suspected to have architecture-specific divergence (e.g. builds different packages on different architectures). > how is the network connectivity? I assume we want to use a proxy, though I > have no idea whether one for both machines or one on each machine (though > with > 20gb diskspace there is not really space for a proxy...) Network isn't amazingly fast, but there's a squid-deb-proxy on the local network for package caching with ~40GB for the cache, and it could be expanded if needed. >> Let me know if you need access to these machines to configure them. > yes, we need access. Preferedly root/sudo, else user ssh access (account name > holger for me please) and we need a jenkins users with a quite liberal > sudoers.d... Will give you access and free reign to set up as you wish. :) 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
Re: [Reproducible-builds] ARM build machines
Hi Vagrant, do you need to be cc:ed? On Montag, 27. Juli 2015, Vagrant Cascadian wrote: > Thanks for all your work on reproducible builds! :-) Thanks for helping on the armhf hardware side! :-) > So I set about trying to patch u-boot and test reproducibility myself, > only to discover that the reproducible toolchain didn't include arm > packages... yes, we either need to make sure to manually build there in future too, or setup some autobuilders... > So I could build all this infrastructure locally, but figured better to > offer something to the reproducible builds effort at large. So I'd like > to make a few armhf build machines available to the project... very cool! > I've currently got two up and running, but it sounds like there's more > work to do on the backend to integrate with jenkins and other > infrastructure... yes, we need to make some changes to our infrastructure as well: - add scheduling for armhf - have jenkins jobs to prepare pbuilder chroots for armhf on these machines - add support for building on remote machines - integrate the armhf build results into the web ui > The current specs: > > bpi0-armhf-rb.debian.net: > Banana PI, dual-core, 1GB ram, ~20GB mSATA. > ssh port: > ssh fingerprints: > 2048 8f:0a:d0:77:a8:59:c0:bb:d0:76:de:14:13:5b:a6:56 (RSA) > 256 af:b4:13:04:21:30:46:b3:e8:79:ff:7d:99:20:86:f0 (ECDSA) > > hb0-armhf-rb.debian.net: > HummingBoard i2ex, dual-core, 1GB ram, ~20GB mSATA. > ssh port: 2224 > ssh fingerprints: > - 2048 04:af:b4:e8:f0:13:13:66:25:7b:e3:d6:ee:b3:0d:0a (RSA) > - 256 2f:1b:3a:fb:55:cf:27:3f:f6:de:e4:3d:e1:4c:59:c8 (ECDSA) nice, that should be plenty. how is the network connectivity? I assume we want to use a proxy, though I have no idea whether one for both machines or one on each machine (though with 20gb diskspace there is not really space for a proxy...) > I hope to get a wandboard quad-core with 2gb of ram and a 60GB SSD set > up in a few days, and possibly a cubox-i4pro with similar specs too. > > Let me know if you need access to these machines to configure them. yes, we need access. Preferedly root/sudo, else user ssh access (account name holger for me please) and we need a jenkins users with a quite liberal sudoers.d... I'll send you an ssh pub key in a seperate mail. Thanks again for your support! 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
[Reproducible-builds] debbindiff_26~bpo8+1_amd64.changes is NEW
binary:debbindiff is NEW. source:debbindiff is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will recieve an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Bug#793460: Bug#793460: debbindiff: please consider backport to Jessie
control: tags -1 + pending thanks Hi Wolfgang, On Freitag, 24. Juli 2015, W. Martin Borgert wrote: > In devscripts/stable, debbindiff is mentioned both in the long > package description as well as in debdiff(1). However, debbindiff > does not exist in stable. A backport to Jessie would be nice. I've just uploaded that backport, it's now awaiting bpo NEW processing. Thanks for your bug report! 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
[Reproducible-builds] Processed: Re: Bug#793460: debbindiff: please consider backport to Jessie
Processing control commands: > tags -1 + pending Bug #793460 [debbindiff] debbindiff: please consider backport to Jessie Added tag(s) pending. -- 793460: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793460 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Processing of debbindiff_26~bpo8+1_amd64.changes
debbindiff_26~bpo8+1_amd64.changes uploaded successfully to localhost along with the files: debbindiff_26~bpo8+1.dsc debbindiff_26~bpo8+1.tar.xz debbindiff_26~bpo8+1_all.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
[Reproducible-builds] Processing of debbindiff_26~bpo8+1_amd64.changes
debbindiff_26~bpo8+1_amd64.changes uploaded successfully to ftp-master.debian.org along with the files: debbindiff_26~bpo8+1.dsc debbindiff_26~bpo8+1.tar.xz debbindiff_26~bpo8+1_all.deb Greetings, Your Debian queue daemon (running on host coccia.debian.org) ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
