Bug#910377: System-critical package management
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", "w");
should work.
Simon
OpenPGP_signature
Description: OpenPGP digital signature
Bug#951479: [files list file for package 'base-passwd' is missing final newline] [debian buster 10.3]
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 power loss, as the metadata update is covered by the journal and can be replayed, while the data write itself is lost. That can happen e.g. with ext4 in "data=writeback" mode, which is discouraged precisely for that reason. Simon
Bug#951479: [files list file for package 'base-passwd' is missing final newline] [debian buster 10.3]
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 it's not the package's fault. The "final newline" check is a safety check to see that the file name is complete, guarding against write errors. You need to reinstall the base-passwd package, possibly after deleting /var/lib/dpkg/info/base-passwd.list, and I'd also run a file system check for good measure, because that state should only happen on write errors (although I remember it also sometimes happened when /var was full, but IIRC that got fixed). Simon
Bug#846405: dpkg-shlibdeps: scales badly for many binaries
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 up, e.g. with a cache? Simon -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-8 ii libc62.24-5 ii liblzma5 5.2.2-1.2 ii libselinux1 2.6-3 ii tar 1.29b-1.1 ii zlib1g 1:1.2.8.dfsg-2+b3 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 1.3.1 -- no debconf information
Bug#840308: dpkg: extraction of additional orig archives into nested subdirectory
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 separate archive instead of repacking the source. Simon -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-8 ii libc62.23-5 ii liblzma5 5.1.1alpha+20120614-2.1 ii libselinux1 2.5-3 ii tar 1.29b-1 ii zlib1g 1:1.2.8.dfsg-2+b1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 1.3~rc4 -- no debconf information
Bug#591522: dpkg-shlibdeps still fails when cross-compiling
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 fails try the host > objdump as a fallback. I have an use case here where the native objdump will fail on the target binary, so if there is a fallback, it needs to be per-file. I also wonder whether "objdump fails to read it" might already be a strong hint that the file is the wrong version. If another file exists that can be read using the targetted objdump, and has the correct architecture, then I'd expect the build to continue, and ideally, to not complain too loudly. Simon -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#591522: dpkg-shlibdeps still fails when cross-compiling
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, because the builds were only correct by chance before. Symptom is that during a cross build of a library that links against libutil, the following is output: m68k-linux-gnu-objdump: /lib/libutil.so.1: File format not recognized dpkg-shlibdeps: error: m68k-linux-gnu-objdump gave error exit status 1 The correct file would be /usr/m68k-linux-gnu/lib/libutil.so.1 . The path can be retrieved from the target gcc using the -print-search-dirs option. Simon -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg depends on: ii coreutils 8.5-1 GNU core utilities ii libbz2-1.01.0.5-4high-quality block-sorting file co ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libselinux1 2.0.96-1 SELinux runtime shared libraries ii xz-utils 4.999.9beta+20100713-1 XZ-format compression utilities ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.7.25.3 Advanced front-end for dpkg -- no debconf information -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539038: dpkg: please add support for ad-hoc architecture definitions
Hi, On Sun, Oct 25, 2009 at 05:23:46PM +0100, Guillem Jover wrote: > > As discussed during DebConf, I agree with the goal but I'm not entirely > > happy with the proposed use of “x-”, as the dash breaks current > > assumptions of what's what depending on the position relative to it. > What I've been thinking about is to use a different character, for > example ~, so we'd have “~arch” denoting an unofficial architecture, > or “~foo-bar” which would not break the - notation. I've tried with a tilde both as prefix and as suffix, and both are a mess to get working properly through the entire toolchain: - (suffix) Architecture specific debhelper files are interpreted as backup files by dh_clean and subsequently deleted - (prefix) If the argument to -a is separated with a space, the shell could interpret it as a home directory - dpkg-buildpackage refuses the architecture name while parsing dpkg-architecture output - dpkg-cross generates an invalid package name when it copies the architecture name into the generated package's name The latter two are fixable, but mean that more tools are affected; the former two I believe to be real showstoppers. I think the "x-" notation is the cleanest one still; the other options I can see are "unofficial-" (but third party vendors might not like to have the word "unofficial" show up in every package name), "vendor-" (somewhat nice, as you can follow it up with a vendor name), a percent sign (still requires massive changes, but at least no showstoppers here), or an underscore (probably breaks other stuff as it is used as a field separator in several places, but at least there is precedent for a trailing underscore as a marker in dpkg). Simon -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#558095: dpkg: please accept ":native" multiarch qualifier in build dependencies
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 build dependencies that are
required as tools (e.g. debhelper) or for building a tool (e.g. zlib-dev
for building a jar archiver which is then used to build a JAR file), and
build dependencies required for linking (e.g. zlib-dev for building a
java interpreter which can then unpack the JAR file).
The multiarch specification solves this to some extent, as tools are
marked "Multi-Arch: foreign" and libraries "Multi-Arch: same", which
allows us to have reasonable defaults by requiring "foreign" packages to
be installed in working order (i.e. preferentially DEB_BUILD_ARCH, but
any working one will do) and "same" packages in the version required for
linking (i.e. DEB_HOST_ARCH).
The cases not handled by the multi-arch specification are:
- A library package (M-A: same) is to be installed for DEB_BUILD_ARCH.
- A hybrid package (M-A: allowed) is to be installed for
DEB_BUILD_ARCH.
- A hybrid package (M-A: allowed) is to be installed for any
architecture.
The last case is somewhat implied in the original specification (":any"
qualifier in Depends lines), but never explicitly allowed for
Build-Depends; the others require introducing a new qualifier that is
only meaningful in build dependencies.
In phase one, which needs to happen before the squeeze release for this
to be useful, it would therefore be good if ":any" and ":native"
qualifiers in build dependencies were accepted. As Debian itself does
not yet cross-compile packages, actually supporting the specified
resolution is optional (but would be nice to have in
dpkg-checkbuilddeps).
A minimal implementation would accept those qualifiers in all tools that
handle Build-Depends fields, but interpret the field as if the
qualifiers were not present (thus falling back to the strictest possible
interpretation for a native build).
A full implementation would resolve the dependencies according to the
table on the specification page[1].
Simon
[1] https://wiki.ubuntu.com/MultiarchCross
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539038: please add support for ad-hoc architecture definitions
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, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg depends on: ii coreutils 7.5-6 GNU core utilities ii libc6 2.9-27 GNU C Library: Shared libraries ii lzma 4.43-14Compression method of 7z format in dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.7.24 Advanced front-end for dpkg -- no debconf information -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539038: dpkg: please add support for ad-hoc architecture definitions
Package: dpkg
Version: 1.14.25
Severity: wishlist
Tags: patch
Hi,
this patch adds an exception to dpkg-architecture that allows architecture
names that start with "x-" as long as a GNU architecture name is also
specified.
This is incredibly useful if one wants to define local architectures for
cross-compiling (using both -a and -t to dpkg-buildpackage works).
The downside is that DEB_HOST_ARCH_OS and DEB_HOST_ARCH_CPU cannot be
automatically set to sane values, which I think is a limitation one can
live with.
Simon
-- System Information:
Debian Release: 5.0.2
APT prefers stable
APT policy: (990, 'stable'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages dpkg depends on:
ii coreutils 6.10-6 The GNU core utilities
ii libc6 2.7-18 GNU C Library: Shared libraries
ii lzma 4.43-14Compression method of 7z format in
dpkg recommends no packages.
Versions of packages dpkg suggests:
ii apt 0.7.20.2+lenny1 Advanced front-end for dpkg
-- no debconf information
--- /usr/bin/dpkg-architecture.orig 2009-07-19 19:03:35.0 +0200
+++ /usr/bin/dpkg-architecture 2009-07-19 19:11:14.0 +0200
@@ -152,7 +152,7 @@
unless defined $req_host_arch;
}
-if ($req_host_gnu_type ne '' && $req_host_arch ne '') {
+if ($req_host_gnu_type ne '' && $req_host_arch ne '' && !($req_host_arch =~
/^x-/)) {
my $dfl_host_gnu_type = debarch_to_gnutriplet($req_host_arch);
die (sprintf(_g("unknown default GNU system type for Debian architecture
%s"),
$req_host_arch))
@@ -187,7 +187,11 @@
if ($action eq 'l') {
foreach my $k (@ordered) {
- print "$k=$v{$k}\n";
+ if (defined $v{$k}) {
+ print "$k=$v{$k}\n";
+ } else {
+ print "$k=unknown\n";
+ }
}
} elsif ($action eq 's') {
foreach my $k (@ordered) {
Bug#455501: dpkg: patch for extra uClinux and uClibc architectures
Package: dpkg Followup-For: Bug #455501 Hi, this would be the proposed patch adding architectures for uClibc based Linux and uClinux. Using uClinux implies uClibc, so it is not mentioned explicitly in the arch name. This is mainly useful in connection with multiarch. Simon -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 6.10-6 The GNU core utilities ii libc6 2.7-18 GNU C Library: Shared libraries ii lzma 4.43-14Compression method of 7z format in dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.7.20.2+lenny1 Advanced front-end for dpkg -- no debconf information --- ostable.orig2009-07-28 18:31:35.0 +0200 +++ ostable 2009-07-28 18:12:42.0 +0200 @@ -16,7 +16,11 @@ # gnueabi-linux linux-gnueabi linux[^-]*-gnueabi gnulp-linuxlinux-gnulp linux[^-]*-gnulp +uclibceabi-linux linux-uclibceabilinux[^-]*-uclibceabi +uclibc-linux linux-uclibclinux[^-]*-uclibc gnu-linux linux-gnu linux[^-]*(-gnu.*)? +uclibceabi-uclinux uclinux-uclibceabi uclinux[^-]*-uclibceabi +uclibc-uclinux uclinux-uclibc uclinux[^-]*(-uclibc.*)? gnu-kfreebsd kfreebsd-gnukfreebsd[^-]*(-gnu.*)? gnu-knetbsdknetbsd-gnu knetbsd[^-]*(-gnu.*)? gnu-hurd gnu gnu[^-]* --- triplettable.orig 2009-07-28 18:31:41.0 +0200 +++ triplettable2009-07-28 18:14:11.0 +0200 @@ -6,6 +6,10 @@ gnueabi-linux-arm armel gnulp-linux-i386 lpia gnu-linux- +uclibceabi-linux-arm uclibc-linux-armel +uclibc-linux- uclibc-linux- +uclibceabi-uclinux-arm uclinux-armel +uclibc-uclinux- uclinux- gnu-kfreebsd- kfreebsd- gnu-knetbsd- knetbsd- gnu-hurd- hurd-
Bug#534831: wrong quotation marks in German translation
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 latter being rarely used in print. Apart from that, quotes in the above sentence are mismatched. Simon -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.26-1-powerpc Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg depends on: ii coreutils 7.4-2 The GNU core utilities ii libc6 2.9-18 GNU C Library: Shared libraries ii lzma 4.43-14Compression method of 7z format in dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.7.21 Advanced front-end for dpkg -- no debconf information -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533916: C++ symbol mangling difference between arches
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 changes, and the "double"/"triple" symbols are there precisely because the ABI says so. Except for a vtable/typeinfo/name group (which reeks of actual doubled code) all lines in your output are constructors, destructors and thunks to destructors. Simon -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#457371: dpkg: please add the DEB_VARIANT build environment variable
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 derived distributions; there is
currently no reliable way to communicate cross-derivatives building of a
package that uses the same source tree in multiple distributions but
should provide different binaries on each; the most notorious example is
gcc which uses different compiler defaults on Ubuntu, and detects
whether the build system is a Debian or Ubuntu system and configures the
target compiler appropriately (so it is difficult to build a compiler
that will create binaries targeted at a Debian system on an Ubuntu
system, as the resulting compiler will assume that the target's libc
contains SSP support).
A different application will be embedded systems, where a variant string
could be used to build a finer grained package split or leave out large
optional bits of the package.
The system is self-perpetuating; as soon as a deriver built dpkg with
this patch once, telling it which DEB_VARIANT to use, this information
will be passed on to all packages built from there on, including newer
versions of dpkg. This will allow for branding changes to be merged back
into Debian, and thus reduce merging work.
Simon
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-3-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages dpkg depends on:
ii coreutils 5.97-5.6 The GNU core utilities
ii libc6 2.7-5 GNU C Library: Shared libraries
dpkg recommends no packages.
-- no debconf information
diff -Nru /tmp/CTGRa1SVPh/dpkg-1.14.12/configure.ac
/tmp/Zg4BEoCa5A/dpkg-1.14.12/configure.ac
--- /tmp/CTGRa1SVPh/dpkg-1.14.12/configure.ac 2007-11-29 05:58:22.0
+0100
+++ /tmp/Zg4BEoCa5A/dpkg-1.14.12/configure.ac 2007-12-21 23:46:29.0
+0100
@@ -49,6 +49,15 @@
esac])
AC_SUBST(admindir)
+AC_ARG_WITH(variant,
+ AS_HELP_STRING([--with-variant=VARIANT],
+ [Debian system variant [[debian]]]),
+[case "$with_variant" in
+ "") AC_MSG_ERROR([invalid variant specified]) ;;
+ *) variant="$with_variant" ;;
+esac],
+[variant=debian])
+AC_SUBST(variant)
# Checks for programs.
AC_PROG_CC
diff -Nru /tmp/CTGRa1SVPh/dpkg-1.14.12/debian/rules
/tmp/Zg4BEoCa5A/dpkg-1.14.12/debian/rules
--- /tmp/CTGRa1SVPh/dpkg-1.14.12/debian/rules 2007-10-18 00:30:14.0
+0200
+++ /tmp/Zg4BEoCa5A/dpkg-1.14.12/debian/rules 2007-12-22 00:04:27.0
+0100
@@ -32,6 +32,9 @@
confflags += --with-selinux=static
endif
+DEB_VARIANT ?= debian
+
+confflags += --with-variant=$(DEB_VARIANT)
# Create configure script if necessary, automake handles rebuilding it.
configure:
diff -Nru /tmp/CTGRa1SVPh/dpkg-1.14.12/scripts/dpkg-buildpackage.pl
/tmp/Zg4BEoCa5A/dpkg-1.14.12/scripts/dpkg-buildpackage.pl
--- /tmp/CTGRa1SVPh/dpkg-1.14.12/scripts/dpkg-buildpackage.pl 2007-10-18
00:41:02.0 +0200
+++ /tmp/Zg4BEoCa5A/dpkg-1.14.12/scripts/dpkg-buildpackage.pl 2007-12-22
00:09:07.0 +0100
@@ -48,6 +48,7 @@
-usunsigned source.
-ucunsigned changes.
-a Debian architecture we build for (implies -d).
+ -VDistribution variant we build for
-b binary-only, do not build source. } also passed to
-B binary-only, no arch-indep files. } dpkg-genchanges
-S source only, no binary files. }
@@ -106,6 +107,11 @@
my $diffignore = '';
my $binarytarget = 'binary';
my $targetarch = my $targetgnusystem = '';
+my $variant = "debian";
+
+if (defined($ENV{'DEB_VARIANT'})) {
+ $variant = $ENV{'DEB_VARIANT'};
+}
while (@ARGV) {
$_ = shift @ARGV;
@@ -139,6 +145,8 @@
} elsif (/^-a(.*)$/) {
$targetarch = $1;
$checkbuilddep = 0;
+} elsif (/^-V(.*)$/) {
+$variant = $1;
} elsif (/^-s[iad]$/) {
$sourcestyle = $_;
} elsif (/^-s[nsAkurKUR]$/) {
@@ -299,6 +307,8 @@
}
close $arch_env or subprocerr('dpkg-architecture');
+$ENV{'DEB_VARIANT'} = $variant;
+
my $arch;
unless ($sourceonly) {
$arch = mustsetvar($ENV{'DEB_HOST_ARCH'}, _g('host architecture'));
diff -Nru /tmp/CTGRa1SVPh/dpkg-1.14.12/scripts/Makefile.am
/tmp/Zg4BEoCa5A/dpkg-1.14.12/scripts/Makefile.am
--- /tmp/CTGRa1SVPh/dpkg-1.14.12/scripts/Makefile.am2007-11-24
06:14:44.0 +0100
+++ /tmp/Zg4BEoCa5A/dpkg-1.14.12/scripts/Makefile.am2007-12-21
23:35:20.0 +0100
@@ -90,8 +90,10 @@
dist_pkglib_SCRIPTS = \
controllib.pl
+variant = @variant@
do_perl_subst = sed -e "s:^\#![:space:]*/usr/bin/pe
Bug#398625: adapted patch against current dpkg
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 system
clock.
Basically, what this patch does: if -B was used, it will attempt to use
the "build-arch" target. if that fails, and either -nc was set or it
took longer than 300 seconds to fail, the build is aborted there,
otherwise, the tree is cleaned and the build retried with the "build"
target.
Rationale: if it takes longer than 300 seconds for the package to find
out whether it has a "build-arch" target or not, the situation is FUBAR
anyway. Either the package build scripts are horribly broken, or the
machine is completely overloaded -- in neither case it makes real sense
to continue here. This does, however, solve the problem where a package
takes long to build in the build-arch target and fails later -- those
builds should not be retried -- and where a package does not have a
"build-arch" target -- these should. As (hopefully) many packages start
implementing these currently optional targets, the number of "normal"
FTBFS cases is high enough that we don't want to waste autobuilder time
on trying these packages twice.
A special string "I: optional-target-failed" followed by the name of the
target is output if the build is being retried -- this will allow
generating a database of packages that do not have the optional targets,
so interested individuals can contribute patches.
Simon
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.20-1-vserver-powerpc (SMP w/1 CPU core)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages dpkg depends on:
ii coreutils 5.97-5.4 The GNU core utilities
ii libc6 2.6.1-6GNU C Library: Shared libraries
dpkg recommends no packages.
-- no debconf information
--- scripts/dpkg-buildpackage.pl.orig 2007-10-08 06:12:43.0 +0200
+++ scripts/dpkg-buildpackage.pl2007-11-04 14:18:31.0 +0100
@@ -102,6 +102,7 @@
my $signsource = 1;
my $signchanges = 1;
my $diffignore = '';
+my $buildtarget = 'build';
my $binarytarget = 'binary';
my $targetarch = my $targetgnusystem = '';
@@ -160,6 +161,7 @@
} elsif (/^-b$/) {
$binaryonly = '-b';
@checkbuilddep_args = ();
+ $buildtarget = 'build-arch';
$binarytarget = 'binary';
if ($sourceonly) {
usageerr(sprintf(_g("cannot combine %s and %s"), '-b', '-S'));
@@ -167,6 +169,7 @@
} elsif (/^-B$/) {
$binaryonly = '-B';
@checkbuilddep_args = ('-B');
+ $buildtarget = 'build-arch';
$binarytarget = 'binary-arch';
if ($sourceonly) {
usageerr(sprintf(_g("cannot combine %s and %s"), '-B', '-S'));
@@ -365,7 +368,30 @@
chdir($dir) or failure("chdir $dir");
}
unless ($sourceonly) {
-withecho('debian/rules', 'build');
+# This handles the (currently) optional build targets. In case they ever
+# become mandatory, replace this entire "if" block with the "else" branch.
+# The timeout is ugly -- but it will stop packages that have the optional
+# target but fail to build from wasting more than five minutes of
+# autobuilder time -- and honestly, if a package takes five minutes to
+# find out that it actually does not have an optional target, failing to
+# build once is the least of its problems.
+if($buildtarget ne 'build') {
+my $starttime = time;
+eval { withecho('debian/rules', $buildtarget); };
+ my $stoptime = time;
+if($@) {
+ if($noclean || (($stoptime - $starttime) > 300))
+{
+die "$@";
+}
+print "[EMAIL PROTECTED]";
+print "I: optional-target-failed $buildtarget\n";
+withecho($rootcommand, 'debian/rules', 'clean');
+withecho('debian/rules', 'build');
+}
+} else {
+withecho('debian/rules', $buildtarget);
+}
withecho($rootcommand, 'debian/rules', $binarytarget);
}
if ($usepause &&
Bug#229357: Can we require build-arch/indep targets for lenny?
Hi, Frank Lichtenheld schrieb: 3) Autodetection My approach would be to have the autobuilders use "build-arch", and if that fails within 60 seconds, "clean" and "build". If "build-arch" is not implemented, it fails rather quickly, so we use "build" and make a note in the build log. Later, one can grep for that note. If it is implemented, but fails within 60 seconds, not much is lost. If it takes longer to fail, then it's a normal FTBFS. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440094: dpkg-dev: allow specifying the source version explicitly
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" as a suffix, with "debian" being replaced by
"ubuntu" for Ubuntu builds etc.
In principle the only way to be sure would be to add another special
character ("#" springs to mind), but that would be a pretty invasive thing.
Although I'm not sure this is
worth it, in most cases, you'll need to modify the source anyway, and
in the others having an additional diff.gz is not that much (that does
not take into account native packages, but there should not be that
many of those anyway).
Well, all current toolchain packages auto-backport without any source
changes; I'd expect a lot of packages already work fine.
[patch adding DEB_SOURCE_VERSION]
I don't think this is a good idea, it makes automatically building those
packages rather cumbersome, and difficult to reproduce.
For normal binNMUs, nothing changes, as the current behaviour is still
the default. When (automatically) building a backport with a nonstandard
version number, all that has to be done is save the version number
before the addition of the extra changelog entry, and pass that as the
contents of DEB_SOURCE_VERSION during the build process.
Omitting this step leaves us at the status quo, so there is no
regression in the patch either.
Also the patch is wrong, Source-Version != source:Version, otherwise
we'd not have introduced the new variables.
Well, at this specific point, they are initialized to the same value, so
I'd expect them to be much the same at least at this point in time.
Simon
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440094: dpkg-dev: allow specifying the source version explicitly
Package: dpkg-dev
Version: 1.14.5
Severity: wishlist
Tags: patch
Hi,
when backporting, the version number needs to be adapted to sort lower
than the current version, and ideally, to encode information on the
targetted distribution; however, the source version should point to the
actual source package used.
If multiple backports (for different target distributions) can be built
from the same source version, it would be preferrable to only keep one
copy of the sources, for that to work, the binary packages need to point
to an explicit source version number that cannot be deduced from the
changelog.
The attached patches add support for an environment variable
DEB_SOURCE_VERSION that specifies the version that should be encoded in
the binary package, and forbid "dpkg-source -b" to be run with this
variable set (that would be nonsensical).
Simon
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22-1-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages dpkg-dev depends on:
ii binutils 2.18~cvs20070812-1 The GNU assembler, linker and bina
ii cpio 2.9-3 GNU cpio -- a program to manage ar
ii dpkg 1.14.5 package maintenance system for Deb
ii make 3.81-3 The GNU version of the "make" util
ii patch 2.5.9-4Apply a diff file to an original
ii perl [perl5] 5.8.8-7Larry Wall's Practical Extraction
ii perl-modules 5.8.8-7Core Perl modules
Versions of packages dpkg-dev recommends:
ii bzip2 1.0.3-7high-quality block-sorting file co
ii gcc [c-compiler] 4:4.1.2-3 The GNU C compiler
ii gcc-4.1 [c-compiler] 4.1.2-15 The GNU C compiler
-- no debconf information
--- dpkg-1.14.5/scripts/controllib.pl.orig 2007-08-29 18:48:01.955126739
+0200
+++ dpkg-1.14.5/scripts/controllib.pl 2007-08-29 18:53:56.411326046 +0200
@@ -543,14 +543,24 @@
$substvar{'Space'} = " ";
$substvar{'Tab'} = "\t";
-# XXX: Source-Version is now deprecated, remove in the future.
-$substvar{'Source-Version'}= $fi{"L Version"};
$substvar{'binary:Version'} = $fi{"L Version"};
-$substvar{'source:Version'} = $fi{"L Version"};
-$substvar{'source:Version'} =~ s/\+b[0-9]+$//;
-$substvar{'source:Upstream-Version'} = $fi{"L Version"};
+
+if(defined($ENV{'DEB_SOURCE_VERSION'}))
+{
+ $substvar{'source:Version'} = $ENV{'DEB_SOURCE_VERSION'};
+}
+else
+{
+$substvar{'source:Version'} = $substvar{'binary:Version'};
+$substvar{'source:Version'} =~ s/\+b[0-9]+$//;
+}
+
+$substvar{'source:Upstream-Version'} = $substvar{'source:Version'};
$substvar{'source:Upstream-Version'} =~ s/-[^-]*$//;
+# XXX: Source-Version is now deprecated, remove in the future.
+$substvar{'Source-Version'}= $substvar{'source:Version'};
+
# FIXME: this needs all progs using controllib to set $version as 'our'.
# We expect the calling program to set $version.
$substvar{"dpkg:Version"} = $version;
--- dpkg-1.14.5/scripts/dpkg-source.pl.orig 2007-08-29 19:29:53.806268977
+0200
+++ dpkg-1.14.5/scripts/dpkg-source.pl 2007-08-29 19:29:10.683811568 +0200
@@ -210,6 +210,11 @@
if ($opmode eq 'build') {
+if(defined($ENV{'DEB_SOURCE_VERSION'}))
+{
+&error(_g("DEB_SOURCE_VERSION cannot be used when building source
packages"));
+}
+
$sourcestyle =~ y/X/A/;
$sourcestyle =~ m/[akpursnAKPUR]/ ||
&usageerr(sprintf(_g("source handling style -s%s not allowed with
-b"), $sourcestyle));
Bug#229357: Can we require build-arch/indep targets for lenny?
Hi, Wouter Verhelst wrote: $(shell ls temp-target-* && rm temp-target-*): Yes, that's broken, but there are your side effects, and you'll have to run this code if you want to make your --has-target work. Yes, that is exactly what I'm proposing. The same thing happens for -q mode now. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#229357: Can we require build-arch/indep targets for lenny?
Hi, Ian Jackson wrote: We want the package to _declare_ whether it supports this new target. Ideally, we'd want all packages to support the new target, and then turn that into policy, otherwise we'll end up supporting both for a very long time. The proposed -Options field will actually be very useful for any other enhancements we make to the source package format. I'm not disputing that, but I'm not sure we really want it in this case. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#229357: Can we require build-arch/indep targets for lenny?
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 autobuilders handle it now. So no problem there; packages that implement build-arch can move the dependencies not needed for building arch-dependent packages from B-D to B-D-I as soon as the autobuilders start using build-arch. Getting rid of unneeded build dependencies is mostly orthogonal to the issue at hand, though. Running debian-rules can always have side effects and can actively rely on them so a "--has-target" can not be implemented cleanly in make. I am proposing hooking into the logic that ultimately decides that there is no such target in the Makefile and goes on to print "Don't know how to make 'foo'. Stop.". This means that Makefiles are rebuilt before that test is performed, we stop immediately before the point where we would go towards the first goal target. Yes, that means running commands that possibly have side effects. But we are going to run these commands anyway. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#229357: Can we require build-arch/indep targets for lenny?
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 is present using a simple script. But who said it has to be a script? Proposed alternative solution: 1. hack GNU make to support a "--has-target" option that returns an appropriate return code (hey, it's free software, after all!). Proposed return codes are 0 (yes), 1 (no) and 2 (error). 2. make "dpkg-buildpackage -B" use this facility to determine whether the target is present. If yes, use the "build-arch" target to build; if no, use the "build" target after printing a warning. 3. grep the build logs for warnings about missing "build-arch" target, add an entry to the TODO list on the package overview page on qa.debian.org and to DDPO. The only remaining question is what should happen with build failures in packages that provide a non-functional "build-arch" target. In my opinion, this is a genuine bug, even if policy can be read in a way that makes it disagree. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376123: a way for a prerm to postpone package removal
Package: dpkg
Version: 1.13.21
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I thought it would be nice if there were a way for a prerm to indicate
that it would like to abort package removal but not flag an error.
Rationale: When I have the metapackage for "current kernel" installed, I
get a new kernel-image package every so often, and at the same time the
old kernel goes unused in the eyes of aptitude, so it wants to remove
it. The kernel's prerm then asks the user whether to uninstall the
running kernel (bad) or abort the removal. If the user chooses to abort
the removal, dpkg bails out as it could not perform the requested
action, thus making the entire installation fail. If it were possible to
say "not yet" and have dpkg ignore the removal request and return a
special exit code ("not entirely successful"), then aptitude could
reconsider that the removal is not required at this time (because it's
just an unused package being removed) and leave the package in "to be
removed" state. Eventually, the user will boot the new kernel, at which
time the removal of the old kernel will succeed.
The only way to "emulate" such a feature for aptitude would be to retry
removals package-by-package in order to find out what failed (the user
would be prompted again here), which takes a lot more time than just
rereading the status and deciding on a further course of action (fail if
the removal was needed, ignore otherwise).
Simon
- -- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-amd64-k8
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Versions of packages dpkg depends on:
ii coreutils 5.96-3 The GNU core utilities
ii libc6 2.3.6-15 GNU C Library: Shared libraries
dpkg recommends no packages.
- -- debconf-show failed
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349120: dpkg: assertion failure after failing to configure a package
Package: dpkg Version: 1.13.11 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, A bug in linux-image-2.6.15-1-powerpc appears to have left me without a ramdisk creator which would not be much of an issue were it not for Setting up linux-image-2.6.15-1-powerpc (2.6.15-3) ... Running depmod. Finding valid ramdisk creators. Failed to find suitable ramdisk generation tool for kernel version 2.6.15-1-powerpc on running kernel 2.6.15-1-powerpc in mkinitramfs mkinitrd.yaird dpkg: error processing linux-image-2.6.15-1-powerpc (--configure): subprocess post-installation script returned error exit status 9 dpkg: dependency problems prevent configuration of linux-image-2.6-powerpc: linux-image-2.6-powerpc depends on linux-image-2.6.15-1-powerpc (= 2.6.15-3); however: Package linux-image-2.6.15-1-powerpc is not configured yet. dpkg: error processing linux-image-2.6-powerpc (--configure): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of linux-image-powerpc: linux-image-powerpc depends on linux-image-2.6-powerpc (= 2.6.15-3); however: Package linux-image-2.6-powerpc is not configured yet. dpkg: error processing linux-image-powerpc (--configure): dependency problems - leaving unconfigured dpkg: ../../src/packages.c:191: process_queue: Assertion `dependtry <= 4' failed. At this time, dpkg exits with SIGABRT and leaves the database in a broken state so apt refuses to do anything before "dpkg --configure -a" is run, which again leads to the above problem. Please let me know what additional information is required. Simon - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (50, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-powerpc Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages dpkg depends on: ii coreutils [textutils] 5.93-5 The GNU core utilities ii libc6 2.3.5-12 GNU C Library: Shared libraries an dpkg recommends no packages. - -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
