Re: Bug#836732: strip-nd: FTBFS when locale is not English
Chris Lamb: > tag 836732 + pending > thanks > >> Not sure how much related they are, but I guess it means something given >> that it's not in the English build. > > I don't really understand why that would be causing an error but we follow > your assumption that the "return" that is causing the FTBFS, then it was > removed and thus fixed in Git already: I think this has nothing to do with locale. The problem is that dash and bash are treating 'return' differently. $ bash -c 'true; return $?' && echo ok bash: line 0: return: can only `return' from a function or sourced script $ dash -c 'true; return $?' && echo ok ok $ So depending on what is used as /bin/sh the build fails or not. > > https://anonscm.debian.org/git/reproducible/strip-nondeterminism.git/commit/?id=72d70fcd7a088ca0f97d4a9f67e2e42c0c1505ff If it's not needed at all that's nice. Else you could replace 'return' with 'exit'. signature.asc Description: OpenPGP digital signature ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
reproducible.debian.net status changes for strip-nondeterminism
2016-09-05 03:18 https://tests.reproducible-builds.org/debian/unstable/amd64/strip-nondeterminism changed from reproducible -> FTBFS ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: [Reproducible-builds] Minimising work needed for this build-path issue
Ximin Luo:
> HW42:
>> Ximin Luo:
>>> [..]
>>>
>>> 1. Patch GCC to set debug-prefix-map to "$pwd=." by default (and the
>>> analogue for other languages / tools).
>>>
>>> This behaviour is concretely different from the current situation:
>>> during recursive-make scenarios, the gcc in subdirectories will have
>>> different values for debug-prefix-map. Our current situtation OTOH is
>>> that dpkg-buildflags is called once at the top-level directory, and
>>> this value persists for all gcc subchildren for the whole build
>>> (unless the upstream buildscripts do something weird to CFLAGS).
>>>
>>> If the behaviour were not different, I would strongly suggest "let's
>>> just do this". But it's different, and I'm not sure what consequences
>>> that would have. I'm looking for your comments on this.
>>
>> I think this breaks the mapping to the source file, for example in gdb.
>> So I think this is not a good solution.
>>
>
> Yeah, this is what I was worried about, but my background knowledge
> here isn't good enough to be sure. Do you know where I could read up
> on how this all works?
Sorry I have currently no link handy. But the process for C is not very
complex:
When loading a file gdb tries to load the debug symbols from the binary
itself or else from a well known location (/usr/lib/debug/.build-id/...)
Without them gdb can't resolve symbols. (Output shortened)
$ gdb apt
Reading symbols from apt...(no debugging symbols found)...done.
(gdb) p main
No symbol table is loaded. Use the "file" command.
After installing the debug symbols gdb will load the debug symbols and
can resolve symbols. The debug symbols contain a reference (file path
and line number) to the source. When printing the source gdb search for
this file based on the working directory (and those passed by
--directory). So without installed soure it prints an error message.
$ sudo apt-get install apt-dbgsym
$ gdb apt
Reading symbols from apt...Reading symbols from
/usr/lib/debug/.build-id/63/7ee005a89714dd26a13f950028c6febd13c28f.debug...done.
done.
(gdb) p main
$1 = {int (int, const char **)} 0x1680
(gdb) l main
94 ./cmdline/apt.cc: Datei oder Verzeichnis nicht gefunden.
When you now put the source (or at least some text file ;P) in the right
path, gdb will print it for you.
$ apt-get source apt && cd apt-*/
$ gdb apt
(gdb) l main
96 }
97
/*}}}*/
98 int main(int argc, const char *argv[])
/*{{{*/
99 {
100CommandLine CmdL;
101auto const Cmds = ParseCommandLine(CmdL, APT_CMD::APT, &_config,
&_system, argc, argv, , );
>>> Note that for languages that define "the path is the namespace" like
>>> golang or java, this does not really matter. So in these cases I
>>> strongly suggest patching the tool itself, instead of adding extra
>>> command-line flags.
>>
>> Could you clarify what you mean? I don't think the namespace and the
>> path are the same in golang or in Java (sure, the namespace is the
>> suffix of the path but including java.nio.file.Path into the binary
>> doesn't break any of our assumptions).
>>
>
> What I meant more specifically is that, either there is only one
> source root (GOPATH) or different source roots are not generally
> expected to be children of each other (in the directory tree of a
> source repo written in that language). For example one never sees a
> Java project with src/com/google and src/com/google/org/apache, but
> it's fairly common to see C/C++ projects with src/a/*.c treating src/a
> as the include-root, but with src/a/1/*.c treating src/a/1 as the
> include-root, yet with src/a/2/*.c treating src/a as the include-root.
>
> With the former, it's fairly easy for a debugger to see that src/ is
> the source root. And I'm guessing the latter case is what would mess
> with gdb's source-file mappings if we went with (1). But it would be
> good to have someone explain this in more detail.
Ah I now get your point. Yes for those cases we don't need an extra
SOURCE_ROOT (or w/e). In go $GOPATH/src and in java -sourcepath, etc.
can be used as base for source paths.
signature.asc
Description: OpenPGP 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] Minimising work needed for this build-path issue
Ximin Luo: > However the question is, do we want to do this every time an upstream > saves CFLAGS somewhere? [...] > 2. Define another variable SOURCE_ROOT to be set to the top-level > source dir, and patch GCC to use this as the default value for > debug-prefix-map (and the analogue for other languages / tools). > > This would have the same concrete behaviour as the current situation, > but then we're defining yet another variable... but probably less > tools will need to support this than SOURCE_DATE_EPOCH. And as with > (1), this would not be necessary for the path-is-namespace languages. This is to some extend already possible with with gcc (Thanks to guillem for the idea). Add '-specs /usr/.../rb.spec' to CFLAGS and then set inside the specs file debug-prefix-map based on an env var: *cc1_options: + -fdebug-prefix-map=%:getenv(SOURCE_ROOT =.) Unfortunately this is not that easy. The getenv function fails hard if the env var is not set. And since the build environment for Debian packages is mostly unconstrained there seems to be no way to guarantee that this variable is always set. signature.asc Description: OpenPGP 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] [Reproducible-builds] More lazy-loading for diffoscope html output
> Do you have a concrete suggestion? Otherwise I will just turn the > background light pink, #f99. Something like that, although I'm not quite a fan of pink… I would definitely increase the padding and — to use a UI/UX term — to increase the affordance that they are something that may be clicked, I would be tempted to experiment with styling these somewhat à la rather than à la . This is because the latter subconciously suggests that the browser will navigate "away", rather than expand inline. 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: [diffoscope] [Reproducible-builds] More lazy-loading for diffoscope html output
Chris Lamb: > Hi Ximin, > >> https://people.debian.org/~infinity0/res/dfs-demo/index.html > > One quick bit of feedback is that the: > >" ... load diff (3 pieces, truncated) ... " > > links aren't always immediately obvious to my eyes/colour scheme. > > Indeed, I am sure I found find myself wondering where the rest of > differences were. I'm sure some judicial CSS styling would solve this. > Do you have a concrete suggestion? Otherwise I will just turn the background light pink, #f99. 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#836786: diffoscope: Differences between long lines are missing in HTML format
Source: diffoscope Severity: normal Dear Maintainer, The packages "python-hypothesis" & "cppformat" & "python-xmp-toolkit" & "python-mne" from unstable/amd64 have long line that contain JavaScript code, the HTML format don't contain the differences between the lines (it cut the line by scissors symbol instead) searchindex.js: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/python-hypothesis.html https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/cppformat.html https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/python-xmp-toolkit.html bootstrap.min.js: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/python-mne.html Suggestion for fixes: 1. The above examples are minified JavaScript code, thus it's possible to use JavaScript beautifier on JavaScript files (*.js) and then compare the results. 2. Add JavaScript code to the HTML format that will expand the view when scissors is clicked (or don't cut the line at all) ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Re: Bug#836784: diffoscope: Several "Too much input for diff" on debian packages from unstable/amd64
Emanuel Bronshtein: > Source: diffoscope > Severity: normal > > Dear Maintainer, > > The packages "esajpip" & "aptly" & "nikwi" from unstable/amd64: > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/esajpip.html > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/aptly.html > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/nikwi.html > > return "Too much input for diff" instead of meaningful diff. > Hi Emanuel, try setting the --max-diff-input-lines flag to a higher value. In the next version we'll let "0" mean "unlimited" as well as having a --no-max value to disable all such limits. If you are satisfied with this, please close this bug - otherwise please suggest something concrete that we can do to satisfy you. (The reason for this input limit is that diff(1) reads the whole file into memory, so runs out of memory for very large files.) 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
Re: [diffoscope] [Reproducible-builds] More lazy-loading for diffoscope html output
Hi Ximin, > https://people.debian.org/~infinity0/res/dfs-demo/index.html One quick bit of feedback is that the: " ... load diff (3 pieces, truncated) ... " links aren't always immediately obvious to my eyes/colour scheme. Indeed, I am sure I found find myself wondering where the rest of differences were. I'm sure some judicial CSS styling would solve this. 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: [diffoscope] [Reproducible-builds] More lazy-loading for diffoscope html output
Ximin Luo: > Chris Lamb: >>> https://people.debian.org/~infinity0/res/dfs-demo/ >> >> Like it! >> >> However, hould you object to making it show some — however small — diff on >> page load? I am all behind lazy-loading of further chunks but I am certain >> I will find it annoying to have to click «load diffs» when I did not before. >> >> It makes it much harder to skip over chunks I don't care about, and also >> requires me to switch from keyboard to mouse. >> > > Understood, yeah I agree, I'll fix this before I push. > Updated here: https://people.debian.org/~infinity0/res/dfs-demo/index.html >>> I will push this "soon" unless people complain. :p So please play around >>> with it yourself etc >> >> Can you clarify whether this would change the output behaviour of the >> "--html " or is some other switch required…? >> > > This is just for --html-dir so far. But I have some ideas for merging the > flags which would also affect --html, but hopefully make it easier to think > about. I'll go implement them then it'll be easier for me to try to describe > it. > Flag changes completed and described here: https://anonscm.debian.org/cgit/reproducible/diffoscope.git/commit/?h=better-lazy-loading=ebbf88382a0762166f10e3d6cd9489b8ee790113 The TL;DR version is that instead of having --max-diff-block-lines affects single (--html) and child pages, in unpredictable ways --separate-file-diff-size affects parent and child pages, in unpredictable ways we now have --max-diff-block-lines affects single (--html) and parent pages, in the same way --max-diff-block-lines-html-dir affects child pages 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
Re: [PATCH] New reproducible website location
Holger Levsen wrote: > > Apologies for the top-posting, but ping on the below: > > pong… > > I haven't forgotten about this, just had no time to get around to do it. Another ping for this? Many thanks. 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: [notes] 01/01: Tag 9 total packages with user_hostname_manually_added_requiring_further_investigation
Hi Emanuel, On Sun, Sep 04, 2016 at 09:22:28PM +0100, Chris Lamb wrote: > Just want to jump in here to say I think you're doing sterling > work here. likewise, many thanks for joining our efforts and contributing so nicely! (just please also tell your email client to not (only) send HTML mails… ;) -- 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
Processed: Re: Bug#836732: strip-nd: FTBFS when locale is not English
Processing commands for cont...@bugs.debian.org: > tag 836732 + pending Bug #836732 [src:strip-nondeterminism] strip-nd: FTBFS when locale is not English Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 836732: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836732 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
Bug#836732: strip-nd: FTBFS when locale is not English
tag 836732 + pending thanks > Not sure how much related they are, but I guess it means something given > that it's not in the English build. I don't really understand why that would be causing an error but we follow your assumption that the "return" that is causing the FTBFS, then it was removed and thus fixed in Git already: https://anonscm.debian.org/git/reproducible/strip-nondeterminism.git/commit/?id=72d70fcd7a088ca0f97d4a9f67e2e42c0c1505ff 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
Bug#836732: strip-nd: FTBFS when locale is not English
source: strip-nondeterminism version: 0.024-1 severity: serious As you can see in reproducible-builds buildlogs, strip-nd fails to build when locale is not English, i.e. in the second build. For example, for Italian: | All tests successful. | Files=2, Tests=15, 59 wallclock secs ( 0.33 usr 0.03 sys + 55.59 cusr 2.80 csys = 58.75 CPU) | Result: PASS | sh: riga 0: return: è possibile eseguire "return" solo da una funzione o da uno script chiamato | sh: riga 0: test: OPTIMIZE=-O0 -fprofile-arcs -ftest-coverage: atteso operatore unario | Reading database from /build-2nd/strip-nondeterminism-0.025/cover_db | | | --- -- -- -- -- -- -- | File stmt bran condsub time total | --- -- -- -- -- -- -- | .../lib/File/StripNondeterminism.pm 78.5 40.0 66.6 92.8 97.1 67.5 | ...le/StripNondeterminism/Common.pm 100.0n/an/a 100.00.0 100.0 | ...ripNondeterminism/handlers/ar.pm 100.0 64.2 50.0 100.00.0 89.0 | ...ndeterminism/handlers/gettext.pm 20.60.00.0 66.60.6 18.1 | ...pNondeterminism/handlers/gzip.pm 79.6 42.5 33.3 100.00.0 65.8 | ...ipNondeterminism/handlers/jar.pm 62.0 23.0 33.3 84.61.7 53.4 | ...ndeterminism/handlers/javadoc.pm 95.8 63.6 33.3 100.00.0 83.3 | ...inism/handlers/javaproperties.pm 97.2 62.5 33.3 100.00.0 86.2 | ...rminism/handlers/pearregistry.pm 100.0 50.0 40.0 100.00.0 86.2 | ...ipNondeterminism/handlers/png.pm 97.3 73.3 100.0 100.00.1 91.7 | ...ipNondeterminism/handlers/zip.pm 79.7 38.4 41.6 85.70.0 69.8 | Total 79.3 43.6 50.0 92.7 100.0 69.8 | --- -- -- -- -- -- -- | | | HTML output written to /build-2nd/strip-nondeterminism-0.025/cover_db/coverage.html | done. | debian/rules:10: set di istruzioni per l'obiettivo "override_dh_auto_test" non riuscito | make[1]: *** [override_dh_auto_test] Errore 2 | make[1]: uscita dalla directory "/build-2nd/strip-nondeterminism-0.025" | debian/rules:13: set di istruzioni per l'obiettivo "build" non riuscito | make: *** [build] Errore 2 | dpkg-buildpackage: error: debian/rules build gave error exit status 2 | I: copying local configuration | E: Failed autobuilding of package The sh errors above translates to sh: line 0: return: is possible to execute "return" only from a function or from a script called sh: line 0: test: OPTIMIZE=-O0 -fprive-arcs -ftest-coverage: exepected unary operator Not sure how much related they are, but I guess it means something given that it's not in the English build. -- 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
Bug#800159: Error handling seems poor
tag 800159 + pending thanks Patch in git, pending upload. (ETA ~1 week) 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
Processed: Re: Error handling seems poor
Processing commands for cont...@bugs.debian.org: > tag 800159 + pending Bug #800159 [strip-nondeterminism] Error handling seems poor Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 800159: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800159 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
