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
t on a
production system)? It might be interesting to experiment with the new
layout.
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.
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
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
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
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
ns, we can talk about init system
support in Debian and costs/benefits of supporting some of them. :-)
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
y go ahead as planned, i.e., social costs are not considered,
but should be (IMHO).
Ansgar
added a small warning to the
FAQ: https://wiki.debian.org/Teams/Dpkg/FAQ?action=diff&rev1=78&rev2=79
Ansgar
ppointed how the ctte appears to do as much as they can
to avoid deciding on this :-(
Ansgar
eb.debian.org
and so on, I think the Debian project *is* the upstream for dpkg.
Ansgar
s might result 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 possible.
>
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 missi
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 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
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 deriv
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 merged-
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
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
Thanks,
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
forward 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 understan
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:
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
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
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
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
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
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
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
g to know which ones you are talking about. Would
maintainers have to accept patches stopping use of systemd-tmpfiles,
systemd-hostnamed, ...?
Ansgar
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
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
>
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
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
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
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
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
ns would have applied the years
before November as well, and certainly since the default was switched
again in June last year.
Ansgar
is: there are only 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
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-cl
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 unusrmerge
"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 f
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-suppo
h 3b you need some way to make sure existing 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'
delays me spending time 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
k would then be required.
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
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
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
t;5 months for 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 c
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
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
ss more people use than ham radio. (Some of these USB dongles
also emulate network cards and provide a DHCP server instead IIRC.)
Ansgar
/bin/true;
/usr/bin/true --version'
gpg (GnuPG) 2.1.17
[...]
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>
.
(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
t; to build the package from
the files upstream considers source? If it is more than "cat", some
more information would be helpful.
Ansgar
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
; 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
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
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,
[ 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
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
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
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.
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
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
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
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
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
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
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
#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
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
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
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
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
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
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
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
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
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
1 - 100 of 109 matches
Mail list logo
