This was fixed by f69cee3033a7842633199151956f405de4d253f9 [1] which
is part of release 1.1. Updating should fix the failure.
[1]:
https://github.com/VIDA-NYU/reprozip/commit/f69cee3033a7842633199151956f405de4d253f9
Yours truly,
The upstream maintainer
https://github.com/VIDA-NYU/reprozip/pull/330).
--
Rémi Rampin
This appears to be a duplicate of #943442.
Upstream version 1.0.16 fixes the problem. It seems that there have
been uploads of reprozip but not reprounzip, I'm not sure why.
Upstream version 1.0.16 supports Python 3.8.
1.0.15 and below won't work because of the removed
platform.linux_distribution() function in Python 3.8.
2018-11-15 21:39 EST, Guillem Jover :
> The same principle I proposed for --listfiles can be used for --search,
> you'd just batch as many filenames as can possibly fit within the
> command-line length limit (ARG_MAX - environment length) to reduce as
> many dpkg-query calls as possible. Doing a «d
Upstream developer here. ReproZip needs to match from filename to package,
not the other way around. It formerly used `dpkg-query -S FILENAME` to do
this, but this was switched to reading the database directly for
performance reasons (exact commit is
https://github.com/ViDA-NYU/reprozip/commit/b085
2017-05-02 15:05 EDT, Ghislain Vaillant :
> Thanks for clarifying. Just out-of-curiosity, why is the tracer
> restricted to x86?
There is no technical limitation here, I would just have to write the
system call map [1] for other platforms (and find a CI service I can
test it on). It might be imple
2017-05-02 12:11 EDT, Ghislain Vaillant:
> Do you mean Linux the kernel or the platform? The tracer would not work
> on a non-Linux kernel such as FreeBSD or the Hurd, am I right?
The tracer requires a Linux kernel, and currently only supports x86 and x86_64.
> Since the tool itself targets repro
x" from the short
> description,
> and maybe also s#reproducible#reproducing#…
We don't actually use this description anywhere I could find. The
packages are collectively labelled as "Linux tool enabling
reproducible experiments". Let me know if I missed something.
Thank you for your work on this
--
Rémi Rampin
been open for over a year. I don't see a reason to
escalate this when this is clearly a simple omission on your part, fixable
in a matter of seconds.
--
Rémi Rampin
Just a reminder that there is still a severe and obvious logic error in the
escape() for loop. I uploaded a patch to fix it 6 months ago. The new
version you uploaded still exhibits the same bugs.
Regards
I think you get the problem at this point, but I'm going to mention
that this prevents people from using the installer for the Anaconda
Python distribution. Neither curl nor openssl connects to
repo.continuum.io. Same CA: thawte_Primary_Root_CA.crt
https://github.com/ContinuumIO/anaconda-issues/is
There's actually another bug in escape(): the terminating null byte
doesn't break out of the loop if the last character is a backslash.
You can't see the garbage that gets copied to the buffer because the
null byte gets copied, the the overrun does happen.
New patch that also addresses that.
--- b
Nevermind, I found the bug in the source. It actually fumbles if the
backslash *isn't the last character in the format unit*.
New patch attached, fixes up escape() in hexdump/parse.c
I don't know if there is an upstream to report this to, but other
distributions are affected.
--- bsdmainutils/usr
This is a neat workaround, but I really wouldn't say that "it works".
On Sun, 11 May 2003 15:37:26 +0300 Kalle Kivimaa wrote:
> Currently tar without --keep-old-files silently overwrites existing files
> with versions from the archive. With --keep-old-files existing files can
> be retained but tar complains about each and every file. This can cause
> grief in postin
16 matches
Mail list logo
