Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Sean Whitton]

Hello,

On Wed 10 May 2023 at 11:47PM +02, Ansgar wrote:

> Cool, then let's ask tech-ctte.
>
> Dear ctte, please consider overruling the dpkg maintainer to include
> the patch from #994388[1].
>
> Thanks,
> Ansgar
>
>   [1]: https://bugs.debian.org/994388#397

This would require a new, maintainer-overruling vote.
Our existing decisions do not apply, so far as I can tell.

I have written a separate message to the bug and to debian-dpkg with a
proposal to avoid having to have such a vote.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Ansgar]

Package: tech-ctte
X-Debbugs-Cc: Russ Allbery , Sean Whitton 
, Helmut Grohne , Luca Boccassi 
, debian-d...@lists.debian.org, debian-devel@lists.debian.org

On Wed, 2023-05-10 at 14:36 -0700, Russ Allbery wrote:
> Ansgar  writes:
> > Debian going out of its way to tell derivative users to switch back from
> > merged-/usr to split-/usr is the *opposite* of trying to make things as
> > smooth for them as possible.
> 
> Yes, I agree with that part and I think I objected to that at the time.
> Nonetheless, one bad decision doesn't mean that it is Debian policy that
> we don't care about derivatives or their users.  I think we made a mistake
> there which is not in alignment with our ideals or our goals.  We should
> try to reverse that mistake, not double down on it.

Cool, then let's ask tech-ctte.

Dear ctte, please consider overruling the dpkg maintainer to include
the patch from #994388[1].

Thanks,
Ansgar

  [1]: https://bugs.debian.org/994388#397

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

[Russ Allbery]

Ansgar  writes:
> On Wed, 2023-05-10 at 13:50 -0700, Russ Allbery wrote:

>> Caring about them isn't the same thing as doing everything they want. 
>> We can both try to make things as smooth for them as possible and still
>> make design decisions about Debian that they may disagree with or that
>> may make some property they want to maintain difficult or impossible. 
>> It's the sort of decision we have to make on a case-by-case basis.

> Debian going out of its way to tell derivative users to switch back from
> merged-/usr to split-/usr is the *opposite* of trying to make things as
> smooth for them as possible.

Yes, I agree with that part and I think I objected to that at the time.
Nonetheless, one bad decision doesn't mean that it is Debian policy that
we don't care about derivatives or their users.  I think we made a mistake
there which is not in alignment with our ideals or our goals.  We should
try to reverse that mistake, not double down on it.

-- 
Russ Allbery (r...@debian.org)  

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

[Ansgar]

Hi Russ,

On Wed, 2023-05-10 at 13:50 -0700, Russ Allbery wrote:
> Ansgar  writes:
> > As far as I understand, we do explicitly *not* care about our
> > derivatives with regard to merged-/usr as some packages in Debian
> > recommend users to move *away* from merged-/usr to split-/usr on
> > derivatives, i.e., to an unsupported fs layout.
> 
> Caring about them isn't the same thing as doing everything they want.  We
> can both try to make things as smooth for them as possible and still make
> design decisions about Debian that they may disagree with or that may make
> some property they want to maintain difficult or impossible.  It's the
> sort of decision we have to make on a case-by-case basis.

Debian going out of its way to tell derivative users to switch back
from merged-/usr to split-/usr is the *opposite* of trying to make
things as smooth for them as possible.

I asked the ctte to consider not telling derivative users to revert
from merged-/usr and was told me that "we [ctte] would not consider
this [change] to be in line with our existing decisions" (informally).

I take that as explicitly not caring that we break derivative users'
systems.

Ansgar

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

[Russ Allbery]

Ansgar  writes:

> So why do we allow changes that require listing all reverse dependencies
> in Breaks then? This is known to be wrong for all non- listed packages,
> e.g., all local/vendor/derivative-specific packages.

Because it's a balance; we don't want to stop making changes, and never
making a backward-compatible change doesn't work, so we do the best we can
with the tools we have.  However, if someone with an out-of-Debian package
tells us that a change breaks it, historically we did add them to Breaks.
We just don't have a good way of discovering this.

> As far as I understand, we do explicitly *not* care about our
> derivatives with regard to merged-/usr as some packages in Debian
> recommend users to move *away* from merged-/usr to split-/usr on
> derivatives, i.e., to an unsupported fs layout.

Caring about them isn't the same thing as doing everything they want.  We
can both try to make things as smooth for them as possible and still make
design decisions about Debian that they may disagree with or that may make
some property they want to maintain difficult or impossible.  It's the
sort of decision we have to make on a case-by-case basis.

-- 
Russ Allbery (r...@debian.org)  

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

[Ansgar]

On Wed, 2023-05-10 at 08:35 -0700, Sean Whitton wrote:
> On Sun 07 May 2023 at 11:14AM +02, Ansgar wrote:
> > Debian's dependency system requires to explicitly declare
> > Depends/Conflicts/Replaces/Breaks, but for obvious reasons we
> > cannot do
> > that for packages outside Debian's ecosystem.
> > 
> > The same is true for diversions/alternatives/* or anything else
> > requiring coordination among all users: the dpkg ecosystem has too
> > many
> > practical limitations to support non-Debian packages on anything
> > but a
> > "it might work" basis (which is usually "good enough").  (This is
> > even
> > true for packages within the Debian ecosystem, especially when one
> > considers partially implemented features like multi-arch.)
> 
> I don't think this is the consensus view.

So why do we allow changes that require listing all reverse
dependencies in Breaks then? This is known to be wrong for all non-
listed packages, e.g., all local/vendor/derivative-specific packages.

> Our derivatives are among our users, for example, and we care about
> them being able to add packages in appropriate ways.

As far as I understand, we do explicitly *not* care about our
derivatives with regard to merged-/usr as some packages in Debian
recommend users to move *away* from merged-/usr to split-/usr on
derivatives, i.e., to an unsupported fs layout.

AFAIR the ctte felt that doing so on derivatives is fine for packages
in Debian (w/o an explicit formal ruling).

Ansgar

Bug#1035888: ITP: dh-builtusing -- debhelper tool generating the Built-Using field for Debian packages

[Nicolas Boulenguez]

Package: wnpp
Severity: wishlist
Owner: Nicolas Boulenguez 
X-Debbugs-Cc: debian-devel@lists.debian.org, 689...@bugs.debian.org, 
990...@bugs.debian.org

* Package name: dh-builtusing
  Upstream: native Debian package, I am the author
  Version : 0.0.1
* URL : https://salsa.debian.org/debian/dh-builtusing
* License : GPL-3+
  Programming Lang: Perl
  Description : debhelper tool generating the Built-Using field for Debian 
packages

This tool may help maintainers of Debian packages by generating parts
of the Built-Using dependencies at build time.
.
It searches the Built-Using and Static-Built-Using fields in a source
control file for substitutions of variables names like
dh-builtusing:x, looks for x in build-dependencies, then defines the
variable with the source package and version for x.
.
In other words, it replaces the call to dpgk-query that each package
or debhelper tool has to duplicate for the Built-Using field.


The dh_builtusing.pod manual page contains a full description.
The log for #689062 contains the original discussion.

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

[Sean Whitton]

Hello,

On Tue 09 May 2023 at 02:07AM +01, Luca Boccassi wrote:

> But again, I do think we need to try and define what it is that we
> want to support here. If we are serious about it, then we should
> codify it, and hold any future changes to the same standards, wherever
> they may come from. If we are not willing to do this, then I have to
> ask why.

If we can come to some specific conclusions about what we are and are
not going to support that have consensus, as part of this work, we can
and should write those down in Policy.  There's probably too much
complexity to achieve something more general than that, however.

It is completely reasonable, as you wrote in another message, to want
this transition to be held to the same standards as others.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sean Whitton]

Hello,

On Sun 07 May 2023 at 11:14AM +02, Ansgar wrote:

> Debian's dependency system requires to explicitly declare
> Depends/Conflicts/Replaces/Breaks, but for obvious reasons we cannot do
> that for packages outside Debian's ecosystem.
>
> The same is true for diversions/alternatives/* or anything else
> requiring coordination among all users: the dpkg ecosystem has too many
> practical limitations to support non-Debian packages on anything but a
> "it might work" basis (which is usually "good enough").  (This is even
> true for packages within the Debian ecosystem, especially when one
> considers partially implemented features like multi-arch.)

I don't think this is the consensus view.

Our derivatives are among our users, for example, and we care about them
being able to add packages in appropriate ways.

Our policy documents and best practices contain various provisions with
user's own packages in mind.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Emmanuel Arias]

On Wed, May 10, 2023 at 11:41 AM Ricardo Ribalda Delgado <
rica...@ribalda.com> wrote:

> Hi Emmanuel
>
>
> On Wed, May 10, 2023 at 1:03 AM Emmanuel Arias  wrote:
> >
> > Upstream respond  without  objection. Is there any volunter  to this
> transition?  If not i would happy to work on it.
>
> I can take care of it. I won't probably start until the weekend though
>

Sounds good, thanks!

Cheers,

>
> Regards
>
> >
> > Cheers
> >
> >
> > El mar, 9 de may de 2023, 07:54, Emmanuel Arias 
> escribió:
> >>
> >> Oh, I did not note/check that virtme already exists in Debian.
> >>
> >> Anyway, I am interest in the package, so I will follow virtme/virme-ng
> project :-)
> >>
> >> El mar, 9 de may de 2023, 07:49, Ricardo Ribalda Delgado <
> rica...@ribalda.com> escribió:
> >>>
> >>> On Tue, May 9, 2023 at 12:46 PM Andrea Righi <
> andrea.ri...@canonical.com> wrote:
> >>> >
> >>> > On Tue, May 09, 2023 at 11:32:59AM +0200, Ricardo Ribalda Delgado
> wrote:
> >>> > > Hi
> >>> > >
> >>> > >
> >>> > > On Tue, May 9, 2023 at 11:28 AM Héctor Orón Martínez
> >>> > >  wrote:
> >>> > > >
> >>> > > > Hello,
> >>> > > >
> >>> > > > El mar, 9 may 2023, 9:51, Andrea Righi <
> andrea.ri...@canonical.com> escribió:
> >>> > > >>
> >>> > > >> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez
> wrote:
> >>> > > >> > Hello,
> >>> > > >> >
> >>> > > >> >   virtme already exists in Debian, what would be the benefit
> of virtme-ng
> >>> > > >> > over virtme?
> >>> > > >> >
> >>> > > >> > https://salsa.debian.org/debian/virtme
> >>> > > >> >
> >>> > > >> > Regards
> >>> > > >>
> >>> > > >> The original virtme project is not maintained anymore
> >>> > > >> (https://github.com/amluto/virtme), so we decided to fork the
> project
> >>> > > >> and continue the development / bug fixing in virtme-ng
> >>> > > >> (https://github.com/arighi/virtme-ng).
> >>> > > >>
> >>> > > >> Some people are already using and contributing to virtme-ng and
> there
> >>> > > >> are plans to package it in SuSE.
> >>> > > >>
> >>> > > >> Honestly I don't know what would be the right procedure to
> "obsolete"
> >>> > > >> the old virtme package and replace it virtme-ng (if possible),
> but
> >>> > > >> ideally it would be nice to do something like this. Any
> guidance or
> >>> > > >> suggestion is welcome.
> >>> > > >
> >>> > > >
> >>> > > > I suggest we evaluate switching upstream from virtme to
> virtme-ng, on the Debian virtme package. I would not mind if you want to be
> added as uploader for the package.
> >>> > > >
> >>> > > > Ricardo has been working on virtme. What do you think?
> >>> > >
> >>> > > SGTM. Maybe we can send an email out of courtesy to the old virtme
> author.
> >>> >
> >>> > All good to me as well! I already sent an email to the virtme author
> >>> > (Andrew Lutomirski) to inform him that I was forking the project,
> but I
> >>> > didn't get any response.
> >>>
> >>> That sounds good.
> >>>
> >>> >
> >>> > Maybe I can try to ping him again and see if he's also happy about
> this
> >>> > plan.
> >>>
> >>> May I suggest that when you ping them, tell them about the plans to
> >>> replace virtme with virtme-ng on Debian and put  me on cc?
> >>>
> >>> Thanks!
> >>>
> >>>
> >>> >
> >>> > -Andrea
>

Bug#1035883: general: TMOUT and autologout are set to 3600, but logout occurs much earlier

[Jim Anderson]

Package: general
Severity: minor

Dear Maintainer,

This bug report is a rather minor issue, but it is an inconvenience for me.

I realize that auto logout is a general security feature, but in my
case, I have a secrure environment where only my wife and I have access to
my computer. I strong prefer to NOT have my computer auto logout for 10 hours,
allowing me to leave my computer in the evening and return to it in the
morning without haveing to log on.

I have the enrivonment variables TMOUT and autologout both set to 36000,
or 10 hours, but these are not honored by the system.

Thank you.

Jim Anderson


-- System Information:
Distributor ID: Bunsenlabs
Description:BunsenLabs GNU/Linux 10.5 (Lithium)
Release:10.5
Codename:   buster
Architecture: x86_64

Kernel: Linux 4.19.0-23-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Re: RFP: virtme-ng -- Tool to build and run a kernel inside a virtualized snapshot of your live system

[Ricardo Ribalda Delgado]

Hi Emmanuel


On Wed, May 10, 2023 at 1:03 AM Emmanuel Arias  wrote:
>
> Upstream respond  without  objection. Is there any volunter  to this 
> transition?  If not i would happy to work on it.

I can take care of it. I won't probably start until the weekend though

Regards

>
> Cheers
>
>
> El mar, 9 de may de 2023, 07:54, Emmanuel Arias  escribió:
>>
>> Oh, I did not note/check that virtme already exists in Debian.
>>
>> Anyway, I am interest in the package, so I will follow virtme/virme-ng 
>> project :-)
>>
>> El mar, 9 de may de 2023, 07:49, Ricardo Ribalda Delgado 
>>  escribió:
>>>
>>> On Tue, May 9, 2023 at 12:46 PM Andrea Righi  
>>> wrote:
>>> >
>>> > On Tue, May 09, 2023 at 11:32:59AM +0200, Ricardo Ribalda Delgado wrote:
>>> > > Hi
>>> > >
>>> > >
>>> > > On Tue, May 9, 2023 at 11:28 AM Héctor Orón Martínez
>>> > >  wrote:
>>> > > >
>>> > > > Hello,
>>> > > >
>>> > > > El mar, 9 may 2023, 9:51, Andrea Righi  
>>> > > > escribió:
>>> > > >>
>>> > > >> On Tue, May 09, 2023 at 09:30:54AM +0200, Héctor Orón Martínez wrote:
>>> > > >> > Hello,
>>> > > >> >
>>> > > >> >   virtme already exists in Debian, what would be the benefit of 
>>> > > >> > virtme-ng
>>> > > >> > over virtme?
>>> > > >> >
>>> > > >> > https://salsa.debian.org/debian/virtme
>>> > > >> >
>>> > > >> > Regards
>>> > > >>
>>> > > >> The original virtme project is not maintained anymore
>>> > > >> (https://github.com/amluto/virtme), so we decided to fork the project
>>> > > >> and continue the development / bug fixing in virtme-ng
>>> > > >> (https://github.com/arighi/virtme-ng).
>>> > > >>
>>> > > >> Some people are already using and contributing to virtme-ng and there
>>> > > >> are plans to package it in SuSE.
>>> > > >>
>>> > > >> Honestly I don't know what would be the right procedure to "obsolete"
>>> > > >> the old virtme package and replace it virtme-ng (if possible), but
>>> > > >> ideally it would be nice to do something like this. Any guidance or
>>> > > >> suggestion is welcome.
>>> > > >
>>> > > >
>>> > > > I suggest we evaluate switching upstream from virtme to virtme-ng, on 
>>> > > > the Debian virtme package. I would not mind if you want to be added 
>>> > > > as uploader for the package.
>>> > > >
>>> > > > Ricardo has been working on virtme. What do you think?
>>> > >
>>> > > SGTM. Maybe we can send an email out of courtesy to the old virtme 
>>> > > author.
>>> >
>>> > All good to me as well! I already sent an email to the virtme author
>>> > (Andrew Lutomirski) to inform him that I was forking the project, but I
>>> > didn't get any response.
>>>
>>> That sounds good.
>>>
>>> >
>>> > Maybe I can try to ping him again and see if he's also happy about this
>>> > plan.
>>>
>>> May I suggest that when you ping them, tell them about the plans to
>>> replace virtme with virtme-ng on Debian and put  me on cc?
>>>
>>> Thanks!
>>>
>>>
>>> >
>>> > -Andrea