On Fri, 23 Feb 2024, Santiago Ruano Rincón wrote:
> Really sorry, this has fallen through the cracks.
Thanks - no problem, happens.
> Could you please confirm the version available in this repo fixes the
> issue:
>
> https://debian.pages.debian.net/-/isc-dhcp/-/jobs/5350735/artifacts/aptly/inde
Hallo,
It seems that this bug (fixed for Debian Unstable) "PECL extensions
FTBFS with PHP Fatal error: Call to a member function getFilelist()
on null" now appeared in Debian Stable (Jessie) with the PHP5 security
updates, but there missing the fix introduced.
To reproduce try rebuilding the p
> 2016-03-15 13:46:49 status unpacked kpartx:amd64 0.5.0+git1.656f8865-7
> 2016-03-15 13:46:49 status half-configured kpartx:amd64
> 0.5.0+git1.656f8865-7
> 2016-03-15 13:46:49 status installed kpartx:amd64 0.5.0+git1.656f8865-7
>
> On Tue, 2016-03-15 at 17:30 +0100, Sven-Haeg
Hallo,
This bug is not fixed yet - maybe just an empty pre-removal script will
help?
Preparing to unpack .../kpartx_0.5.0+git1.656f8865-7_amd64.deb ...
Failed to stop multipathd.service: Unit multipathd.service not loaded.
dpkg: warning: subprocess old pre-removal script returned error exit
sta
Package: joe
Version: 3.7-2.1
Severity: grave
Justification: renders package unusable
Upgrading joe from 3.7-2 to 3.7-2.1 fails:
Setting up joe (3.7-2.1) ...
update-alternatives: error: alternative editorrc can't be slave of editor:
it is a master alternative.
dpkg: error processing joe (--config
On Tue, 7 Jun 2011, Dima wrote:
> > > But it was in an inline function in that header, so if some binary
> > > package was built on a machine with ancient libc6-dev, that could be a
> > > half-explanation. Where do you get your binary packages from?
> >
> > ftp.de.debian.org
> >
> I also get my p
On Tue, 7 Jun 2011, Jonathan Nieder wrote:
> Sven-Haegar Koch wrote:
>
> > While upgrading from libc6 2.13-4 to 2.13-5 on a i386 system:
> >
> > Preparing to replace libc6 2.13-4 (using
> > .../archives/libc6_2.13-5_i386.deb) ...
> > Unpacking replacement li
Package: libc6
Version: 2.13-5
Severity: critical
Justification: breaks the whole system
While upgrading from libc6 2.13-4 to 2.13-5 on a i386 system:
Preparing to replace libc6 2.13-4 (using .../archives/libc6_2.13-5_i386.deb) ...
Unpacking replacement libc6 ...
Setting up libc6 (2.13-5) ...
In
Package: iceape-browser
Version: 2.0.4-2
Severity: serious
Justification: Policy 9.1.1
The package contains the following files in an invalid location, it should
never create the directory structure starting with /mozilla:
hae...@aurora:~$ grep ^/mozilla /var/lib/dpkg/info/iceape-browser.list
/
Peter Samuelson wrote:
I came up with several ways around this - the latest is to use
libneon24 but *not* link libssl0.9.8. There was never any reason for
us to link to openssl at all; this was a packaging bug.
Can you please retest with my packages at
http://p12n.org/tmp/svn-336373/ ?
Havin
10 matches
Mail list logo
