Re: Bug#1109499: bacula-director-sqlite3: fails to dist-upgrade from bookworm to trixie

upgrade severity -2 important thanks On Sat, 19 Jul 2025 11:40:14 +0200 Chris Hofstaedtler wrote: On Sat, Jul 19, 2025 at 11:06:17AM +0200, Niels Thykier wrote: > FWIW, I checked the stable version of bacula-common and it has the same > story. The `systemd-tmpfiles` call only appears

Re: Bug#1109499: bacula-director-sqlite3: fails to dist-upgrade from bookworm to trixie

Chris Hofstaedtler: [...] The preinst script should be this: https://binarycontrol.debian.net/cache/unstable/bacula-common/preinst which does not invoke systemd-tmpfiles. I wonder whats really happening. Is dpkg invoking the new postinst (at postinst time), but putting "pre-installation" into

Re: Status for RT on `Rules-Requires-Root: no` transition

Hi, Here is one final update as the freeze is about to start. * First and foremost, I consider the transition as over, since there are no more packages left that are actionable by me nor is there any pending reason to revert the change. * Only three known issues remain as affecting tes

Re: Status for RT on `Rules-Requires-Root: no` transition

Paul Gevers: Hi Niels, On 14-01-2025 10:46, Niels Thykier wrote: Another update on the transition One month further. What's the current status? Paul Hi, Key package-wise, we are down to 5 packages affecting testing: * d-i + shim + its helper: All which are not actionable to

Status for RT on `Rules-Requires-Root: no` transition

Hi Release team Another update on the transition # High level summary * 41 RC bugs still affect testing out of 229 bugs known. * Fixes for 18 RC bugs are expected later today, bringing us down to 23 RC bugs. * 13 RC bugs affect key packages in testing with fixes for 3 of them expecte

RT Status on `Rules-Requires-Root: no` transition

Hi Release team # Here is an update on the transition: * All bugs 227 are now RC of which 136 affect testing. - When eyeballing the list of "affecting testing" bugs, the most common issues seem to be "not yet fixed in sid" and "age" at this stage. - 82 are pending with about

Re: Timing on `Rules-Requires-Root: no` being the new default

Paul Gevers: Hi Niels, Hi Paul Thanks for the feedback. On 29-12-2024 11:12, Niels Thykier wrote:   * Do you think it is feasible for us to do this change in Trixie and,     if so, do you have any preferences for timing or bug counts that we     should keep in mind? If you are

Re: Timing on `Rules-Requires-Root: no` being the new default

Niels Thykier: Hi Release team, Hi, Please CC me OR debian-dpkg@l.d.o on replies. I am not subscribed to d-release. [...] With this in mind:  * Do you think it is feasible for us to do this change in Trixie and,    if so, do you have any preferences for timing or bug counts that we

Timing on `Rules-Requires-Root: no` being the new default

Hi Release team, I could use your views on the `Rules-Requires-Root: no` MBF/transition here. Concretely, I am looking for your gut feeling on if/when we commit to the MBF and have the remaining bugs bumped to RC. While I have no doubt this counts part of the "transition and toolchain freeze",

Re: Proposal: Optional `Priority: optional` and changed `Section` fall-back

Daniel Baumann: Hi, both sound good (dropping mandatory priority is nice and consistent, fixing unknown section behaviour too), thanks! Thanks for the feedback. :) ideally these changes would be in dpkg in trixie, but maintainers would start dropping priority fields *after* trixie so that f

Proposal: Optional `Priority: optional` and changed `Section` fall-back

Hi, Historically, if you omitted `Priority` and `Section` from your package, `dpkg` would warn and use `-` or `unknown` as placeholder when it absolutely needed a value for these fields in the `.dsc` and the `.changes` file. The resulting `.deb` would omit the field. We would like to change this

Re: Building with many cores without OOM

Helmut Grohne: Hi Guillem and other developers, I am one of those who builds a lot of different packages with different requirements and found that picking a good parallel=... value in DEB_BUILD_OPTIONS is hard. Go too low and your build takes very long. Go too high and you swap until the OOM ki

[MBF]: Proposing `Rules-Requires-Root: no` being the new default

Hi We would like to propose a change in default for `dpkg`, which will enable `rootless` by default (changing it from "opt-in" to "opt-out"). This would be a considerable milestone bringing us to into 90-99% territory of removing the need for root (`fakeroot` or otherwise) in the Debian packaging

Re: Bug#1064454: debian-policy: Restrict deb822 field names more

Guillem Jover: Hi! On Thu, 2024-02-22 at 12:10:06 +0100, Niels Thykier wrote: Package: debian-policy Severity: wishlist While the parser is technically correct given the Policy description above, I cannot see any case where this is a desirable outcome. Instead, I think we should classify

Re: Scriptable interface for "set package selection to this set"

Simon Richter: Hi, > [...] > This is understandable, apt special-cases itself, and for a good reason. I have no problem hardcoding an "apt install" into my package selection, that solves this nicely.  - whether e2fsprogs is Essential This is only Important, not Essential, so dpkg marks it

Re: debian-policy: Restrict deb822 field names more

Thu, 22 Feb 2024 12:10:06 +0100 Niels Thykier wrote: Package: debian-policy Severity: wishlist X-Debbugs-Cc: ni...@thykier.net X-Debbugs-Cc: lintian-ma...@debian.org X-Debbugs-Cc: de...@lists.debian.org X-Debbugs-Cc: debian-dpkg@lists.debian.org Hi I am hoping we can agree to some tighter bounds

Re: Proper way to do setcap in maintscript

Niels Thykier: Hi, I have seen the following pattern in multiple packages, where we use `setcap` to replace a setuid (or setgid) mode with a capability. I think it is about time that we get proper packaging helper support for it. [...] Best regards, Niels [...] Hi Thanks for the

Re: Proper way to do setcap in maintscript

Helmut Grohne: Hi Niels, thanks for reaching out. Thanks for the quick feedback. :) On Sat, Nov 18, 2023 at 05:13:44PM +0100, Niels Thykier wrote: * Should the snippet use dpkg-statoverride instead of a chmod? (If dpkg-statoverride is used, how will this interact with the next

Proper way to do setcap in maintscript

Hi, I have seen the following pattern in multiple packages, where we use `setcap` to replace a setuid (or setgid) mode with a capability. I think it is about time that we get proper packaging helper support for it. ``` if [ "$1" = configure ]; then if command -v setcap > /dev/null; then

debian-policy,dpkg: Please document maintscript flow with `prerm deconfigure`

Package: debian-policy,dpkg Severity: wishlist X-Debbugs-Cc: ni...@thykier.net,debian-dpkg@lists.debian.org Hi The flow charts at https://www.debian.org/doc/debian-policy/ap-flowcharts.html unfortunately does not cover the `prerm deconfigure [...]` This makes it hard to figure whether a pack

Re: RFC: New dpkg-build-api levels

Guillem Jover: Hi! Hi! Some time ago I started work on a new dpkg build API level system resembling the one used by debhelper. My current WIP is at , which I'd like to finalize and merge for 1.22.x. This works by

Re: Support for optional substvars

Guillem Jover: > Hi Niels! > > Several months ago you asked on IRC about extending the substvars file > format to be able to mark substvars as optional (so that they would not > warn in case they end up not being used, like how several of the built-in > ones are handled). At the time I mentioned t

Re: Support for optional substvars

Guillem Jover: > Hi Niels! > > Several months ago you asked on IRC about extending the substvars file > format to be able to mark substvars as optional (so that they would not > warn in case they end up not being used, like how several of the built-in > ones are handled). At the time I mentioned t

Re: Bug#999420: dh_shlibdeps: Please consider option (or default) to ignore weak symbols for dependencies

Control: reassign -1 dpkg Josh Triplett: > Package: debhelper > Version: 13.5.2 > Severity: wishlist > File: /usr/bin/dh_shlibdeps > X-Debbugs-Cc: j...@joshtriplett.org > > When a program or library declares a weak symbol, that typically > indicates that it's prepared to do without the symbol. >

Re: xournal FTBFS: wrongly declared R³

Guillem Jover: > Hi! > > On Sat, 2020-10-24 at 11:54:54 +0200, Niels Thykier wrote: >> Rather, I suspect the issue is that Rules-Requires-Root is set to "No" >> rather than "no". AFAICT, only "no" has been defined and it is >> interpre

Re: xournal FTBFS: wrongly declared R³

On Sat, 24 Oct 2020 11:49:46 +0200 Helmut Grohne wrote: > Source: xournal > Version: 1:0.4.8.2016-6 > Severity: serious > Tags: ftbfs > > xournal fails to build from source on buildds, because it wrongly > declares that it doesn't need root while in fact it does issue > dh_testroot. Dropping the

[Summary]: RFC: Standardizing source package artifacts build paths

Guillem Jover: > Hi! > > We currently have many built artifacts being dropped directly under > debian/ or under tool specific directories such as debian/.debhelper/. > These have at least the following problems: > > - Make cleaning, an operation that requires executing code from the > sourc

Re: RFC: Standardizing source package artifacts build paths

Sean Whitton: > Hello, > > On Tue 14 Apr 2020 at 10:54AM +02, Niels Thykier wrote: > >> Guillem and I have debated this and come to a solution, which we believe >> will be able to address the concerns about the path being "hidden". It >> also enables us to

Re: RFC: Standardizing source package artifacts build paths

Sam Hartman: > I'm concerned about a leading . at least for: > > * the debian/tmp replacement > * the replacement for the package install directories under debian. > > I think that maintaining those directories such that ls shows them will > be more friendly for new maintainers. > So I'd prefer s

Standardized way of extracting additional build-time artefacts (was: Re: RFC: Standardizing source package artifacts build paths)

Simon McVittie: > On Mon, 09 Mar 2020 at 20:45:13 +0100, Niels Thykier wrote: >> Simon McVittie: >>> For example, dpkg-buildpackage could perhaps read one glob per >>> line from debian/artifacts and hardlink matched files (if any) into >>> debian/.build/a

Re: RFC: Standardizing source package artifacts build paths

Simon McVittie: Hi :) > On Mon, 09 Mar 2020 at 10:09:46 +0100, Guillem Jover wrote: >> We'd like to standardize on a new set of artifact build pathnames >> for our deb toolchain. These would have the following form: >> >> - debian/.build/upstream* >> >> These could be used for out-of-tree b

Re: debhelper: Please default Rules-Require-Root to no

Hideki Yamane: > Hi, > > On Fri, 24 May 2019 10:47:22 -0700 > Sean Whitton wrote: >> (surely we are a very long way from r-r-r: no for every package?) > > I don't think so since lintian info about > "should-specify-rules-requires-root" > containts only 98 packages. > https://lintian.debian.o

Re: debhelper: Please default Rules-Require-Root to no

Sean Whitton: > Hello, > > On Fri 24 May 2019 at 01:42PM +09, Hideki Yamane wrote: > >> Hi, >> In summary: The debhelper fundamentally cannot affect whether Rules-Requires-Root: no is default or not. The debhelper compat level system is the wrong interface to do this as well.

Re: dpkg-buildpackage modifying *png file

Weatherby,Gerard: > I'm using dpkg-buildpackage -b -uc -us to prepare a *deb package for a > private repository. > > It seems to be modifying a byte PNG image file, as indicated by "cmp" > > ./relax/docs/html/icons/index.png > ./debian/relax/usr/software/relax/docs/html/icons/index.png differ:

Re: debhelper: Please default Rules-Require-Root to no

On Fri, 22 Dec 2017 18:11:00 + Niels Thykier wrote: > Control: tags -1 wontfix > > [...] > > Hi, > > Thanks for the suggestion. > > In the thread that you referenced, I received the same request and > answered it in https://lists.debian.org/debi

Re: RFC: Unified package metadata format

Guillem Jover: > Hi! > > On Tue, 2017-03-28 at 16:22:58 -0700, Matthew Garrett wrote: >> I'm looking at implementing support for IMA file signatures inside >> dpkg. The previous patches posted for this >> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850340) did so >> using extended PAX metad

[PATCH] fields.c: Avoid unnecessary translations for error messages

onsidering, ~Niels From 88dd21620509fd72eab402e3a871203cec406c72 Mon Sep 17 00:00:00 2001 From: Niels Thykier Date: Sun, 2 Apr 2017 13:28:08 + Subject: [PATCH] fields.c: Avoid unnecessary translations for error messages When dpkg-query is parsing the status database, simply looking up transl

Re: debian-policy: Deprecating dependency of "binary" on "build"

On Thu, 25 Aug 2016 22:06:51 +0200 (CEST) Santiago Vila wrote: > Package: debian-policy > Version: 3.9.8 > Severity: wishlist > > Greetings. > Hi, CCing debian-dpkg@l.d.o because I think Guillem would be interested in this. > Debian Policy 4.9 says: > > Both binary-* targets should depend on

Re: [MBF]: Building arch:all and arch:any without build-{arch,indep} targets

Sven Joachim: > On 2016-07-06 02:51 +0200, Guillem Jover wrote: > >> [...] >> This has happened now with the upload of dpkg 1.18.8. > > Anyone volunteering to upgrade the severity of those 82 bugs to serious? > > Cheers, >Sven > > > 1. > https://bugs.debian.org/cgi-bin/pkgreport.cgi?t

Re: [debhelper-devel] Bug#825792: issues caused by lack of a bpo in jessie

Nicholas D Steeves: > Package: debhelper > Version: 9.20160403 > > Dear maintainer, > > Please backport debhelper to Jessie. Here are the issues I've > encountered resulting from its absence: > > 1) lintian bpo version depends on a newer debhelper > - lintians errors must presently be ignor

Re: [PATCH v2] Support for PAX extended header and Linux extended attributes

Ian Jackson: > Stefan Berger writes ("[PATCH v2] Support for PAX extended header and Linux > extended attributes"): >> The following patch adds support for the tar pax extended header to the tar >> parser so that tar files with pax extended headers containing Linux extended >> attributes can be pr

Re: [PATCH] Support for PAX extended header and Linux extended attributes

Mimi Zohar: > [...] > (CC'ing Niels and Andrew) > > Support for including security.ima xattrs in Debian packages (Bug#766267 > ) required debhelper scripts. With the following two kernel patches, > GNU tar works without any other changes. Should we update the original > request or open a new one

[MBF]: Building arch:all and arch:any without build-{arch,indep} targets

Hi, The targets are "officially" mandatory and have been since 3.9.4 (released in September 2012). Currently lintian and dpkg still forgive their absence to avoid auto-rejects and FTBFS bugs. However, Guillem and I would like to get the remaining packages updated sooner rather than later (notab

Re: [RFC/dpkg PATCH] Introducing an relaxed-Essential-like "Important" field

Julian Andres Klode: > Since a few years, APT supports an "Important" field that is similar > to Essential, but without the requirement for those packages to be > installed (they just need to remain installed) and the ordering > constraints. Previously, it was already an alias for Essential in > AP

Re: Bug#657390: lintian: Please make build-arch and build-indep required targets

On Wed, 28 Aug 2013 04:28:07 +0200 Guillem Jover wrote: > Hi! > > On Mon, 2013-08-26 at 09:58:33 +0200, Niels Thykier wrote: > > [...] > > Well, if we take into account the dynamics of normal transitions the > remaining long tail usually takes a very long time

Re: simple next step for getting .buildinfo files into Debian

Niels Thykier: > Holger Levsen: >> Hi ftp folks, >> > > Hi, > >> while we still appreciate your comments on this proposal as last week >> described in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763822 I'd >> like >> to make a in

Re: simple next step for getting .buildinfo files into Debian

ldinfo files in > Debian… > > > cheers, > Holger > Thanks, ~Niels From 10bc29c42eb36916aba1290c155126755837d903 Mon Sep 17 00:00:00 2001 From: Niels Thykier Date: Mon, 14 Dec 2015 20:46:28 + Subject: [PATCH 1/2] daklib/upload.py: Silently accept and discard .buildinfo file

Re: Replacing ldconfig maintscripts with declarative methods

Hi, As of debhelper/9.20151004, dh_makeshlibs is now using triggers rather than maintainer scripts to invoke ldconfig. * Lintian in untable + testing is already aware of this * Lintian has /not yet/ been backported. Lintian from backports still (incorrectly) reports this an issue. Please d

Add signatures and stronger hashes to deb files (was: Re: [debhelper-devel] Request to re-open "Bug#540215: Introduce dh_checksums" discussion)

On 2015-07-06 19:11, Mimi Zohar wrote: > Hi! > > When I opened the "Bug#766267: debhelper: add file signature support > in .deb packages" feature request for adding file signatures to debian > packages, I wasn't aware Franklin Liat submitted a feature request in > 2010 for sha256 support - Bug#54

Re: Replacing ldconfig maintscripts with declarative methods

On 2015-08-29 23:52, Aurelien Jarno wrote: >[...] > >> * The major concern I have, is that "activate"-triggers are done for >>- unpack (is this ok?) >>- configure (ok) >>- remove (ok, assuming it is post-removal) >>- purge (should not be an issue) >>- deconfigure (would be a no

Re: Replacing ldconfig maintscripts with declarative methods

On 2015-08-25 15:12, Ian Jackson wrote: > Niels Thykier writes ("Replacing ldconfig maintscripts with declarative > methods"): >> A possible solution is to replace these scripts with an >> "activate-no-await" trigger (again, no-await to avoid trigger cycles

Re: [DDEB] Status on automatic debug packages (2015-08-24)

On 2015-08-25 11:29, Matthias Klose wrote: > On 08/24/2015 11:12 PM, Niels Thykier wrote: >> * debhelper will be including debug-ids in the control file to make it >>easier to find the necessary debug symbols for a given file. >>- Thanks to paultag for this idea. &

[DDEB] Status on automatic debug packages (2015-08-24)

Hi, Here is the "post-debconf" status on automatic debug packages ("ddebs"). The previous status from 2015-06-29 can be found in [0]. What is it? === * ddebs are Debian packages with the extension .deb that contain debugging symbols and are built implicitly. - A package foo_1.23.deb

Re: [dpkg+debhelper] On declarative packaging and dpkg metadata

On 2015-08-23 15:30, Niels Thykier wrote: > Hi, > > Guillem and I had a chat at DebConf about making packaging more > declarative and dpkg metadata - these are the notes, I wrote down. > > [...] > > [1] Format we discussed was based on the update-alternatives --query &

Replacing ldconfig maintscripts with declarative methods

Hi, Currently, all Debian libraries (is required to) have a call ldconfig in postrm and postinst. I would like to replace that with a declarative method somehow. There are a couple of reasons for this: * Packages without postinst scripts do not need to be "configured" explicitly (because dp

[dpkg+debhelper] On declarative packaging and dpkg metadata

Hi, Guillem and I had a chat at DebConf about making packaging more declarative and dpkg metadata - these are the notes, I wrote down. * Use a spec/manifest to declare what is in the package (e.g. mtree-like). This could store (among other things) the following metadata about each file:

[APT+dpkg] Ad-hoc dpkg/APT meeting

Hi, There was a meeting about APT and dpkg yesterday. Attendees: DonKult, jak, aj, mvo, XTaran, matm, mones, guillem, nthykier * APT announced some new features. These are already on d-d-a, so I will skip over them. * Guillem suggested that APT moved its packages lists to a "neutral"

Status on ddeb support in Debian

Niels From fe1277fe3301839d5c8b1d9c7ef518909e1b4277 Mon Sep 17 00:00:00 2001 From: Niels Thykier Date: Sat, 4 Apr 2015 08:45:21 +0200 Subject: [PATCH] Unconditionally enable ddeb-support Signed-off-by: Niels Thykier Conflicts: dh_strip --- dh_strip | 3 ++- 1 file changed, 2 insertions(

Re: Bug#786763: redmine: error messages during update of ruby-rails packages

On 2015-06-12 15:36, Antonio Terceiro wrote: > Hello Niels, > > Thanks for your insight. Maybe you can help me a little further? > > On Sat, May 30, 2015 at 07:46:02AM +0200, Niels Thykier wrote: >> The output from dpkg suggests redmine has an /awaiting/ trigger cycle.

Re: Bug#786763: redmine: error messages during update of ruby-rails packages

Control: reassign -1 redmine On 2015-05-29 12:49, Antonio Terceiro wrote: > Control: reassign -1 dpkg > Hi Antonio, > On Mon, May 25, 2015 at 02:07:37PM +0200, Jörg-Volker Peetz wrote: >> Antonio Terceiro wrote on 05/25/2015 13:48: >> >> >>> I'm sorry but I cannot see what is the problem; did

Status on (experimental) ddeb support in Debian

Here is an updated status on ddeb support in Debian. The big picture: Still not done. Currently we are just waiting for two parties to implement the missing parts. Where are we? = * We seem to have a rough consensus on using the ".deb" extension for ddebs. I have implemented t

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

On 2015-05-03 18:58, Guillem Jover wrote: > Hi! > > On Tue, 2015-04-07 at 22:11:18 +0200, Niels Thykier wrote: >> A) Use ".deb" (i.e. the regular extension) with a new "section". > > Is there any problem with using the existing "debug" section

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

On 2015-04-04 10:54, Niels Thykier wrote: > On 2015-04-04 09:54, Josselin Mouette wrote: >> Le jeudi 02 avril 2015 à 19:37 +0200, Esokrates a écrit : >>> Hi, >>> >>> I am particularly interested in automatic debug packages, as the current >>> situa

Re: Experimental ddeb support in debhelper and lintian

On 2015-04-11 07:14, Niels Thykier wrote: > [...] > >> Stretch is a two year time frame though, which makes me kinda sad. Thanks >> for you effort though, keep up the amazing work! If I understand correctly, >> if >> it would have been something for stretch,

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

On 2015-04-09 09:25, Esokrates wrote: > On Tuesday, April 07, 2015 10:11:18 PM Niels Thykier wrote: >> [...] > > So mostly that is more a decision making (political) problem, than a > technical > one. It is not entirely clear to me that we any have (major) political issu

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

On 2015-04-07 21:10, Niels Thykier wrote: > On 2015-04-04 12:58, Esokrates wrote: >> On Saturday, April 04, 2015 10:54:09 AM Niels Thykier wrote: >> >> [...] >> >> I know predictions are hard, but is there a plan to get things done for the >> next release

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

On 2015-04-04 12:58, Esokrates wrote: > On Saturday, April 04, 2015 10:54:09 AM Niels Thykier wrote: >> [...] >>- Trying to get the reproducible team to try it out to see if it >> regresses anything (incl. reproducible builds) > > I guess the ddeb's

Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

On 2015-04-04 09:54, Josselin Mouette wrote: > Le jeudi 02 avril 2015 à 19:37 +0200, Esokrates a écrit : >> Hi, >> >> I am particularly interested in automatic debug packages, as the current >> situation is pretty messy imho. I found >> https://wiki.debian.org/AutomaticDebugPackages. >> Does any

Re: More trigger cycles

On 2015-02-20 17:42, Guillem Jover wrote: > Hi! > > On Wed, 2015-02-18 at 19:00:23 +0100, Niels Thykier wrote: > [...] >> @dpkg maintainers: Please make the necessary changes to revert the >> trigger cycle error or have dpkg recover from it automatically >> im

Re:

On 2015-02-18 18:45, Glenn wrote: > I'm running Debian Wheezy Linux and have no problems installing and > running Privoxy when using: > sudo apt-get install privoxy > > > However, when I do the following on a fresh Debian installation: > sudo dpkg-deb -x libyaml-tiny-perl_1.51-1_all.deb / > sudo

More trigger cycles

Hi, Based on #778695, it seems like we still have trigger cycles. At this point in the freeze, I am afraid it is too late to fix the remaining cycles. I have asked Johannes if this kind of trigger cycles can be found via his script. If so, hopefully we can have them eliminated for Stretch, but

Re: apt-get -qq and warning about possible modification

On 2015-02-02 13:29, Murukesh Mohanan wrote: > The manpage for apt-get says: > > Note that quiet level 2 implies -y; you should never use -qq without a > no-action modifier such as -d, --print-uris or -s as APT may decide to do > something you did not expect. > > Are there any concrete examples o

Re: gitweb breaks apache upgrade

On 2015-01-08 09:56, Guillem Jover wrote: > Hi! > > On Wed, 2015-01-07 at 17:07:14 -0800, Jonathan Nieder wrote: >> Guillem Jover wrote: >>> In this case though, it seems switching to interest-noawait is the >>> correct fix, because gitweb just wants to be notified when the >>> apache2-maintscript

Re: Bug#771971: dpkg hangs installing "init" during upgrade from wheezy to jessie

Control: tags -1 moreinfo On Thu, 4 Dec 2014 00:56:48 + Steve McIntyre wrote: > This is reproducible on demand \o/ > > I realised that the VM image had a few unneeded packages, so I did > > # apt-get remove --purge x11-common libx11-6 libx11-data > > then > > # apt-get update > # apt-get

Re: dbus fails to upgrade rendering entire apt unusable

On Fri, 23 Jan 2015 09:07:37 -0500 Yaroslav Halchenko wrote: > Package: dbus > Version: 1.8.12-1 > Severity: critical > > Decided to upgrade my jessie/sid system today to see if remedy for hangouts > not > working came about (#770659) and upgrade failed because of dbus. Here is an > output of

Re: gitweb: dpkg trigger cycle via apache2

On 2015-01-07 21:29, Jonathan Nieder wrote: > Hi Niels, > > Niels Thykier wrote: > >> Debian `dpkg' package management program version 1.17.23 (amd64). > [...] >> chain of packages whose triggers are or may be responsible: >> gitweb -> gitweb >>

Two more trigger issues found

Hi, Thanks to Johannes and Holger's work on finishing the trigger cycle detection script on jenkins.d.n, we managed to spot two more trigger issues[1]: #774558 and #774559. Thanks to all involved in creating the tool/job for detecting the cycles (including, but not limited to Johannes and Holger)

Pending dpkg upload will Break your package due to trigger cycle in your package

Hi, This package appears to have a trigger cycle causing upgrade issues from Wheezy to Jessie. To fix this issue, you need upload a patched version without this cycle *and* dpkg needs to be upgraded prior to your package. The latter is solved by making dpkg "Breaks" your package. I have request

Re: understanding dpkg trigger cycles

On 2014-12-11 19:59, Guillem Jover wrote: > [ CCed d-release. TL;DR: josch has created a list of packages that can > generate trigger cycles (13), I'm filing bug reports. ] > > Hi! > > On Thu, 2014-12-11 at 13:51:16 +0100, Johannes Schauer wrote: >> [...] > > Yes, it does! I've excluded self-

Re: Bug#770627: dbus: Please (consider) switch(ing) to no-await triggers

On 2014-12-05 05:20, Guillem Jover wrote: > Hi! > > [...] >> My question is, crucial for who? If dbus-daemon has not yet reloaded, >> then dbus-daemon will continue to work fine (it's in a consistent state >> either way), but the package that shipped the system service or security >> policy (in #7

Re: Bug#770448: reassigning to dpkg ("Setting up libpam-modules-bin (1.1.8-3.1) hangs forever with dpkg using 100% cpu")

On 2014-12-07 12:50, Holger Levsen wrote: > control: severity -1 serious > control: reassign -1 dpkg > > Hi, > > reassigning to dpkg, as this is the hanging process here. Several people have > now reported they have seen this issue on there systems... (here and also via > irc.) > > If you disa

Re: Status on dpkg for Jessie

On 2014-11-21 19:34, Guillem Jover wrote: > Hi! > > On Fri, 2014-11-21 at 18:36:45 +0100, Niels Thykier wrote: >> Do you have an ETA on the next upload of dpkg (and if there is anything >> blocking it)? > > Yes, it's waiting on readahead-fedora, waiting in the DEF

Status on dpkg for Jessie

Hi Dpkg maintainers, Do you have an ETA on the next upload of dpkg (and if there is anything blocking it)? Besides the filed 3 RC bugs, the compat symlinks also need to be recreated. The latter does not have a bug (at least, not an RC one); if you prefer I can file one for it Thanks, ~Niels -

Re: [RFC PATCH] dpkg-buildflags: Switch to -fstack-protector-strong

On 2014-06-27 17:04, Moritz Mühlenhoff wrote: > On Tue, Jun 24, 2014 at 09:38:18PM +0200, Niels Thykier wrote: >>> I think we need a lintian check to gain some traction. >> >> Already implemented in 2.5.23 (#711193)[1]. > > Thanks! Seems I was fooled by outda

Re: [RFC PATCH] dpkg-buildflags: Switch to -fstack-protector-strong

On 2014-06-24 18:37, Moritz Muehlenhoff wrote: > On Tue, Jun 24, 2014 at 07:11:58AM -0700, Kees Cook wrote: >> Though really hardening-wrapper should be >> deprecated for Jessie. > > I looked into it, but the number of packages using -wrapper or > -includes is too large to do this realistically. R

Re: stable update of dpkg (>= 1.17.2) and apt (>= 0.9.16.1) for build profiles

On 2014-05-01 05:29, Guillem Jover wrote: > Just out of curiosity what part of the infrastructure requires an > updated dpkg to get profiles support? My guess would be lintian and > sbuild, anything else? Although isn't lintian run from a git checkout, > or is that only for lintian.d.o and not for

[dpkg:src/unpack.c] Possible unused call to strcpy

Hi, I spotted this piece of code in src/unpack.c (around line 614) """ /* * OK, we're going ahead. */ trig_activate_packageprocessing(pkg); strcpy(cidirrest, TRIGGERSCIFILE); trig_parse_ci(cidir, NULL, trig_cicb_statuschange_activate, pkg, &pkg->available); /* Read the conffil

Re: Status of build-arch coverage

On 2014-02-20 18:21, Steve Langasek wrote: > On Thu, Feb 20, 2014 at 12:31:28PM +, Colin Watson wrote: >> On Wed, Feb 19, 2014 at 02:29:45PM -0800, Steve Langasek wrote: >>> Ok. The statistics still seem awfully low to me; but I guess >>> http://people.debian.org/~cjwatson/dhstats.png shows th

Re: [dpkg] 03/20: dpkg-buildpackage: Honor new DEB_SIGN_KEYID environment variable

On 2013-10-27 05:22, Guillem Jover wrote: > This is an automated email from the git hooks/post-receive script. > > guillem pushed a commit to branch master > in repository dpkg. > > commit f397e9d72bf811c3e8d44746a41b7757638a5c1e > Author: Guillem Jover > Date: Sat Aug 31 18:21:53 2013 +0200 >

Re: Bug#657390: lintian: Please make build-arch and build-indep required targets

On 2013-01-23 04:46, Guillem Jover wrote: > Hi! > Hi, Restarting this as Wheezy has been out for a while. > On Tue, 2013-01-22 at 23:16:06 +, Roger Leigh wrote: >> On Thu, Jan 10, 2013 at 11:46:46AM +0100, Niels Thykier wrote: >>> Things have changed a bit since w

Unchecked close of write handles (Was: Re: [SCM] dpkg's main repository branch, master, updated. 1.16.10-146-ga62fb6a)

On 2013-04-24 01:28, Guillem Jover wrote: > The following commit has been merged in the master branch: > commit a62fb6adecfcb362e5f8927db33f32676668984a > Author: Guillem Jover > Date: Sun Dec 30 01:42:11 2012 +0100 > > Use three-argument form of open in perl code > > Fixes InputOu

Re: Bug#657390: lintian: Please make build-arch and build-indep required targets

On 2013-01-23 04:46, Guillem Jover wrote: > Hi! > > [...] > > The first stage could be to wait a bit after testing thaws to see the > progress; after a bit, change/rename the tag to an error w/o autoreject. That can be done. > Wait and see how it progresses, and after a bit more (several months

Re: Absolute symlinks in deb-packages

On 2012-11-27 15:46, Tobias Eliasson wrote: > Hi. > Hi, > I hope this question is sent to the right mailing-list. > I am not sure it is, d-devel might be better but I am not certain enough to do the actual redirect. > We're using debian-packages (wheezy) for building our cross-toolchain at >

off_t and dpkg_ar_member_get_size

Hi, I was considering to document the functions of ar.c when I noticed a possible issue in dpkg. It seems to me that dpkg_ar_member_get_size may (silently) truncate a "large file" when off_t is 32 bits. But I admit being uncertain here as I had difficulties finding a normative specification of t

Re: Bug #340306: Specification draft for signed debs

On Jun 11, 2012 12:21 "Ansgar Burchardt" wrote: > Hi, > > On 06/11/2012 11:26 AM, Niels Thykier wrote: > > Archive support > > --- > > > > The FTP masters have requested that all signatures are stored in a > > single ar member of the

Bug #340306: Specification draft for signed debs

me. :) ~Niels PS: I am not subscribed to the bug, so please CC me accordingly. [DRM] https://wiki.debian.org/Teams/Dpkg/RoadMap """ Merge back functionality from dpkg-sig, debsigs-verify, etc: * Draft a new spec for the signature support inside .deb. * Write a dpkg-sig

Typos in 1.16.4 changelog

Hi, I noticed two potentional typoes in the changelog: * usege -> usage * invokations -> invocations Admittedly, I am not a 100% sure on the latter, but googling "define: invokations" suggests should have been "invocations". ~Niels 0001-d-changelog-Fix-two-typoes.patch Description: applicat

Re: [PATCH] Add documentation for dpkg/version.h

On 2012-05-24 20:35, Guillem Jover wrote: > Hi! > Hi, > On Thu, 2012-05-24 at 15:07:23 +0200, Niels Thykier wrote: >> Attached is a proposed patch to add doxygen documentation for the >> contents of dpkg/version.h. I was not sure if you would have preferred >> a bug

[PATCH] Add documentation for dpkg/version.h

/coding-style.txt ~Niels [1] http://people.debian.org/~nthykier/dpkg-doxygen/group__version.html >From 2afb5a1114602601ea0d07b1208d21bbf2784018 Mon Sep 17 00:00:00 2001 From: Niels Thykier Date: Thu, 24 May 2012 13:08:51 +0200 Subject: [PATCH 1/2] Fix two typoes in doc/coding-style.txt Sig

Re: Multiarch file overlap summary and proposal

On 2012-02-14 07:43, Russ Allbery wrote: > [...] > > * Lintian should recognize arch-qualified override files, and multiarch: > same packages must arch-qualify their override files. debhelper > assistance is desired for this. > > [...] I have no problem with Lintian accepting arch-qualified

  1   2   >