Hi,
* Theodore Ts'o [2021-08-23 20:48]:
I want to ask a potentially stupid question.
[...]
This is pretty much what I was wondering about in
https://lists.debian.org/debian-devel/2021/08/msg00372.html
You, however, phrased it much more eloquently than I could.
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭─
I want to ask a potentially stupid question.
As I understand things, the problem is that in a usrmerge'd file
system where we have the top-level symlinks /{bin,lib,sbin} which
point at /usr/{bin,lib,sbin}, the problem is if we have a package
which contains the file in /sbin/blart, it gets installe
Sam Hartman writes:
> However, Simon has raised what I think is a credible argument that it
> is harmful to perform both / -> /usr transitions and to move files
> between packages in the same release.
> My take away from that is that it may be harmful to move a bunch of
> stuff from / -> /usr unt
TL;DR: Should we hold off on moving stuff from / to /usr in packages
until we develop our plan?
If so, how do we communicate that to people?
> "Russ" == Russ Allbery writes:
Russ> Simon Richter writes:
>> It is less nonsensical because usrmerge exists, since we
>> presumably do
Ansgar writes:
> Different, non-conflicting packages shipping binaries with the same name
> in /bin and /usr/bin (or similar) should be resolved for a while
> now. That as looked at when usrmerge was first introduced. I'm aware of
> one instance where this was intentional to prefer one program ov
Hi Russ,
On Mon, 2021-08-23 at 13:41 -0700, Russ Allbery wrote:
> Right now, in the absence of such a plan, it's obvious that having
> two
> unrelated packages (that do not Conflict) ship a binary with the same
> name
> in /bin and /usr/bin is not sensible, yes? (I believe that's the
> topic
> un
Simon Richter writes:
> It is less nonsensical because usrmerge exists, since we presumably
> don't want to keep the /bin paths in the packages, so at some point we
> need to move /bin/foo to /usr/bin/foo inside a package. That is safe
> with current dpkg, as dpkg will not delete /bin/foo if it
Package: wnpp
Severity: normal
X-Debbugs-CC: debian-devel@lists.debian.org debian-multime...@lists.debian.org
Hi all,
I request help in maintaining package taglib and doing upgrade to new upstream
version (1.12).
Taglib is an essential library to process audio metadata with very high popcon
(> 9
Hi,
On 23.08.21 17:23, Russ Allbery wrote:
[one package with /bin/foo, another with /usr/bin/foo]
This seems clearly nonsensical to me even if usrmerge was never on the
horizon, since which binary you got would randomly depend on the PATH
ordering and the order of /bin vs. /usr/bin in user-set
Tomas Pospisek wrote:
> On 22.08.21 00:11, Guillem Jover wrote:
>> I'm personally just not seeing such consensus, despite the attempts of
>> some to make it pass as so. My perception is that this topic has become
>> such a black hole of despair, that people that take issue with it, are
>> simply
On 23/08/21 at 13:45 +0200, Gard Spreemann wrote:
>
> Mattia Rizzolo writes:
>
> > On Mon, Aug 23, 2021 at 12:59:39PM +0200, Gard Spreemann wrote:
> >> Have the uscan watch file checks that feed qa.debian.org stopped? Is it
> >> on purpose? Perhaps a consequence of the recent release?
> >
> > Th
#
# bts-link upstream status pull for source package general
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
# https://bts-link-team.pages.debian.net/bts-link/
#
user debian-bts-l...@lists.debian.org
# remote status report for #992503 (http://bugs.debian.org/992503)
Processing commands for cont...@bugs.debian.org:
> #
> # bts-link upstream status pull for source package general
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> # https://bts-link-team.pages.debian.net/bts-link/
> #
> user debian-bts-l...@lists.debian.org
Setting
* Ansgar [210823 11:16]:
> Hi Marvin,
>
> On Mon, 2021-08-23 at 10:29 -0400, Marvin Renich wrote:
> > Yet they cannot be counted on to work on Debian now, nor will they on
> > non- or partially-merged systems. You are saying "the end result is
> > thus, so the partially merged system must have t
Luca Boccassi writes:
> Thank you - it has been brought up in this thread as an example of a
> valid setup, so if it is not, I think it could be good to be extra clear
> in the policy? How about the following:
If we tried to document every random bit of buggy packaging behavior
anyone thought of
Hi Marvin,
On Mon, 2021-08-23 at 10:29 -0400, Marvin Renich wrote:
> Yet they cannot be counted on to work on Debian now, nor will they on
> non- or partially-merged systems. You are saying "the end result is
> thus, so the partially merged system must have this property."
No. I am comparing end
> "Simon" == Simon Richter writes:
>> I can see two arguments why we might need a dpkg update:
>>
>> 1) To fix bugs related to directory aliasing.
>>
>> I don't think that there is a consensus those bugs need to be
>> fixed to move forward. (Put another way it's not
* Ansgar [210822 17:29]:
> Hi,
>
> On Sun, 2021-08-22 at 12:29 -0400, Marvin Renich wrote:
> > * Ansgar [210822 05:08]:
> > > To get a filesystem layout equivalent to merged-/usr via symlinks
> > > farming *every* package shipping files in at least /usr/bin,
> > > /usr/sbin and possibly some of
> "Simon" == Simon Richter writes:
Simon> Current dpkg already has handling code so that /bin/foo ->
Simon> /usr/bin/foo is not a problematic move even on usrmerge'd
Simon> systems, so a possible policy would be to allow those and
Simon> disallow package splits, that way we cou
On Sun, 2021-08-22 at 19:10 -0700, Russ Allbery wrote:
> Luca Boccassi writes:
> > On Sun, 2021-08-22 at 07:45 -0700, Russ Allbery wrote:
>
> > > This is already the case. Policy 10.1:
>
> > > To support merged-/usr systems, packages must not install files in
> > > both /path and /usr/pat
Hi Fabian,
Le 23/08/2021 10:53, Fabian Greffrath a écrit :
in the short term, I'd like to replace the prboom-plus Doom engine in
Debian with its more actively developed fork dsda-doom. While
developement of the former has mostly stagnated (granted, it had its
2.6.1um release earlier this month),
Mattia Rizzolo writes:
> On Mon, Aug 23, 2021 at 12:59:39PM +0200, Gard Spreemann wrote:
>> Have the uscan watch file checks that feed qa.debian.org stopped? Is it
>> on purpose? Perhaps a consequence of the recent release?
>
> That's one part that's included in the UDD downtime reported here:
>
On Mon, Aug 23, 2021 at 12:59:39PM +0200, Gard Spreemann wrote:
> Have the uscan watch file checks that feed qa.debian.org stopped? Is it
> on purpose? Perhaps a consequence of the recent release?
That's one part that's included in the UDD downtime reported here:
https://lists.debian.org/debia
Hi list,
Have the uscan watch file checks that feed qa.debian.org stopped? Is it
on purpose? Perhaps a consequence of the recent release?
Best,
Gard
signature.asc
Description: PGP signature
On Mon, Aug 23, 2021 at 9:29 AM Simon McVittie wrote:
> override_dh_gencontrol:
> dh_gencontrol -pprboom-plus --
> -v3:$(DEB_VERSION_UPSTREAM_REVISION)
Using this technique you can even do entirely without bumping the
epoch, using 2:2.6.1um+dsda$(DEB_VERSION_UPSTREAM_REVISION)-..
Hi Stephen and Simon,
Am 23.08.2021 11:28, schrieb Simon McVittie:
Could you build dsda-doom as version 0.21.0-1 with no epoch, while
attaching an epoch to only the prboom-plus transitional binary package?
very good idea! I didn't even think about this possibility, but this is
how I'll do it.
On Mon, 23 Aug 2021 at 10:53:12 +0200, Fabian Greffrath wrote:
> The downside is that dsda-coom introduced a new versioning scheme which
> is currently at v0.21.0, whereas prboom-plus is already at 2.6.1um. To
> provide for an easy upgrade path for prboom-plus users, I'd like to
> introduce the dsd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi all,
in the short term, I'd like to replace the prboom-plus Doom engine in
Debian with its more actively developed fork dsda-doom. While
developement of the former has mostly stagnated (granted, it had its
2.6.1um release earlier this month), the
On Mon, Aug 23, 2021 at 02:21:04AM +0200, Vincent Lefevre wrote:
> On 2021-08-22 23:32:15 +0500, Andrey Rahmatullin wrote:
> > On Sun, Aug 22, 2021 at 08:25:41PM +0200, Tomas Pospisek wrote:
> > > Wouldn't the Bcc'ed email that arrived to the BTS be visible in the bug's
> > > log/archive (on the bu
29 matches
Mail list logo
