Bug#877813: reprotest: regression between 0.7.1 and 0.7.2

2017-10-05 Thread gregor herrmann 
On Thu, 05 Oct 2017 22:59:00 +, Ximin Luo wrote:

> gregor herrmann:
> > [..]
> > sudo: Î޷¨½âÎöÖ÷»ú£ºjadzia
> > tail: Î޷¨´ò¿ª'debian/changelog' ¶ÁȡÊý¾: ȨÏ޲»¹»
> > dpkg-buildpackage: erreur: fin de debian/changelog a produit une erreur de 
> > sortie de type 1
> > [..]
> > sudo: impossible de déterminer le nom de l'hôte jadzia
> > tail: no se puede abrir 'debian/changelog' para lectura: Permiso denegado
> > dpkg-buildpackage: error: tail of debian/changelog gave error exit status 1

> tail(1) apparently can't read debian/changelog. 

Yes, after manually installing fakeroot, which I didn't need to do
for reprotest <= 0.7.1.

And the error before "tail: can't open ..." (in Spanish) is still
"sudo: can't determine hostname ..." (in French).

I might be wrong, but this still sounds like a problem related to
sudo to me.

Full disclosure: I'm not running systems in the Ubuntu-style of "sudo
all all nopasswd everything ". And so far both autopkgtest
and reprotest (which are both using the same schroot chroot, and are
the only ones, as for building I'm using cowbuilder) just worked.

> I don't know how you set up your schroot, but reprotest is coded
> against the sbuild-createchroot stuff. Have you tried using that?

That's a good question :) And I'm not entirely sure since I did this
years ago and I only use the schroot chroot for autopkgtest and
reprotest; but I think it was sbuild-createchroot as well.
 
> What command line are you running to get these errors?

Another good question; I call reprotest from a wrapper script:

https://anonscm.debian.org/cgit/pkg-perl/packages/pkg-perl-tools.git/tree/examples/check-build#n86

Which, run under 'sh -x' looks like:

#v+
+ read -n 1 -p 'reprotest? y/N ' REPRO
reprotest? y/N y+ '[' y = y ']'
+ REPROTESTLOG=../build-area/openpgp-applet_1.0-2_amd64_reprotest.log
+ '[' -x /usr/bin/schroot ']'
+ schroot -l
+ grep -q default
+ REPROTEST_VIRT_SERVER=schroot
+ REPROTEST_VIRT_SERVER_ARGS=default
+ '[' -n schroot ']'
++ dpkg-query -f '${Version}\n' -W reprotest
+ REPROTESTVERSION=0.7.2
+ dpkg --compare-versions 0.7.2 ge 0.7
+ REPROTESTPARAMS='--variations=+all,-build_path,-user_group --verbosity 1 . '
+ env -u TMPDIR -- reprotest --variations=+all,-build_path,-user_group 
--verbosity 1 . -- schroot default
+ tee ../build-area/openpgp-applet_1.0-2_amd64_reprotest.log
preset auto-selected: ReprotestPreset(build_command='\nif [ "$(id -u)" 
= 0 ]; then\nsudo -E -u "$LOGNAME" sh -ec \'dpkg-buildpackage 
--no-sign -b\';\nelse\nsh -ec \'dpkg-buildpackage --no-sign 
-b\';\nfi\n', artifact_pattern='../*.deb', testbed_pre=None, 
testbed_init='apt-get -y --no-install-recommends install disorderfs faketime 
locales-all sudo util-linux; test -c /dev/fuse || mknod -m 666 
/dev/fuse c 10 229; test -f /etc/mtab || ln -s ../proc/self/mounts 
/etc/mtab', testbed_build_pre='apt-get -y --no-install-recommends build-dep 
./"."', source_pattern=None, diffoscope_args=[])
STARTING VIRTUAL SERVER 
['/usr/lib/python3/dist-packages/reprotest/virt/autopkgtest-virt-schroot', 
'default']
reprotest [01:25:00]: version @version@
reprotest [01:25:00]: host jadzia; command line: /usr/bin/reprotest 
--variations=+all,-build_path,-user_group --verbosity 1 . -- schroot default
reprotest [01:25:00]: testbed package architecture: amd64
reprotest [01:25:01]: testbed running kernel: Linux 4.12.0-2-amd64 #1 SMP 
Debian 4.12.13-1 (2017-09-19)
Reading package lists...
[.. first build ..]
executing: if ( mv /tmp/autopkgtest.eYrFOo/build-control/ 
/tmp/autopkgtest.eYrFOo/const_build_path && umask 0022 && export 
REPROTEST_BUILD_PATH=/tmp/autopkgtest.eYrFOo/const_build_path/ && export 
REPROTEST_UMASK=$(umask) && linux64 --uname-2.6 sh -ec 'cd 
"$REPROTEST_BUILD_PATH"; unset REPROTEST_BUILD_PATH; umask "$REPROTEST_UMASK"; 
unset REPROTEST_UMASK; 
if [ "$(id -u)" = 0 ]; then
sudo -E -u "$LOGNAME" sh -ec '"'"'dpkg-buildpackage --no-sign 
-b'"'"';
else
sh -ec '"'"'dpkg-buildpackage --no-sign -b'"'"';
fi
' ); then
( __c=0; mv /tmp/autopkgtest.eYrFOo/const_build_path 
/tmp/autopkgtest.eYrFOo/build-control/ || __c=$?; exit $__c; );
else
__x=$?;
if ( __c=0; mv /tmp/autopkgtest.eYrFOo/const_build_path 
/tmp/autopkgtest.eYrFOo/build-control/ || __c=$?; exit $__c; ); then exit $__x; 
else
echo >&2; "cleanup failed with exit code $?"; exit $__x;
fi;
fi

sudo: unable to resolve host jadzia
dpkg-buildpackage: error: fakeroot not found, either install the fakeroot
package, specify a command with the -r option, or run this as root
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 720, in run
return 0 if check_func(*check_args) else 1
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 332, in 
check
local_dists = [proc.send(nv) for nv in zip(bnames, build_variations)]
  File

Bug#877813: reprotest: regression between 0.7.1 and 0.7.2

2017-10-05 Thread gregor herrmann 
On Thu, 05 Oct 2017 22:16:00 +, Ximin Luo wrote:

> gregor herrmann:
> > [..]> dpkg-buildpackage: error: fakeroot not found, either install the 
> > fakeroot
> > package, specify a command with the -r option, or run this as root
> > [..]
> > 
> > This seems to be related to the "sudo" use in the output above (or
> > the funny output in the first line?), or
> > 
> >   * Improve the dsc+schroot preset to run builds as non-root.
> > 
> > in the changelog, or 62416ab in git.
> > 
> > After that, my python knowledge and domain knowledge ends; but
> > unfortunately this means that reprotest 0.7.2 is unusable for me.
> > 

> Hi gregor, does it work if log into your "default" schroot and
> install the "fakeroot" package?

Thanks for your super-fast reply.

Unfortunately, the answer is no:

After installing fakeroot in the schroot chroot and upgrading
reprotest again to 0.7.2 the result is -- hm, well different than
before. The first build succeeds, the second aborts with

package 1:

#v+
dpkg-buildpackage: info: binary-only upload (no source included)
copying /tmp/autopkgtest.uaX6su/artifacts-control/ back from virtual server's 
/tmp/tmp0i8yh6gh/control
build "experiment-1": vary environment, FIX build_path, FIX user_group, vary 
fileordering, vary home, vary kernel, vary locales, vary exec_path, vary time, 
vary timezone, vary umask
copying . over to virtual server's /tmp/autopkgtest.uaX6su/build-experiment-1/
starting build with source directory: 
/tmp/autopkgtest.uaX6su/build-experiment-1/, artifact pattern: ./../*.deb
Note, using directory './.' to get the build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
executing: if ( mv /tmp/autopkgtest.uaX6su/build-experiment-1/ 
/tmp/autopkgtest.uaX6su/const_build_path && mv 
/tmp/autopkgtest.uaX6su/const_build_path/ 
/tmp/autopkgtest.uaX6su/const_build_path-before-disorderfs/ && mkdir -p 
/tmp/autopkgtest.uaX6su/const_build_path/ && disorderfs --shuffle-dirents=yes 
/tmp/autopkgtest.uaX6su/const_build_path-before-disorderfs/ 
/tmp/autopkgtest.uaX6su/const_build_path/ && umask 0002 && export 
REPROTEST_BUILD_PATH=/tmp/autopkgtest.uaX6su/const_build_path/ && export 
REPROTEST_UMASK=$(umask) && faketime +373days+7hours+13minutes linux32 sh -ec 
'cd "$REPROTEST_BUILD_PATH"; unset REPROTEST_BUILD_PATH; umask 
"$REPROTEST_UMASK"; unset REPROTEST_UMASK; 
if [ "$(id -u)" = 0 ]; then
sudo -E -u "$LOGNAME" sh -ec '"'"'dpkg-buildpackage --no-sign 
-b'"'"';
else
sh -ec '"'"'dpkg-buildpackage --no-sign -b'"'"';
fi
' ); then
( __c=0; export PATH="/tmp/autopkgtest.uaX6su/bin:$PATH" || __c=$?; 
fusermount -u /tmp/autopkgtest.uaX6su/const_build_path/ || __c=$?; rmdir 
/tmp/autopkgtest.uaX6su/const_build_path/ || __c=$?; mv 
/tmp/autopkgtest.uaX6su/const_build_path-before-disorderfs/ 
/tmp/autopkgtest.uaX6su/const_build_path/ || __c=$?; mv 
/tmp/autopkgtest.uaX6su/const_build_path 
/tmp/autopkgtest.uaX6su/build-experiment-1/ || __c=$?; exit $__c; );
else
__x=$?;
if ( __c=0; export PATH="/tmp/autopkgtest.uaX6su/bin:$PATH" || __c=$?; 
fusermount -u /tmp/autopkgtest.uaX6su/const_build_path/ || __c=$?; rmdir 
/tmp/autopkgtest.uaX6su/const_build_path/ || __c=$?; mv 
/tmp/autopkgtest.uaX6su/const_build_path-before-disorderfs/ 
/tmp/autopkgtest.uaX6su/const_build_path/ || __c=$?; mv 
/tmp/autopkgtest.uaX6su/const_build_path 
/tmp/autopkgtest.uaX6su/build-experiment-1/ || __c=$?; exit $__c; ); then exit 
$__x; else
echo >&2; "cleanup failed with exit code $?"; exit $__x;
fi;
fi

disorderfs: shuffling dirents
disorderfs: reversing dirents
sudo: Î޷¨½âÎöÖ÷»ú£ºjadzia
tail: Î޷¨´ò¿ª'debian/changelog' ¶ÁȡÊý¾: ȨÏ޲»¹»
dpkg-buildpackage: erreur: fin de debian/changelog a produit une erreur de 
sortie de type 1
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 720, in run
return 0 if check_func(*check_args) else 1
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 332, in 
check
local_dists = [proc.send(nv) for nv in zip(bnames, build_variations)]
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 332, in 

local_dists = [proc.send(nv) for nv in zip(bnames, build_variations)]
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 298, in 
corun_builds
bctx.run_build(testbed, build, artifact_pattern, testbed_build_pre)
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 186, in 
run_build
kind='build')
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 61, in 
check_exec2
adtlog.AutopkgtestError)
  File "/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py", line 370, 
in bomb
raise _type(m)
reprotest.lib.adtlog.AutopkgtestError: "sh -ec if ( mv 
/tmp/autopkgtest.uaX6su/build-experiment-1/ 
/tmp/autopkgtest.uaX6su/const_build_path && mv

Bug#877813: reprotest: regression between 0.7.1 and 0.7.2

2017-10-05 Thread Ximin Luo 
gregor herrmann:
> [..]> dpkg-buildpackage: error: fakeroot not found, either install the 
> fakeroot
> package, specify a command with the -r option, or run this as root
> [..]
> 
> This seems to be related to the "sudo" use in the output above (or
> the funny output in the first line?), or
> 
>   * Improve the dsc+schroot preset to run builds as non-root.
> 
> in the changelog, or 62416ab in git.
> 
> After that, my python knowledge and domain knowledge ends; but
> unfortunately this means that reprotest 0.7.2 is unusable for me.
> 
Hi gregor, does it work if log into your "default" schroot and install the 
"fakeroot" package?

I am not sure why it is not installed there already - I have it installed in my 
unstable-amd64-sbuild chroot.

It would be easy enough to have reprotest install it automatically, but I'm not 
sure that's the best solution since another tool is already supposed to take 
care of that.

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

Bug#877813: reprotest: regression between 0.7.1 and 0.7.2

2017-10-05 Thread gregor herrmann 
Package: reprotest
Version: 0.7.2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

reprotest 0.7 and 0.7.1 work fine for me, 0.7.2 explodes horribly:

#v+
preset auto-selected: ReprotestPreset(build_command='\nif [ "$(id -u)" 
= 0 ]; then\nsudo -E -u "$LOGNAME" sh -ec \'dpkg-buildpackage 
--no-sign -b\';\nelse\nsh -ec \'dpkg-buildpackage --no-sign 
-b\';\nfi\n', artifact_pattern='../*.deb', testbed_pre=None, 
testbed_init='apt-get -y --no-install-recommends install disorderfs faketime 
locales-all sudo util-linux; test -c /dev/fuse || mknod -m 666 
/dev/fuse c 10 229; test -f /etc/mtab || ln -s ../proc/self/mounts 
/etc/mtab', testbed_build_pre='apt-get -y --no-install-recommends build-dep 
./"."', source_pattern=None, diffoscope_args=[])
STARTING VIRTUAL SERVER 
['/usr/lib/python3/dist-packages/reprotest/virt/autopkgtest-virt-schroot', 
'default']
reprotest [23:26:51]: version @version@
reprotest [23:26:51]: host jadzia; command line: /usr/bin/reprotest 
--variations=+all,-build_path,-user_group --verbosity 1 . -- schroot default
reprotest [23:26:52]: testbed package architecture: amd64
reprotest [23:26:52]: testbed running kernel: Linux 4.12.0-2-amd64 #1 SMP 
Debian 4.12.13-1 (2017-09-19)
Reading package lists...
Building dependency tree...
[..]
executing: if ( mv /tmp/autopkgtest.03NT2s/build-control/ 
/tmp/autopkgtest.03NT2s/const_build_path && umask 0022 && export 
REPROTEST_BUILD_PATH=/tmp/autopkgtest.03NT2s/const_build_path/ && export 
REPROTEST_UMASK=$(umask) && linux64 --uname-2.6 sh -ec 'cd 
"$REPROTEST_BUILD_PATH"; unset REPROTEST_BUILD_PATH; umask "$REPROTEST_UMASK"; 
unset REPROTEST_UMASK; 
if [ "$(id -u)" = 0 ]; then
sudo -E -u "$LOGNAME" sh -ec '"'"'dpkg-buildpackage --no-sign 
-b'"'"';
else
sh -ec '"'"'dpkg-buildpackage --no-sign -b'"'"';
fi
' ); then
( __c=0; mv /tmp/autopkgtest.03NT2s/const_build_path 
/tmp/autopkgtest.03NT2s/build-control/ || __c=$?; exit $__c; );
else
__x=$?;
if ( __c=0; mv /tmp/autopkgtest.03NT2s/const_build_path 
/tmp/autopkgtest.03NT2s/build-control/ || __c=$?; exit $__c; ); then exit $__x; 
else
echo >&2; "cleanup failed with exit code $?"; exit $__x;
fi;
fi

sudo: unable to resolve host jadzia
dpkg-buildpackage: error: fakeroot not found, either install the fakeroot
package, specify a command with the -r option, or run this as root
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 720, in run
return 0 if check_func(*check_args) else 1
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 332, in 
check
local_dists = [proc.send(nv) for nv in zip(bnames, build_variations)]
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 332, in 

local_dists = [proc.send(nv) for nv in zip(bnames, build_variations)]
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 298, in 
corun_builds
bctx.run_build(testbed, build, artifact_pattern, testbed_build_pre)
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 186, in 
run_build
kind='build')
  File "/usr/lib/python3/dist-packages/reprotest/__init__.py", line 61, in 
check_exec2
adtlog.AutopkgtestError)
  File "/usr/lib/python3/dist-packages/reprotest/lib/adt_testbed.py", line 370, 
in bomb
raise _type(m)
reprotest.lib.adtlog.AutopkgtestError: "sh -ec if ( mv 
/tmp/autopkgtest.03NT2s/build-control/ /tmp/autopkgtest.03NT2s/const_build_path 
&& umask 0022 && export 
REPROTEST_BUILD_PATH=/tmp/autopkgtest.03NT2s/const_build_path/ && export 
REPROTEST_UMASK=$(umask) && linux64 --uname-2.6 sh -ec 'cd 
"$REPROTEST_BUILD_PATH"; unset REPROTEST_BUILD_PATH; umask "$REPROTEST_UMASK"; 
unset REPROTEST_UMASK; 
if [ "$(id -u)" = 0 ]; then
sudo -E -u "$LOGNAME" sh -ec '"'"'dpkg-buildpackage --no-sign 
-b'"'"';
else
sh -ec '"'"'dpkg-buildpackage --no-sign -b'"'"';
fi
' ); then
( __c=0; mv /tmp/autopkgtest.03NT2s/const_build_path 
/tmp/autopkgtest.03NT2s/build-control/ || __c=$?; exit $__c; );
else
__x=$?;
if ( __c=0; mv /tmp/autopkgtest.03NT2s/const_build_path 
/tmp/autopkgtest.03NT2s/build-control/ || __c=$?; exit $__c; ); then exit $__x; 
else
echo >&2; "cleanup failed with exit code $?"; exit $__x;
fi;
fi
" failed with status 2
#v-

This seems to be related to the "sudo" use in the output above (or
the funny output in the first line?), or

  * Improve the dsc+schroot preset to run builds as non-root.

in the changelog, or 62416ab in git.

After that, my python knowledge and domain knowledge ends; but
unfortunately this means that reprotest 0.7.2 is unusable for me.

I'm happy to provide any further information or do any tests.


Cheers,
gregor


- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500,

Bug#877418: dh-strip-nondeterminism: kills clojure performance

2017-10-05 Thread Daniel Kahn Gillmor 
On Thu 2017-10-05 10:56:46 +0100, Chris Lamb wrote:
> I'd also be curious to know why you think *more* than one second could
> ever be needed here. I think I'm mising something.

some filesystems have a resolution > 1s :(

  http://www.ntfs.com/exfat-comparison.htm

shows that FAT32 has a 2s granularity when used without extensions.
Looks like the Linux kernel remembers a 1sec granularity while still
mounted, but shows just the 2sec granularity across remounts:


   mkfs -t vfat $blkdev
   mount $blkdev /mnt
   for a in 1 2 3; do
  touch /mnt/$a
  sleep 1
   done
   stat /mnt/* | grep Modify
   umount /mnt
   mount $blkdev /mnt
   stat /mnt/* | grep Modify
   umount /mnt


produces two batches of mtime stats:

Modify: 2017-10-05 12:56:14.0 -0700
Modify: 2017-10-05 12:56:15.0 -0700
Modify: 2017-10-05 12:56:16.0 -0700

Modify: 2017-10-05 12:56:14.0 -0700
Modify: 2017-10-05 12:56:14.0 -0700
Modify: 2017-10-05 12:56:16.0 -0700



  --dkg

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#877418: dh-strip-nondeterminism: kills clojure performance

2017-10-05 Thread Daniel Kahn Gillmor 
On Wed 2017-10-04 19:45:49 +0100, Chris Lamb wrote:
> *Very* quick thoughts here: could some variant of a) be merged
> upstream…? Perhaps upstream could move to a hash-based system instead
> of using timestamps? eg. encoding the SHA1 of the file in the filename.

I'm thinking about this problem more generally than clojure
specifically -- other folks have raised python's .py → .pyc mappings and
i'm sure there are other similar frameworks.  I want to make sure we're
thinking about the various places that these checks happen.

It may also matter whether we're talking about file stored in an archive
vs. one stored in the filesystem.  different archive formats and
different filesystems have different timestamp granularity (iirc, FAT
has 2s granularity, for example).

And there are more questions too: what if multiple source files
contributed to the creation of the compiled artifact (e.g. "include"
directives)?

You can also imagine a compilation regime that detects changes to a file
(e.g. via inotify) and immediately triggers recompilation -- with a fast
compiler and a coarse filesystem/archive timestamp, such a regime would
end up in the same situation (serious performance impact).

And of course, it's always possible to (accidentally or intentionally)
just "touch" the timestamps on a totally different bytecode file of the
appropriate name to trick or confuse this optimization step.

There are also problems with the digest based approach that lamby
suggests: it's significantly more expensive to do a full source
extraction and digest than it is to compare timestamp metadata.

--

So i think we have to ask what the goal of this check is from the upstream
platform's point of view:

 * is it strong assurance that the file was built from the
   exposed source?

 * is it a speedy (if fallible) sanity check?

i think that it can't really be the former (because of all the corner
cases outlined above), so the question is what kind of failure modes and
risks they're willing to tolerate.  Those that want absolute assurance
will be obliged to recompile each time unless they have some sort of
externally-audited mapping/manifest.

It sounds to me like python has made a sensible tradeoff (accepting that
equal timestamps means OK) and clojure has made a decision that tries to
get more of a guarantee than they can actually get, and sacrificed
performance for it.

--dkg

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#877418: dh-strip-nondeterminism: kills clojure performance

2017-10-05 Thread Rob Browning 
Chris Lamb  writes:

> I don't quite get what you mean I'm afraid. Filesystem ordering (at least
> via readdir/listdir, etc.) is non-deterministic. Can you explain it to me
> another way?

(...or quite likely I'm not describing things all that well.)

In Clojure's case, I'd think that setting the .clj mtime to at least 1s
before the corresponding .class file in the jar should work fine, though
if Clojure's only consulting the jar, then any other offset that
registers as smaller should also work, i.e. it might not have to be a
full second inside jars.

But sticking with at least 1s should make things a bit more general
because then if you

  jar xf foo.jar

the resulting tree will still show the right relative offsets on common
filesystems (assuming "jar x" tries to preserve mtimes) so that any
tool, clojure, some clojure build tool, etc. will still work as expected
with the tree.


...then I started thinking more generally and wondered if (eventually)
we might be able to do something even more broadly helpful.

If we were to take any archive we're rewriting (tar, jar, cpio), and
sort all the files by decreasing mtime, then assign the set of files
with the largest mtime to have some mtime_0, assign the set of files
with the second largest mtime to have (mtime_0 - 1s), the third set to
(mtime_0 - 2s), etc., we'd preserve the overall ordering among the
files so that something like:

   tar xf some-reproducible-archive.tgz
   cd some-reproducible-archive
   make

would stand a good chance of just working as it would have with the
original archive.

> I'd also be curious to know why you think *more* than one second could
> ever be needed here. I think I'm mising something.

I suspect 1s is just fine, and I have nothing concrete in mind here --
it just made me think of the general floating point issues (if any end
up involved in the path), e.g. 4.000...1 vs 4 vs 3.999... vs
rounding/truncation to the final value, etc.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Bug#877418: dh-strip-nondeterminism: kills clojure performance

2017-10-05 Thread Chris Lamb 
Hi Rob,

> Or rather, if Clojure's only looking at the timestamps in the jar file,
> then those may have a known (fixed) resolution, and so we'd just need to
> make sure that the .clj files are at least that much older than the
> corresponding .class files inside the jar.

Right; that's:

> >  b) We make strip-nondetermism subtract 1 second from the .clj files'
> > target modification times so it matches with the existing ">".

.. is it not? :)

> Though I'd probably still pick 1s or more just so that an unpacked jar
> will still have the right timestamp ordering on the vast majority of
> filesystems.

I don't quite get what you mean I'm afraid. Filesystem ordering (at least
via readdir/listdir, etc.) is non-deterministic. Can you explain it to me
another way? I'd also be curious to know why you think *more* than one
second could ever be needed here. I think I'm mising something.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Re: Next Reproducible Builds IRC meeting: Thursday October 5th @ 18h00 UTC

2017-10-05 Thread Chris Lamb 
Hi all,

> The next IRC meeting will be on Thursday October 5th. I have randomly
> chosen 18h00 UTC for this meeting:
> 
>https://time.is/compare/1800_5_October_2017_UTC
> 
>$ date -d 'Thu Oct 5 18:00:00 UTC 2017'

Apologies for the short notice but due to a family quasi-emergency I
will no longer be able to commit to chair today's meeting.

I may be able to attend/chair after all, I just can't guarantee it and
thus if someone could step up it would a) remove a burden from my mind
and b) ensure that someone can chair after all.

(This is, I guess, also an implicit reminder about today's meeting;
apologies for not sending one earlier...)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Намаление на всички Секси и Еротични Корсети, Разкриващи Комплекти и на всички продукти на Casmir и Passion

2017-10-05 Thread NEUSTOIMA.bg - Еротично Бельо и Дрехи 







www.NEUSTOIMA.bg - Онлайн магазин за Сeкcи
и Еротично бельо и дрехи за
показване.Тази седмица за всички поръчки
направени до 10.10.2017 (Вторник) включително
Ви предлагаме 15% намаление на всички
продукти на марките Passion и CasmirСъщо така само до 10.10.2017
(Вторник) включително Ви предлагаме и 15%
намаление на всички модели Секси и Еротични
корсети и Секси и разкриващи
комплект!Побързайте
количествата са ограничени.Предлагаме Ви и 20% отстъпка
на всички Налични модели Фетиш бельо
и дрехи валидна за всички поръчки
направени до 10.10.2017 (Вторник)
включително.
Ние като ценители на
женската красота и на красивото и
луксозно Еротично бельо и дрехи Ви
предлагаме над 1500 различни модела на
изключително ниски цени, които ще
удовлетворят всеки вкус и всяка
фантазия. Ние ви предлагаме от всичко по
много:При нас ще
намерите огромно разнообразие различни
модела Луксозно Еротично бельо и Секси
дрехи на изключително ниски цени които
ще удовлетворят всеки вкус
и фантазия: Секси Прашки
и бразилиани, Секси Корсети
и Бюстиета, Еротични Бодита,
Целокупни
бодита, Еротични Нощници и
Рокли, Комплекти нощници с
халат, Секси и Еротични
Костюми, Секси и Разкриващи
Комплекти , и др. 
А за
любителите на по-нестандартните
изживявания ви предлагаме стотици
модели Фетиш
бельо и Дрехи  от PVC Винил,
Латекс, Датекс, кожа и др. на
най-големите производители: Ledapol и Anita Berg Разгледайте и
нашите налични модели на склад Фетиш
бельо и Дрехи!Всички наши продукти са
в оригинални луксозни опаковки на
производителя, подходящи за подарък.
Изработени са от висококачествени
платове, сатен и дантела. Производени в
Европа и изработени по Европейските
стандарти и с Европейско
качество.
Почти
всички наши продукти са налични със
срок за доставка до 1-2 работни
дни! 
Побързайте количествата са
ограничени!  www.NEUSTOIMA.bg - Секси бельо и
дрехи за показване!





   
  Съгласно Закона за
Електронната Търговия Ви информираме, че
това може да е непоискано търговско
съобщение. Вие може да го приемете или
отхвърлите. Ние може да сме
получили вашия имейл от Вас, от Ваш
партньор или от публичното
пространство.  Ако не
желаете да получавате повече информация
от "Neustoima.bg", моля ОТПИШЕТЕ
СЕ ОТ ТУКи ще
преустановим изпращането на търговски
съобщения към Вашият имейл адрес.Ако сме Ви обезпокоили, моля да ни
извините! 





___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds