Please give back firebird2.5 on s390x
wb gb firebird2.5_2.5.2~svn+54698.ds4-1 . s390x The regular build[1] failed with a very strange error in the package creation phase: dpkg-shlibdeps: error: dpkg-query --control-path libicu48:s390x symbols died from signal 11 [1] https://buildd.debian.org/status/fetch.php?pkg=firebird2.5arch=s390xver=2.5.2%7Esvn%2B54698.ds4-1stamp=1341081509 Searching other build logs or dpkg bugs showed nothing, so my assumption is that this is a transient problem that can be fixed by retrying the build. Should the rebuild fail again at the same place, I'll file a bug to dpkg. Cc-ing dpkg-maintainers in case they want to investigate further. Thanks! signature.asc Description: Digital signature
Bug#518453: #518453 -- dpkg-source is 5 times slower than quilt applying patches
It seems to me that the reason for dpkg-source applying patches slower than plain quilt push -a is that it invokes quilt once for each patch. Perhaps quilt does some preparation on each invocation and when called multiple times that accumulates. (mkdir glibc-2.9/debian/source; \ echo 3.0 (quilt) glibc-2.9/debian/source/format) $ time dpkg-source --without-quilt -b glibc-2.9 ... real1m6.618s user0m24.906s sys 0m45.139s $ time dpkg-source -b glibc-2.9 ... real1m45.576s user0m40.831s sys 1m3.688s -- damJabberID: d...@jabber.minus273.org signature.asc Description: Digital signature
Bug#677865: Re: Bug#677865: dpkg-gencontrol warns about 'File::FcntlLock not available'
-=| Jens Thoms Toerring, 25.05.2014 23:01:34 +0200 |=- since I got no complaints about the new version of the File::FcntlLock module I just uploaded it to CPAN. I hope that it will help to avoid the problems you had with it. Package libfile-fcntllock-perl upgraded to 0.16 and uploaded to Debian unstable. signature.asc Description: Digital signature
Re: Bug#878901: dh-make-perl: FTBFS with dpkg >= 1.19: "Insecure dependency in eval while running with -T switch"
-=| Guillem Jover, 17.10.2017 22:16:31 +0200 |=-
> On Tue, 2017-10-17 at 19:48:07 +0300, Niko Tyni wrote:
> > It looks like Dpkg::Vendor::get_vendor_info() contents have become
> > tainted, probably due to changes in Dpkg::Control::HashCore. It used to
> > dig the values out with regexp captures but now uses split.
> >
> >
> > https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?h=sid=9e5e03e9a6ddf74bb22ffc5ea8794a14a592d6b6
> >
> > A test case is
> >
> > perl -T -MDpkg::Vendor=get_vendor_info -MScalar::Util=tainted -e 'die if
> > tainted get_vendor_info()->{Vendor}'
> >
> > which dies on libdpkg-perl 1.19.0.1 but not 1.18.24.
> >
> > I don't know if the earlier untainting was accidental or intended.
> > Copying the dpkg maintainers.
>
> TBH, I was not aware that anyone was running Dpkg modules in taint
> mode. And I don't think anyone has writen code for the modules with
> that in mind. I'm not sure either how much of it is taint clean, for
> example.
>
> If people are really running this code in taint mode, I'm willing to
> discuss which parts of the API would make sense to cover or not, and
> what tradeoffs related to performance to take, etc.
I think that using taint mode wasn't justified in that one case, so
imposing that on Dpkg::* would not be necessary.
During discussion, Matt S. Trout suggested on IRC that the check for
a valid package name is better written as $input =~
/\A([A-Za-z]\w*(?:::\w+)*)\Z/. If no hierarchy is possible, then
/\A([A-Za-z]\w*/ would be enough.
(Perhaps this belongs to the place where $name is interpreted as
a module name, not when parsing generic label:value lines).
That may be considered nitpicking, especially without a view on the
big picture, but I'd rather mention it here in case it is useful.
-- dam
