Re: diffoscope timing out.
On Thu, 2023-11-16 14:28:03 +, Holger Levsen wrote: > On Thu, Nov 16, 2023 at 03:20:12PM +0100, Jan-Benedict Glaw wrote: > > So... Stack dumps and crashing is quite okay. We don't expect our > > parents or grandparents to use it, do we? > > I know at least one lawyer who uses diffoscope to compare PDFs to > see exactly how the plain text inside a 100 page PDF has changed. > I expect other users like them, who don't want to see stack dumps etc. > > That's why I said I want both. And surely on jenkins.d.n we would enable > all possible and very verbose options! --debug-verbosely or some such. But they can tell the difference between stdout and stderr? MfG, JBG -- signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: diffoscope timing out.
On Thu, 2023-11-16 14:13:14 +, Holger Levsen wrote: > > However: > [...] > > > — https://docs.python.org/2/library/exceptions.html#exceptions.MemoryError > > ... so this may not work in all situations. > > hmm. as a user I'd really like a mode where *no* tracebacks and other similar > "scary looking" errors are ever visible and instead are replaced with > something > more intuitive/less scary (- and I also think this mode should be the > default). > I understand this is a language/interpreter issue and many developers disagree > I'd just like to imagine a (far away) world where things are perfect. ;) Out of memory is something That Just Should Not Happen[tm]. For a userland program, it doesn't get any scarier. MfG, JBG -- signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: diffoscope timing out.
On Thu, Nov 16, 2023 at 03:20:12PM +0100, Jan-Benedict Glaw wrote: > When a program cannot really continue its expected flow, I'm all for a > stackdump and hard-crashing afterwards! *g* > So... Stack dumps and crashing is quite okay. We don't expect our > parents or grandparents to use it, do we? I know at least one lawyer who uses diffoscope to compare PDFs to see exactly how the plain text inside a 100 page PDF has changed. I expect other users like them, who don't want to see stack dumps etc. That's why I said I want both. And surely on jenkins.d.n we would enable all possible and very verbose options! --debug-verbosely or some such. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "I like beautiful people. I don't care about their looks." signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: diffoscope timing out.
On Thu, 2023-11-16 13:56:05 +, Chris Lamb wrote: > Holger Levsen wrote: > > > I think there is definitly an UI bug in diffoscope here. If/when diffoscope > > runs out of memory, it should state that clearly and not throw 42 lines of > > traceback at the user. > > Good idea. I've added that here: > > > https://salsa.debian.org/reproducible-builds/diffoscope/commit/bb887ddb6e5763b15d4ed9bb448166901dc7253f > > However: > > > Note that because of the underlying memory management architecture > > (C’s malloc() function), the interpreter may not always be able to > > completely recover from this situation; it nevertheless raises an > > exception so that a stack traceback can be printed, in case a > > run-away program was the cause. > > > > — https://docs.python.org/2/library/exceptions.html#exceptions.MemoryError > > ... so this may not work in all situations. When a program cannot really continue its expected flow, I'm all for a stackdump and hard-crashing afterwards! Such a memory runaway situation should not occur in normal use. Either track allocations and impose some arbitrary VSZ limit (which will be wrong for everybody ^^), or just except/abort on failed allocations. (Esp. with overallocations permitted, an allocation may actually look like it was successfull, but you'll get signaled to death once you actually start using that allocation.) So... Stack dumps and crashing is quite okay. We don't expect our parents or grandparents to use it, do we? MfG, JBG -- signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: diffoscope timing out.
On Thu, Nov 16, 2023 at 01:56:05PM +, Chris Lamb wrote: > > I think there is definitly an UI bug in diffoscope here. If/when diffoscope > > runs out of memory, it should state that clearly and not throw 42 lines of > > traceback at the user. > Good idea. I've added that here: > > https://salsa.debian.org/reproducible-builds/diffoscope/commit/bb887ddb6e5763b15d4ed9bb448166901dc7253f thank you. <3 > However: [...] > > — https://docs.python.org/2/library/exceptions.html#exceptions.MemoryError > ... so this may not work in all situations. hmm. as a user I'd really like a mode where *no* tracebacks and other similar "scary looking" errors are ever visible and instead are replaced with something more intuitive/less scary (- and I also think this mode should be the default). I understand this is a language/interpreter issue and many developers disagree I'd just like to imagine a (far away) world where things are perfect. ;) Still, this is great for now. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ “I'll tell you what freedom is to me No fear.” (Nina Simone) signature.asc Description: PGP signature ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: python-ansible-pygments: please make the build reproducible
Stuart Prescott wrote: > I think there's a subtle bug about altering `dirs` while > inside a loop from `os.walk`: I'm quite impressed that you managed to hunt this down — that's very nice work. :) > Which item is not processed in the next iteration by dh_python3 now > depends on the order in which `os.walk` lists the directories. That is > presumably dependent on all manner of things (filesystem? collation? > luck?). It will be dependent entirely on the filesystem being used because `os.walk` merely passes on the underlying filesystem ordering. (The same is true for GNU find as you later query.) Entirely anecdotally, ext4 will be "more orderful", whilst btrfs, possibly due to the way it rebalances its tree data structures, tends to be less so. I raise it only because it can help explain why different folks will get different results locally despite using the same building tools. Building under tmpfs will have different properties as well. Anyway, thank you again. Once this is addressed in dh-python (even as a proposed patch), I'll go through the last few months of bugs that I've filed and see whether they can be closed. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `- ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
Re: diffoscope timing out.
Holger Levsen wrote: > I think there is definitly an UI bug in diffoscope here. If/when diffoscope > runs out of memory, it should state that clearly and not throw 42 lines of > traceback at the user. Good idea. I've added that here: https://salsa.debian.org/reproducible-builds/diffoscope/commit/bb887ddb6e5763b15d4ed9bb448166901dc7253f However: > Note that because of the underlying memory management architecture > (C’s malloc() function), the interpreter may not always be able to > completely recover from this situation; it nevertheless raises an > exception so that a stack traceback can be printed, in case a > run-away program was the cause. > > — https://docs.python.org/2/library/exceptions.html#exceptions.MemoryError ... so this may not work in all situations. -- o ⬋ ⬊ Chris Lamb o o reproducible-builds.org ⬊ ⬋ o ___ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
