Re: [Reproducible-builds] Repro Build report I do not understand

2015-11-06 Thread Jérémy Bobbio 
Dirk Eddelbuettel:
> One of my packages which still didn't build reproduciby is littler -- for
> which I am upstream. I rewrote the build process, and even though it produces
> a small binary (which embeds R for use in #! scripts etc) it now ships as an
> R package on CRAN.  Which all build reproducibly.
> 
> Yet I have this:
>https://reproducible.debian.net/rb-pkg/unstable/amd64/littler.html
> 
> And I don't understand the 'dbgsym' part.  What turns that on? How can I turn
> it off?

You might want to read the latest status update to learn about them:
https://lists.debian.org/debian-devel/2015/08/msg00443.html

But they are not the source of reproducibility, just a symptom.

From the quick look I had, it seems symbols are sorted in a different
order depending on the locale:
https://reproducible.debian.net/dbd/unstable/amd64/littler_0.3.0-2.debbindiff.html#r-cran-littler_0.3.0-2_amd64.deb/data.tar.xz/data.tar/./usr/bin/r/objdump%20--disassemble%20--full-contents%20{}
(It's my guess because both are sorted by the second build has lowercase
'a' grouped together with uppercase 'A'.)

The symbols match the ones in
https://sources.debian.net/src/r-base/3.2.2-1/src/library/datasets/data/

Hope that helps,
-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


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] Repro Build report I do not understand

2015-11-06 Thread Dirk Eddelbuettel 

On 6 November 2015 at 23:44, Jérémy Bobbio wrote:
| Dirk Eddelbuettel:
| > One of my packages which still didn't build reproduciby is littler -- for
| > which I am upstream. I rewrote the build process, and even though it 
produces
| > a small binary (which embeds R for use in #! scripts etc) it now ships as an
| > R package on CRAN.  Which all build reproducibly.
| > 
| > Yet I have this:
| >https://reproducible.debian.net/rb-pkg/unstable/amd64/littler.html
| > 
| > And I don't understand the 'dbgsym' part.  What turns that on? How can I 
turn
| > it off?
| 
| You might want to read the latest status update to learn about them:
| https://lists.debian.org/debian-devel/2015/08/msg00443.html
| 
| But they are not the source of reproducibility, just a symptom.
| 
| From the quick look I had, it seems symbols are sorted in a different
| order depending on the locale:
| 
https://reproducible.debian.net/dbd/unstable/amd64/littler_0.3.0-2.debbindiff.html#r-cran-littler_0.3.0-2_amd64.deb/data.tar.xz/data.tar/./usr/bin/r/objdump%20--disassemble%20--full-contents%20{}
| (It's my guess because both are sorted by the second build has lowercase
| 'a' grouped together with uppercase 'A'.)
| 
| The symbols match the ones in
| https://sources.debian.net/src/r-base/3.2.2-1/src/library/datasets/data/
| 
| Hope that helps,

That is very good too.  Should I ensure a locale during the build?  Any other
heavy hand?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Reproducible-builds] Repro Build report I do not understand

2015-11-06 Thread Dirk Eddelbuettel 

On 6 November 2015 at 23:35, Vincent Bernat wrote:
|  ❦  6 novembre 2015 14:03 -0600, Dirk Eddelbuettel  :
| 
| > One of my packages which still didn't build reproduciby is littler -- for
| > which I am upstream. I rewrote the build process, and even though it 
produces
| > a small binary (which embeds R for use in #! scripts etc) it now ships as an
| > R package on CRAN.  Which all build reproducibly.
| >
| > Yet I have this:
| >https://reproducible.debian.net/rb-pkg/unstable/amd64/littler.html
| >
| > And I don't understand the 'dbgsym' part.  What turns that on? How can I 
turn
| > it off?
| 
| See man dh_strip. However, the correct action would be to find why there
| is a difference in the debug symbols. The difference seems to stem from

I was thinking that too but didn't test.  As an R package, it installs into a
'tree' below /usr/lib/R/site-library/$PACKAGE but I also copy the resulting
binary to /usr/bin/r. I think I need to strip that.

Will the weird dbgsym then be gone?

| the way some strings are sorted (see the end of the differences). They
| come from the r-base package. I don't know why they are embedded into
| debug symbols.

Right.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [Reproducible-builds] Repro Build report I do not understand

2015-11-06 Thread Jérémy Bobbio 
Dirk Eddelbuettel:
> | From the quick look I had, it seems symbols are sorted in a different
> | order depending on the locale:
> | 
> https://reproducible.debian.net/dbd/unstable/amd64/littler_0.3.0-2.debbindiff.html#r-cran-littler_0.3.0-2_amd64.deb/data.tar.xz/data.tar/./usr/bin/r/objdump%20--disassemble%20--full-contents%20{}
> | (It's my guess because both are sorted by the second build has lowercase
> | 'a' grouped together with uppercase 'A'.)
> | 
> | The symbols match the ones in
> | https://sources.debian.net/src/r-base/3.2.2-1/src/library/datasets/data/
> | 
> | Hope that helps,
> 
> That is very good too.  Should I ensure a locale during the build?  Any other
> heavy hand?

You can try to set LC_ALL (or set LC_COLLATE and unset LC_ALL). But you
might want to identify where the sorting happens first.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


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

[Reproducible-builds] Bug#804220: libmath-bigint-gmp-perl: FTBFS: t/bigintpm.t (Wstat: 256 Tests: 3707 Failed: 1)

2015-11-06 Thread Chris Lamb 
Source: libmath-bigint-gmp-perl
Version: 1.43-1
Severity: serious
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Dear Maintainer,

libmath-bigint-gmp-perl fails to build from source in unstable/amd64:

  [..]

  Test Summary Report
  ---
  t/bigintpm.t (Wstat: 256 Tests: 3707 Failed: 1)
Failed test:  791
Non-zero exit status: 1
  Files=11, Tests=6535,  5 wallclock secs ( 0.82 usr  0.05 sys +  4.06
  cusr  0.22 csys =  5.15 CPU)
  Result: FAIL
  Failed 1/11 test programs. 1/6535 subtests failed.
  Makefile:984: recipe for target 'test_dynamic' failed
  make[1]: *** [test_dynamic] Error 255
  make[1]: Leaving directory '/build/libmath-bigint-gmp-perl-1.43'
  dh_auto_test: make -j1 test TEST_VERBOSE=1 returned exit code 2
  debian/rules:4: recipe for target 'binary' failed
  make: *** [binary] Error 2
  dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
  status 2

  [..]

The full build log is attached or can be viewed here:


https://reproducible.debian.net/logs/unstable/amd64/libmath-bigint-gmp-perl_1.43-1.build1.log.gz


Regards,

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


libmath-bigint-gmp-perl.1.43-1.unstable.amd64.log.txt.gz
Description: application/gzip
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Bug#804249: python-setuptools: please make the generated requires.txt files reproducible

2015-11-06 Thread Chris Lamb 
Source: python-setuptools
Version: 18.4-2
Severity: wishlist
Tags: patch
User: reproducible-builds@lists.alioth.debian.org
Usertags: timestamps toolchain
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Hi,

Whilst working on the "reproducible builds" effort [0], we noticed that
python-setuptools generates non-deterministic output when creating
requires.txt files:

│   │   │   │  [all]
│   │   │   │ -fake-factory==0.5.2
│   │   │   │ -pytz
│   │   │   │  numpy>=1.9.0
│   │   │   │  pytz
│   │   │   │ +pytz
│   │   │   │  django>=1.7
│   │   │   │ +fake-factory==0.5.2

Patch attached.

 [0] https://wiki.debian.org/ReproducibleBuilds


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/setuptools/command/egg_info.py b/setuptools/command/egg_info.py
index 50f3d5c..7c8ea53 100755
--- a/setuptools/command/egg_info.py
+++ b/setuptools/command/egg_info.py
@@ -406,7 +406,7 @@ def warn_depends_obsolete(cmd, basename, filename):
 def _write_requirements(stream, reqs):
 lines = yield_lines(reqs or ())
 append_cr = lambda line: line + '\n'
-lines = map(append_cr, lines)
+lines = map(append_cr, sorted(lines))
 stream.writelines(lines)
 
 
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Bug#804222: harvid: FTBFS: *** No rule to make target '../libharvid/libharvid.a', needed by 'harvid'. Stop.

2015-11-06 Thread Chris Lamb 
Source: harvid
Version: 0.8.0-3
Severity: serious
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Dear Maintainer,

harvid fails to build from source in unstable/amd64:

  [..]

  cc -c -o timecode.o -g -O2 -fstack-protector-strong -Wformat
  -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2`pkg-config
  --cflags libavcodec libavformat libavutil libswscale` timecode.c
  export PKG_CONFIG_PATH=;\
  cc -c -o vinfo.o -g -O2 -fstack-protector-strong -Wformat
  -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2`pkg-config
  --cflags libavcodec libavformat libavutil libswscale` vinfo.c
  make[3]: *** No rule to make target '../libharvid/libharvid.a', needed
  by 'harvid'.  Stop.
  make[3]: Leaving directory '/build/harvid-0.8.0/src'
  Makefile:7: recipe for target 'src' failed
  make[2]: *** [src] Error 2
  make[2]: *** Waiting for unfinished jobs
  ar cru libharvid.a decoder_ctrl.o ffdecoder.o frame_cache.o
  image_cache.o timecode.o vinfo.o
  ar: `u' modifier ignored since `D' is the default (see `U')
  ranlib libharvid.a
  make[3]: Leaving directory '/build/harvid-0.8.0/libharvid'
  make[2]: Leaving directory '/build/harvid-0.8.0'
  dh_auto_build: make -j17 CFLAGS=-g -O2 -fstack-protector-strong
  -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
  LDFLAGS=-Wl,-z,relro -Wl,--as-needed VERSION=0.8.0 returned exit code
  2
  debian/rules:9: recipe for target 'override_dh_auto_build' failed
  make[1]: *** [override_dh_auto_build] Error 2
  make[1]: Leaving directory '/build/harvid-0.8.0'
  debian/rules:6: recipe for target 'build' failed
  make: *** [build] Error 2
  dpkg-buildpackage: error: debian/rules build gave error exit status 2

  [..]

The full build log is attached or can be viewed here:


https://reproducible.debian.net/logs/unstable/amd64/harvid_0.8.0-3.build1.log.gz


Regards,

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


harvid.0.8.0-3.unstable.amd64.log.txt.gz
Description: application/gzip
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Bug#804224: ruby-virtus: FTBFS: each_spec.rb:58 # Virtus::AttributeSet#each with a block when the parent has attributes that are duplicates yields the expected attributes

2015-11-06 Thread Chris Lamb 
Source: ruby-virtus
Version: 1.0.5-1
Severity: serious
Justification: fails to build from source
User: reproducible-builds@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org

Dear Maintainer,

ruby-virtus fails to build from source in unstable/amd64:

  [..]
  
  Finished in 1.23 seconds (files took 0.73448 seconds to load)
  459 examples, 16 failures, 2 pending
  
  Failed examples:
  
  rspec ./spec/unit/virtus/attribute_set/each_spec.rb:58 #
  Virtus::AttributeSet#each with a block when the parent has attributes
  that are duplicates yields the expected attributes
  rspec ./spec/unit/virtus/attribute_set/each_spec.rb:30 #
  Virtus::AttributeSet#each with a block when the parent has no
  attributes yields the expected attributes
  rspec ./spec/unit/virtus/attribute_set/merge_spec.rb:28 #
  Virtus::AttributeSet#merge with a duplicate attribute replaces the
  original attribute
  rspec ./spec/unit/virtus/attribute_set/merge_spec.rb:17 #
  Virtus::AttributeSet#merge with a new attribute adds an attribute
  rspec ./spec/unit/virtus/attribute_set/element_set_spec.rb:16 #
  Virtus::AttributeSet#[]= with a new attribute adds an attribute
  rspec ./spec/unit/virtus/attribute_set/element_set_spec.rb:28 #
  Virtus::AttributeSet#[]= with a new attribute allows #reset to track
  overridden attributes
  rspec ./spec/unit/virtus/attribute_set/element_set_spec.rb:20 #
  Virtus::AttributeSet#[]= with a new attribute allows #[] to access the
  attribute with a symbol
  rspec ./spec/unit/virtus/attribute_set/element_set_spec.rb:24 #
  Virtus::AttributeSet#[]= with a new attribute allows #[] to access the
  attribute with a string
  rspec ./spec/unit/virtus/attribute_set/element_set_spec.rb:44 #
  Virtus::AttributeSet#[]= with a duplicate attribute allows #[] to
  access the attribute with a symbol
  rspec ./spec/unit/virtus/attribute_set/element_set_spec.rb:40 #
  Virtus::AttributeSet#[]= with a duplicate attribute replaces the
  original attribute
  rspec ./spec/unit/virtus/attribute_set/element_set_spec.rb:48 #
  Virtus::AttributeSet#[]= with a duplicate attribute allows #[] to
  access the attribute with a string
  rspec ./spec/unit/virtus/attribute_set/element_set_spec.rb:52 #
  Virtus::AttributeSet#[]= with a duplicate attribute allows #reset to
  track overridden attributes
  rspec ./spec/unit/virtus/attribute_set/append_spec.rb:22 #
  Virtus::AttributeSet#<< with a new attribute indexes the new attribute
  under its #name property
  rspec ./spec/unit/virtus/attribute_set/append_spec.rb:28 #
  Virtus::AttributeSet#<< with a new attribute indexes the new attribute
  under the string version of its #name property
  rspec ./spec/unit/virtus/attribute_set/append_spec.rb:16 #
  Virtus::AttributeSet#<< with a new attribute adds an attribute
  rspec ./spec/unit/virtus/attribute_set/append_spec.rb:41 #
  Virtus::AttributeSet#<< with a duplicate attribute replaces the
  original attribute
  
  Randomized with seed 2982
  
  /usr/bin/ruby2.1 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb
  --format documentation failed
  ERROR: Test "ruby2.1" failed. Exiting.
  dh_auto_install: dh_ruby --install
  /build/ruby-virtus-1.0.5/debian/ruby-virtus returned exit code 1
  debian/rules:15: recipe for target 'binary' failed
  make: *** [binary] Error 1
  dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
  status 2

  [..]

The full build log is attached or can be viewed here:


https://reproducible.debian.net/logs/unstable/amd64/ruby-virtus_1.0.5-1.build1.log.gz


Regards,

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


ruby-virtus.1.0.5-1.unstable.amd64.log.txt.gz
Description: application/gzip
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

[Reproducible-builds] Deadline Approaching for 6th IEEE International Advance Computing Conference (IACC- 2016), BHIMVARAM, A.P., INDIA.

2015-11-06 Thread IACC 2016 
 

6th IEEE International Advance Computing Conference (IACC - 2016)

27-28 February 2016, S R K R Engineering College, Bhimavaram, Andhra
Pradesh, India

Dear Researchers,

 

Greetings!

 

Hope you are aware of that 6th IEEE International Advance Computing
Conference (IACC- 2016), will be held during February 27-28, 2016 organized
jointly by IEEE Computer Society-India Council and S R K R Engineering
College,  Bhimavaram, Andhra Pradesh, India. 

 

For a detailed list of topics please visit the conference website
 http://www.iacc2016.com/

 

The Last date for submitting the papers is approaching i.e. 30th Nov 2015. 

 

Accepted and presented papers will be published in IEEE Xplore.  

 

The ISBN number of IEEE Xplore for IACC 2016 is 978-1-4673-8285-4.  

 

Important Dates:

 


Last Date to Submit the Paper

30 November 2015


Notification of Review Outcomes

31 January 2016


Submission of Camera Ready Papers

15 February 2016


Author Registration Deadline

15 February 2016


Conference Dates

27-28 February 2016

 

Looking forward to your participation,

Dr. M.S.V.S. Bhadri Raju,

General Co-Chair, IACC 2016

Professor in CSE
SRKR Engineering College

BHIMAVARM - 534204

Andhra Pradesh, India

 

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

Re: [Reproducible-builds] binNMU detection for generating Changes field in buildinfo (was: Re: binNMU or reproducible builds (choose only one))

2015-11-06 Thread Jérémy Bobbio 
Johannes Schauer:
> Lunar:
> > Simon McVittie:
> > > BinNMUs don't upload any source at all. They instruct the autobuilders
> > > to run sbuild with some non-default options ("sbuild --binNMU=2
> > > --make-binNMU "Rebuild with foo 3" foo_1.2-3" will result in
> > > foo_1.2-3+b2_i386.changes, I think), and sbuild on each autobuilder
> > > downloads the foo_1.2-3.dsc that already exists in the archive.
> > > 
> > > The only inherent conflict that I can see between binNMUs and
> > > reproducible builds is that all attempts to reproduce the original build
> > > need to prepend the same changelog entry as the original build, for
> > > example by copying them from the build info that will already be
> > > necessary to be able to use the same build-dependency versions.
> > 
> > This is already taken in account in the current `.buildinfo`
> > specification [1]:
> > 
> > Changes
> > 
> > Close to the one in `*.changes`. When source and binary versions
> > differ, the field is added with the content of the extra changelog
> > entries.
> > 
> > The field is already created by the experimental `dpkg-genbuildinfo` [2].
> > It is not yet implement in the `srebuild` script but it shouldn't be too
> > hard.
> > 
> >  [1]: 
> > https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification#buildinfo_field_descriptions
> >  [2]: 
> > https://anonscm.debian.org/cgit/reproducible/dpkg.git/tree/scripts/dpkg-genbuildinfo.pl?h=pu/reproducible_builds=c4665b80d7a042216145652ea3d1259b78ac6237#n246
> 
> I don't think this is the right way to do it. Looking at the dpkg-genbuildinfo
> script, it seems that this behaviour is triggered whenever the source version
> differs from the binary version. But binNMUs are not the only case for which
> the source and binary versions differ. To convince yourself you can run the
> following (get all packages that are not binNMUs (detected by them having a bX
> at the end of their version) and which have a versioned Source field):
> 
> grep-dctrl --not --field Version --eregex '\+b[0-9]+$' --and \
>   -F Source --eregex '\(' \
>   
> /var/lib/apt/lists/http.debian.net_debian_dists_sid_main_binary-amd64_Packages
>  \
>   -n -s Package,Source,Version
> 
> It shows that there are several binary packages that have a different source
> package version even though they are not binNMUs. The version of any binary
> package can be done during the build with dh_gencontrol or directly via
> `dpkg-gencontrol -v$version`.

Thanks for the explaination.

> The right way to find out whether a binNMU is done is to check
> $changelog->{'Binary-Only'} as it is done in dpkg-genchanges. During a binNMU,
> sbuild sets binary-only=yes in the top changelog entry.

I've changed the `if` to use $changelog->{'Binary-Only'}, but it was
already working as intended. The code read as follow:

my $sourceversion = $changelog->{'Binary-Only'} ?
$prev_changelog->{'Version'} : $changelog->{'Version'};
my $binaryversion = $changelog->{'Version'};
[…]
if ($binaryversion ne $sourceversion) { # handle binNMU

> In fact, what you call $binaryversion in that script is really the source
> version because your $binaryversion comes from d/changelog. So maybe you want
> to rename that variable. That also then remove the ambiguity from a later part
> in the code when you set the Version field in the buildinfo to $binaryversion.
> This is ambiguous because a source package can build binary packages of 
> several
> different versions.

The naming is coming straight from dpkg-genchanges, so both should be
changed if you fill they are ill-named.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


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

[Reproducible-builds] Repro Build report I do not understand

2015-11-06 Thread Dirk Eddelbuettel 

Howdy,

One of my packages which still didn't build reproduciby is littler -- for
which I am upstream. I rewrote the build process, and even though it produces
a small binary (which embeds R for use in #! scripts etc) it now ships as an
R package on CRAN.  Which all build reproducibly.

Yet I have this:
   https://reproducible.debian.net/rb-pkg/unstable/amd64/littler.html

And I don't understand the 'dbgsym' part.  What turns that on? How can I turn
it off?

Help much was appreciated,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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