Bug#1067427: dpkg-dev: Fail to generate a substitution variable ${t64:Provides} (time_t transition)

Control: tags -1 + moreinfo On Thu, 21 Mar 2024 at 15:00:52 +0100, Christian Marillat wrote: > I noticed this bug with the libopenshot-audio source and with > armel, armh and powerpc architectures from buildd logs and my rebuild. > > I didn't pay attention for others sources, but I noticed that

Re: Another usrmerge complication

On Sun, 17 Mar 2024 at 11:23:28 +0900, Simon Richter wrote: > When /bin is a symlink to usr/bin, > and I install two packages, where one installs /bin/foo and the other > installs /usr/bin/foo My reading of Policy is that this situation is already a Policy violation: To support merged-/usr

Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

Package: tech-ctte Severity: normal X-Debbugs-Cc: debian-d...@lists.debian.org, debian-gtk-gn...@lists.debian.org, vor...@debian.org I'm requesting advice from the tech-ctte (or anyone else with relevant knowledge, e.g. the dpkg team or the drivers of the time64 transition) on how to resolve

Re: DEP 17: Improve support for directory aliasing in dpkg

On Sat, 22 Apr 2023 at 12:43:09 +0200, Helmut Grohne wrote: > Guillem also > raised that this is changing the source of truth from the dpkg database > to the actual filesystem, which Guillem considers wrong and I find that > vaguely agreeable. To be fair, dpkg does already have at least one case

Re: DEP 17: Improve support for directory aliasing in dpkg

On Fri, 21 Apr 2023 at 15:29:33 +0100, Luca Boccassi wrote: > After Bookworm ships I plan to propose a policy change to the CTTE and > policy maintainers to forbid shipping files in the legacy directories > altogether, followed by a debhelper change to adjust any stragglers > automatically at

Bug#1021292: Enabling branch protection on amd64 and arm64

On Tue, 25 Oct 2022 at 15:34:26 +0100, Wookey wrote: > These are hardware features (new instructions) that 'tag' pointers and > branch targets to make it much harder for malicious code to implement > ROP (return oriented programming) and JOP (Jump oriented programming) > attacks. > > They have

Bug#1006655: dpkg-maintscript-helper: new mode to remove unmodified conffile, but without renaming modified conffile

Package: dpkg Version: 1.21.1 Severity: wishlist File: /usr/bin/dpkg-maintscript-helper If the conffile affected by `dpkg-maintscript-helper rm_conffile` has been modified, d-m-h moves it out of the way by renaming it to conffile.dpkg-backup and then to conffile.dpkg-bak. This seems like an

Bug#949395: dpkg: Old packaged files not always removed, causing various issues

On Sun, 12 Sep 2021 at 14:47:20 +0200, Andreas Metzler wrote: > On 2021-09-11 Simon McVittie wrote: > > GLib uses a generated postinst where #MULTIARCH# gets replaced > > by the multiarch tuple of the package. > > dpkg-buildpackage sets DEB_BUILD_MULTIARCH but afai

Bug#994120: dpkg: please provide multiarch tuple to maintainer scripts

Package: dpkg Version: 1.20.9 Severity: wishlist Packages that have a plugin architecture, like glib2.0 and gdk-pixbuf, often want to know the multiarch tuple in their maintainer scripts so that they can enumerate plugins in a multiarch-qualified directory or run multiarch-qualified helper

Bug#949395: dpkg: Old packaged files not always removed, causing various issues

On Sat, 11 Sep 2021 at 18:00:50 +0200, Andreas Metzler wrote: > On 2020-01-20 Simon McVittie wrote: > > Maintainers have seen bugs in various packages where an old file (one > > that was shipped in an old .deb, but not under the same name in a new > > .deb) appears to have

Re: Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

On Tue, 19 Jan 2021 at 05:02:29 +0100, Guillem Jover wrote: > On Mon, 2021-01-11 at 00:48:42 +1100, Stuart Prescott wrote: > > SOURCE_BASE_DIR has a delightful symmetry to SOURCE_DATE_EPOCH and the > > algorithm for use is similar: if it is in the environment then use it, if > > not, > > fall

Bug#974971: lintian: doesn't know about Build-Depends-Packages in deb-symbols(5)

Package: lintian Version: 2.102.0 Severity: normal X-Debbugs-Cc: d...@packages.debian.org dpkg-shlibdeps (>= 1.20.0) adds a Build-Depends-Packages field to deb-symbols(5), which results in warnings from lintian. Please accept this as a known field. Ideally it should be parsed as a list of

Bug#949395: Bug#972703: gnome-boxes does not start, undefined symbol libusb_set_option

dpkg maintainers: This looks similar to #896019 in GLib and #948318 in libcrypt, except instead of their transition from /lib/MULTIARCH to /usr/lib/MULTIARCH, it involves libusb's transition from /lib to /lib/MULTIARCH. I'm worried that we might see this more often as more /lib libraries, like

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

On Tue, 10 Mar 2020 at 07:19:59 +, Paul Wise wrote: > On Tue, Mar 10, 2020 at 7:12 AM Niels Thykier wrote: > > Standardized way of extracting additional build-time artefacts > > This reminds me of the BYHAND stuff, I forget how that works though. I think how that works is that at the

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

On Tue, 10 Mar 2020 at 08:10:55 +0100, Niels Thykier wrote: > Just to clarify something related. Should debhelper and other tools by > default archive "certain files of possible interest" (e.g. config.log)? > Or should we limit it to "on request only"? I think it would probably make most sense

Re: RFC: Standardizing source package artifacts build paths

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/artifacts for collection by a &q

Re: RFC: Standardizing source package artifacts build paths

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 builds replacing current >

Bug#949395: dpkg: Old packaged files not always removed, causing various issues

Package: dpkg Version: 1.19.7 Severity: normal Tags: unreproducible Maintainers have seen bugs in various packages where an old file (one that was shipped in an old .deb, but not under the same name in a new .deb) appears to have been retained on-disk rather than deleted. At some later time,

Bug#942111: dpkg,debhelper: please set HOME, XDG_* to a temporary location during the build

On Mon, 30 Dec 2019 at 09:30:00 +, Niels Thykier wrote: > Jan Braun: > > XDG_RUNTIME_DIR is a systemd-ism, and due to the way it is specified, > > it's extremely unlikely to be implemented in other init systems. XDG_RUNTIME_DIR is not implemented in the init system. It's implemented by

Re: [RFC] Proposal for new source format

On Tue, 22 Oct 2019 at 05:22:57 +0200, Bastian Blank wrote: > - Files need to be compressed and are recorded as such, which is a hard > problem and give rise to tools like pristine-tar and such. My understanding is that this is deliberate: it means the only layer with the hard requirement to be

Bug#942111: dpkg,debhelper: please set HOME, XDG_* to a temporary location during the build

On Thu, 10 Oct 2019 at 14:58:11 +0100, Simon McVittie wrote: > These general-purpose tools, > or the libraries they use, frequently read and write locations such as > $HOME and the freedesktop.org (XDG) base directories[1]. Oops, I forgot the footnote: [1] https://specifications.freede

Bug#908747: Default -I and -i option should not exclude .ignore

On Thu, 13 Sep 2018 at 15:57:48 +0100, Ian Jackson wrote: > Looking more narrowly, it seems to me that: including the .gitignore > (say) is sometimes helpful, and never harmful. So stripping it out is > simply a mistake. I didn't implement this feature, so I could be wrong, but my understanding

Re: Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

On Thu, 13 Sep 2018 at 14:57:47 -0700, Jonathan Nieder wrote: > Jeremy Bicha wrote: > > There is no reason this functionality cannot be offered in Debian. We > > got complaints when we supported other browsers but not Google Chrome. > > Since Google Chrome is not part of Debian, shouldn't this >

Bug#850156: Please firmly deprecate vendor-specific series files [and 1 more messages]

On Wed, 18 Apr 2018 at 21:11:11 -0700, Steve Langasek wrote: > The examples given are for series.ubuntu, which is certainly the case I've > seen in the wild. Ubuntu, as a project, did not ask for this. As an Ubuntu > developer, it has never benefitted me. I have only ever seen it used by >

Bug#850156: Please firmly deprecate vendor-specific series files

On Thu, 19 Apr 2018 at 08:00:28 +, Mike Gabriel wrote: > One example, where the vendor.series file is really helpful is: > https://anonscm.debian.org/cgit/pkg-mate/mate-terminal.git/tree/debian/patches/2001_fix-find-next-previous.patch That one-line change could easily be guarded by #ifdef

Bug#850156: Please firmly deprecate vendor-specific series files

On Wed, 18 Apr 2018 at 14:36:14 +0200, Mike Gabriel wrote: > On Wed, 4 Jan 2017 13:41:53 + Ian Jackson > wrote: > > But [vendor.series] is quite wrong, because it means that the same > > source package has different "contents" on different computers. > > The

Re: Should dpkg remove /etc/opt/ on package removal?

On Mon, 29 Jan 2018 at 22:52:32 +0100, Guillem Jover wrote: > On Sat, 2018-01-27 at 09:46:32 -0500, Jeremy Bicha wrote: > > One of the supported browsers upstream is Google Chrome, which Google > > installs to /opt/chrome/ . According to the FHS, that means its > > configuration should be stored

Re: Bug#884662: glib2.0: sometimes FTBFS on reproducible-builds: tar: ./usr/share/locale/en_??/LC_MESSAGES/glib20.mo/: Cannot savedir: Not a directory

On Mon, 18 Dec 2017 at 09:17:46 +, Simon McVittie wrote: > [#884662] (a build failure inside dpkg-builddeb, not a test failure) > I don't know what is going on, and it doesn't seem particularly likely > to be a GLib bug - GLib just puts files in a tree like any other package, > so

Bug#842845: dpkg-dev: please consider doing parallel build (~= -Jauto) by default

Package: dpkg-dev Version: 1.18.10 Severity: wishlist I've just reported the FTBFS bug for a slang2 upload that failed on all buildds due to a non-parallel-safe upstream build system. It appears that all our official buildds build with DEB_BUILD_OPTIONS=parallel=n for n >= 2, so any Architecture:

Re: Bug#807940: dpkg-deb: unwanted files in data.tar with tar (>= 1.28)

Control: tags 807940 = confirmed Control: merge 807940 807943 Control: retitle 807940 dpkg-deb: unwanted files in data.tar with tar (>= 1.28) Control: reassign 807940 dpkg Control: found 807940 1.17.25 Control: fixed 807940 1.18.2 Control: affects 807940 game-data-packager This bug has already

Re: Bug#807980: libevdocument3-4: Fails to install without specifying an error

Control: reassign 807980 dpkg On 16/12/15 01:15, Wayne Rowcliffe wrote: > I was able to get things working correctly by moving libevdocument3-4 up > in the `/var/lib/dpkg/status` file so that it was next to `evince`. I > have no idea why that changed anything, but afterward it found the > package

Re: Bug#776063: dbus fails to upgrade rendering entire apt unusable

Control: tags 776063 + moreinfo On 23/01/15 14:43, Niels Thykier wrote: On Fri, 23 Jan 2015 09:07:37 -0500 Yaroslav Halchenko deb...@onerussian.com wrote: Decided to upgrade my jessie/sid system today to see if remedy for hangouts not working came about (#770659) and upgrade failed because

Re: Bug#774124: Unable to update dbus to 1.8.12-3

On 29/12/14 06:46, Erwan David wrote: dpkg: dependency problems prevent processing triggers for dbus: dbus depends on libdbus-1-3 (= 1.7.6); however: Package libdbus-1-3:amd64 is not configured yet. dpkg: error processing package dbus (--configure): dependency problems - leaving

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

Control: tags 771989 + moreinfo On Thu, 04 Dec 2014 at 16:39:31 +0100, Niels Thykier wrote: On 2014-12-04 09:11, Simon McVittie wrote: [see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770627#70 for full analysis] If I am correct in my interpretation, then it seems to me that normal

Re: Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)

On 08/02/12 17:22, Aron Xu wrote: Some packages come with data files that endianness matters, and many of them are large enough to split into a separate arch:all package if endianness were not something to care about. AFAIK some maintainers are not aware of endianness issues in their packages