Hi,
On Wed, 2024-06-19 at 08:26 +0200, Ansgar wrote:
> > My understanding of the tag2upload developer position is that this
> > requirement prohibits the goal of tag2upload. People who want to
> > build the source package locally can already use the same algorithm
> >
Hi,
On Sat, 2023-09-16 at 12:58 -0700, Russ Allbery wrote:
> Control: unblock 1051371 by 1050001
>
> Ansgar writes:
>
> > However, there is a proposal by Jackson for an alternative filesystem
> > layout based on symlink farms in consideration by the technical
> &
y be aware of this
policy issue in their consideration of #1050001; the resolution of
which might also cover this issue (#1051371).
Ansgar
[1]: https://bugs.debian.org/1050001#33
esting (not on a
production system)? It might be interesting to experiment with the new
layout.
Ansgar
about this?
Ansgar
[1]: With some exceptions such as some programs have compat symlinks
in the legacy layout or between .../bin and .../sbin.
g out that any software which is trying to
> be portable to Unix systems other than just Linux (which includes the
> BSDs and MacOS) will need to avoid assuming directory aliasing.
Which seems irrelevant for what we do in Debian. On portable system
you can't assume `/bin/sh` to be there either...
Ansgar
and of course avoiding
stuff associated with a certain company which I understand is a goal in
itself for some people)...
I would appreciate a list of technical and ideological reasons why
switching to the Jackson layout is important for Debian.
Ansgar
On Wed, 2023-08-23 at 20:50 +0200, Ansgar wrote:
> > /bin and /lib etc. remain directories (so there is no aliasing). All
> > actual files are shipped in /usr. / contains compatibility symlinks
> > pointing into /usr, for those files/APIs/programs where this is
> > neede
ore coming to the tech-
ctte as far as I know.
If someone wants to go this way, I suggest to just have a GR about it
instead of iterating this at tech-ctte yet again. It's not very
motivating to have some people endlessly argue against moving forward
and wanting to revisit/reverse/change some decisions endlessly.
Ansgar
bout init system
support in Debian and costs/benefits of supporting some of them. :-)
Ansgar
will not give any bugs?
We already *had* these bugs for several releases and found them only
after release (even before usrmerge which makes them non-bugs).
Please provide a plan how to fix these ahead of time; please be aware
that they might only occur with some hardware / configurations.
Ansgar
, social costs are not considered,
but should be (IMHO).
Ansgar
the
FAQ: https://wiki.debian.org/Teams/Dpkg/FAQ?action=diff=78=79
Ansgar
to do as much as they can
to avoid deciding on this :-(
Ansgar
.debian.org
and so on, I think the Debian project *is* the upstream for dpkg.
Ansgar
in non-booting systems.
That is what we sign up to accept by having the warning in dpkg.
Ansgar
Hi Russ,
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 possib
Yes, I do.
Please pass a resolution that you don't want to override the dpkg
maintainer and that telling derivative users to configure their system
in a way that will cause breakage is okay to do for packages in Debian.
Ansgar
Hi,
On Fri, 2023-05-19 at 07:09 -0700, Sean Whitton wrote:
> On Thu 18 May 2023 at 07:55PM +02, Ansgar wrote:
>
> > Why not?
>
> We will not move that fast.
So there is no real reason?
As there doesn't seem to be anything you think need to be talked about
that is missing to
On Thu, 2023-05-18 at 12:14 -0600, Gunnar Wolf wrote:
> Ansgar dijo [Thu, May 18, 2023 at 07:55:03PM +0200]:
> > Why not?
> >
> > Do you think the implications of removing the warning are unclear?
> >
> > Do you think we need to explore alternative sol
Hi,
On Thu, 2023-05-18 at 10:48 -0700, Sean Whitton wrote:
> On Thu 18 May 2023 at 07:21PM +02, Ansgar wrote:
>
> > The full freeze is approaching and there has been no progress on
> > this
> > issue. Does the ctte think a decision before the release is still
> &g
Hi,
On Thu, 2023-05-11 at 00:32 +0200, Ansgar wrote:
> On Wed, 2023-05-10 at 23:47 +0200, Ansgar wrote:
> > Cool, then let's ask tech-ctte.
> >
> > Dear ctte, please consider overruling the dpkg maintainer to
> > include
> > the patch from #994388[1].
> >
On Wed, 2023-05-10 at 19:01 -0700, Sean Whitton wrote:
> 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].
> >
On Wed, 2023-05-10 at 23:47 +0200, 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
For derivat
Package: tech-ctte
X-Debbugs-Cc: Russ Allbery , Sean Whitton
, Helmut Grohne , Luca Boccassi
, debian-d...@lists.debian.org, debian-de...@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
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 merg
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
On Wed, 2022-09-28 at 13:05 -0700, Sean Whitton wrote:
> On Wed 28 Sep 2022 at 08:00PM +02, Ansgar wrote:
> > Package: tech-ctte
> > X-Debbugs-Cc: Zack Weinberg
> > Control: block 1020920 by -1
> >
> > Hi,
> >
> > please clarify if atomi
Thanks,
Ansgar
nd a symlink on merged-/usr systems, and Y is any name?
*sigh*
There has been such a rule for many, many years already.
I really feel you lack investigating the issue before filing yet
another ctte bug about it.
Ansgar
to seeing discussion on this or a summary of previous
private discussion results.
Ansgar
On Sat, 2022-04-09 at 10:59 -0700, Sean Whitton wrote:
> On Sat 09 Apr 2022 at 11:50am +02, Ansgar wrote:
> > I've prepared a patch for the current issue. See the attached proposed
> > NMU diff. I've limited it to minimal changes.
>
> I don't understand. The warning
tee resolves that Debian 'bookworm' should
|support only the merged-usr root filesystem layout, dropping support
|for the non-merged-usr layout.
Maybe the misunderstanding will be resolved with this.
Ansgar
Hi,
I've prepared a patch for the current issue. See the attached proposed
NMU diff. I've limited it to minimal changes.
Is this something the technical committee finds acceptable?
Ansgar
From 2569c0aca93f2f0d7f5521c3158ed077f206ce0a Mon Sep 17 00:00:00 2001
From: Ansgar
Date: Sat, 9 Apr
o the patch being unfinished.
So talk about that when it happens?
As far as I can tell from the last meeting agenda, the technical
committee doesn't seem to see much technical issues with usrmerge.
Ansgar
dpkg maintainer who insited on it being done right.
No, multiarch is in the "mostly works" state.
If you wanted to do things "properly" (whatever that means), we would
still not have multiarch (given the bugs are not fixed).
Ansgar
rrent postinst warning even
though I've seen not many people aggreeing with having it: at least one
ctte member objected to a proposal to vote on this sooner.
Ansgar
On Thu, 2022-03-24 at 09:12 +0100, Ansgar wrote:
> On Tue, 2022-03-15 at 15:14 -0700, Josh Triplett wrote:
> > This escalation seems in direct contradiction to the tech-ctte
> > decision in 994388.
>
> It already confuses users, for example:
It was pointed out in #-deve
On Thu, 2022-03-24 at 14:49 +0100, Helmut Grohne wrote:
> On Thu, Mar 24, 2022 at 09:12:14AM +0100, Ansgar wrote:
> > Maybe it should be changed into a warning that non-merged-/usr
> > systems
> > will not be supported in the future. The `dpkg-fsys-usrunmess`
> > progr
onger supported by Debian in the future.
Either way, given related questions were already before the tech ctte
several times it would be nice if this could be decided quickly to
avoid this becoming yet another energy drain (we had several
sufficiently long enough threads about this topic already).
Ansgar
d/or `tempfile` to be
considered essential.)
Ansgar
[1]: https://bugs.debian.org/851747
eferences to essential
packages[2] and OpenSuSE[3]).
Ansgar
[1]: https://lists.debian.org/debian-devel/2020/11/msg00232.html
[2]: https://lists.debian.org/debian-ctte/2021/01/msg00041.html
[3]: https://lists.debian.org/debian-ctte/2021/01/msg00037.html
uilt on systems with non-merged-/usr for the reasons we do so
currently).
But I consider these implementations details; it's only useful to
discuss them when we know where we are going and most (or hopefully all)
detail questions probably don't need the technical committee either.
Regards,
Ansgar
[1]: https://en.opensuse.org/openSUSE:Usr_merge
for legacy installations for a move to merged-usr-only
to be implemented. This also isn't relevant for Debian 11 (bullseye),
but I would like to have enough time in the Debian 12 (bookworm)
cycle.
Ansgar
[1]: https://lists.debian.org/debian-devel/2020/11/#00232
continued in December: https
you are talking about. Would
maintainers have to accept patches stopping use of systemd-tmpfiles,
systemd-hostnamed, ...?
Ansgar
build them in an environment suitable for "large" packages.
(Such bugs should of course still be fixed, but that doesn't require
them to be release critical.)
Ansgar
Russ Allbery writes:
> Ansgar writes:
>> Even more, from the "32 bit archs in Debian" BoF at DebConf15 I remember
>> the suggestion that one might have to switch to 64-bit compilers even on
>> 32-bit architectures in the future... So building packages would in
>
o switch to 64-bit compilers even on
32-bit architectures in the future... So building packages would in
general require a 64-bit kernel, multi-arch and 4+ GB RAM.
Ansgar
rozen can be avoided even when the TC
sets it; I even agree that it should be avoided.
Ansgar
to the same location anyway, no compat
symlinks or maintainer script logic required.
Ansgar
in /usr/local/bin when they have locally installed
binaries and autodetection using $PATH is used? /usr/local/bin is
usually before /usr/bin and /bin after all.
dpkg could add a "not-built-in-a-clean-chroot" flag to detect those.
Ansgar
Dear technical committee,
it would be nice if #919951 would be dealt with in time to allow
affected packages to migrate to testing before the freeze.
FWIW it looks like whitedune was now binNMUed, but dune is still blocked
by #919953.
Ansgar writes:
> I am tempted to suggest that this is
inct and could cause confusion with the
| Git project itself.
+---
Just as a guideline for the other 3+ projects that might have come up
with that name ;-)
I am tempted to suggest that this issue is dealt with by passing a
resolution reminding the submitter of 6.3.6 of the constitution and
suggesting a bit more constructive behavior in the future.
Ansgar
ore November as well, and certainly since the default was switched
again in June last year.
Ansgar
very few packages
causing problems and these should have a patch soon.
In addition one has to actually built one of the very few packages in a
merged-/usr environment and then install them in a non-merged-/usr
environment to actually trigger the problem and debootstrap already
defaults to non-mer
Adam Borowski writes:
> On Tue, Dec 04, 2018 at 06:48:45PM +0100, Ansgar Burchardt wrote:
>> In very rare cases (an estimated 0.3% of the archive or so). I'm fairly
>> confident that for more than 0.3% of the archive something can go wrong
>> when building in non-clean e
Ian Jackson writes:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
>> Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
>> systems would no longer be supported. In this case someone would have
>> to write a unusrm
"Alexander E. Patrakov" writes:
> Ansgar Burchardt wrote:
>> Making the feature default was discussed years ago which you are surely
>> aware of. It's not mandatory.
>
> Unfortunately I have to disagree here. Merged /usr is already,
> de-facto, mandatory for ev
Adam Borowski writes:
> On Mon, Dec 03, 2018 at 10:25:46PM +0100, Ansgar Burchardt wrote:
> I believe the difference between those is less than between suboptions of 1
> and 3, but then, as an opponent of 2 as a whole I'm biased.
>
>> Switching to (1) or (3a-with-no-support-in
systems are
>> converted (also with 3a except for far more time for testing).
>
> I agree with your assessment. There are still too many mails I haven't
> read, though, and I cannot commit my hypothetical vote so far, but I
> think the sanest way will be to revert the change in debootstrap.
So (2) with the default to non-merged-/usr or (3a)?
I'm not sure why (2) should not default to merged-/usr though.
Ansgar
On Mon, 2018-12-03 at 12:38 +, Ian Jackson wrote:
> Ansgar Burchardt writes ("Bug#914897: debating the wrong thing"):
> > It is very demotivating to have discussed and implemented something
> > mostly years ago, for people then to come and complain "let's not
ime on the remaining things I wanted to
look at, so at least not more time is wasted. (Not that I currently
have too much time for Debian anyway, and secure boot is quite a lot of
work for something I don't need...)
Ansgar
n symlink would then be required.
Ansgar
t; And where will the binaries and up on an un-usrmerged system with a
> dedicated /usr? in /usr, I hope?
They won't move on a system that doesn't have merged-/usr. /bin/bash
will stay in /bin/bash. If you switch to a merged-/usr (for example by
installing usrmerge) then they will be moved to /usr.
Ansgar
hat there are no /bin -> /usr/bin symlink in the staging area where the
package is built (i.e. debian/${package} or debian/tmp).
Packages have to continue shipping binaries in /bin unless we decide to
make merged-/usr mandatory and convert existing systems.
Ansgar
Ansgar Burchardt writes:
> There were discussions about enabling this by default years ago, I
> don't think minor issues should be a reason to delay this change.
>
> Note that it has been delayed for after the stretch release as there
> were major issues back then (it was ena
someone to find a problem this time
which is pretty good for any change.
Ansgar
Simon McVittie writes:
> On Thu, 29 Nov 2018 at 18:34:42 +0100, Ansgar Burchardt wrote:
>> Regardless of debootstrap defaults or flag days, we could also consider
>> moving programs from /{s,}bin to /usr/{s,}bin with a compat symlink in
>> /{s,}bin
>
> I'm not co
o make supporting
merged-/usr and non-merged-/usr simpler as the programs would always be
available in both locations.
Some packages such as iptables have already done this ad-hoc.
I'm toying around with ideas for a dh_usrmove tool which would allow to
easily add this to existing packages. That would also allow to drop it
later in one go should one in the far future require the /bin ->
/usr/bin symlink.
Ansgar
s prior.
(Well, on the plus side the package was just hijacked because rules
don't apply to some people... That's a step forward.)
Ansgar
[1] https://bugs.debian.org/683839#77
[2] https://bugs.debian.org/877024
which I
would guess more people use than ham radio. (Some of these USB dongles
also emulate network cards and provide a DHCP server instead IIRC.)
Ansgar
/true --version'
gpg (GnuPG) 2.1.17
[...]
Ansgar
On Fri, 2016-08-26 at 12:38 -0400, Sam Hartman wrote:
> "Ansgar" == Ansgar Burchardt <ans...@debian.org> writes:
>
> Ansgar> On Fri, 26 Aug 2016 08:50:13 -0400 Sam Hartman wrote:
> >> I think we want to reaffirm that policy section 9.
that, Policy currently requires *all* packages to ship
sysvinit scripts that integrate with any alternative init system which
I am fairly sure also isn't current policy...)
Ansgar
age from
the files upstream considers source? If it is more than "cat", some
more information would be helpful.
Ansgar
retain their init system
– which goes along with “upgrades should not change the sy‐
sytem state” generall – as much as possible.
No, the ctte did not say that. We had a flamewar about that
interpretation before.
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
).
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761e3nioo@deep-thought.43-1.org
Hi,
Adam Borowski kilob...@angband.pl writes:
As Ansgar requests technical solutions, here's one:
just like systemd-shim|systemd-sysv, switch the init package from
Pre-Depends: systemd-sysv | sysvinit-core | upstart
to
Pre-Depends: sysvinit-core | systemd-sysv | upstart
From a simple
prefer if
we did not end in perpetual further discussion until the freeze is over.
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87vbmas2w0@deep-thought.43-1
waiting longer...
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546c9240.8010...@debian.org
' systems by publishing
packages with dependencies which result in their preferred setup.
What gives you the impression that different maintainers fight over
providing init? I have not seen that happening.
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject
on that principle. So using it as a
reason for other changes is not a very convincing argument.
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjdwj63q@marvin.43-1
not to accept your patches
Is that right ?
I don't think that is a valid option[2]. However, the ctte can of course
offer advice.
[2] https://lists.debian.org/debian-devel/2014/06/msg00597.html
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject
this issue be closed? The last upload restored support for upstart[1].
[1] http://packages.qa.debian.org/t/tftp-hpa/news/20140504T133456Z.html
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
maintainers aren't really interested in menus, but people
implementing menu systems are and have to know all the details.
Ansgar
[1] This might include maintainers having to convert icons at package
build time and so on.
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
) is IMO clearly preferable.
Don't you mean drop GNOME, KDE and others? It's not only GNOME that
plans to depend on logind... And it sounds like a really brillant idea
to drop all of them to keep ChaosEsque Team happy with Debian.
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ
Hi,
Ian Jackson ijack...@chiark.greenend.org.uk writes:
Ansgar Burchardt writes (Bug#727708: init system coupling etc.):
Don't you mean drop GNOME, KDE and others? It's not only GNOME that
plans to depend on logind...
logind is a red herring because AIUI we already have a technical
solution
, pretty much regardless of the contents.
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9dy12bb@deep-thought.43-1.org
?
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f50dd7.3000...@debian.org
Steve Langasek vor...@debian.org writes:
On Fri, Feb 07, 2014 at 05:46:15PM +0100, Ansgar Burchardt wrote:
If you decide on the init system question first, you could just file a
bug against debian-policy and things could go their usual way.
Alternatively, the Policy maintainers could defer
that the preferences above FD will result in a tie
and the question will be decided by casting vote.
What would you think is the way forward in this case? A GR after all?
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
integration is currently in a state that would cause
terrible regressions for many server users.
I'm not sure of that (and would leave this to the systemd maintainers),
but it would probably take at least a few weeks of preparation in any
case.
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ
changes.
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52f36793.6050...@debian.org
this.
Would a gnome-session-systemd package that requires systemd violate
this (if gnome-session is also available)? If yes, what is the reason
for forbidding people from trying out new things?
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble
Adrian Bunk b...@stusta.de writes:
On Tue, Jan 28, 2014 at 12:18:09AM +0100, Ansgar Burchardt wrote:
...
== version multiple only ==
2. Debian intends to support multiple init systems, for the
foreseeable future, and so long as their respective communities
and code
be similar to the situation
with different kernels: when applications support all of them, fine, but
there may be programs that require a specific kernel.
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
Hi,
Adrian Bunk b...@stusta.de writes:
On Thu, Jan 16, 2014 at 09:39:37PM +0100, Ansgar Burchardt wrote:
...
Maintainers only should not drop support for a (default) init system
when the application supports it.
...
So if udev (maintained by systemd upstream as part of the systemd
sources
sort of
system one wants to end up with. And I'm not sure if the tech-ctte is
the right place to decide about the general direction the project wants
to take (tough I appreciate the discussion and arguments from all
sides).
Ansgar
[1] At least that's my guess what people argue about in the end
systemd in
Debian.
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9fhrl6c@deep-thought.43-1.org
matter and
break things if done wrong. Not having to worry about this as init
takes care of it removes one source of errors.
So I think having these features integrated into init rather than
wrapper commands is preferable.
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ
1 - 100 of 105 matches
Mail list logo
