Re: Buildinfo in the Debian archive, updates
On 2016-12-07, Jonathan McDowell wrote: > On Tue, Dec 06, 2016 at 09:24:20PM +, Holger Levsen wrote: >> On Mon, Nov 14, 2016 at 02:57:00PM +, Ximin Luo wrote: >> > This email is a summary of some discussions that happened after the >> > last post to bug #763822, plus some more of my own thoughts and >> > reasoning on the topic. >> >> I think that given our last mail on this bug was >4 weeks ago, it's >> mostly important we reply to the bug at all now… >> >> > I think having the Debian FTP archive distribute unsigned buildinfo >> > files is an OK intermediate solution, with a few tweaks: >> > >> > 1. the hashes of the *signed* buildinfo files must be referred-to >> > for each binary package, in Packages.gz >> >> I actually think thats too much to ask for right now. we should >> *propose* this now as a 2nd step, but right now the first step should >> be that those .buildinfo files are stored *at all*, for later >> consumption. > > The storage of the hashes of the signed buildinfo files in Packages.gz > seems to be in order to deal with the fact that the signature is not > available elsewhere. Well, the storage of the hashes of buildinfo files in Packages is a way to for the archive to attest "this is the exact buildinfo file used to create this exact .deb package version on archictecture X", in the same file it distributes information about the .deb Packages. Having a separate Buildinfos.xz file *might* at some point be out of sync with the Packages file (even if just due out-of-sync mirrors). It seems (perhaps naively) like it should be cheap to add a single-line checksum along with the Packages file, which allows users to look for the corresponding .buildinfo (perhaps in-archive, perhaps through a third-party service) without having to download additional Buildinfos.xz. I think supporting multiple buildinfo files in-archive, while nice, shouldn't block getting the .buildinfo files used to generate the .deb (and related) files in-archive. It's more important to distribute the .buildinfo files in-archive that were used to build the package included in-archive, than require an implementation supporting multiple signers. Overall, I'm in favor of whatever incremental progress moves in the right general direction, even if not the "perfect" direction. :) 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
до - 70 % през декември!
Рекламата по имейл - директният имейл маркетинг е най-бързият и измерим похват в интернет рекламата, който позволява изпращането на стотици хиляди, дори милиони, оферти по имейл за броени часове. Реално се отварят между 4 и 10 % от всички изпратени електронни съобщения. Това означава че, ако изпратите съобщение до 100 000 фирми, може да очаквате от 4 до 10 000 прочетени писма. Също така, статистиката е много подробна и освен че, знаете колко имейла са отворени, знаете и кой точно ги е отворил и кой е посетил сайта ви. През месец Декември предлагаме до – 70 % отстъпка за услугата изпращане на електронни съобщения. Ето какво предлагаме? - Голяма база данни - за България разполагаме с 1 800 000 валидни e-mail адреса, от които 400 000 са на фирми - Консултации по съдържанието и заглавието на писмото. - Изпращане на e-mail-ите през наши домейни и сървъри. - Статистика в реално време от независим източник за отворени писма и кликове на линковете в писмото. - Автоматизирана система за отписване за получаване на e-mail-и. Вижте промоционалните цени от този линк http://www.market-mail.info/?page_id=19 Също може да се обадите сега на 0878 161 901 за да получите подробна информация и лични препоръки, кой обем ще е най подходящ за вашия бизнес. Изпратете вашата оферта и тези, които имат интерес ще се свържат с вас. Поздрави Market Mail екип i...@market-mail.info за въпроси и коментари се обадете на 0878 161 901 Съгласно закона за електронна търговия Чл. 6, ал. 1 Ви уведомяваме, че е възможно това да е непоискано търговско съобщение. То е еднократно изпратено писмо до Вашия e-mail адрес, който е взет от публичното пространство. Извиняваме се, ако по някаква причина сме Ви притеснили с нашето предложение. Ако не желаете да получавате съобщения от "Market-mail", моля натиснете ОТПИСВАНЕ за да се откажете да получавате нашите бюлетини! ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Buildinfo in the Debian archive, updates
On Tue 2016-12-06 17:41:34 -0500, Jonathan McDowell wrote: > The storage of the hashes of the signed buildinfo files in Packages.gz > seems to be in order to deal with the fact that the signature is not > available elsewhere. If dkg's suggestion of using ECC signatures is > followed then some quick checking shows a signature size of 165 bytes > (when ASCII armoured). This seems sufficiently small to me that you > could just map it into a Signature: field at the end of the buildinfo > stanza within buildinfo.xz, with the bonus that at some point that would > allow for multiple such fields, all within the archive mirror network. I'd be wary about this "multiple such fields" bit. it seems likely that different buildinfo files will not match each other, even if the *output* is reproducible. This is because buildinfo files can capture some things that do not have an impact on the resultant binary artifacts. Otherwise, though, i agree with Jonathan that stuffing a small signature into the buildinfo file itself seems OK. --dkg 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: Buildinfo in the Debian archive, updates
On Tue, Dec 06, 2016 at 09:24:20PM +, Holger Levsen wrote: > On Mon, Nov 14, 2016 at 02:57:00PM +, Ximin Luo wrote: > > This email is a summary of some discussions that happened after the > > last post to bug #763822, plus some more of my own thoughts and > > reasoning on the topic. > > I think that given our last mail on this bug was >4 weeks ago, it's > mostly important we reply to the bug at all now… > > > I think having the Debian FTP archive distribute unsigned buildinfo > > files is an OK intermediate solution, with a few tweaks: > > > > 1. the hashes of the *signed* buildinfo files must be referred-to > > for each binary package, in Packages.gz > > I actually think thats too much to ask for right now. we should > *propose* this now as a 2nd step, but right now the first step should > be that those .buildinfo files are stored *at all*, for later > consumption. The storage of the hashes of the signed buildinfo files in Packages.gz seems to be in order to deal with the fact that the signature is not available elsewhere. If dkg's suggestion of using ECC signatures is followed then some quick checking shows a signature size of 165 bytes (when ASCII armoured). This seems sufficiently small to me that you could just map it into a Signature: field at the end of the buildinfo stanza within buildinfo.xz, with the bonus that at some point that would allow for multiple such fields, all within the archive mirror network. The max permitted size of such a field could be something configurable by ftp-master, so if that they wanted to allow full RSA based signatures they could set it to ~800 bytes, or limit it to ECC at < 200 bytes. > Thinking again, I think we should not outline stuff for the 2nd step > right now, just the very 1st, which is saving the files at all, > somewhere on the local disk (of ftp-master.d.o). Saving them into the projectb is probably the way to go. I started looking at the dak code to do this back at DebConf, then stopped when it looked like I was going down a different path to what was desired. I had hoped to try and pick this up again before the meeting next week but haven't found a sufficient block of time yet. J. -- OK, if we can't have a tour, can we at least have a look around? 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: Buildinfo in the Debian archive, updates
Hi, On Mon, Nov 14, 2016 at 02:57:00PM +, Ximin Luo wrote: > This email is a summary of some discussions that happened after the last post > to bug #763822, plus some more of my own thoughts and reasoning on the topic. I think that given our last mail on this bug was >4 weeks ago, it's mostly important we reply to the bug at all now… > I think having the Debian FTP archive distribute unsigned buildinfo files is > an > OK intermediate solution, with a few tweaks: > > 1. the hashes of the *signed* buildinfo files must be referred-to for each >binary package, in Packages.gz I actually think thats too much to ask for right now. we should *propose* this now as a 2nd step, but right now the first step should be that those .buildinfo files are stored *at all*, for later consumption. we "loose" .buildinfo files each day currently… [lots of interesing and useful stuff deleted.] Thinking again, I think we should not outline stuff for the 2nd step right now, just the very 1st, which is saving the files at all, somewhere on the local disk (of ftp-master.d.o). -- cheers, Holger 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] arm64 reproducible build network
Hi, Holger Levsen wrote: > On Tue, Dec 06, 2016 at 09:24:50AM -0800, Martin Michlmayr wrote: > > I heard from a Linaro contact that LeMaker wasn't able to fix the PCIE > > issue and was going to produce the board without, but that update is > > from October and there has been nothing since. :( […] > on the plus side we now got access to some moonshot-arm64 hardware, so > at least we'll be testing on arm64 soon. though for diversity reasons, > we absolutly still like to get access to LeMaker boards too! Not that I want to undermine Martin's efforts, but I wonder if we should start by taking some more boards into account for arm64, too: * Raspberry Pi 3 now works also with arm64: https://wiki.debian.org/RaspberryPi3 https://people.debian.org/~stapelberg/raspberrypi3/ (Serial console only as of now, but that should be ok-ish for a reproducible builds node.) * Odroid C2 works fine with arm64, too. Not sure what's needed to get all kernel modifications upstreamed: https://www.armbian.com/odroid-c2/ I could imagine providing the hardware and hosting for a few such devices. (Maybe in addition to the hopefully somewhen arriving LeMaker Cello boards.) http://www.pollin.de/shop/dt/ODA1OTgxOTk-/Bauelemente_Bauteile/Entwicklerboards/Odroid/ODROID_C2_Einplatinen_Computer_1_5_GHz_QuadCore_2_GB_RAM_4x_USB.html http://www.pollin.de/shop/dt/OTQxNzkyOTk-/Bauelemente_Bauteile/Entwicklerboards/Raspberry_Pi/Raspberry_Pi_3_Model_B.html I'm aware of the connectivity requirements, but wrt. Raspberry Pi 3 and Odroid C2 I wonder about disk space and speed requirements. Would e.g. a Class 10 UHS-1 8 GB microSD card suffice? http://www.pollin.de/shop/dt/OTQ2NzcyOTk-/Computer_Informationstechnik/Speichermedien/microSD_SDHC_Speicherkarten/MicroSDHC_Card_VERBATIM_44004_8_GB.html Or are the probably faster but also more expensive eMMC devices preferred? http://www.pollin.de/shop/dt/NTk0OTgxOTk-/Bauelemente_Bauteile/Entwicklerboards/Odroid/ODROID_C2_eMMC_Modul_8_GB_mit_Linux.html Or is even some real hard disk or SSD needed? As a power supply e.g. this one might suffice: http://www.pollin.de/shop/dt/MjUyODQ2OTk-/Stromversorgung/Ladegeraete/USB_Ladegeraete/4_fach_USB_Lader_LOGILINK_PA0096_weiss.html Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] arm64 reproducible build network
Hi Martin, On Tue, Dec 06, 2016 at 09:24:50AM -0800, Martin Michlmayr wrote: > I heard from a Linaro contact that LeMaker wasn't able to fix the PCIE > issue and was going to produce the board without, but that update is > from October and there has been nothing since. :( ouch & thanks for keeping us informed & getting back to them… on the plus side we now got access to some moonshot-arm64 hardware, so at least we'll be testing on arm64 soon. though for diversity reasons, we absolutly still like to get access to LeMaker boards too! -- cheers, Holger 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] arm64 reproducible build network
* Martin Michlmayr [2016-09-02 14:59]: > * Martin Michlmayr [2016-05-25 11:51]: > > The LeMaker Cello web site still says "shipping in Q2". I'll let you > > know when that changes. > > LeMaker sent out an update a few weeks ago saying that there is some > PCIE problem they are still debugging before mass production can > start. Unfortunaetly, there's still no update. I tried to contact LeMaker several times but didn't get a reply. I heard from a Linaro contact that LeMaker wasn't able to fix the PCIE issue and was going to produce the board without, but that update is from October and there has been nothing since. :( -- Martin Michlmayr http://www.cyrius.com/ ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
