Hi,
On 18.09.23 19:38, Julian Andres Klode wrote:
I'm not sure how that works because you'd need to respawn yourself
with systemd-inhibit, whereas the API essentially gives you a file
descriptor over dbus that you keep open until it is safe to reboot.
popen("systemd-inhibit ... cat",
Hi,
On Mon, Feb 17, 2020 at 04:49:44PM +0100, Jean-Marc LACROIX wrote:
> >Could you attach the old base-passwd.list file?
> yes, in attached file.
That file has a sensible size, but consists of only zeroes. This typically
happens with file systems that have metadata only journaling after a
Hi,
On Mon, Feb 17, 2020 at 10:31:25AM +0100, Jean-Marc LACROIX wrote:
> dpkg: unrecoverable fatal error, aborting:
> files list file for package 'base-passwd' is missing final newline
> E: Sub-process /usr/bin/dpkg returned an error code (2)
That file is generated by dpkg on installation, so
Package: dpkg
Version: 1.18.15
Severity: minor
Hi,
when building the piglit package, the dpkg-shlibdeps invocations take
upwards of 30 minutes (on an i7, building inside a tmpfs). Most of the
time seems to be spent spawning several thousand instances of dpkg-query.
Is there a way to speed this
Package: dpkg
Version: 1.18.10
Severity: wishlist
Hi,
I have several packages that use additional .orig archives for program
modules, but these are almost always expected in a nested subdirectory for
the package build, e.g. "modules/foo". It would be nice if there was a way
to ship this as a
Hi,
On Tue, Aug 03, 2010 at 04:01:48PM -0400, Loïc Minier wrote:
I wonder whether it makes sense to look into /usr/lib at all when
cross-building?
Not really, I think.
If that's not an option, I think the routine checking the format of
executable could run the cross-objdump and if it
Package: dpkg
Version: 1.15.8.2
Severity: normal
Hi,
while using the target objdump is a Good Thing(tm), it uncovered another
bug: for dependent libraries, the host's version is passed to the target
objdump.
While this looks like a regression as builds that used to work now fail,
it isn't,
Package: dpkg
Version: 1.15.5.2
Severity: wishlist
User: debian-embed...@lists.debian.org
Usertags: multiarch-cross
Hi,
We would like to allow people to prepare their packages for
cross-compiling. Most functionality is already in place, however we are
still lacking a way to distinguish between
Package: dpkg
Severity: normal
Hi,
any news on this?
Simon
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=ja_JP.UTF-8,
Hi,
On Sat, Jun 27, 2009 at 09:23:29AM +0300, Modestas Vainius wrote:
While it is a good idea worth consideration but I think demangled symbol
names are somewhat too ambiguous to be used in general. See below:
[Examples]
Not a problem IMO -- we need a new package name anyway if gcc's ABI
Package: dpkg
Version: 1.15.2
Severity: minor
Tags: l10n
Hi,
dpkg occasionally prints the warning
dpkg: Warnung: veraltete Option »--print-installation-architecture, bitte
verwenden Sie »--print-architecture« stattdessen.«
The correct quotation marks for German are „quote“ or «quote», the
Package: dpkg
Version: 1.14.12
Severity: wishlist
Tags: patch
Hi,
the attached patch adds a new variable DEB_VARIANT to the build
environment, which can be used to build different binary packages out of
the same source package in different circumstances.
The most obvious application would be
Package: dpkg
Version: 1.14.7
Followup-For: Bug #398625
Hi,
I have written a new implementation of the patch proposed earlier,
against the current shell script.
This patch tries to address all the concerns raised so far, however it
introduces some ugliness in doing so: behaviour depends on the
Hi,
Guillem Jover wrote:
What you describe is a binNMU but with a different suffix. Maybe we
could come up with a generic syntax for binNMU-style versions, which
could include backports and the like.
That would be difficult. For example, for my cross-toolchain backports I
use ~debian4.0+b1
Hi,
Andreas Metzler wrote:
---
Somehow make dpkg-buildpackage -B make use of the build-arch target
if present. Either by detecting it automatically or by something like
#229357.
---
The entire issue circles around not being able to reliably detect
whether the target
Hello,
Goswin von Brederlow wrote:
The seconds part requires that tools like sbuild and pbuilder know
beforehand if build or build-arch will be used.
For packages that do not implement build-arch, it is acceptable to call
the build target with only B-D installed, because that is the way the
16 matches
Mail list logo
