to drive the future course of Debian... nor
something we should beat the GNOME Team up about before it's actually
happened.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu
On Tue, Dec 31, 2013 at 07:08:34PM -0800, Steve Langasek wrote:
> On Tue, Dec 31, 2013 at 11:15:33AM -0800, Russ Allbery wrote:
> > Similarly, I'm not sure why the focus on only adding necessary tools to
> > the initramfs image. Surely this doesn't matter much if the to
licable it is; but there are many x86
platforms where the bootloader doesn't have particularly impressive I/O
performance, and having to load a large initramfs before booting the kernel
has a major impact on boot speed.
--
Steve Langasek Give me a lever long enough a
ision.
I think the current Debian GNOME team has a not-undeserved reputation for
being obstructionist with respect to bugfixes that require divergence from
upstream's stated direction. If the team demonstrated they were open to
contributions of the kind you described, volunteers to do the work w
changes to the position
statement.
Cameron, as per the first paragraph, please do not change the page directly,
but discuss any proposed changes with me first.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and
On Tue, Dec 31, 2013 at 01:16:32AM -0800, Josh Triplett wrote:
> Steve Langasek wrote:
> > Looking more closely, I find that one of the conflicting files is a conffile
> > (/etc/dbus-1/system.d/org.freedesktop.systemd1.conf). diversions and
> > conffiles still don't mi
's not useful for the
> sysvinit support either, and it seems better to just drop it in all
> supported init systems rather than have it be inconsistent. Either way,
> you'd need a NEWS entry, etc., so that seems cleaner to me.
Agreed.
--
Steve Langasek Give
md in
> Debian.
upstart requires no part of systemd (unless you count udev as "systemd"
now). It's only the desktop environments which have dependencies on these
dbus interfaces.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Mon, Dec 30, 2013 at 09:52:37PM +0100, Tollef Fog Heen wrote:
> ]] Ian Jackson
> > Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
> > > So I repeat here my request that the systemd maintainers make a suitable
> > > split of the systemd
will actually work
> even if your primary network is a wireless network managed by
> NetworkManager, and even if that network doesn't actually work until the
> user has logged in, assuming your service is not actually in the
> dependency path of the user logging in.
And what makes
On Mon, Dec 30, 2013 at 10:04:09PM -0800, Russ Allbery wrote:
> Oh, sorry, I forgot to respond to this part.
> Steve Langasek writes:
> > Of course if we were writing all our services according to best
> > practices, we wouldn't have to worry about this, as the servic
s would be
very difficult to express in systemd language, yet it's altogether vital for
providing a boot that is both reliably ordered, and recoverable in the event
of problems.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Mon, Dec 30, 2013 at 04:04:05PM -0800, Russ Allbery wrote:
> Steve Langasek writes:
> > From comments made by various GNOME upstream developers on this, I think
> > they are being suitably cautious about avoiding scope creep where the
> > systemd dependencies are concern
oject
making a decision and being able to all pull together in the same direction
to provide the best possible OS, we will continue to coast, squandering
efforts on preserving users' ability to make choices about things that no
user should ever be asked to care about.
--
Steve Langasek
have the good sense to not
reinvent the wheel unnecessarily. No one ever tried to reimplement logind
for Ubuntu, at all. Why should they, when logind is already a perfectly
usable implementation of logind?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian
On Mon, Dec 30, 2013 at 01:03:48PM -0800, Steve Langasek wrote:
> > This would be quite wrong; Replaces is not supposed to be used like
> > that (but you apparently know that).
> Yes. Raphaël rightly points out that dpkg-divert can be used for this; if
> necessary, that's
there being room for a simplified view of jobs that works from
a terminal.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
they can be consumed unmodified by
distributions, but in practice Debian is going to be on the hook for
debugging the very long tail of integration problems. It's hard to gauge
whether the energy saved by not bringing upstart up to feature parity
outweighs the energy spent on bringin
On Mon, Dec 30, 2013 at 06:29:10PM +, Ian Jackson wrote:
> Steve Langasek writes ("Bug#727708: systemd-shim uploaded to NEW"):
> > So I repeat here my request that the systemd maintainers make a suitable
> > split of the systemd binary package, so that systemd-shim
On Mon, Dec 30, 2013 at 05:35:49PM +, Ian Jackson wrote:
> Steve Langasek writes ("Re: Bug#727708: upstart user jobs"):
> > On Sat, Dec 14, 2013 at 12:31:57PM +, Ian Jackson wrote:
> > > I have some questions about these. Forgive me if I could just have
On Mon, Dec 30, 2013 at 04:51:55PM +, Ian Jackson wrote:
> Steve Langasek writes ("Bug#727708: systemd and upstart, a view from a daemon
> Debian maintainer"):
> > I also think that the extensive maintainer script changes required for any
> > upstart-using
er session support in the current releases of upstart (the only
implementation that's been used in production in Ubuntu) doesn't work this
way; and the manpage has been updated to match.
--
Steve Langasek Give me a lever long enough and a Free
nting us from merging /usr/
into / by default, is an example of such historical incompatibilities. But
any other cases where binaries have moved from one directory or another
without providing such compat symlinks would also qualify.
--
Steve Langasek Give me a lever long enough and a Fr
rum on this question while systemd was more ambitious. If
anything, the long time it's taken Debian to even seriously consider the
question of moving to upstart shows that by at least one relevant measure,
even upstart was being too aggressive. :/
--
Steve Langasek
f
basic.target, not of remote-fs-pre.target, which would enable use of
socket-based activation for fs helper daemons like those in nfs-common?
(Note, of course, that nfs-utils currently has no support for the systemd
socket activation protocol. However, if one of the arguments for sys
es have been giving upstart's
downstreams what they need.
> and/or are if there other features in upstart that you think will never
> deliver the benefits one would naively expect from them?
Socket-based activation has never been a feature that upstart upstream has
promoted the use of.
On Sun, Dec 29, 2013 at 11:21:07AM +0100, Josselin Mouette wrote:
> Le dimanche 29 décembre 2013 à 01:10 -0800, Steve Langasek a écrit :
> > If I'm not mistaken (no references to hand - sorry), systemd upstream has
> > claimed in the course of discussions on debian-devel tha
r script snippets disappear in favor of a
trigger, or rolled into the update-rc.d script which is already being
called.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
ted better). I guess you figured this out after having written
this mail?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
le for those who might prefer to start their
services without the need for writing socket-handling code; but in my
estimation, the flaws wrt system startup (which as far as I can see also
affect the systemd implementation) make it altogether unsuitable for any
services you're expecting to
just use socket-based activation which is better anyway". But I'm sure
there will be upstreams who don't want lazy initialization any more than
they want an external library dependency.
--
Steve Langasek Give me a lever long enough and a Free O
to be the lesser evil if the systemd maintainers continue to
insist on a monolithic binary package.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
tibility with sysvinit",
which I think is fine at this stage.
It's never premature to be a good citizen in Debian.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
aving.)
> Most of this complexity is because systemd's maintainers are also trying
> to fix the problem with daemon automatically starting after
> install. They would have used triggers otherwise.
What "problem" do you refer to here? Starting daemons automaticall
ream is a good thing.
But as Andi said, there's no real conceptual difference between the two
approaches, and I don't see anything here that weighs in favor of one
project over the other. Do you agree? If so, perhaps we should table this
particular thread; we can always discuss the f
lost when it does.
Right, those are all pretty much the reasons I would expect for preferring
rsyslog. As I said, I just think there's a trade-off between supporting
this and having confusing complexity exposed to the users.
On Fri, Dec 20, 2013 at 06:52:51PM +, Ian Jackson wrote:
> S
On Thu, Dec 19, 2013 at 11:26:19PM +0100, Josselin Mouette wrote:
> Le jeudi 19 décembre 2013 à 12:35 -0800, Steve Langasek a écrit :
> > The reasons for not upgrading to the current version of logind aren't to do
> > with any fragility of the existing glue code (the system
log (for
reasons of avoiding a dependency on on external daemon for debuggability).
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
d we haven't
really revisited because it hasn't been a maintenance burden.
- Various fixes to test cases that were failing in Debian builds. These
fixes have been pushed to trunk and will be included in the next upstream
release.
Aside: the full upstream delta is 441 lines. So
ode.
It seems to me that most of this code would have to be written to support
logind on non-Linux anyway, and is a much better choice than supporting
consolekit indefinitely for those ports.
--
Steve Langasek Give me a lever long enough and a Free OS
De
tely, so I didn't analyze them in much depth.)
Right, I also agree this kind of thing is best implemented directly in the
init system. I don't think it's the highest priority for implementing, but
it would have its uses and the init system is best placed to handle it.
--
Steve Langa
mething modern, and wants a say in what that replacement
will be, it should decide now.
And if Debian's not going to adopt upstart, then we should adopt systemd
immediately so that we have a say in its direction between now and jessie,
instead of waiting until after jessie and finding ourselves wit
tu.com/UpstartCompatibleInitScripts was drafted, I wasn't
aware that init-functions hooks were supported, so assumed that a central
implementation would carry a performance penalty for users who weren't
running upstart and thought that might be impolite.
--
Steve Langasek
erwise, I'm rescheduling our next
> meeting to:
> date -d 'Thu Dec 19 18:00:00 UTC 2013'
> I'll update the calendar and IRC channel shortly.
Heh. I assume this is moved up with only three days notice to increase the
chances that I will again miss finishing my a
t; 1. 19th same time
> 2. 26th same time
> 3. 27th same time
> 4. 28th same time
> 5. 29th same time
> 6. 30th same time
> 7. Some other time (I will do a doodle poll)
Any of these times look ok to me.
--
Steve Langasek Give me a lever long enough and a Free OS
nment. There haven't been any of
those.
> I don’t know whether Jef’s list is complete. It would be nice if someone
> had the time to dig into old upstart bugs to see which ones would have
> mandated a security label.
I think that would be a great waste of the t
yes.
> I offer to work on producing an easily mergable patch, should Bastian
> agree to that.
This was my concern with the technical implementation as well. I would be
happy with lvm2/systemd integration that used a static configuration instead
of requiring a generator.
--
Steve Langas
ants to be slightly more advanced than TWM is going to
> need it. Even Ubuntu is using logind and is iirc maintained there by
> Steve Langasek.
It's collectively maintained in Ubuntu; I do help with it, but Martin Pitt
does most of the routine maintenance for the systemd source pack
On Mon, Dec 02, 2013 at 11:24:41AM -0800, Russ Allbery wrote:
> Steve Langasek writes:
> > Note that the original complaint in the samba upstream discussion was
> > about hard-coding of paths to system utilities, which a) is not portable
> > between distributions and b) cont
Hi Russ,
On Fri, Nov 01, 2013 at 08:11:38PM -0700, Russ Allbery wrote:
> 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 upgradi
t in the samba upstream discussion was about
hard-coding of paths to system utilities, which a) is not portable between
distributions and b) contradicts Debian policy.
So systemd upstream may support separate /usr, but that doesn't change the
fact that there are still portability issues when
On Sat, Nov 30, 2013 at 04:07:17PM +0100, Moritz Mühlenhoff wrote:
> On Thu, Nov 28, 2013 at 08:07:16PM -0600, Steve Langasek wrote:
> > All distributions "care" about not having security issues in their code, but
> > that's not the same thing as actually doing t
tand by the overall security design of either
sysvinit or upstart, namely that the user-accessible interfaces are kept as
small as possible to make them as auditable as possible.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on
ing a solid design to reduce the attack surface,
as it does with the developers' skill.
> I am also sure that other init systems have (had) similar bugs. And if
> there is no evidence of that yet, maybe nobody looked really closely yet…?
> :)
Unless you're offering to do a security
members.
> Sorry about the delay.
> Here is the final resolution. I hereby call for a vote. There are
> three options: Packard, Kern and FD.
I vote: Kern, Packard, FD.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to s
r to the other camps' points ?
> I think this would still be a good idea.
At this point I'm satisfied with
<https://wiki.debian.org/Debate/initsystem/upstart>, at least as a starting
point for further discussion with the TC. I'm sure the systemd folks and I
could
imposing a new rule that each TC member can
only propose one ballot option, or that the ballot option they propose must
be their first choice.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on,
ddress this before
upgrading from systemd logind 204 and will hold at 204 until a correct
solution is known"?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
On Fri, Nov 01, 2013 at 06:49:34PM +, Ian Jackson wrote:
> Steve Langasek writes ("Bug#727708: Value of reading other's position
> statements [was: systemd vs. whatever]"):
> > I agree with all of the technical critiques here, I just don't see that this
>
On Fri, Nov 01, 2013 at 05:39:15PM +, Ian Jackson wrote:
> Steve Langasek writes ("Bug#727708: Value of reading other's position
> statements [was: systemd vs. whatever]"):
> > I agree. It would still require some fiddling to make 'expect stop' work
&
f you actually need
upstart to know non-racily when the service is started you would need the
process under trace to SIGSTOP its own parent. Not elegant, but possible.
Or if you don't need to worry about a non-racy startup for the service
you're testing, just omit the 'expect' s
On Thu, Oct 31, 2013 at 07:20:12AM -0400, Theodore Ts'o wrote:
> On Thu, Oct 31, 2013 at 01:41:53AM -0700, Steve Langasek wrote:
> > I'm surprised by this comment. Very little policy is actually encoded in
> > upstart's C code; in fact, the only policy I can think
Aside from adding links to manpages to all
of the upstart jobs themselves (which I don't think is reasonable), are
there things you think should be done to make the right documentation easy
to find? (For starters, what were you trying to find documentation of?)
--
Steve Langasek
apabilities
will be made available in a non-systemd environment, because a lot of this
has to do with decisions that need to be made in the relevant wider
technical communities and have nothing to do with the init system per se.
--
Steve Langasek Give me a lever long e
d be a
single process managing the cgroup heirarchy on behalf of userspace; the
existing libcgroup is a library that lets individual processes interface
with /sys/fs/cgroup, not an implementor of the userspace cgroup manager
service.
--
Steve Langasek Give me a lever long
; but while we should be aware that choosing a non-systemd
default does imply a certain amount of work, we shouldn't rathole on
deciding how to structure that work if we haven't even decided yet if that
work will be necessary.
--
Steve Langasek Give me
rt to their architecture.
> This would become radically easier if gnome were to become Architecture:
> linux-any.
GNOME may be the trigger for this being raised to the TC, but it's not the
core question that we need to address.
--
Steve Langasek Give me
On Mon, Oct 28, 2013 at 05:22:14PM +, Wouter Verhelst wrote:
> 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;
On Sat, Oct 26, 2013 at 10:46:38AM -0700, Russ Allbery wrote:
> Steve Langasek writes:
> > I don't think either of these are the right question. Even if we change
> > the default init system for jessie, because we *must* support backwards
> > compatibility with sysvi
m be for jessie? The rest are technical details that can be
straightforwardly worked out once we have a decision on the direction.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu D
It's not easy to
admit that we've bitten off more than we can chew, and even if it did get
brought to the TC, it seems that this bug can be resolved amicably,
consensually and with no need for a TC vote.
Arno, Laurent: are either or both of you willing to take over the package
gain; but adding oneself as a
comaintainer without *explicit* consent is a sleazy bypass of our normal
(QA, TC) processes for changing a package's maintainership.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and
On Fri, Feb 22, 2013 at 12:27:18PM -0800, Russ Allbery wrote:
> Steve Langasek writes:
> > I'm not sure how you've arrived at this conclusion. Have you overlooked
> > that the shlibs in the ntfs-3g package have been fixed by the maintainer
> > in unstable (as com
n the ntfs-3g package have been fixed by the maintainer in
unstable (as commented in bug #700677)?
It still doesn't comply with policy 8.1. But I think that's a policy bug
and that this bug report should be referred over to the policy package; I
don't see anything further here that
A to make package B uninstallable in testing?
> Exactly. Because making package B uninstallable is much more
> acceptable than making it unrunnable.
Neither is an acceptable way of handling Debian testing.
--
Steve Langasek Give me a lever long enough and a Free OS
Debia
On Mon, Feb 18, 2013 at 10:45:59AM -0800, Steve Langasek wrote:
> On Sun, Feb 17, 2013 at 01:57:46AM +, Dmitrijs Ledkovs wrote:
> > On 16/02/13 05:36, Daniel Baumann wrote:
> > > n 02/16/2013 03:40 AM, Colin Watson wrote:
> > >> have ntfs-3g Provides: l
ies in packages that link against it, is definitely buggy.
If you're happy with this patch I don't see any reason that the tech ctte
needs to be involved in any sort of formal ruling here, and the policy
language polishing question can be referred to debian-policy for discussion.
--
Steve
s are required,
> deployment should occur in a planned and cooperative way.
> Maintainers should be reluctant to upload changes which break
> other packages. If such breakage is necessary to move forward, it
> should only occur after obtaining rough consensus amongst the
&g
On Fri, Feb 08, 2013 at 07:37:36AM +, Adam D. Barratt wrote:
> On 08.02.2013 03:16, Steve Langasek wrote:
> >On Thu, Feb 07, 2013 at 04:26:49PM +, Ian Jackson wrote:
> >>How about this for a disposal:
> >I would vote for the below with reservation or modi
On Thu, Feb 07, 2013 at 04:26:49PM +, Ian Jackson wrote:
> How about this for a disposal:
I would vote for the below with reservation or modifications. Thanks for
drafting this, Ian.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Develo
intainer who is in a position to become a critical
blocker for the release is a good way to make sure releases don't happen.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
On Fri, Dec 14, 2012 at 01:35:49PM +0100, Philipp Kern wrote:
> On Fri, Dec 14, 2012 at 12:18:31AM -0800, Steve Langasek wrote:
> > (Furthermore, I think the whole idea of needing custom desktop
> > infrastructure to tell apps whether they're online or not is silly;
> > y
ork-manager
- the user has removed /etc/network/interfaces from the system instead of
leaving an empty or commented-out file
Even setting aside the fact that taking a name from one network device and
giving it to another is largely full of kernel/udev race lulz, I don't see
an
On Fri, Dec 14, 2012 at 09:50:37AM +0100, Tollef Fog Heen wrote:
> ]] Steve Langasek
> > - Installing the gnome or the NM package must not cause the network to
> >break on upgrade, even temporarily, under any circumstances.
> Is this a requirement for other network-pro
I vote BCFA.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com
onto users' systems on upgrade
is probably a suitable remedy for that. But I am not convinced that this is
*presently* the case and that an override of the maintainers is necessary
to force this particular remedy which, in any event, would be an imperfect
solution for the user-affecting bu
On Thu, Oct 04, 2012 at 02:05:53PM -0700, Don Armstrong wrote:
> I call for a vote on the following resolution to #573745.
I vote CBFA.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubu
y are something to be sorted out *after* establishing a maintenance
team with comaintainers, not before.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
ease team. Defer to them on automation.
> F. Further Discussion.
I vote BAF.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://ww
RC against evince.
> 6. The release team should clarify which mime types the RC-bugginess
> applies to. We recommend that the starting point should be those
> mime types advertised by evince via the mime system in squeeze.
Otherwise I have no objections here.
--
Steve La
tion.
> For clarity, the current proposal would be
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=35;filename=mime-support-desktop.patch;att=1;bug=497779
> , or something similar?
Yes. The nascent mime-support maintenance team has also committed a patch to
the repo at
<http://a
ary interface instead. But until we have such a tool
working in the release, it's the responsibility of the evince maintainers to
make sure their package complies with policy.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Deve
o all agree to use an obsolete experimental codec
which suffers from serious non-theoretical security issues.
So I'm really not sure why it's useful for the TC to be debating which of
the bad options we consider least bad.
--
Steve Langasek Give me a lever long enough
t 0.7.1 as a dependency; the mumble case is a very
particular issue related to the exact manner in which the server is
repeating the audio to all clients, and I don't see any reason to suspect
this would be an issue for the other packages that have dropped celt
support.
--
Ste
hould probably be fine, no?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com
reak?
And if it breaks, shouldn't we consider that a release critical bug in NM in
its own right, to be fixed for wheezy, regardless of whether NM is being
pulled in by default on upgrade?
--
Steve Langasek Give me a lever long enough and a Free OS
Deb
On Wed, Jul 18, 2012 at 01:18:27PM -0400, Michael Gilbert wrote:
> On Wed, Jul 18, 2012 at 12:24 PM, Kurt Roeckx wrote:
> > On Wed, Jul 18, 2012 at 10:31:15AM +0200, Stefano Zacchiroli wrote:
> >> > The current wording, read literally, means that if I happened to run into
on upgrade
in this way is problematic, and that additional care needs to be taken so
that users who opted out of using network-manager in squeeze can have their
choice preserved in wheezy.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
for
Debian to install as its default desktop. I believe that to date, the
installer team have delegated the decisions about what to include in the
default desktop over to the GNOME team. If we think that this metapackage
gives the wrong behavior for a default Debian desktop, we might replace it
with a d
merge 681783 681834
thanks
Hi Noel,
This appears to be the same as bug #681783. Merging the two reports.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
101 - 200 of 426 matches
Mail list logo
