Bug#901127: dpkg: dpkg crashed with segfault and core dump: ../../src/packages.c:245: process_queue: Assertion `dependtry <= 4' failed.
Package: dpkg Version: 1.19.0.5+b1 Severity: important Dear Guillem, dpkg just crashed with a segfault during setting up all remaining package after a dist-upgrade (via aptitude) which had some issues with a few packages (namely some emacs plugins which caused emacs' recompilation-trigger to fail). But it crashed on another package: [...] Setting up python-opencv (3.2.0+dfsg-4+b5) ... dpkg: ../../src/packages.c:245: process_queue: Assertion `dependtry <= 4' failed. Aborted (core dumped) Additional facts: The machine did not have much free disk space and hadn't been upgraded for months. Backtrace: Core was generated by `dpkg --configure -a'. Program terminated with signal SIGABRT, Aborted. #0 0xb7f0ad09 in __kernel_vsyscall () (gdb) bt #0 0xb7f0ad09 in __kernel_vsyscall () #1 0xb7cf25b2 in __libc_signal_restore_set (set=0xbfacc6dc) at ../sysdeps/unix/sysv/linux/nptl-signals.h:80 #2 __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48 #3 0xb7cf39d1 in __GI_abort () at abort.c:79 #4 0xb7cea6ab in __assert_fail_base ( fmt=0xb7e44100 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x52d220 "dependtry <= 4", file=0x52d1ae "../../src/packages.c", line=245, function=0x52da18 <__PRETTY_FUNCTION__.6143> "process_queue") at assert.c:92 #5 0xb7cea709 in __GI___assert_fail (assertion=0x52d220 "dependtry <= 4", file=0x52d1ae "../../src/packages.c", line=245, function=0x52da18 <__PRETTY_FUNCTION__.6143> "process_queue") at assert.c:101 #6 0x0050ccd0 in process_queue () at ../../src/packages.c:245 #7 0x0050cf1b in packages (argv=0xbfaccbd0) at ../../src/packages.c:162 #8 0x004fe79d in main (argc=, argv=) at ../../src/main.c:926 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (900, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (201, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: i386 (i686) Kernel: Linux 4.16.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-8.1 ii libc62.27-3 ii liblzma5 5.2.2-1.3 ii libselinux1 2.8-1 ii tar 1.30+dfsg-2 ii zlib1g 1:1.2.11.dfsg-1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt1.6.1 pn debsig-verify -- no debconf information
Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it
Hi Holger, Quoting Holger Levsen (2018-06-08 17:47:47) > as I'm not an sbuild user (yet) myself, I was hesistant to try this > myself, so I'm confused now: does it work as it is now? (or does it need > changes to snapshot.d.o?) yes, it does work as it is now. Just supply the script with a buildinfo file to see it in action. It does not require superuser privileges. The script will query snapshot.debian.org to retrieve the right snapshot timestamp that contains all the package versions specified in the buildinfo file. At the end of execution the script will print how to either reproduce the buildinfo manually via dpkg-buildpackage or how to run sbuild such that it does it for you. People who know how to use pbuilder could easily add a section that outputs how to run pbuilder to do the same. Naturally, instead of just printing how to use sbuild or pbuilder, the script could also be made actually run either. The main two limitations of the script are: 1. it will fail if there is not a single snapshot that contains all the right package versions 2. it will instruct sbuild/pbuilder to use the last stable release as the base which might not allow upgrading to the right package versions Both issues can be fixed by manually downloading exactly the required binary package set and creating a completely new chroot with exactly the required packages. But I didn't get around to doing that yet. Thanks! cheers, josch signature.asc Description: signature
Bug#901068: marked as done (dpkg-checkbuilddeps: split Build-Depends into Build-Depends + Test-Depends)
Your message dated Fri, 8 Jun 2018 18:30:39 +0200 with message-id <20180608163038.ga3...@alf.mars> and subject line Re: Bug#901068: dpkg-checkbuilddeps: split Build-Depends into Build-Depends + Test-Depends has caused the Debian Bug report #901068, regarding dpkg-checkbuilddeps: split Build-Depends into Build-Depends + Test-Depends to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 901068: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901068 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: dpkg-dev Version: 1.19.0.5 Severity: wishlist Hi all, today when a build-dependency has a RC bug, it affects current package even if this dependency is used only for tests. I propose to add a "Test-Depends" field in debian/control. Packages mentionned in it will stay required but a RC bug will not affect packages that use it only for tests. In the same idea, it could be interesting to add also a "Test-Recommends" field: packages mentionned in it will be required if available in this distribution but build process will even be launched if not. Of course, corresponding tests have to detect that package is missing and skip test (skip mechanism used in Perl Test::More for example). So a package removed for any reason will not affect packages that optionaly use it. Example: a suggested package that is also used in a test. Regards, Xavier -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (600, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg-dev depends on: ii binutils 2.30-21 ii bzip2 1.0.6-8.1 ii libdpkg-perl 1.19.0.5 ii make 4.1-9.1 ii patch 2.7.6-2 ii perl 5.26.2-5 ii tar 1.30+dfsg-2 ii xz-utils 5.2.2-1.3 Versions of packages dpkg-dev recommends: ii build-essential 12.5 ii fakeroot 1.22-2 ii gcc [c-compiler] 4:7.3.0-3 ii gcc-7 [c-compiler] 7.3.0-21 ii gnupg2.2.5-1 ii gnupg2 2.2.5-1 ii gpgv 2.2.5-1 ii libalgorithm-merge-perl 0.08-3 Versions of packages dpkg-dev suggests: ii debian-keyring 2018.06.04 -- no debconf information --- End Message --- --- Begin Message --- On Fri, Jun 08, 2018 at 05:21:56PM +0200, Xavier Guimard wrote: > today when a build-dependency has a RC bug, it affects current package > even if this dependency is used only for tests. I propose to add a > "Test-Depends" field in debian/control. Packages mentionned in it will > stay required but a RC bug will not affect packages that use it only for > tests. We want Build-Depends to be predictable. By randomly dropping Test-Depends, you break that. Still the equivalent of Test-Depends is already there. You can write "" after a build dependency. A builder can the decide to skip tests (and skip those dependencies) by adding nocheck to both DEB_BUILD_OPTIONS and DEB_BUILD_PROFILES. What you want is technically there (although called differently). Thus I am closing this bug. Helmut--- End Message ---
Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it
Guillem, josch: thanks for your feedback, much appreciated. On Fri, Jun 08, 2018 at 08:38:49AM +0200, Johannes Schauer wrote: > > I say it's an artificial blocker, because it is based on the problem > > faced while implementing the srebuild script to use the current > > snapshot.d.o API. And I think that's your actual blocker. Fixing that > > API would also mean you can use it right away independently of what's > > already installed on the system and might be useful for other users > > too. I think the fix would imply adding an API entry point based on > > the name-version-arch tuple. > > yes, that would also solve the problem. as I'm not an sbuild user (yet) myself, I was hesistant to try this myself, so I'm confused now: does it work as it is now? (or does it need changes to snapshot.d.o?) > I unblocked the bug, because it's not a hard blocker but just an > inconvenience. thanks > The bigger blocker of #774415 is, that the script needs somebody who feels > responsible for it and who is willing to maintain it. I only wrote it but I > have no intention of being its maintainer. I'd be happy to maintain it, once I'm a user of it :) (which might happen quite soon via tests.r-b.o…) -- cheers, Holger signature.asc Description: PGP signature
Bug#901068: dpkg-checkbuilddeps: split Build-Depends into Build-Depends + Test-Depends
Package: dpkg-dev Version: 1.19.0.5 Severity: wishlist Hi all, today when a build-dependency has a RC bug, it affects current package even if this dependency is used only for tests. I propose to add a "Test-Depends" field in debian/control. Packages mentionned in it will stay required but a RC bug will not affect packages that use it only for tests. In the same idea, it could be interesting to add also a "Test-Recommends" field: packages mentionned in it will be required if available in this distribution but build process will even be launched if not. Of course, corresponding tests have to detect that package is missing and skip test (skip mechanism used in Perl Test::More for example). So a package removed for any reason will not affect packages that optionaly use it. Example: a suggested package that is also used in a test. Regards, Xavier -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (600, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg-dev depends on: ii binutils 2.30-21 ii bzip2 1.0.6-8.1 ii libdpkg-perl 1.19.0.5 ii make 4.1-9.1 ii patch 2.7.6-2 ii perl 5.26.2-5 ii tar 1.30+dfsg-2 ii xz-utils 5.2.2-1.3 Versions of packages dpkg-dev recommends: ii build-essential 12.5 ii fakeroot 1.22-2 ii gcc [c-compiler] 4:7.3.0-3 ii gcc-7 [c-compiler] 7.3.0-21 ii gnupg2.2.5-1 ii gnupg2 2.2.5-1 ii gpgv 2.2.5-1 ii libalgorithm-merge-perl 0.08-3 Versions of packages dpkg-dev suggests: ii debian-keyring 2018.06.04 -- no debconf information
Bug#900830: dpkg-dev: enable gcc/clang color diagnostics if DEB_BUILD_OPTIONS=color
On Fri, Jun 08, 2018 at 03:47:14AM +0200, Guillem Jover wrote:
> On Tue, 2018-06-05 at 18:32:21 +0200, Adam Borowski wrote:
> > Here's a patch to turn on colorized diagnostics via dpkg-buildflags if
> > DEB_BUILD_OPTIONS includes "color".
[...]
> > To read such a log, you print it to a terminal, less -R, ansi2html or so on.
>
> I hope you don't intend for this to be the default in the future, as I
> expect it might wreak havoc. :)
Havoc that causes FTBFS: not with any not thoroughly insane build system.
To get a failure, a package would need to either parse gcc's output (which
changes so often) or have weird assumptions about build flags (which would
break if you change similar options).
Havoc that causes garbage in logs: yes, unless the tool that reads build
logs understands color. Thus, even though I do wish to request "color" to
be enabled on buildds when/if #875439 is done, the option still wouldn't
be the default to avoid breaking custom build setups we don't control.
Out of ~2% packages that output color already even though they shouldn't,
the vast majority don't do so from gcc (usually java or some test suite);
one example of hard-coded -fdiagnostics-color=always:
https://buildd.debian.org/status/fetch.php?pkg=seafile-client=amd64=6.1.8-1=1527948413=0
> > I'm not sure what to do with LDFLAGS: currently dpkg-buildflags gives
> > options like -g -O2 only to ${LANG}FLAGS, these are supposed to be given
> > when linking as gcc fails to do some optimizations otherwise (especially
> > with LTO), but some packages pass LDFLAGS only. Should we add
> > -fdiagnostics-color=always there as well? This would be redundant but
> > harmless for properly written makefiles.
>
> I think using a flag here is also a bit suboptimal, and it clutters the
> compiler flags. But I don't see any other way to force colors for gcc
> and clang. The presence of GCC_COLORS envvar enables at most auto mode,
> and clang does not seem to support any envvar. :/
I agree: a flag that affects output rather than compilation should use an
env var; most programs with conditional color indeed use env vars (without
any standardization...). It would be probably good to ask gcc's upstream to
do so -- but that wouldn't happen until gcc 9 or 10.
> So, thanks for the patch! It's missing an update to the man page
> though.
Not sure where to put it in: the man page talks mostly about feature flags;
the only generic one is "noopt" in another section.
> About the option name, I'd probably use "colors", but that
> does not really describe its nature, which is to force them, perhaps
> "colors-forced" or "colors-always" but that's a bit long.
This is kind of a bike shedding, but no other DEB_BUILD_OPTIONS is in
plural, even if more pluralizable than "color". As for "-forced" or
"-always", most package building comes via a wrapper that redirects build
logs somewhere, thus piping is an implementation detail that doesn't
interest the user -- I think that'd make "-forced" puzzling.
For this reason, I'd stick with a short name.
> I'd probably also force DPKG_COLORS=always from dpkg-buildpackage if
> the option is set.
dpkg-buildpackage you say? I was planning to ask to include env vars in
debhelper, as the vast majority of packages use debhelper, and not all build
entry points go through dpkg-buildpackage -- but then, if you do incremental
attempts by running debian/rules build directly, you're almost always on a
terminal. Thus, setting them in dpkg-buildpackage might indeed be better.
As for env vars themselves, they tend to be tool-specific. One
standardization effort I've seen uses CLICOLOR_FORCE=1:
https://bixense.com/clicolors/ which is supported by cmake and waf, and
requested inclusion elsewhere (including gcc and clang). The name is goofy
(apparently comes from OSX), but does what we want.
Thus, having dpkg-buildpackage be the tool that set CLICOLOR_FORCE=1 and
DPKG_COLORS=always sounds like a good idea.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ I've read an article about how lively happy music boosts
⣾⠁⢰⠒⠀⣿⡁ productivity. You can read it, too, you just need the
⢿⡄⠘⠷⠚⠋⠀ right music while doing so. I recommend Skepticism
⠈⠳⣄ (funeral doom metal).
Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it
Hi, Quoting Guillem Jover (2018-06-08 04:30:45) > Having reread the blocking bug, and the specific message where josch > says this one is a blocker (https://bugs.debian.org/774415#44), I > think this is actually an artificial blocker! > > [...] > > I say it's an artificial blocker, because it is based on the problem > faced while implementing the srebuild script to use the current > snapshot.d.o API. And I think that's your actual blocker. Fixing that > API would also mean you can use it right away independently of what's > already installed on the system and might be useful for other users > too. I think the fix would imply adding an API entry point based on > the name-version-arch tuple. yes, that would also solve the problem. I unblocked the bug, because it's not a hard blocker but just an inconvenience. The bigger blocker of #774415 is, that the script needs somebody who feels responsible for it and who is willing to maintain it. I only wrote it but I have no intention of being its maintainer. Thanks! cheers, josch signature.asc Description: signature
Processed: unblock 774415 with 802241
Processing commands for cont...@bugs.debian.org: > unblock 774415 with 802241 Bug #774415 [sbuild] sbuild: please add the srebuild sbuild wrapper to reproduce builds 774415 was blocked by: 774359 802241 774415 was not blocking any bugs. Removed blocking bug(s) of 774415: 802241 > thanks Stopping processing here. Please contact me if you need assistance. -- 774415: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774415 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
