Hi,
Hideki Yamane writes:
> On Sun, 2 Dec 2018 15:15:21 +
> Simon McVittie wrote:
>> > - What is the problem? (broken build for which packages? Just R?)
>>
>> The problem we're aware of is:
>>
>> Some packages auto-detect the absolute path to an executable (for example
>> bash or perl) an
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
Gunnar Wolf writes:
> Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]:
>> (...)
>> So, let's enumerate possible outcomes:
>>
>> 1. no usrmerge
>> 1a. no moves at all (no effort needed!)
>> 1b. moves via some dh_usrmove tool, until /bin is empty
>> 2. supporting both merged-usr and u
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'
Adam Borowski writes:
> I see that we're debating the merits of merged-usr vs non-merged-usr, while
> expending lots of effort and filing bugs (requiring further urgent action of
> unrelated maintainers), for little gain.
There is no "urgent action" required (unlike, say, for the last glibc
update
Marc Haber writes:
> The next debhelper change might choose to give / instead of /usr as a
> target directory by default, moving hundreds of megabytes from /usr to /
> over time. My question was about the distant future, and not the current
> snapshot of things.
If anything then /usr would be the
Marc Haber writes:
> On Sat, Dec 01, 2018 at 11:36:45PM +0100, Didier 'OdyX' Raboud wrote:
>> Le samedi, 1 décembre 2018, 19.29:59 h CET Marc Haber a écrit :
>> > Will binaries move from /usr/bin to /bin? Or will binaries move from
>> > /bin to /usr/bin?
>>
>> A merged-/usr has a /bin → /usr/bin s
Marc Haber writes:
> On Sat, Dec 01, 2018 at 07:20:57PM +0100, Didier 'OdyX' Raboud wrote:
>> * Currently, according to my `apt-file`, 259 binaries are shipped in /bin
>> directly, accross 85 packages. (for /sbin, 597 binaries for 190 packages).
>
> This might sound like a stupid question, what w
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
On Fri, 2018-11-30 at 19:40 +0100, Didier 'OdyX' Raboud wrote:
> Dear Hideki, dear src:debootstrap maintainers,
>
> tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by
> default now, or are you OK letting the TC decide on this subject?
There were discussions about enabling
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
Adam Borowski writes:
> Andreas Henriksson wrote:
>> On Wed, Nov 28, 2018 at 03:14:20PM +, Ian Jackson wrote:
>> > Julien Cristau writes ("Re: Bug#914897: debootstrap, buster:
>> > Please disabled merged /usr by default"):
>> [...]
>> > > I'd suggest that this should be fixed by not shipping an
Sam Hartman writes:
> Also, as may be obvious from my previous post today, I was shaken by
> some of the meta issues here. I am much more focused at the moment on
> thinking about the TC process and our community than I am about this issue.
If the ctte believes that escalating an issue to the ct
"Keith Packard" writes:
> 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.
>
> Would it be sufficient to simply stop ins
Philip Hands writes:
> I stumbled across 'proot' while looking into the background for this,
> which seems to be able to provide the effect of a bind mount without
> needing root privilege, and would presumably deal with Ian's original
> problem quite nicely.
If you enable unprivileged user namesp
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>
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
9.3.3
> represent current policy for init scripts, quoting particularly the
> following text from section 9.3.2:
>
> Packages that include daemons for system services shou
On Wed, 2016-07-13 at 10:43 -0500, Don Armstrong wrote:
> Or are you asking us to potentially overrule the ftpmasters inclusion
> of libjs-handlebars? Or potentially overrule the release managers
> determination of whether this particular bug is RC or not?
[...]
> I'd certainly be more comfortable
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
On 11/28/2014 03:16 PM, Thorsten Glaser wrote:
> On Fri, 28 Nov 2014, Marco d'Itri wrote:
>> I disagree: upgrades should get the default init system unless the
>> system administrator chooses otherwise.
>
> I disagree with you, and so does CTTE, this time: they said
> that existing installations
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
--
To UNSUBS
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 | upstart
>From a simple test this se
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,
Don Armstrong writes:
> Speaking personally, without specific patches which have been discussed
> with the maintainers of the init package and well tested, I'm unlikely
> to vote any resolution on this issue above FD.
Does this include the "no change is required" option? I would prefer if
we
Hi,
I would like to see an end to open questions on systemd in Jessie.
So, given that the GR is over and no technical proposals for not
switching init systems on upgrade to Jessie have been made, is it
possible to draw a conclusion to this issue now? I'm not sure there is
much to gain from waitin
Hi Ian,
On 10/21/2014 05:44 PM, Ian Jackson wrote:
> I think the principle, of whether this switch should be made
> automatic, ought to be addressed separately, and should be regarded as
> a question of overlapping jurisdictions. We can't have different
> maintainers fighting over init on users'
Ian Jackson writes:
> As I understand it from reading the threads in the bug and on
> debian-devel, the effect of this would be:
[...]
> * squeeze->jessie upgrades which are not already using systemd would
> not be switched silently to systemd but would use systemd-shim
> instead.
That's
On 08/19/2014 14:27, Ian Jackson wrote:
> Helmut Grohne :
>> I ask you to find a way that enables uploading packages that make use of
>> build profiles[1] to the experimental archive as soon as possible. The
>> need for build profiles is already known for years (#661538), but it was
>> hard to agre
Hi,
Ian Jackson writes:
> Can we stop the general commentary on Daniel Baumann's performance as
> maintainer ? I don't think it's helpful or relevant to the discussion
> about tftp-hpa and upstart.
Is there still anything left to discuss on tftp-hpa/upstart or could
this issue be closed? The la
Hi,
On 04/10/2014 13:48, Ian Jackson wrote:
> That comes directly from its goal
> of being easily consumable by a very wide range of window managers.
The number of consumers (window manager, menu applets, desktop
environments) is much smaller than the number of providers (in theory
every applicat
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
Ian Jackson writes:
> Firstly, I think the scenario where the required integration work is
> not done is unlikely. But in that scenario, we have two choices:
> (a) Effectively, drop all init systems other than systemd
> (b) Effectively, drop GNOME
>
> Of these, (b) is IMO clearly preferable.
D
Hi,
Andreas Barth writes:
>> I hereby call for votes on the following resolution:
>>
>>The init system decision is limited to selecting a default
>>initsystem for jessie. We expect that Debian will continue to
>>support multiple init systems for the foreseeable future; we
>>cont
Hi,
Steve Langasek writes:
> Quite frankly, given that all members of the TC have by this point weighed
> in with their preference on the "systemd vs. upstart" question and these
> preferences can be tallied by hand, I don't think there should be any doubt
> as to how the vote on that core questi
Hi,
Russ Allbery writes:
> Just to be very clear here, I do believe that we're deadlocked, even
> though I expect the resolution process to be able to spit out a decision.
> I don't mean deadlocked in the sense that Condorcet will fail, but rather
> deadlock in the sense that the preferences abov
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
On 02/07/2014 17:01, Ian Jackson wrote:
> Kurt Roeckx writes ("Bug#727708: Both T and L are wrong, plea for something
> simpler (was: Re: Call for votes on init system resolution)"):
>> I'm currently of the opinion that gnome made an initial decisions
>> and as reaction to that they are setting po
On 02/06/2014 11:50, Colin Watson wrote:
> I don't interpret L as meaning that everything must support "all" init
> systems, certainly not "alike" (indeed the text of that option is
> explicit that it isn't necessarily alike). Rather, I interpret it as
> saying that software-outside-init must be f
Hi,
On 02/06/2014 06:33, Russ Allbery wrote:
> Don Armstrong writes:
>> Would one more IRC meeting be useful to nail down the ballot options and
>> their drafts?
>
> I personally suspect that we have exhausted the capacity of the TC to deal
> with this problem, and that spending more time on it
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
Hi,
Ian Jackson writes:
> Ian Jackson writes ("Bug#727708: multiple init systems - formal resolution
> proposal"):
>> I hereby propose the following resolution:
>>
>>1. Support for sysvinit is mandatory in jessie.
>
> I hereby propose and accept an amendment to add a new rubric paragraph
>
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
Hi,
Ian Jackson writes:
> AFAICT we are all agreed that:
[...]
> * Applications which aren't part of the init system must not require a
> particular init to be pid 1. (So in particular a desktop
> environment may not require a particular pid 1.)
What about applications that are specifically
Colin Watson writes:
> On Tue, Dec 31, 2013 at 05:50:59PM -0800, Don Armstrong wrote:
>> On Wed, 01 Jan 2014, Tollef Fog Heen wrote:
>> > and I think it'd be a shame if we ended up losing or demotivating a
>> > good bunch of good developers again.
>>
>> Pretty much every time the CTTE makes a rul
Hi,
Colin Watson writes:
> Reservations with systemd
> -
[...]
> Basically, systemd would be more compelling to me if it tried to do
> less. I don't expect to persuade systemd advocates of this, as I think
> it amounts to different basic views of the world, but the basic
Ian Jackson writes:
> intrigeri writes ("Bug#727708: init system other points, and conclusion"):
>> The difference lies in who are the people who "need" to do this work
>> "anyway", and who else may instead dedicate their time to other tasks,
>> lead by their own desires and needs.
>
> I think tha
Ian Jackson writes:
> Russ Allbery writes ("Bug#727708: Quick upstart and systemd feature
> comparison"):
>> * Lots of really interesting defense-in-depth security features. I
>> particularly liked ReadWriteDirectories, ReadOnlyDirectories,
>> InaccessibleDirectories, PrivateNetwork, and NoN
Hi,
Adrian Bunk writes:
> On Wed, Dec 18, 2013 at 01:19:48PM +0100, Josselin Mouette wrote:
>> > And now you bring up the point that Debian should reconsider the
>> > lenght of it's release cycles if systemd upstream decides to not
>> > support upgrades between distribution releases as far apart
Hi,
Russ Allbery writes:
> Steve Langasek writes:
>
>> For the TC decision, what kind of information are you looking for about
>> the plans, beyond "the Ubuntu developers expect to need to address this
>> before upgrading from systemd logind 204 and will hold at 204 until a
>> correct solution i
On 06/29/2013 11:43, Andreas Barth wrote:
> However, for recommends there might be cases where this is not
> possible (because there are only non-main-packages), and this case is
> not considered RC right now. This is the more interessting point for
> me.
A package in main recommending a package i
On 04/17/2013 01:05, Thomas Goirand wrote:
> On 04/16/2013 03:58 AM, Joerg Jaspert wrote:
>> And we do consider a bit more here. Each and every package
>> takes extra space in the various metadata places, like Packages (times
>> number of architectures), our database, our various handling scripts o
On 02/07/2013 09:31, Raphael Hertzog wrote:
> Technically d-i point release updates are built in
> "stable-proposed-updates" and build dependencies are satisfied in stable
> (+ s-p-u maybe). Similarly it should be possible to build d-i for wheezy
> in testing-proposed-updates right now (and have bu
55 matches
Mail list logo
