On Tue, Aug 06, 2024 at 03:16:49PM +0100, Luca Boccassi wrote:
> On Tue, 6 Aug 2024 at 15:00, Wouter Verhelst wrote:
> > The question is:
> >
> > what is, exactly, the problem that the os-release specification is
> > supposed to solve? And how does
On Tue, Aug 06, 2024 at 10:11:05AM +0100, Luca Boccassi wrote:
> On Tue, 6 Aug 2024 at 09:03, Wouter Verhelst wrote:
> > On Sun, Aug 04, 2024 at 07:44:29PM +0100, Luca Boccassi wrote:
> > > That would make it contradictory with itself and everything else that
> > > us
On Sun, Aug 04, 2024 at 07:44:29PM +0100, Luca Boccassi wrote:
> On Sun, 4 Aug 2024 at 19:08, Wouter Verhelst wrote:
> >
> > On Sat, Aug 03, 2024 at 04:15:36PM +0100, Luca Boccassi wrote:
> > > On Fri, 2 Aug 2024 at 21:29, Helmut Grohne wrote:
> > > > >
On Sat, Aug 03, 2024 at 04:15:36PM +0100, Luca Boccassi wrote:
> On Fri, 2 Aug 2024 at 21:29, Helmut Grohne wrote:
> > > 2) Testing and unstable can continue to remain indistinguishable, and
> > > both be erroneously identified as trixie
> >
> > Isn't there the third option of adhering to the os-r
On Sun, Aug 04, 2024 at 01:00:38PM +0200, Paul Gevers wrote:
> Hi Wouter,
>
> On Sat, 3 Aug 2024 20:07:14 +0200 Wouter Verhelst wrote:
> > In the nbd autopkgtest, I need to do a debootstrap of "whatever we are
> > currently running". That code starts off with &
On Fri, Aug 02, 2024 at 11:35:54AM +0100, Luca Boccassi wrote:
> Testing and unstable have completely separate and independent
> archives, you can point an image builder to one OR the other, in
> isolation, and it will produce a fully complete and runnable and
> bootable OS tree. The fact that they
On Wed, Jan 03, 2024 at 04:43:45PM +0100, Helmut Grohne wrote:
> On Thu, Dec 21, 2023 at 10:41:57AM +0100, Helmut Grohne wrote:
> > We can restore lost files in a postinst. For this to work, we must
> > duplicate (e.g. hard link) affected files in the data.tar.
> > Example: #1057220 (systemd-sysv u
On Fri, Apr 08, 2022 at 12:07:25PM -0700, Sean Whitton wrote:
> Hello Wouter,
>
> On Fri 08 Apr 2022 at 09:36AM +02, Wouter Verhelst wrote:
>
> > Given that, in case the dpkg maintainer chooses to remain silent
> > again, I believe the only way forward is for the TC to
On Fri, Apr 08, 2022 at 02:31:27PM +0100, Wookey wrote:
> On 2022-04-08 09:36 +0200, Wouter Verhelst wrote:
> >
> > The dpkg maintainer has chosen not to engage with the TC in #994388, and
> > now seems to be actively subverting a validly-made TC decision.
> >
> &
On Fri, Apr 08, 2022 at 03:41:25AM -0700, Felix Lechner wrote:
> Hi,
>
> On Fri, Apr 8, 2022 at 1:48 AM Wouter Verhelst wrote:
> >
> > The nuclear option here is obviously to take maintenance of dpkg away
> > from the dpkg maintainer unless and until he decides to foll
On Fri, Apr 08, 2022 at 01:28:16PM +0500, Andrey Rahmatullin wrote:
> On Fri, Apr 08, 2022 at 09:36:21AM +0200, Wouter Verhelst wrote:
> > FWIW, I think the TC should punt this bug to a GR.
> >
> > The dpkg maintainer has chosen not to engage with the TC in #994388, an
Hi,
On Tue, Mar 15, 2022 at 03:14:36PM -0700, Josh Triplett wrote:
> It would appear that the situation has deteriorated further. dpkg 1.21.2
> now issues a warning on all merged-usr systems:
>
> Setting up dpkg (1.21.2) ...
> dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
On Fri, Dec 03, 2021 at 04:08:24PM -0500, Nicholas D Steeves wrote:
> Control: severity -1 serious
> Control: tags = confirmed
>
> CCing the release team, and CTTE because I don't know who else is
> tracking issues related to the usrmerge effort. I've consciously chosen
> not to pour gasoline on
On Tue, Jan 26, 2021 at 12:28:45AM +0100, Marco d'Itri wrote:
> Also, as is has been discussed, if the /usr/doc/ transition was
> representative then this would probably take many years.
You keep using that as an argument. I think it's very disinginuous to
point to a problem Debian had over 20 ye
On Mon, Jan 11, 2021 at 09:07:03PM +, Matthew Vernon wrote:
> [0] to that end, orphan-sysvinit-scripts is in NEW,
Glad you're taking that route. I had been thinking of other things to
suggest that would make your life easier while allowing maintainers to
drop init scripts if they so desire, bu
Hi Sam,
On Sun, Dec 27, 2020 at 10:05:37AM -0500, Sam Hartman wrote:
> >>>>> "Wouter" == Wouter Verhelst writes:
> Wouter> On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
> >> I think that we should either decide that
> >>
> &g
On Wed, Dec 16, 2020 at 10:28:55AM -0500, Sam Hartman wrote:
> I think that we should either decide that
>
> 1) NetworkManager should support elogind
>
> or
>
> 2) That we haven't seen enough development of alternatives to systemd
> and the project consensus on the GR has changed.
Personally, I
On Thu, Nov 19, 2020 at 09:04:07AM +, Matthew Vernon wrote:
> [I don't need a CC, thanks]
> Hi,
>
> > I know it was mentioned back in the day, but trying to re-ask it now:
> > Wouldn't it be possible to ship init scripts for compatibility purposes
> > from a sysvinit (or maybe a sysvinit-suppo
On Wed, Oct 07, 2020 at 09:53:06PM +0200, Michael Biebl wrote:
> Forwarding this to the CTTE, just in case they have some input on this
> proposed plan.
>
>
> Weitergeleitete Nachricht
> Betreff: Re: Bug#946456: systemd: Provide systemd-sysusers as an
> independent package
> Dat
On Fri, Sep 06, 2019 at 11:32:06AM +0200, Bill Allombert wrote:
> On Thu, Sep 05, 2019 at 09:17:59AM +0200, Didier 'OdyX' Raboud wrote:
> > Le mercredi, 4 septembre 2019, 23.53:06 h CEST Bill Allombert a écrit :
> > > On Wed, Sep 04, 2019 at 11:04:57PM
On Thu, Sep 05, 2019 at 09:17:59AM +0200, Didier 'OdyX' Raboud wrote:
> I have come to wonder if these two functions shouldn't be separated, in
> different bodies (eventually with different nomination rules, etc.). This
> "steering" question had also been phrased, slightly differently, by Mehdi,
On Fri, Jul 26, 2019 at 06:45:35PM +0200, Guillem Jover wrote:
> * This is a body composed of members that come and go, these might have
> wide experience in Debian in general (although not necessarily) or
> might had expertise in specific fields. The problem is that this body
> gets
On Sun, Dec 02, 2018 at 11:31:13PM +0100, Marco d'Itri wrote:
> On Dec 02, Wouter Verhelst wrote:
>
> > One thing that has not been answered yet in this discussion (and if the
> > TC is to make a decision about it, I think it should be) is "why are we
> >
On Wed, Nov 28, 2018 at 01:49:45PM +, Ian Jackson wrote:
> Control: reassign -1 tech-ctte
>
> Dear Technical Committee. I don't know if you are all aware of the
> discussion surrounding this, so I will recap:
>
> Recently debootstrap was changed to do merged-/usr by default, so that
> /bin -
Hi,
On Wed, Oct 17, 2018 at 09:47:57PM +0100, Simon McVittie wrote:
> However, it leaves the default as "fail hard", which I'm not convinced
> is the most appropriate thing for systems that lack an experienced
> sysadmin (which are the systems where defaults matter most, because an
> inexperienced
I must stop writing emails when tired...
On Tue, Oct 09, 2018 at 08:35:33PM +0200, Wouter Verhelst wrote:
> On Tue, Oct 09, 2018 at 10:52:15AM +0200, Wouter Verhelst wrote:
> > - The policy-rc.d interface could be extended to allow it to signal a
> > "restart, but do not fa
On Tue, Oct 09, 2018 at 10:52:15AM +0200, Wouter Verhelst wrote:
> - The policy-rc.d interface could be extended to allow it to signal a
> "restart, but do not fail on error" kind of policy. This would work
> for the "we have thousands of desktops and don't care a
On Tue, Oct 09, 2018 at 10:14:44AM -0400, Sam Hartman wrote:
> >>>>> "Wouter" == Wouter Verhelst writes:
>
> Wouter> On Fri, Oct 05, 2018 at 08:40:03AM -0400, Sam Hartman wrote:
> >> That said, even there there are tradeoffs. As an example,
Hi Simon,
Thanks for your summary.
On Sun, Oct 07, 2018 at 11:49:09AM +0100, Simon McVittie wrote:
> Attempting to summarize what was said on this topic in the thread so
> far, and at the last technical committee meeting:
>
> It's perhaps important to note that we are not discussing ideal situat
On Fri, Oct 05, 2018 at 08:40:03AM -0400, Sam Hartman wrote:
> That said, even there there are tradeoffs.
> As an example, Ubuntu tries to use unmodified Debian source packages
> where possible. In some cases I think that the maintenance advantages
> of doing this and the slight but real political
On Sat, Sep 22, 2018 at 09:50:11AM +0200, Wouter Verhelst wrote:
> Nobody is arguing that if the init system or policy-rc.d block service
> starts, that then postinst should silently not start the daemon.
That should read:
Nobody is arguing that if the init system or policy-rc.d block s
Hi Tollef,
On Fri, Sep 21, 2018 at 09:53:13PM +0200, Tollef Fog Heen wrote:
> ]] Wouter Verhelst
>
> > On Tue, Sep 18, 2018 at 10:04:26PM +0200, Tollef Fog Heen wrote:
>
> [...]
>
> > > The API provided by a package being in the configured state is not
> &
On Fri, Sep 21, 2018 at 10:07:31PM +0200, Tollef Fog Heen wrote:
> ]] Ian Jackson
>
> > Tollef Fog Heen writes ("Bug#904558: What should happen when maintscripts
> > fail to restart a service"):
>
> [...]
>
> > > This means that failure to start a daemon should generally not cause the
> > > p
On Tue, Sep 18, 2018 at 10:04:26PM +0200, Tollef Fog Heen wrote:
> ]] Ian Jackson
>
> Hi,
>
> > There may be good reasons not to treat daemon startup failure as a
> > postinst failure, but the argument above is not one of them.
>
> I think this is the core question. I largely agree with Ian he
On Sat, Sep 15, 2018 at 04:14:57PM -0300, David Bremner wrote:
> Tollef Fog Heen writes:
>
> >
> > The Committee recognises that there is a need for packages to behave
> > differently when built on different distributions, but this should be
> > done as part of the build process, using current an
On Mon, Aug 20, 2018 at 04:51:30PM +0300, Adrian Bunk wrote:
> On Mon, Aug 20, 2018 at 09:28:30AM +0200, Wouter Verhelst wrote:
> > On Mon, Aug 20, 2018 at 12:15:00AM +0300, Adrian Bunk wrote:
> > > How should we handle architecture-specific patches properly inside
> >
On Mon, Aug 20, 2018 at 12:15:00AM +0300, Adrian Bunk wrote:
> How should we handle architecture-specific patches properly inside
> Debian?
Why should there ever be architecture-specific patches?
I get that there sometimes need to be vendor-specific patches, because
defaults may differ between d
On Thu, Aug 02, 2018 at 09:46:28AM +0100, Simon McVittie wrote:
> mate-terminal and tilix, both terminals, have been adapted to Ubuntu
> having patched vte to stay with pcre instead of moving to pcre2.
> mate-terminal could easily use cpp; tilix is written in D, and I don't
> know whether that has
On Wed, May 16, 2018 at 08:59:35PM +0200, Margarita Manterola wrote:
> As David mentioned in IRC and I mentioned in person to the people in
> Hamburg, it is a bit worrying to not have anything to discuss,
Why is it worrying?
The TC not having things to discuss means everyone in Debian is getting
Hi Didier,
Thanks for caring.
On Fri, Feb 09, 2018 at 12:36:07PM +0100, Didier 'OdyX' Raboud wrote:
> Le jeudi, 30 novembre 2017, 14.03:15 h CET Wouter Verhelst a écrit :
> > Having said that though, I'm also not convinced that the current
> > completely priva
On Fri, Dec 01, 2017 at 11:25:01AM +0100, Didier 'OdyX' Raboud wrote:
> Le jeudi, 30 novembre 2017, 14.03:15 h CET Wouter Verhelst a écrit :
> > On Tue, Nov 28, 2017 at 10:48:25AM -0800, Don Armstrong wrote:
> > > My rationale is that the private "vote" isn&#
On Tue, Nov 28, 2017 at 10:48:25AM -0800, Don Armstrong wrote:
> On Tue, 28 Nov 2017, Wouter Verhelst wrote:
> > On Tue, Nov 28, 2017 at 09:40:45AM +0100, Didier 'OdyX' Raboud wrote:
> > > Question:
> > >
> > > - Does this private vote respect l
On Tue, Nov 28, 2017 at 09:40:45AM +0100, Didier 'OdyX' Raboud wrote:
> Question:
>
> - Does this private vote respect letter and/or intent of §6.3.4 "votes on
> appointments must be public"?
No. However, I think it is wrong for anyone to insist on that, and I
think the constitution should be u
On Wed, Oct 18, 2017 at 09:18:37PM +0200, Aleksander Morgado wrote:
> On Tue, Oct 17, 2017 at 6:48 PM, Ian Jackson
> > I will do that upload: to DELAYED, picking some suitably cautious
> > version number, unless I hear to the contrary. (And I'll wait at
> > least a week for a reply to this questio
On Wed, Sep 27, 2017 at 02:13:50PM -0700, Keith Packard wrote:
> Ian Jackson writes:
>
> (speaking as a Debian user, not as a TC member)
>
> > I'm afraid don't really want to do the work of writing a better UI.
> > But I have provided a simple patch which at least makes the behaviour
> > safe.
>
On Sat, Dec 10, 2016 at 12:06:44PM +0100, Philip Hands wrote:
> How about one or both of:
>
> bare-bones -- nothing selected
> minimal-server -- ssh and nothing else
>
> Is there any objective way of working out what other combinations would
> be popular, rather than just guessing?
Note
On Wed, Dec 07, 2016 at 08:59:53AM +0100, Ole Streicher wrote:
> But it also gives a wrong sign: Debian Pure Blends are by definition
> integral part of Debian itself. But even now, this is hard to understand
> for many people -- questions like "what is the difference between Debian
> Astro and Deb
Hi Sam,
[side note: while I joined the original discussion, I don't really have
a stake in the outcome, other than the desire to have a working menu]
On Tue, Jul 21, 2015 at 09:06:08AM +, Sam Hartman wrote:
> Should Bill have recused?
> Your current process does not describe when policy edito
On Mon, 22 Dec 2014 14:29:44 + Ian Jackson
wrote:
> The traditional Debian menu system (mostly done by Bill Alombert) has
> been providing menu entries for bc and dc and everything for years.
> That is what its users expect. It is what users like Matthew Vernon
> want:
> https://bugs.debia
Op 31-10-13 02:50, Theodore Ts'o schreef:
> On Wed, Oct 30, 2013 at 06:18:29PM -0700, Russ Allbery wrote:
>> I suspect you and I have a root disagreement over the utility of exposing
>> some of those degrees of freedom to every init script author, but if you
>> have some more specific examples of p
Op 30-10-13 00:16, Russ Allbery schreef:
> Carlos Alberto Lopez Perez writes:
>> On 28/10/13 20:14, Christoph Anton Mitterer wrote:
>
>>> For those who haven't seen it, Lennart has posted some of his comments
>>> about all this on G+:
>>> https://plus.google.com/u/0/115547683951727699051/posts/8R
Op 29-10-13 09:26, Steve Langasek schreef:
> I see no reason that, if upstart were chosen as the default, porters could
> not use it for our non-Linux ports as well.
With some work, sure.
> This is a much better outcome
> across our distribution as a whole than to require developers to continue
>
On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
> Right. Whichever init system we pick, I do expect the next step to be to
> drop the requirement to maintain sysvinit backwards-compatibility;
While I'm not sure from your mail whether you meant to suggest otherwise, I do
think that
53 matches
Mail list logo
