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 sy
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 w
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 build
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 ba
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 appropri
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 fo
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
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
>
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
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
> f
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 in
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
On Fri, 24 Jun 2016 at 23:01:21 -0700, Josh Triplett wrote:
> Some packages, if installed on any architecture, must be installed for
> every enabled architecture. Most notably, an NSS or PAM module package,
> if enabled in /etc/nsswitch.conf or /etc/pam.d respectively, must exist
> for every enabl
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 bee
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
Control: reassign 776063 apt
Control: severity 771428 critical
Control: forcemerge 771428 776063
Control: affects 771428 dbus
On Fri, 23 Jan 2015 at 19:04:33 +0100, Guillem Jover wrote:
> I think this one should be merged with the other dbus+triggers+apt
> bugs.
Merging it, using the higher of th
Control: tags 776063 + moreinfo
On 23/01/15 14:43, Niels Thykier wrote:
> On Fri, 23 Jan 2015 09:07:37 -0500 Yaroslav Halchenko
> wrote:
>> 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.
>
> T
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 t
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 s
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 packag
20 matches
Mail list logo
