with me as regards the question of requiring debian/rules to be a
makefile or not.
I do think that there are lots of other reasons we want to be able to rely
on makefile behavior from debian/rules on the developer side - introspection
for the build-arch transition being a good example of thi
it explicitly with the TC to require a makefile.
The handful of exceptions have definitely caused us far more trouble as a
project than any benefit you get as a maintainer from using a shell script
in place of a makefile.
--
Steve Langasek Give me a lever long enough and a Free
imental implementation as possible so that as
>many bugs as possible can be resolved prior to uploading it to
>unstable.
>
>This option requires a 3:1 majority.
>
> B. The Technical Committee declines to override the decision of the dpkg
>maintainer to hold the
ot a
position that is supported by historical practice. I'm fairly certain that
this is not what our DPLs expected when expanding the scope of delegated
roles within the project.
Perhaps Ian would like to chime in here wearing his "I wrote the
constitution" hat. :)
--
Steve Lan
e "teams", and the TC cares about the
principle of having a team, it doesn't seem to me that we're achieving much
by voting on these particular options.
Are there any members of the TC who are of the opinion that replacing
Matthias as python maintainer with a team of one is an appr
and try to /persuade/ them to
use a different name.
Clint Byrum has nudged me about this (wearing his Ubuntu Server hat rather
than his shiny new Debian Developer hat) and I've agreed to approach node.js
upstream about a possible upstream rename. I'll report back to
edora package could also be helpful to someone working
>on this.
Well, changing a filename should be trivial; should be no problem to feed
upstream a patch.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set
On Thu, May 03, 2012 at 07:58:59PM -0500, Jonathan Nieder wrote:
> Steve Langasek wrote:
> > On Thu, May 03, 2012 at 04:23:21PM -0500, Jonathan Nieder wrote:
> >> Best of luck. You know they've been asked twice before (once for Fedora,
> >> once for Debian),
hat's so complicated about all this. With a
clear note in README.Debian and NEWS.Debian, ham radio users will not
suffer.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
-
On Sat, May 05, 2012 at 10:50:21PM +0200, Carsten Hey wrote:
> * Steve Langasek [2012-05-04 09:49 -0700]:
> > On Fri, May 04, 2012 at 08:38:43AM -0700, Russ Allbery wrote:
> > > Raphael's approach of creating a compatibility symlink in postinst
> > > during upgrades
d an
> exception for a policy violation -- is that enough to kill the idea?
I think it's an acceptable compromise under the circumstances.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the wo
ebian is frozen tomorrow, then Nodejs will not be part of it, for
> the very reason that I *did* respect Policy.
It may not be part of the release, but it will still be a mess for everyone
involved.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Sun, May 06, 2012 at 09:49:11PM +0200, Jonas Smedegaard wrote:
> On 12-05-06 at 10:22am, Steve Langasek wrote:
> > On Sat, May 05, 2012 at 03:07:27AM +0200, Jonas Smedegaard wrote:
> > > We have until now maintained Nodejs only in unstable because
> > > requests to
Fridays.
> Ok. Any of those are fine for me, but I believe only Thursday at 1700
> UTC will work for Russ. Does that work for everyone else? (date -d
> @1338483600).
It looks like this works for me.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Develo
for ridicule.
You are in no position to say that Matthias does not want collaboration from
his fellow DDs when it's you who continues to make it very clear that you
want him out.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
g.
> So, unless something has changed, and as a sort of reminder (to self),
> this is for today at the above coordinates.
> Thanks for the organization Don, by-fiat-ftw! :-)
Something did change; Ian said he can't make Wednesdays, so the final agreed
time is tomorrow (date -d @1338483600
n the
matter, and we appear to have a consensus regarding the correct technical
path forward. If there are specific technical objections to the proposed
resolution, we should of course take those on board; but I don't think it
helps anything to waffle on the question of who is making the decis
ut immediately afterwards on IRC, I
had grabbed the wrong bug number. The one I had /meant/ to take was for bug
#573745.
--
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
or node and nodejs
2. Further discussion
I'll wait for feedback until 30 Jun 00:00:00 UTC before calling for a vote,
in case there are bugs above.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
ges.
=== End Resolution ===
Draft Ballot:
1. Approve transition plan for node and nodejs
2. Further discussion
I'll wait for feedback until 30 Jun 00:00:00 UTC before calling for a vote,
in case there are bugs above.
Thanks,
--
Steve Langasek Give me a lever long enough and a
So the deadline I set myself for this is now long past; sorry about that.
Responding to comments - call for votes will come in a separate message.
On Fri, Jun 29, 2012 at 12:20:24PM +0100, Colin Watson wrote:
> On Thu, Jun 28, 2012 at 12:52:39PM -0700, Steve Langasek wrote:
> > Sorry t
I'm calling for votes on the below resolution on the Node/NodeJS question.
=== Resolution ===
The Technical Committee reaffirms the importance of preventing namespace
collisions for programs in the distribution, while recognizing that
compatibility with upstreams and with previous Debian releases
On Sun, Jul 08, 2012 at 05:08:17PM -0600, Steve Langasek wrote:
> === Resolution ===
> The Technical Committee reaffirms the importance of preventing namespace
> collisions for programs in the distribution, while recognizing that
> compatibility with upstreams and with previous Debian
I'm calling for votes on the below resolution on the Node/NodeJS question.
=== Resolution ===
The Technical Committee reaffirms the importance of preventing namespace
collisions for programs in the distribution, while recognizing that
compatibility with upstreams and with previous Debian releases
On Sun, Jul 08, 2012 at 05:08:17PM -0600, Steve Langasek wrote:
> === Resolution ===
> The Technical Committee reaffirms the importance of preventing namespace
> collisions for programs in the distribution, while recognizing that
> compatibility with upstreams and with previous Debian
here, since the entire point
of the exercise that if a user has already installed a piece of non-free
software that satisfies the logical dependency, they should not have to
install another free package to satisfy the annotated dependency. This
applies regardless of what kind of non-free it is.
--
S
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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 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
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
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
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
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
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
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
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
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
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
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
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
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;
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
; 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
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
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
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
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
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 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
&
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
>
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
201 - 300 of 426 matches
Mail list logo
