Искате да отидете на мечтаната ски ваканция?

[NaZaem bg]

Здравейте,Ще Ви помогнем за
мечтаните покупки с бърз 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+)

[Vagrant Cascadian]

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

[Ed Maste]

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?

[Holger Levsen]

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?

[Ximin Luo]

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

[Holger Levsen]

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

[Mattia Rizzolo]

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?

[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.


-- 
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

[Holger Levsen]

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 ?

[Ximin Luo]

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 ?

[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 ?

-- 
  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

[Holger Levsen]

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