Bug#934601: help2man: FTBFS when binNMUed
Ah, never mind me. It was the very last change I made that seems to have tickled this problem. Uploading shortly. On Mon, 12 Aug 2019 at 22:19, Brendan O'Dea wrote: > This is due to a sanity check that I've added to ensure that everything is > prepared for an "upstream" release to both Debian and GNU. This is the > first time in ~16 years of the package containing an arch-specific binary > that I've come across a case where a bin-NMU has been required for > help2man. Out of curiosity, why? libc update? > > I'll upload a change shortly to skip these checks if the version number > matches the bin-NMU pattern. > > On Mon, 12 Aug 2019 at 22:03, Ivo De Decker wrote: > >> package: src:help2man >> version: 1.47.10 >> severity: serious >> tags: ftbfs >> >> Hi, >> >> The latest version of help2man in unstable fails on i386 because it was >> binNMUed there: >> >> https://buildd.debian.org/status/package.php?p=help2man >> >> dpkg-buildpackage >> - >> >> Command: dpkg-buildpackage -us -uc -mamd64 / i386 Build Daemon >> (x86-ubc-02) -B -rfakeroot >> dpkg-buildpackage: info: source package help2man >> dpkg-buildpackage: info: source version 1.47.10+b1 >> dpkg-buildpackage: info: source distribution sid >> dpkg-source --before-build . >> dpkg-buildpackage: info: host architecture i386 >> fakeroot debian/rules clean >> test -x configure # autoconf has been run >> grep -qF 'help2man-1.47.10+b1.tar' README # exists and up to date >> make: *** [debian/rules:122: check-maint-prep] Error 1 >> dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned >> exit status 2 >> >> Cheers, >> >> Ivo >> >
Bug#934601: help2man: FTBFS when binNMUed
This is due to a sanity check that I've added to ensure that everything is prepared for an "upstream" release to both Debian and GNU. This is the first time in ~16 years of the package containing an arch-specific binary that I've come across a case where a bin-NMU has been required for help2man. Out of curiosity, why? libc update? I'll upload a change shortly to skip these checks if the version number matches the bin-NMU pattern. On Mon, 12 Aug 2019 at 22:03, Ivo De Decker wrote: > package: src:help2man > version: 1.47.10 > severity: serious > tags: ftbfs > > Hi, > > The latest version of help2man in unstable fails on i386 because it was > binNMUed there: > > https://buildd.debian.org/status/package.php?p=help2man > > dpkg-buildpackage > - > > Command: dpkg-buildpackage -us -uc -mamd64 / i386 Build Daemon > (x86-ubc-02) -B -rfakeroot > dpkg-buildpackage: info: source package help2man > dpkg-buildpackage: info: source version 1.47.10+b1 > dpkg-buildpackage: info: source distribution sid > dpkg-source --before-build . > dpkg-buildpackage: info: host architecture i386 > fakeroot debian/rules clean > test -x configure # autoconf has been run > grep -qF 'help2man-1.47.10+b1.tar' README # exists and up to date > make: *** [debian/rules:122: check-maint-prep] Error 1 > dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned > exit status 2 > > Cheers, > > Ivo >
Bug#925136: help2man: FTBFS in unstable (dh_clean fails)
On Fri, Mar 22, 2019 at 05:42:37PM +0100, Sven Joachim wrote: >On 2019-03-21 20:45 +1100, Brendan O'Dea wrote: >> I suspect that it is related to reproducible builds, [...] >There has indeed been such a change in dpkg-source: > >, >| - Generate reproducible source tarballs by using the new GNU tar >| --clamp-mtime option in Dpkg::Source::Archive, to make sure no file >| in source packages has an mtime later than the changelog entry time. >` > >However, that was in version 1.18.10, uploaded July 2016. > >It seems that in previous versions of help2man help2man.PL was older >than debian/changelog, so you did not hit the problem. Ah thanks. I assumed that this was more recent. Looking at some previous source packages, the max date is indeed clamped, but it just so happened that I updated the version in help2man.PL before making the changelog entry so didn't trip over this. Incidentally, I'm slightly puzzled at this behaviour for native packages. Under what circumstances would the source tar ball for a released package be re-built without changing the version? >> I'll try to find a way to revise this check that will be more robust to this >> kind of timestamp modification. Somewhat annoyingly, the "test" builtin has >> -nt and -ot options, but no way to test that timestamps are newer or equal >> (or >> even just equal). > >A negated test with the -ot option might help: > > ! test README -ot help2man.PL # maintainer sanity check Thanks, good suggestion but rather ungainly. I've cooked up a different solution for the next release which doens't depend on the mtimes. --bod
Bug#925136: help2man: FTBFS in unstable (dh_clean fails)
On Wed, Mar 20, 2019 at 10:21:39AM +0100, Gianfranco Costamagna wrote: >Looks like README needs a newer timestamp wrt help2man.PL file? [...] >dpkg-buildpackage: info: host architecture amd64 > fakeroot debian/rules clean >test README -nt help2man.PL # maintainer sanity check >make: *** [debian/rules:40: clean] Error 1 Well this is odd, it seems that there has been a change in dpkg-source which breaks this particular sanity check (intended to ensure that I've run the maint-prep step since updating the version in help2man.PL). I suspect that it is related to reproducible builds, since the timestamps that ended up in the tarball have been changed to the changlog timestamp (in fact there are no files in the tarball with later dates). ~/debian/help2man-1.47.9 $ ls -l README help2man.PL -rw-r--r-- 1 bodbod 540 2019-03-18 19:16 README -rwxr-xr-x 1 bodbod 23166 2019-03-18 19:13 help2man.PL ~/debian/help2man-1.47.9 $ tar tvJf ../help2man-1.47.9.tar.xz help2man-1.47.9/README help2man-1.47.9/help2man.PL -rw-r--r-- 0/0 540 2019-03-18 19:10 help2man-1.47.9/README -rwxr-xr-x 0/0 23166 2019-03-18 19:10 help2man-1.47.9/help2man.PL ~/debian/help2man-1.47.9 $ dpkg-parsechangelog -S Date Mon, 18 Mar 2019 19:10:35 +1100 I'll try to find a way to revise this check that will be more robust to this kind of timestamp modification. Somewhat annoyingly, the "test" builtin has -nt and -ot options, but no way to test that timestamps are newer or equal (or even just equal). --bod
Bug#625963: vile: FTBFS on armel and s390 (hangs in configure?)
On Sat, May 07, 2011 at 02:20:33PM +0200, Julien Cristau wrote: See https://buildd.debian.org/status/package.php?p=vile The configure failed at different points for both armel and s390, but there is nothing particularly exceptional about either test, moreover this exact source package has compiled fine on both architectures recently. Could these two builds be retried please? --bod -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552797: perl: dpkg-shlibdeps fails on suid-perl on i386
On Wed, Oct 28, 2009 at 7:13 PM, Niko Tyni nt...@debian.org wrote: http://git.debian.org/?p=perl/perl.git;a=commitdiff;h=063f225d0fdeca563c7906927fc30171c3684f70 This makes sure the script runs with the system perl and not the new one. Note that one of the reasons why perl has a slightly eccentric rules file is so that the package is able to be built on a system without any perl installed. This was to allow new ports to bootstrap and is the reason why ./perl.static is used in that file rather than /usr/bin/perl. It is entirely possible that bit-rot has made this no longer work, but it is still a useful goal to retain. See debian/checkperl, which is invoked for the install rule. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536384: perl-modules must depend on perl-base (= 5.10.0-24) or ship the changelog.Debian.gz
On Mon, Aug 17, 2009 at 7:01 AM, Niko Tynint...@debian.org wrote:
There are ways around that, have the perl package provide a name which
maps to the debian version less NMUs (either by manually updating
debian/control, or an automated process which removes bin NMUs from
the version).
As binNMUs get an extra changelog entry compared to their arch:all
counterparts, all approaches that try to make them equivalent seem
fundamentally broken to me. But maybe I'm just misunderstanding you.
I was suggesting:
Package: perl
Provides: perl-${debian-base:Version}
Package: perl-modules
Depends: perl-${debian-base:Version}
or something similar, and to have debian-base:Version set by
debian/rules to be the Debian version =~ s/\+b\d+$//
This would mean that arch-indep packages may have a changelog which
contains one or more binary NMU lines that technically do not apply,
but as these are machine generated metadata do we really care?
Another alternative, certainly the simplest, would be to remove
perl-modules entirely and have those arch-indep parts included in the
perl package. [...]
I find this suggestion somewhat appealing, particularly as it would
remove the dependency loop that people frequently complain about
(#527917 / #502455) and simplify major version upgrades.
The size of the packages is roughly
package size installed-size
perl 5M 15M
perl-modules 3M 15M
so with ~15 architectures, the join would take on the order of 50
megabytes more mirror space per suite, altogether something like 200
megabytes. That does sound a bit much, but OTOH it's less than .1 %
of the total archive size.
Note that while size in the archive was part of the original
motivation of splitting the arch-indep parts out, it also seemed to be
the correct thing to do in so far as making scenarios such as
described in the FHS easier to manage
(http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA).
Having said that, I'm inclined to believe that merging the two is
perhaps the best course.
A quick count shows 116 packages in sid that have a versioned dependency
(build- or otherwise) on perl-modules. Those would have to be fixed
first unless we provided a transitional empty perl-modules package.
My inclination would be to have an empty package.
In any case, the join wouldn't solve the issue this bug is about
completely, as perl-doc also has an arch:all-arch:any symlink in
/usr/share/doc. It therefore seems to me that a possible perl/perl-modules
join is a separate matter and should not necessarily be coupled with
this bug.
This similarly could be solved with the provides/dependency as described above.
I think removing the symlinks with maintainer scripts and separating
the /usr/share/doc entries is the best course of action here.
Sure. I would still be inclined to keep the majority of the
documentation under /usr/share/doc/perl (as it is currently), and
merely have copies of changelog.Debian.gz, copyright and perhaps a
short README.Debian in /usr/share/doc/perl-doc.
If, OTOH you think that it would be clearer to split the docs across
perl-base, perl and perl-doc, I can take a look at what machinations
would be required to apply that on update.
--bod
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536384: perl-modules must depend on perl-base (= 5.10.0-24) or ship the changelog.Debian.gz
On Mon, Jul 13, 2009 at 6:12 AM, Niko Tynint...@debian.org wrote: On Fri, Jul 10, 2009 at 11:15:17PM +1000, Brendan O'Dea wrote: I vote that we fix this problem by simply nailing the dependencies between perl-base/perl/perl-modules to an exact equivalence. [...] I agree with you that this is a cure worse than the disease. Furthermore, as Adrian stated, it has problems with binNMUs. There are ways around that, have the perl package provide a name which maps to the debian version less NMUs (either by manually updating debian/control, or an automated process which removes bin NMUs from the version). Another alternative, certainly the simplest, would be to remove perl-modules entirely and have those arch-indep parts included in the perl package. perl could transitionally provide perl-modules. The packages versions of perl/perl-modules were never intended to be disjoint--the split was intended only to reduce redundancy in the archive. Is disk sufficiently cheap theses days that we no longer care? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#536384: perl-modules must depend on perl-base (= 5.10.0-24) or ship the changelog.Debian.gz
On Fri, Jul 10, 2009 at 1:23 AM, Adrian Bunkb...@stusta.de wrote: /usr/share/doc/perl-modules is a symlink to /usr/share/doc/perl, and /usr/share/doc/perl/changelog.Debian.gz is shipped in the perl-base package. [...] the Debian source tree of perl-modules 5.10.0-24 is hardly the 5.10.0-1 or 5.10.0-30 perl source tree. I strongly disagree that this is a serious violation. Completely omitting the changelog is a serious violation. There being the possibility of a slight difference between perl/perl-modules is hardly so, and for a working package in the stable distribution the intent is that there be no difference. For the sake of preventing further Policy lawyer bugs of this variety, I vote that we fix this problem by simply nailing the dependencies between perl-base/perl/perl-modules to an exact equivalence. This may render perl un-installable in unstable at times for some architectures, but heck the most important thing is obviously sticking to the letter of Policy, so let's do it. --bod -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#492816: libperl must NOT be installed in /usr/lib
On Wed, Jul 30, 2008 at 7:52 AM, Marc Lehmann [EMAIL PROTECTED] wrote: On Tue, Jul 29, 2008 at 11:17:33PM +1000, Brendan O'Dea [EMAIL PROTECTED] wrote: I think that you have some other problem. -Lpath -lperl will search at compile time for libperl.so or libperl.a in path before it searches /usr/lib. No, it will srearch for libperls.o *first* in all directories and then for libperl.a. If the alternative perl is built without a shared library, then the debuian one will be picked up first. That is not the way that any linker I have ever used works, and the current unstable Debian linker works pretty much exactly as I would expect. To test this, I picked a simple function from libperl, Perl_my_snprintf which could be used to demonstrate which library is selected by the linker. See attached local_libperl.c which provides an implementation of this function, operating in a way that allows it to be clearly distinguished from the packaged library, and test.c which calls the function. A transcript follows: $ ls -l /usr/lib/libperl.* -rw-r--r-- 1 root root 5424738 2008-07-17 02:32 /usr/lib/libperl.a lrwxrwxrwx 1 root root 15 2008-07-30 21:05 /usr/lib/libperl.so - libperl.so.5.10 lrwxrwxrwx 1 root root 17 2008-07-30 20:40 /usr/lib/libperl.so.5.10 - libperl.so.5.10.0 -rw-r--r-- 1 root root 1364380 2008-07-17 02:32 /usr/lib/libperl.so.5.10.0 $ cc -c local_libperl.c $ ar rv /tmp/libperl.a local_libperl.o ar: creating /tmp/libperl.a a - local_libperl.o $ cc test.c -o debian -lperl $ cc test.c -o local -L/tmp -lperl $ ./debian Debian libperl $ ./local local libperl So on my machine, updated to latest unstable and with libperl-dev installed, linking with -Lpath -lperl selects the library from path, even with /usr/lib contains both .so and .a. If by windows process emulation? you are referring to threads, I suggest that you go read the POSIX standard. That's just a stupid ad-hominem :( I know the posix standard very well, but it is irrelevant: perl doesn't offer threads, what it does is emulate processes *using* threads (and it uses pthreads on e.g. debian to do that). In the context of a response to the assertion that I had made some extremely bad choices for configuration, and what appeared to be a rather naive assertion about the nature of ithreads, I believe that I was fairly restrained. When you create a perl thread, then perl actually creates a pseudo-process by copying the *whole* perl interpreter. There is no shared address space, and the whole thing was created to emulate processes on windows, thus process emulation. I am intimately aware how Perl threading works. I can assure you that it was not created to emulate processes on Windows. There can be shared address space when required (see threads::shared). The major reason for enabling ithreads however was not primarily to allow people to use threads, but more to allow perl to be embedded into threaded programs (mod_perl 2.0 for example required perl to be compiled with ithreads). --bod local_libperl.c Description: Binary data test.c Description: Binary data
Bug#492816: libperl must NOT be installed in /usr/lib
On Wed, Jul 30, 2008 at 7:55 AM, Marc Lehmann [EMAIL PROTECTED] wrote: (I really wonder when debian maintainers learn to do their job properly and stop trying to act like bignosed idiots who know everything better - wasn't the we-know-better-than-openssl incident enough?). Sorry, but you deserved it :( Did I, really? You are free to choose a different distribution, or in fact operating system. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492816: libperl must NOT be installed in /usr/lib
On Tue, Jul 29, 2008 at 10:44 AM, Marc Lehmann [EMAIL PROTECTED] wrote: debian makes it impossible to install perls in other prefixes by forcing libperl.so (a private library that should not be in the default search path) into /usr/lib, where it clashes with every other libperl. Impossible? Have you tried? Many people are running non-Debian perl installs in /opt, /usr/local or whatever. Unfortunately, debian completely breaks this mechanism by moving it into /usr/lib, where it clashes with all other libperls on the same system, as /usr/lib is alwas in the default linker search path. i.e. -L/opt/perl/lib/CORE -lperl will link against the correct perl library (here in /opt/perl/lib) on every system except on debian, as debian puts the libperl into the default library search path, when libperl was never intended to be put there. I think that you have some other problem. -Lpath -lperl will search at compile time for libperl.so or libperl.a in path before it searches /usr/lib. When linking to a shared library in a directory outside of /usr/lib either LD_RUN_PATH must also be set correctly, or -rpath passed to the linker such that at runtime the library will be found in the correct directory. (this is especially bad as debian uses some extremely bad choices for configuration, such as enabling the windows process emulation on unix, which serves no purpose except slow down perl considerably for no gain whatsoever on unix, so compiling one's own is practically required) If by windows process emulation? you are referring to threads, I suggest that you go read the POSIX standard. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489928: libcgi-pm-perl: tries to overwrite file owned by libcgi-fast-perl
On Wed, Jul 9, 2008 at 5:53 AM, gregor herrmann [EMAIL PROTECTED] wrote: On Tue, 08 Jul 2008 20:47:48 +0200, Ralf Treinen wrote: Possible solutions include: * make libcgi-pm-perl conflict (and maybe provide) with libcgi-fast-perl; that would mean changing the Priority to extra (also of depending packages) ..or changing the priority of the libcgi-fast-perl to optional. * remove Fast.pm from libcgi-pm-perl and depend on libcgi-fast-perl; that's happening right at the moment a few hundred kilometers to the south east from, and maybe the newer package will already be uploaded before this mail is finished :) Neat. For the short term, this seems a simple fix. * in the long run it might be an idea to stop building libcgi-fast-perl from the perl source package, add Fast.pm to libcgi-pm-perl again, and create a dummy transitional package with the usual conflicts/provides/replaces dance for libcgi-fast-perl from the libcgi-pm-perl source package; Brendan and Niko, what do you think about this idea? For 5.10, I moved the module to the vendor directory which on reflection was probably a bad idea (debian/rules:233-236). I'd say that the simplest solution would be to just reverse that decision, which would allow libcgi-pm-perl to provide a newer version without the path conflict. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#465783: perl: ExtUtils::Install upgrade in Perl 5.10 breaks too many packages
On Fri, Feb 15, 2008 at 09:39:42AM +0100, Raphael Hertzog wrote:
On Thu, 14 Feb 2008, Niko Tyni wrote:
I run a few greps on debian/rules of the source packages of all the
binary packages matching '-perl' in unstable. Results: at least 398
arch:all and 38 arch:any packages apparently do an unconditional rmdir
for the empty directory.
I tend to disagree. The number are big but the fix is easy. I'd suggest
to work with Lucas to do a full rebuild with perl 5.10 and submit those
400 bugs right now with severity important. Also usertag them to be able
to follow the evolution.
I'm keen to get 5.10 into Lenny, since the length of our stable release
cycles otherwise means that we'll be stuck with 5.8 for quite a while.
My initial thought was to set up a staging area, although was told that
with the binNMU mechanism it should no longer be necessary... This
issue with rmdir however would appear to have torpedoed that plan.
Given the mechanical nature of the fix required, I am still inclined to
uploading to unstable before the soft freeze in a week or so. Remember,
it's called unstable for a reason, people.
--bod
#!/usr/bin/perl -lp
if
(m!^\s+(@\s*)?rmdir(\s+(--parents|--ignore-fail-on-non-empty|-p))*((\s+\S+/(lib|share)/perl5)+)\s*$!)
{
$_ = join \n,
map \t[ ! -d $_ ] || rmdir --ignore-fail-on-non-empty --parents
--verbose $_,
split ' ', $4;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461876: perl_5.10.0-2(experimental/mipsel/mimir): FTBFS: Testsuite failure in ext/IO/t/io_sock.t
On Mon, Jan 21, 2008 at 11:52:21AM +0100, Marc 'HE' Brockschmidt wrote: | ext/IO/t/io_sock..FAILED--expected test 11, saw test 12 That's puzzling. Is the build tree still around? If so, does the test fail consistently? Run: cd t; ./perl ../lib/io/t/io_sock.t There is an overall timer on the test of 120 secs, and if the timeout expires before the child process writes ok 11 I could see this happening. It seems unlikely that the test would take that long to run, unless there resolving localhost is really slow however. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457760: perl_5.10.0-1(experimental/i386/demosthenes): test suite failure in ext/Sys/Syslog/t/syslog
On Tue, Dec 25, 2007 at 01:26:11PM +0100, Marc 'HE' Brockschmidt wrote: Package: perl Version: 5.10.0-1 Severity: serious Tags: experimental Heya, Building perl 5.10 failed on all my buildds due to the same test suite failure: | ext/Sys/Syslog/t/syslog...# Failed test 'setlogsock() should return true: ''' | # at ../ext/Sys/Syslog/t/syslog.t line 204. | # Looks like you failed 1 test of 199. | FAILED at test 176 [...] | Failed 1 test out of 1433, 99.93% okay. | ../ext/Sys/Syslog/t/syslog.t This failure is caused by the test expecting /dev/log to be a listening socket. Looks like I need to add sysklogd to the build-depends, and to perhaps modify the test to quietly succeed (skip) where the setlogsock fails if possible. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450794: CVE-2007-5116 buffer overflow in the polymorphic opcode regcomp.c
On Sat, Nov 10, 2007 at 07:00:17PM +0100, Nico Golde wrote: the following CVE (Common Vulnerabilities Exposures) id was published for perl. Upload is waiting for ftp-master to come back. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450456: perl: DSA 1400-1: heap overflow
On Thu, Nov 08, 2007 at 12:09:30AM +1100, Steffen Joeris wrote: Package: perl The patch used for this update is below. The CVE number is CVE-2007-5116. Please mention it in your changelog, when you fix this bug. Thanks, will apply and build tonight. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434433: apt-show-versions fails to install
On Tue, Jul 24, 2007 at 09:01:51PM +0100, Marcos Marado wrote: OK, the working machine outputs nothing, but the non-working says: $ perl -e use Scalar::Util 'weaken' Weak references are not implemented in the version of perl at -e line 1 BEGIN failed--compilation aborted at -e line 1. The bad machine has this includes that aren't in the good machine: 'Config.pm' = '/usr/lib/perl/5.8/Config.pm', 'Exporter/Heavy.pm' = '/usr/share/perl/5.8/Exporter/Heavy.pm', 'AutoLoader.pm' = '/usr/share/perl/5.8/AutoLoader.pm', 'DynaLoader.pm' = '/usr/lib/perl/5.8/DynaLoader.pm', Can you please give me any more help in this issue? Please provide the output of the following commands: dpkg -l perl-base perl perl-modules strace -etrace=open perl -MScalar::Util=weaken -e 1 --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429017: libapt-pkg-perl 0.1.20 can't be installed
merge 334958 429017 thanks On Fri, Jun 15, 2007 at 03:08:40PM +0200, Andrea Cavaglieri wrote: I can't install the package in subject because the virtual package libapt-pkg-libc6.3-6-3.11 isn't installable (or better, package apt provides libapt-pkg-libc6.5-6-4.4 but not libapt-pkg-libc6.3-6-3.11). Welcome to unstable. A new package will be uploaded before too long. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374396: perl: FTBFS on MIPS/hppa
On Mon, Jul 24, 2006 at 05:44:22PM +0200, Sven Mueller wrote: Is there any chance to get this fixed within the next week or two? It's already blocking something like 60 packages from entering testing. Not a whole lot that I can do about it. Ryan believes that the problem with MIPS is a kernel issue, and was planning to upgrade the kernel on the buildds soonish. As far as hppa goes, perl-5.8.8-5 successfully autobuilt on bld-3, then -6 failed on the same machine. There are no significant code changes between those perl versions--the keyword register was removed from a header file as a work-around for gcc-4.1 (gcc folks said that in the context, it was ignored anyway). From the build logs*, it appears that the same kernel (2.6.12-10-hppa64) was running for both builds, but the toolchain was different: OK: libc6-dev_2.3.6-7 linux-kernel-headers_2.6.13+0rc3-2.1 gcc-4.0_4.0.3-3 g++-4.0_4.0.3-3 binutils_2.16.1cvs20060413-1 libstdc++6-4.0-dev_4.0.3-3 libstdc++6_4.1.0-4 FAIL: libc6-dev_2.3.6-13 linux-kernel-headers_2.6.13+0rc3-2.1 gcc-4.1_4.1.1-2 g++-4.1_4.1.1-2 binutils_2.16.1cvs20060413-1 libstdc++6-4.1-dev_4.1.1-2 libstdc++6_4.1.1-2 Would it be possible to get the hppa build retried with the most recent version of gcc-4.1 (-9) please? --bod * http://buildd.debian.org/fetch.php?pkg=perlver=5.8.8-5arch=hppastamp=1149353856file=logas=raw http://buildd.debian.org/fetch.php?pkg=perlver=5.8.8-6arch=hppastamp=1150209684file=logas=raw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335105: perl FTBFS in t/op/fork
reassign 335105 kernel close 335105 2.6.5 thanks On Sun, Dec 11, 2005 at 10:24:56AM +, Andrew Suffield wrote: My bet is that it's this kernel bug: I don't know if you've been following, but it was recently discoverd that on smp, if multiple processes read from /dev/urandom at the same time, they can get the same data. Theodore Tytso posted a patch to fix this for 2.6, and someone else told me this problem has existed all the way back to 1.3. Fixed in 2.4.29 and 2.6.5. What kernel version have you got there? If it's 2.4.27 (sarge) then I think we have our problem found. Thanks Andrew, This does appear to be the cause of the problem. I tracked down the original patch which added the fork/rand test. The intent of the addition is to test rand (specifically the implicit srand on first call) rather than fork: a change in 5.8.1 to randomise hash ordering was causing an implicit call of srand when perl was started, causing a behaviour change: $ perl -le 'fork; print rand' was printing the same value twice. Re-assigning to kernel and closing. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231082: spamassassin: spamc hangs since most recent perl package updates for stable
On Mon, Apr 12, 2004 at 03:31:35PM -0700, Peter Sebastian Masny wrote: I have what I believe is the same problem using working postfix and procmail. In detail: apt-get install spamassassin librazor-perl enable spamd in /etc/default/spamassassin /etc/init.d/spamassasin restart then in my user .procmailrc I added :0fw |/usr/bin/spamc However, spamc gets stuck. The procmail log reads: procmail: [22511] Mon Apr 12 13:06:56 2004 procmail: Executing /usr/bin/spamc and no more. About 15 minutes later the following is added to the procmail log [22511] Mon Apr 12 13:22:56 2004 procmail: Timeout, terminating /usr/bin/spamc procmail: [22511] Mon Apr 12 13:22:56 2004 procmail: Rescue of unfiltered data succeeded I can't duplicate this on unstable with the current versions of perl and spamassassin. Is this still an issue, or can it be closed. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353761: perl: Perl lib version (v5.8.4) doesn't match executable
On Tue, Feb 21, 2006 at 10:54:08AM +0100, Ulrich Fürst wrote: Steve Langasek [EMAIL PROTECTED] wrote: Please forward the output of ls -ld /usr/lib/perl/5.8 to this bug. ls -ld /usr/lib/perl/5.8 drwxr-xr-x 27 root root 4096 2006-02-20 15:02 /usr/lib/perl/5.8/ This should be a symlink belonging to the perl-base package, and it should be pointing at /usr/lib/perl/5.8.7. Yours apparently is not. I suspect this is an instance of local breakage, not a packaging bug. It is possible that the cause of this problem is a package which has mistakenly installed to the CORE (archlib=/usr/lib/perl/5.8) rather than vendor directories. If such a package were to be installed *before* perl, then a directory would be created, which dpkg would then honour when unpacking perl, rather than creating the symlink. Please check the output of 'dpkg -S /usr/lib/perl/5.8'. You should only get 'perl-base' as a match. If any other packages appear, please file a bug on that package. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325528: libm17n-0: segfaults with mgp, rendering it unusuable
tags 325528 - unreproducible tags 325528 + patch found 325528 1.2.0-5 thanks On Tue, Aug 30, 2005 at 04:22:36AM +0900, Hidetaka Iwai wrote: Marc Dequènes (Duck) [EMAIL PROTECTED] wrote: Using any sample file provided with mgp resulted in a segfault after rendering background, so i guess when rendering text. See the attached backtrace showing segfault occuring deep in libm17n (which made me report on libm17n-0 instead of mgp). I can't reproduct this problem with mgp 1.11b-5 on the following environment, so could you please give me more information? The problem appears to be caused by fonts which have no family, an example being -cronyx-nil-medium-r-normal--2-20-75-75-c-10-iso10646-1 (from xfonts-cronyx-misc). Such fonts cause mplist_find_by_key(plist, family) to match a list entry with a NULL key. As this entry also has a NULL val, xfont_table becomes NULL, which causes the SEGV at m17n-X.c:560 in the initial bug report: MLIST_APPEND1(xfont_table, fonts, font, MERROR_WIN); I'm not sure how these fonts should be handled, but the following patch removes the SEGV (by skipping fonts with no family). --bod --- m17n-lib-1.2.0.orig/src/m17n-X.c2004-11-08 18:49:10.0 +1100 +++ m17n-lib-1.2.0/src/m17n-X.c 2006-01-03 18:53:01.603258394 +1100 @@ -488,6 +488,9 @@ int base_len; int fields; + if (!family) + continue; + if (p MPLIST_KEY (p) != family) p = mplist_find_by_key (plist, family); if (p) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341542: perl: Still vulnerable...
On Thu, Dec 08, 2005 at 12:41:02PM -0800, Charles Stevenson wrote: [EMAIL PROTECTED]:~$ perl -e 'printf(%2918905856\$vs)' Segmentation fault I haven't had time yet but I imagine it might be possible to gain root through perl-suid. This is not a buffer overflow. You're causing a SEGV by attempting to address a non-existant argument to printf. You don't need a large number to do this--the same happens with: perl -e 'printf q/%1$vs/' Addressing memory (or the failure to do so) is not a security risk in the same way that a buffer overflow is: the program simply aborts as opposed to continuing to run, potentially executing exploit code. It may be worth considering bounds-checking the index to svargs, if only to produce a more meaningful error than Segmentation fault. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341542: CVE number
On Fri, Dec 02, 2005 at 10:55:56AM +0100, Martin Pitt wrote: The CVE number CVE-2005-3962 has been assigned to this. Please mention this number in the changelog when you fix this. Yes, Fedora quoted that number in their advisory. Oddly, cve.mitre.org doesn't appear to have that have a match for that number. I've prepared a preliminary upload incorporating change 26240, although am holding off for a bit, as there would appear that there may be more than one patch required: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2005-12/msg00030.html --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339955: sysv-rc: /etc/init.d/*.sh should be sourced in runlevel S
On Mon, Nov 21, 2005 at 09:55:22AM +0100, Thomas Hood wrote:
Brendan O'Dea wrote:
there are quite a few instances in /etc/init.d/*.sh scripts where exit is
called.
All the exit commands are either (1) at the end of usage exception sections,
or (2) preceded by colons ':'. Testing suggests that a : exit 0 does the
same as :, namely, nothing.
Yes, : is a no-op, which returns true. Sometimes used for side-effects:
: ${foo:=bar} # set foo=bar if not set
Not all instances are harmless. Take /etc/init.d/hwclock.sh for example
(util-linux):
[ ! -x /sbin/hwclock ] exit 0
chmod -x /sbin/hwclock should not stop my system from booting.
--bod
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339955: sysv-rc: /etc/init.d/*.sh should be sourced in runlevel S
On Mon, Nov 21, 2005 at 09:34:11AM +0100, Thomas Hood wrote: Brendan O'Dea wrote: Note: I believe that return should work to exit from a script both when sourced and when executed but perhaps someone with a copy of POSIX could confirm. Disconfirmation: $ cat /tmp/s #!/bin/bash echo foo return echo bar [EMAIL PROTECTED]:~/src/sysvinit/pkg-sysvinit/sysvinit/trunk/debian/initscripts/etc/init.d$ /tmp/s foo /tmp/s: line 3: return: can only `return' from a function or sourced script bar Bleah, I tested with sh test-script, forgetting that I have sh as an alias for $SHELL (ksh). In which case, what's needed is return N 2/dev/null || exit N, which should cover all cases. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339955: sysv-rc: /etc/init.d/*.sh should be sourced in runlevel S
Package: sysv-rc Version: 2.86.ds1-5 Severity: serious Debian Policy states (§9.3.1): Also, if the script name ends `.sh', the script will be sourced in runlevel `S' rather that being run in a forked subprocess, but will be explicitly run by `sh' in all other runlevels. This could probably be achieved with the attached patch, although there are quite a few instances in /etc/init.d/*.sh scripts where exit is called. These scripts need to be changed to use return* appropriately before the behaviour is changed. Note: I believe that return should work to exit from a script both when sourced and when executed but perhaps someone with a copy of POSIX could confirm. --bod --- /etc/init.d/rc.orig 2005-11-20 08:43:41.0 +1100 +++ /etc/init.d/rc 2005-11-20 08:55:10.0 +1100 @@ -37,12 +37,14 @@ action=$1 shift scripts=$@ +sh=sh +[ S = $runlevel ] sh=. case $CONCURRENCY in none) for script in $scripts ; do case $script in *.sh) - $debug sh $script $action + $debug $sh $script $action ;; *) $debug $script $action -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339955: [Pkg-sysvinit-devel] Bug#339955: sysv-rc: /etc/init.d/*.sh should be sourced in runlevel S
On Sat, Nov 19, 2005 at 11:33:44PM +0100, Petter Reinholdtsen wrote: [Brendan O'Dea] Debian Policy states (§9.3.1): Also, if the script name ends `.sh', the script will be sourced in runlevel `S' rather that being run in a forked subprocess, but will be explicitly run by `sh' in all other runlevels. What a strange thing for policy to specify. :) I'm not quite sure what the initial rationale was, although Adam Heath suggested on IRC that it could be to allow scripts to set environment variables which would propagate through to subsequent scripts. This will make it impossible to speed up the rcS.d boot by running scripts in parallel. It does not sound sensible to me. Yes, I saw CONCURRENCY in /etc/init.d/rc. Not quite sure how that's supposed to work with a value of shell. I presume that startpar is/will be a helper function/script that interprets the LSB Required-Start pseudo header? This could probably be achieved with the attached patch, although there are quite a few instances in /etc/init.d/*.sh scripts where exit is called. These scripts need to be changed to use return* appropriately before the behaviour is changed. Well, I would be surprised if any of the scripts used in rcS.d uses exit, as this would break the boot. It won't currently, but will if the patch is applied. $ grep -lw exit /etc/rcS.d/*.sh | wc -l 12 --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334030: perl_5.8.7-6(m68k/unstable):
On Fri, Oct 14, 2005 at 12:44:33PM +0200, [EMAIL PROTECTED] wrote: Package: perl Version: 5.8.7-6 Severity: serious There was an error while trying to autobuild your package: Automatic build of perl_5.8.7-6 on ska by sbuild/m68k 69 Build started at 20051013-0833 [...] ** Using build dependencies supplied by package: Build-Depends: file, cpio (= 2.6-5), libdb4.2-dev, libgdbm-dev, netbase [!hurd-i386], gcc (= 4:4.0) [...] ### You may have to set your dynamic library search path, ### LD_LIBRARY_PATH, to point to the build directory: ### setenv LD_LIBRARY_PATH `pwd`:$LD_LIBRARY_PATH; cd t; ./perl harness ### LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH; cd t; ./perl harness ### export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH; cd t; ./perl harness ### for csh-style shells, like tcsh; or for traditional/modern ### Bourne-style shells, like bash, ksh, and zsh, respectively. u=168.79 s=18.99 cu=18908 cs=1628.38 scripts=914 tests=101051 make[3]: *** [_test_notty] Error 1 make[3]: Leaving directory `/build/buildd/perl-5.8.7' make[2]: *** [_test] Error 2 make[2]: Leaving directory `/build/buildd/perl-5.8.7' make[1]: *** [test] Error 2 make[1]: Leaving directory `/build/buildd/perl-5.8.7' make: *** [libperl.so.5.8.7] Error 1 A full build log can be found at: http://buildd.debian.org/build.php?arch=m68kpkg=perlver=5.8.7-6 From the looks of the test (t/op/rand.t) it would appear that there is the rare potential for it to fail. I suspect that this is a false positive. You can confirm by running make test from the build directory. If it fails again then there's a real problem. There will be a new upload shortly: I'm working on a fix for arm now. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333510: [FTBFS] perl fails on arm with -O2
On Wed, Oct 12, 2005 at 12:01:03PM +0300, Riku Voipio wrote: Perl fails to build on arm/armeb with -O2 optimization and current gcc4. with -01, perl compiled fine and pass testsuites withoout a problem. By using the following patch instead of the current 63_debian_ppc_opt.. patch, this (gcc) issue can be worked around. Building a new package now. I've dropped the optimisation on only the following files (which proved to be the source of the problem on other architectures): pp_ctl.c, pp_hot.c and pp_sort.c . If this doesn't fix the problem, re-open and I'll drop everything to -O1. Would have tested this first, but unfortunately there doesn't seem to be an arm machine available for developers right now... --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#326090: perl: 'libperl.so' missing in 'libperl-dev' package
reassign 326090 cpio
retitle 326090 cpio -p does not copy dangling symlinks
thanks
On Thu, Sep 01, 2005 at 08:33:08PM +0200, Andreas Jochens wrote:
Without 'libperl.so' some packages which Build-Depend on
'libperl-dev' will FTBFS.
This build worked fine when originally run. It appears that the
behaviour of cpio has changed with respect to dangling symbolic links.
$ mkdir -p /tmp/cpio-test/{a,b}
$ cd /tmp/cpio-test
$ ln -s foo a/bar
$ cd a; echo bar | cpio -vdumpl ../b
cpio: bar: No such file or directory
0 blocks
This worked in previous versions of cpio (2.4.2 for example).
--bod
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322746: any progress?
On Thu, Aug 18, 2005 at 10:19:48PM +0200, martin f krafft wrote: Is there any progress being made on this bug? I can't install any more debconf-using packages on my system, or packages uses perl for maintainer scripts, and this is quite bad. I haven't been able to replicate the problem. debconf, perl and libc 2.3.5-3 have been working fine on my i386, sparc and powerpc systems. # dpkg-reconfigure locales [...] Generating locales (this might take a while)... [...] Generation complete. # Running the test given in #304604 of: # MALLOC_CHECK_=3 dpkg-reconfigure dash malloc: using debugging hooks [...] malloc: using debugging hooks # Issues several of the malloc messages shown above, but no complaints about free. Perhaps this is related to a specific debconf frontend? # debconf-show debconf * debconf/frontend: Dialog * debconf/priority: medium # --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279232: What about perl-bug #279232?
On Fri, Apr 08, 2005 at 08:36:05AM +0200, Henning Glawe wrote: it could be fixed by introducing a versioned pre-dependency of perl-modules on perl-base while letting perl-base conflict with too old perl-modules, which forces apt to update both packages together; this combination may be highly unstable (conflicts+pre-depends is a loop-like construct), but results in the right behaviour. Given an alternate option I'd really rather not do this. It seems fragile at best, disasterous at worst. Given the recent freeze announcement, I'd suggest that regardless of what other fixes are made, a good first step would be to get a fixed doc-base (i.e. one that works with the current stable perl-base only) package into stable-proposed-updates *now*. If nothing else, this reduces the size of the problem if there's a point release prior to sarge. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286905: [vendor-sec] CAN-2004-0452 File::Path::rmtree() vulnerability
On Fri, Feb 04, 2005 at 03:32:05PM +0100, Thierry Carrez wrote:
Brendan O'Dea wrote:
Seems a pretty clean fix, I've applied this to Debian's 5.8.4-5 package.
Paul Szabo brought to our attention that the fix for CAN-2004-0452 does
not handle all race conditions cases and that rmtree is still vulnerable :
=
Just changing the chmod to 0700 and 0600 instead of 0777 and 0666
does NOT solve the issue. The chmod change was for another, but related,
problem. See bugs.debian.org/286905 and 286922.
=
Apparently discussion still rages on how this would best be fixed.
Any clue ?
Well actually, discussion doesn't rage at all as to how this should be
fixed.
Basically it's been acknowledged as a problem, but one that requires
more than a trivial patch to rmtree to correct, so as such is currently
languishing until such time as rmtree is rewritten to remove the race
condition.
I was kind of hoping that someone else would tackle that task since I
don't really regard myself as a security expert and did't want to make
the problem worse by introducing new, different security issues with a
recursive implementation.
However in the absence of any alternate suggestion, I've appended a
first-cut rmtree replacement.
For the moment I've ignored the third argument entirely; tempted to do
so permanently.
I've also ignored $Is_VMS and $Is_MacOS; will need some input from
perl5-porters as to what changes are required to support those
platforms.
--bod
use strict;
use warnings;
use Carp;
use Cwd 'getcwd';
sub _rmtree;
sub _rmtree
{
my ($path, $prefix, $up, $up_dev, $up_ino, $verbose) = @_;
my ($dev, $ino) = lstat $path or return 0;
unless (-d _)
{
unlink $path or return 0;
print unlink $prefix$path\n if $verbose;
return 1;
}
chdir $path or return 0;
# avoid a race condition where a directory may be replaced by a
# symlink between the lstat and the chdir
my ($new_dev, $new_ino) = stat '.';
unless ($new_dev:$new_ino eq $dev:$ino)
{
croak Directory $prefix$path changed before chdir, aborting\n;
}
my $count = 0;
if (opendir my $dir, '.')
{
my $entry;
while (defined ($entry = readdir $dir))
{
next if $entry =~ /^\.\.?$/;
$count += _rmtree $entry, $prefix$path/, '..', $dev, $ino,
$verbose;
}
closedir $dir;
}
# don't leave the caller in an unexpected directory
unless (chdir $up)
{
croak Can't return to $up from $prefix$path ($!)\n;
}
# ensure that a chdir .. didn't take us somewhere other than
# where we expected (see CVE-2002-0435)
unless (($new_dev, $new_ino) = stat '.'
and $new_dev:$new_ino eq $up_dev:$up_ino)
{
croak Previous directory $up changed since entering $prefix$path\n;
}
if (rmdir $path)
{
print rmdir $prefix$path\n if $verbose;
$count++;
};
return $count;
}
sub rmtree
{
my ($p, $verbose) = @_;
$p = [] unless defined $p and length $p;
$p = [ $p ] unless ref $p;
my @paths = grep defined length, @$p;
unless (@paths)
{
carp No root path(s) specified\n;
return;
}
my $oldpwd = getcwd or do {
carp Can't fetch initial working directory\n;
return;
};
my ($dev, $ino) = stat '.' or do {
carp Can't stat initial working directory\n;
return;
};
my $count = 0;
for my $path (@paths)
{
$count += _rmtree $path, '', $oldpwd, $dev, $ino, $verbose;
}
$count;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286905: perl-modules: File::Path::rmtree makes setuid
On Wed, Jan 12, 2005 at 05:02:41PM -0500, Aaron Sherman wrote: [p5p:] If anyone had a cleaner (and cross-platform) fix, I'd love to hear of it. Well, certainly relying on rm (and you assumed a -v option which, AFAIK implies GNU rm specifically) is right out. I'm sure others will say the same. Sure, it was proposed as a quick hack for the Debian package, where it is safe to assume /bin/rm is from GNU coreutils. If it weren't for the requirement to retain the current API (returning the number of deletions, and verbose output) then a thin wrapper around system 'rm', '-rf', @paths would suffix for POSIX systems. Quick fix? Reduce the race by making any changes just before and just after an operation, not in preparation for a whole directory. Now you still have a problem, but a smaller one. A race is a race, no matter how small the window. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
