Искате да отидете на мечтаната ски ваканция?
Здравейте,Ще Ви помогнем за мечтаните покупки с бърз online заем до 2 000 лева - влезте в NaZaem.bg изберете желаните от Вас сума, срок и попълнете формата за кандидатстване. Молбата Ви ще бъде разгледана и ако е одобрена ще наредим сумата по посочената от Вас банкова сметка или каса на EasyPay до 10 минути.Като наш клиент ще се възползвате от най-добрите условия на пазара: · Прогресивно намаляващи такси; ·Всеки 7-ми заем САМО с 1 лев такса за ползване, независимо от избраните сума и срок (за заеми до 400 лева); · Одобрение и превод на сумата само за 1 минута - след първия изплатен заем; · Възможност за удължаване на заема (за заеми до 400 лева). Кандидатствайте още днес!С уважение,Екипът на NaZaem.bg Cъглacнo чл. 6, ал. 1 от Закона за електронната търговия, отправеният по – горе анонс представлява непоискано търговско съобщение. В случай, че не желаете да получавате търговски съобщения от "NaZaem.bg", натиснете ОТПИСВАНЕ. Молим да ни извините за причиненото неудобство. ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Another new armhf node (Pine64+)
Yet Another arm board ready to be configured for the build farm! p64c-armhf-rb.debian.net: Pine64+, Allwinner A64 (cortex-a53) quad-core, 2GB ram ssh port: 2248 ssh fingerprints: 2048 7e:11:62:84:b2:e8:cd:2b:52:f5:41:c1:98:bf:7a:d2 (RSA) 256 83:48:b1:c2:11:45:5c:51:9d:67:d1:58:0a:95:3d:33 (ECDSA) 256 2a:5a:c1:f3:90:14:dd:25:c3:6a:92:72:f4:23:e9:7e (ED25519) Another arm64 system running armhf userland. This one has just a plain USB stick; we'll see how that goes. 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
Bug#855169: diffoscope: use BSD-style stat on FreeBSD
Package: diffoscope Version: 77 >From GNU stat output diffoscope filters those parts that are allowed to change. The BSD stat(1) command does not match the output format and reports undesired differences: % python3 setup.py test --pytest-args="-rsx -l -vv tests/test_main.py::test_no_differences_directories" ... > assert ret == 0 E assert 1 == 0 capsys = <_pytest.capture.CaptureFixture object at 0x806b08c18> create_dir = .create_dir at 0x808576b70> err= '' out= '--- /tmp/pytest-of-emaste/pytest-13/test_no_differences_directorie0/a\n+++ /tmp/pytest-of-emaste/pytest-13/test_no_di...14 21:49:59 2017" "Jan 1 00:00:00 1970" 32768 8 0 /tmp/pytest-of-emaste/pytest-13/test_no_differences_directorie0/b\n' ret= 1 ... BSD stat accepts a -f argument to specify the output format so the filtering can be avoided altogether. Attached patch (also available as https://github.com/emaste/diffoscope/commit/e709c11212a18105f3b6862d5ed20de61038b71a) is my approach at addressing this. commit e709c11212a18105f3b6862d5ed20de61038b71a Author: Ed Maste Date: Tue Feb 14 16:42:20 2017 -0500 Assume BSD-style stat(1) on FreeBSD diff --git a/diffoscope/comparators/directory.py b/diffoscope/comparators/directory.py index d30cb64..1327912 100644 --- a/diffoscope/comparators/directory.py +++ b/diffoscope/comparators/directory.py @@ -45,25 +45,31 @@ def list_files(path): return all_files -class Stat(Command): -@tool_required('stat') -def cmdline(self): -return ['stat', self.path] - -FILE_RE = re.compile(r'^\s*File:.*$') -DEVICE_RE = re.compile(r'Device: [0-9a-f]+h/[0-9]+d\s+') -INODE_RE = re.compile(r'Inode: [0-9]+\s+') -ACCESS_TIME_RE = re.compile(r'^Access: [0-9]{4}-[0-9]{2}-[0-9]{2}.*$') -CHANGE_TIME_RE = re.compile(r'^Change: [0-9]{4}-[0-9]{2}-[0-9]{2}.*$') - -def filter(self, line): -line = line.decode('utf-8') -line = Stat.FILE_RE.sub('', line) -line = Stat.DEVICE_RE.sub('', line) -line = Stat.INODE_RE.sub('', line) -line = Stat.ACCESS_TIME_RE.sub('', line) -line = Stat.CHANGE_TIME_RE.sub('', line) -return line.encode('utf-8') +if os.uname()[0] == 'FreeBSD': +class Stat(Command): +@tool_required('stat') +def cmdline(self): +return ['stat', '-t', '%Y-%m-%d %H:%M:%S', '-f', '%Sp %l %Su %Sg %z %Sm %k %b %#Xf', self.path] +else: +class Stat(Command): +@tool_required('stat') +def cmdline(self): +return ['stat', self.path] + +FILE_RE = re.compile(r'^\s*File:.*$') +DEVICE_RE = re.compile(r'Device: [0-9a-f]+h/[0-9]+d\s+') +INODE_RE = re.compile(r'Inode: [0-9]+\s+') +ACCESS_TIME_RE = re.compile(r'^Access: [0-9]{4}-[0-9]{2}-[0-9]{2}.*$') +CHANGE_TIME_RE = re.compile(r'^Change: [0-9]{4}-[0-9]{2}-[0-9]{2}.*$') + +def filter(self, line): +line = line.decode('utf-8') +line = Stat.FILE_RE.sub('', line) +line = Stat.DEVICE_RE.sub('', line) +line = Stat.INODE_RE.sub('', line) +line = Stat.ACCESS_TIME_RE.sub('', line) +line = Stat.CHANGE_TIME_RE.sub('', line) +return line.encode('utf-8') @tool_required('lsattr') ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: diffoscope 77 in stretch or not?
On Tue, Feb 14, 2017 at 08:44:00PM +, Ximin Luo wrote: > I do think it's OK to try to support diffoscope 67 for 2 years because it's > been quite well tested. well, yes… but… > I understand that 77 fixes quite a lot of bugs over 67… 77 *exists* and is quite probably a lot better than 67, so I now think we should strive for 77 (or 77++ if needed) in stretch… I like 77, I just don't like the way we got there. But now that we have it, no need to hide it. -- 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: diffoscope 77 in stretch or not?
Holger Levsen: > On Tue, Feb 14, 2017 at 09:38:51AM +1300, Chris Lamb wrote: >>> what did you plan on to do with diffoscope in regard to Debian's >>> stretch when you decided to work on it >> I didn't decide anything at all; I was enjoying the coding, adding >> features, tests, squashing bugs... > > you decided to put this work into the master branch though and to upload this > to unstable, while you certainly were aware of the freeze (which is always > the reasons for tensions btw) and the surrounding policies. > > Me too would have appreciated and expected some discussion about this, eg > a simple mail to the list "what shall we do, I think we should push $this > into unstable and stretch". > >> (However, whatever version ends up in stretch will surely become pretty >> outdated that we will be sending people to Backports within a few >> months anyway, so I'm not overly concerned about this.) > > well, whatever we put in stretch now has been tested on 25k packages in > Debian plus a bunch of other projects, so, yeah, whatever, it might become > slightly outdated in a while, yet diffoscope today is quite great and deserves > proper care. > I do generally agree with this and have been concerned about the specific pace of diffoscope commits in the past few weeks. Not only because of the security issue [1], but because it is bypassing the normal Debian process a bit. I don't think it's good to "try an unblock b/c we have good relations with that team", this type of personal/social politics is not how I'd like to see Debian function. Personally I would prefer it if the release team forced us to backport the security fix and kept the stretch version at 67+security1 because that would be "more fair treatment". I do think it's OK to try to support diffoscope 67 for 2 years because it's been quite well tested. The core functionality is all there, and people have been using it for ages. There's no need to rush things into unstable, we can push to experimental until the freeze is over. I understand that 77 fixes quite a lot of bugs over 67, but this could have been done without the other changes (which could have been made in a side branch). And that would be more in line with the "normal unblock process". X [1] I have other words to say about that but unfortunately some people don't like how I choose to express things -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [diffoscope] diffoscope commit mails
On Tue, Feb 14, 2017 at 08:59:59PM +0100, Mattia Rizzolo wrote: > > To: reproducible-comm...@lists.alioth.debian.org, > > diffosc...@lists.reproducible-builds.org > that's a different mailing list, on alioth, reproducible-commits. > I'm talking about rb-commits, on reproducible-builds.org: > https://lists.reproducible-builds.org/listinfo/rb-commits well, I dont know why you were talking about something else in this thread which I started to discuss the very fact that currently these commit mails go to reproducible-comm...@lists.alioth.debian.org and diffosc...@lists.reproducible-builds.org ;-p so can we maybe come back to the initial question and agree on a single list to send those commit messages too? I really dont care which, as long as it's one. I'd also be fine with a new lists, diffoscope-commits@l.r-b.o > > > The only thing that I can think of that would clash with this would be > > > dreamed shared notes… > > Please don't call this a dream… > sorry! ;) :) thanks! -- 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: [diffoscope] diffoscope commit mails
On Tue, Feb 14, 2017 at 07:50:11PM +, Holger Levsen wrote: > > > hm, that makes rb-commits@l.r-b.o more noisy and less specific, so maybe > > > we should > > > use diffoscope-comm...@lists.reproducible-builds.org instead? > > > > I don't think it wold: rb-commits is *not used* at all right now, last > > email was on August (so I'm led to believe some post-commit hook broke > > somewhere), and all the other things are updated much less often than > > diffoscope. > > I'm getting commits there every day, eg for diffoscope the last was: > > Date: Mon, 13 Feb 2017 19:39:58 + > From: Maria Glukhova > To: reproducible-comm...@lists.alioth.debian.org, > diffosc...@lists.reproducible-builds.org > Subject: [diffoscope] branch siamezzze/containers updated (5a5c341 -> 9570f1c) > Reply-To: reproducible-builds@lists.alioth.debian.org, > siamezzze-gu...@users.alioth.debian.org > List-Id: Commit messages for the Reproducible Builds project > that's a different mailing list, on alioth, reproducible-commits. I'm talking about rb-commits, on reproducible-builds.org: https://lists.reproducible-builds.org/listinfo/rb-commits > > The only thing that I can think of that would clash with this would be > > dreamed shared notes, that by definition would need to go in that > > mailing list. > > Please don't call this a dream… sorry! ;) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- 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: diffoscope 77 in stretch or not?
On Tue, Feb 14, 2017 at 09:38:51AM +1300, Chris Lamb wrote: > > what did you plan on to do with diffoscope in regard to Debian's > > stretch when you decided to work on it > I didn't decide anything at all; I was enjoying the coding, adding > features, tests, squashing bugs... you decided to put this work into the master branch though and to upload this to unstable, while you certainly were aware of the freeze (which is always the reasons for tensions btw) and the surrounding policies. Me too would have appreciated and expected some discussion about this, eg a simple mail to the list "what shall we do, I think we should push $this into unstable and stretch". > (However, whatever version ends up in stretch will surely become pretty > outdated that we will be sending people to Backports within a few > months anyway, so I'm not overly concerned about this.) well, whatever we put in stretch now has been tested on 25k packages in Debian plus a bunch of other projects, so, yeah, whatever, it might become slightly outdated in a while, yet diffoscope today is quite great and deserves proper care. -- 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: [diffoscope] diffoscope commit mails
On Tue, Feb 07, 2017 at 07:16:41PM +0100, Mattia Rizzolo wrote: > On Tue, Feb 07, 2017 at 06:04:35PM +, Holger Levsen wrote: > > > > Shouldn't we drop the mails to > > > > reproducible-comm...@lists.alioth.debian.org > > > > and just send them to diffosc...@lists.reproducible-builds.org?! > > > IMHO, we shouldn't email them to diffoscope@l.r-b.o either, but instead > > > rb-commits@l.r-b.o, same for the other non-debian specific stuff. > > > > hm, that makes rb-commits@l.r-b.o more noisy and less specific, so maybe we > > should > > use diffoscope-comm...@lists.reproducible-builds.org instead? > > I don't think it wold: rb-commits is *not used* at all right now, last > email was on August (so I'm led to believe some post-commit hook broke > somewhere), and all the other things are updated much less often than > diffoscope. I'm getting commits there every day, eg for diffoscope the last was: Date: Mon, 13 Feb 2017 19:39:58 + From: Maria Glukhova To: reproducible-comm...@lists.alioth.debian.org, diffosc...@lists.reproducible-builds.org Subject: [diffoscope] branch siamezzze/containers updated (5a5c341 -> 9570f1c) Reply-To: reproducible-builds@lists.alioth.debian.org, siamezzze-gu...@users.alioth.debian.org List-Id: Commit messages for the Reproducible Builds project > The only thing that I can think of that would clash with this would be > dreamed shared notes, that by definition would need to go in that > mailing list. Please don't call this a dream… -- 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: would/Does it make sense to have .buildinfo feature into compiling tools as well ?
shirish शिरीष: > Dear all, > > My idea/suggestion may be crap but still please go through it. > > From whatever little I understand of reproducible builds, one of the > basic things it tries to do is have a .buildinfo file which can be > shared with the other person so that s(he) can use the .buildinfo file > to generate the same binary and see that the checksums > (sha1sum/sha256sum) are the same. > > Wouldn't you say it would also make sense to have the same/similar > feature built into compiling tools like make, cmake, premake etc. not > just for the security POV but also to figure out build failures - > > What do you think ? > > The best thing about the .buildinfo file is that it gives/shares all > the files needed for a build to happen, like in debian's case with > dpkg-buildpackage to generate a debian binary. > > Looking forward to know what people think of the idea ? > Hi shirish, I think it's a good idea in principle. But then you have to decide what your eventual goal is, and whether it's worth the cost needed to achieve this goal. Do you have a particular build tool in mind, to start this for? One thing I can see: .buildinfo files for Debian packages are relatively easy to make because there is one unified way to build a Debian package, and a compact way of describing what else is present on the system (Installed-Build-Depends). For other distributions, they all have similar concepts so it would not be much more expensive - RPM are working on something similar now. With some other buildsystems, it is easy for them to describe what else is present on the system and was used as part of the build. For example languages that have their own package managers: haskell, ocaml, rust. With other buildsystems, this is harder. For example, C or C++ buildsystems. These pass around -I flags and so on, and they might not be able to describe this "compactly" as a package-version string. You might be able to do something equivalent by storing the hashes of all input files - some of which may be binary files, and they may or may not be reproducible. This would be more costly and might not be worth the effort. Or maybe it would, I don't know. X -- GPG: ed25519/56034877E1F87C35 GPG: rsa4096/1318EFAC5FBBDBCE https://github.com/infinity0/pubkeys.git ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
would/Does it make sense to have .buildinfo feature into compiling tools as well ?
Dear all, My idea/suggestion may be crap but still please go through it. From whatever little I understand of reproducible builds, one of the basic things it tries to do is have a .buildinfo file which can be shared with the other person so that s(he) can use the .buildinfo file to generate the same binary and see that the checksums (sha1sum/sha256sum) are the same. Wouldn't you say it would also make sense to have the same/similar feature built into compiling tools like make, cmake, premake etc. not just for the security POV but also to figure out build failures - What do you think ? The best thing about the .buildinfo file is that it gives/shares all the files needed for a build to happen, like in debian's case with dpkg-buildpackage to generate a debian binary. Looking forward to know what people think of the idea ? -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8 -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8 ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: package uploaded to our repo
On Tue, Feb 14, 2017 at 04:52:22PM +1300, Chris Lamb wrote: > No. This upload to our repo adds new codepaths to Python 2.7 which are then > enabled on the "b" build on jenkins.debian.net; see > <1486933699.96290.878650304.07373...@webmail.messagingengine.com> for the > background. ic, thanks. > Let me know if there is anything specific that you are unsure of in the > above referenced message as I'm not sure what remains unclear. I really want to see a bug number here. > > also, you uploaded python2.7_2.7.13-3~reproducible1 for amd64, do you plan > > to > > do upload the other architectures as well? > Let's just start with amd64 for now and see what happens. No. For once, this needs a bug somewhere for tracking. Secondly, we should either do this on all architectures or on none at all. > Perhaps it will > not be of any value, so preparing other uploads or making long-term plans > for the patch would be premature. IMO it's also premature to deploy this in our setup, if it's so unclear whether it's useful. We have worked long and hard to be able to say "we are testing 100% unmodified pure Debian", we should spoil this for something premature. -- 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