ns would have applied the years
before November as well, and certainly since the default was switched
again in June last year.
Ansgar
very distinct 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
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 issue
fer to binaries 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
to the same location anyway, no compat
symlinks or maintainer script logic required.
Ansgar
rozen can be avoided even when the TC
sets it; I even agree that it should be avoided.
Ansgar
ght have to 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
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
>
uld just 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
g to know which ones you are talking about. Would
maintainers have to accept patches stopping use of systemd-tmpfiles,
systemd-hostnamed, ...?
Ansgar
h 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 Decem
ory
are still built 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
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
d/or `tempfile` to be
considered essential.)
Ansgar
[1]: https://bugs.debian.org/851747
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
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
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 #-devel t
month-long discussion even about just the current 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
nd it was the 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
to 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
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:
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
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 understan
forward to seeing discussion on this or a summary of previous
private discussion results.
Ansgar
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
Thanks,
Ansgar
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 atomic update
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 pac
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-
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
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 deriv
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].
>
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].
>
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
> > p
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 solutions?
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 missi
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 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 possible.
>
s might result in non-booting systems.
That is what we sign up to accept by having the warning in dpkg.
Ansgar
eb.debian.org
and so on, I think the Debian project *is* the upstream for dpkg.
Ansgar
ppointed how the ctte appears to do as much as they can
to avoid deciding on this :-(
Ansgar
added a small warning to the
FAQ: https://wiki.debian.org/Teams/Dpkg/FAQ?action=diff&rev1=78&rev2=79
Ansgar
y go ahead as planned, i.e., social costs are not considered,
but should be (IMHO).
Ansgar
e in /bin) 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
ns, we can talk about init system
support in Debian and costs/benefits of supporting some of them. :-)
Ansgar
n before 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
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
actice it seems to work fine, 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
gt; I think it's worth pointing 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
y thoughts about this?
Ansgar
[1]: With some exceptions such as some programs have compat symlinks
in the legacy layout or between .../bin and .../sbin.
t on a
production system)? It might be interesting to experiment with the new
layout.
Ansgar
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
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
> &
e best time to try. I also spotted a bug when uploads
would go to t-p-u instead of wheezy in the .changes (which should be
fixed now)...
As Adam already pointed out we would still need another d-i upload to
unstable to make sure unstable has a higher-or-equal version compared to
testi
be annoying.
There are many packages that require this. A random example: mediawiki
depends on php5-mysql | php5-pgsql | php5-sqlite | php5-mysqlnd. Which
one is right depends on the configuration.
Having mediawiki-mysql, mediawiki-pgsql, mediawiki-sqlite, ... instead
would not scale well. It get
ng a package in non-main (with no
alternative in main) is already a policy violation. It's covered in the
same sentence as depending on a non-main package (2.2.1).
What do you want to be changed here?
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subjec
having a more concrete roadmap than "we might just stay at logind 204
forever" from the UpstarT proponents seems very important to me.
[1] <https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf>
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/87mwlndobg@eisei.43-1.org
grades between major releases of their
> enterprise distribution.
Except they do: "Red Hat Enterprise Linux 7 will offer an in-place
upgrade feature for common server deployment types, allowing data
centers to migrate existing Red Hat Enterprise Linux 6.5 systems to Red
Hat Enterprise
file.
* The order of invocations of the wrapper commands might 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
h they
suggested before... This would also allow having a newer 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
d need to
invest resources into to maintain an upstart replacement.
[1] <https://lists.debian.org/debian-ctte/2014/01/msg00017.html>
Ansgar
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debi
re is no technical
"right" or "wrong" between a more integrated, featureful system or a
more minimalistic approach[1]. It depends on expectations what 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 di
ould 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
Hi,
Adrian Bunk 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
init system to be pid 1.
It's unclear if reduced functionality (or in the extreme case no
functionality) would satisfy 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
Adrian Bunk 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 l
n bugs before the freeze if the
init system 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
gt; people who care about various init systems to step up and implement it.
What does this mean in the concrete example that lead to the ctte bug?
That is:
Provided logind is only provided by systemd (the current situation). May
GNOME depend on logind?
If not, do you plan to override the
ripe for a
> TC decision (if not wildly overdue).
Can the Secretary decide that the second part of 6.1.1 is to be ignored?
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 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 coul
e 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 "unsubscr
#x27;ve seen
> suggests that systemd 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
s.
>
> Voting in favour (i.e. Resolution, FD).
I think it is a very bad idea to vote on a resolution proposed in
anger, 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
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 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 w
application 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.d
his 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 li
g decisions:
>
> - ftpmaster's decision against using a non-packaged python-apt
> - DSA's decision only to use stable or stable-backports
> - SRM's decision not to accept your patches
> - backports's decision not to accept your patches
>
> Is that right
ot settled 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.org
ver init on users' 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.
from 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
ption? I would 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.org
Hi,
[ Replying to the bug. ]
On 11/20/2014 06:27 PM, Don Armstrong wrote:
> On Thu, 20 Nov 2014, Ansgar Burchardt wrote:
>> Don Armstrong writes:
>>> Speaking personally, without specific patches which have been discussed
>>> with the maintainers of the init p
Hi,
Adam Borowski 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 |
Hi Svante,
Svante Signell writes:
> Has the proposed (pre-)depends ordering on init been tested and the
> results known?
You might want to read https://bugs.debian.org/762194#142, but the
obligation for tests is really on the side of the people who want this
change (IMO).
Ansgar
; that existing installations should 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 UNS
On 11/28/2014 03:24 PM, Thorsten Glaser wrote:
> On Fri, 28 Nov 2014, Ansgar Burchardt wrote:
>> No, the ctte did not say that. We had a flamewar about that
>> interpretation before.
>
> That was almost word by word from
> https://lists.debian.org/debian-devel-announce/20
t; to build the package from
the files upstream considers source? If it is more than "cat", some
more information would be helpful.
Ansgar
.
(Related to 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
On Fri, 2016-08-26 at 12:38 -0400, Sam Hartman wrote:
> "Ansgar" == Ansgar Burchardt writes:
>
> Ansgar> On Fri, 26 Aug 2016 08:50:13 -0400 Sam Hartman wrote:
> >> I think we want to reaffirm that policy section 9.3.2 and
> section
> Ansgar>
/bin/true;
/usr/bin/true --version'
gpg (GnuPG) 2.1.17
[...]
Ansgar
ss more people use than ham radio. (Some of these USB dongles
also emulate network cards and provide a DHCP server instead IIRC.)
Ansgar
de 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
m Debian), and b) it would also 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
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 c
t;5 months for someone to find a problem this time
which is pretty good for any change.
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 enab
m. Note
that 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
> 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
k would then be required.
Ansgar
1 - 100 of 115 matches
Mail list logo
