Bug#947847: Bug#952897: opentmpfiles: Please make opentmpfiles to be drop-in replacement to systemd-tmpfiles
On 3/1/20 5:15 PM, Ondřej Surý wrote:
> Package: opentmpfiles
> Version: 0.2+2019.05.21.git.44a55796ba-2
> Severity: important
>
> Dear Maintainer,
>
> to make opentmpfiles usable for package maintainers
> it needs to be drop-in replacement in a sense that
> I can rely on the interface to be available for my
> packages. Not by calling extra script, not by adding
> extra shell spaghetti to decide whether systemd-tmpfiles
> is available and if not try opentmpfiles and if not ...
>
> As a packager I want to be able to freely use the
> declaratife interfaces provided by systemd even when
> writing sysv-rc scripts. The other option would be
> to just drop the init script and provide just the
> service file, but I am not decided I want to go
> this path.
>
> Ondrej
Hi Ondrej,
I very much agree with this, which is why there's a bug open against the
tech ctte: #947847 (which I'm CC-ing hereby). That's probably too much
reading. Basically, I'm asking the tech ctte what is the best way to
achieve what you described above. We're down to:
- using update-alternatives
The tech ctte and the systemd maintainer expressed themselves against
the idea.
- having systemd package tmpfiles and sysusers in separate packages, and
have them conflict with open{sysusers,tmpfiles}
This could work, but would need some non-trivial work from systemd
maintainers, also the systemd version may be a little too big. Also,
that's micro-packaging, and we're not sure if that's the solution. If we
go that path, maybe we will need 2 new virtual packages.
- using dpkg-divert in open{sysusers,tmpfiles} to replace the systemd
implementations.
That's really what I would hate doing, because this would hide things
from our users. Most Debian users don't even know about dpkg-divert, and
even less how to use it.
The question I've opened to the tech ctte is wider than just how to
package open{sysusers,tmpfiles}, it's also about how reverse dependency
should use it. Contrary to what I've been told, the point of using
open{sysusers,tmpfiles} goes beyond just non-linux ports: I want them to
be real alternatives, including in small environment (containers, VMs,
embedded), and I want that any user can choose what to use, even if
systemd is installed. I hope I'll be heard.
So, this bug will continue to be open until the tech ctte decides, or
the systemd maintainers agree to be open{sysusers,tmpfiles} friendly,
whatever comes first. Until then, I'm also putting on hold any work on
these 2 packages.
Cheers,
Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
On 2/21/20 9:10 PM, Niko Tyni wrote: > Hi Thomas, > > on IRC recently you said: > > 23:24 < zigo> If you're just answering about update-alternatives, then you > haven't paid attention to what I >wrote in the bug report. > 23:25 < zigo> And IMO, missing the point ... > > As I read the above, the systemd maintainers declined your suggestion to > add support for handling /usr/bin/systemd-sysusers with the alternatives > system, and you then requested the Technical Committee to overrule them. > > If this is not the case, could you please state clearly what you want > us to decide. > > Among other things, you later mention that a separate systemd-sysusers > package would be acceptable to you, pointing to #946456 . This avenue > doesn't seem to be exhausted yet? Hi, IMO, the question is a bit more hard than just "having packages that conflicts" or "using update-alternatives". As I think the issue is complicated, I would have like to have the tech ctte opinion on how to handle this case, for the Debian project at large. This is a general opinion that I'm asking for here, and guidance on how to set the policy for programs using systemd-sysusers, and the ones willing to (re-)implement the systemd interface to be used as an alternative implementation. It is my opinion that it's not good enough for the maintainer of systemd and systemd-sysusers to just decide, as every program using sysuser may be affected. Also please keep in mind that this is not only about sysusers, but a more broad scope (tmpfiles is concerned too... more may come!). Using update-alternatives for /bin/systemd-sysusers is what I thought was the best option, because cheap and easy to implement, with the nice advantage that we can have both packages installed at the same time, and programs can decide if they want a specific implementation or just any of them. However, if everyone is in the opinion that it's a bad idea, then I'm open to other solutions. Having systemd package systemd-sysusers (and systemd-tmpfiles) as separate package is also an option that would work. It's IMO annoying, because it takes a way longer to switch from one implementation to another, when update-alternatives instantly changes the configuration. We also loose the co-instability, and the fact that a given program can actively decide to use a specific implementation. But that still works too. However, packaging systemd-sysusers as a separate package it isn't as easy as one may think. See #946456 for the discussion. Using update-alternatives should have been a way easier. At the present moment, I'm not aware of any decision from the systemd maintainer, as this looks like not as easy as one may think. The only thing which I do *not* want to do, is using dpkg-divert. It is my strong opinion that this is a disservice to our users to do that, because dpkg-divert is rarely known, yet even understood by the average Debian users, so they wouldn't be able to even understand what happened to their system. We should be able to find a much nicer way to implement things. I'm also strongly against a /bin/sysusers which both programs would update-alternatives to, because then, we have a different implementation than on other platforms (this would be Debian specific). Cheers, Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/30/20 8:18 PM, Anthony DeRobertis wrote: > On 1/30/20 7:02 AM, Thomas Goirand wrote: >> This is normally solved if using pre-depends, which ensure that a >> package is configured before using it (and not just unpacked). > > Having everything using sysusers have versioned Pre-Depends on systemd | > opensysusers would probably minimize the problem, but could potentially > be a fair number of Pre-Depends to add. (I have no idea if non-versioned > Pre-Depends on a virtual package works, if so that'd be better. If not, > it'd also require adjusting them all if another alternative is introduced.) I wrote that it could be a solution to the said problem, but I am really not convince there's a problem at all. Thomas
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/30/20 7:16 AM, Anthony DeRobertis wrote: > There are some more that come to mind: > > * if we convert the exiting name to an alternative, there is the > somewhat interesting work of actually changing a file over from an > executable shipped in the package to an alternative, which would > normally be set up by postinst. That could leave an uncomfortably > large window during upgrade where the system would be broken (and > possibly not boot) if interrupted. This is normally solved if using pre-depends, which ensure that a package is configured before using it (and not just unpacked). > * if we use a new, different name, then we've introduced a > Debian-specific interface. One of the nice things about most of the > Linux world standardizing on systemd is increased cross-distro > compatibility; here we'd be breaking it. That's exactly what made me think that using the original name was less Debian wide work indeed. Though because of the binary name prefixed with "systemd-" this is less elegant than standardizing on /bin/sysusers. Cheers, Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 8:19 PM, Simon McVittie wrote:
> - Linux systems not booted with systemd
> (either no init system at all, like a typical schroot or Docker
> container, or a non-systemd init system like sysvinit)
This is very much one type of systems I have in mind, yes, and
open{sysusers,tmpfiles} could help to make them smaller. Just pulling
the whole systemd stack to add system users seems too much for very
little benefits.
> I think we have a fairly good picture of the costs that would be
> incurred from using alternatives: more interacting code paths to test,
> potentially more configurations that are technically possible but are
> not considered supported, and packages with "Depends: systemd (>= 321)"
> (or indeed systemd itself, in the case of systems using it to boot)
> not being able to rely on having access to all systemd 321 features,
> which doesn't seem like a least-astonishment situation to be in. However,
> Michael, or anyone else opposing this change: if you have anything to
> add to those, please do.
We don't need to do "Depends: systemd (>= 321)", we could have a virtual
package provided by both implementations.
Cheers,
Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 4:49 PM, Didier 'OdyX' Raboud wrote: > Le mercredi, 29 janvier 2020, 16.07:21 h CET Thomas Goirand a écrit : >> This reasoning can make sense, if we agree that we should use something >> else than /bin/systemd-sysusers and standardize on something else like >> /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is >> *the* way to do things, and using /bin/systemd-sysusers becomes a bug of >> severity "serious" (policy violation). > > We'd first have to agree that an alternative is actually _needed_. And so > far, > the only arguments I have read in favour of providing alternatives to > /bin/systemd-sysusers are: > * A) it is shipped in the systemd binary package; > * B) Having competing implementations is important; > * C) it comes from the systemd project; > * D) it has a systemd-* name; Very much, B for me... I don't want to see Debian stuck in a position where we are locked-in. This is my main motivation. C and B are distractions that I'm not at all diving into. A is annoying, because that imposes micro-packaging on systemd maintainers (a 200k+ package for just this simple feature? really?), and we try to avoid this project-wide. Thomas
Bug#947847: please install systemd-sysusers using update-alternatives
ain motivations behind packaging opensysuser. There's also the well known thing that systemd upstream rejects a variety of patch classes, like the ones allowing non-linux systems, for example. This isn't very much inviting, unfortunately. But that's not really my thing (I'm not so much interested in kFreeBSD or Hurd...). I do like the fact though, that maybe one day OpenRC will implement the parsing of .service files as Xu told about, and then it can become nice to have opensysusers and opentmpfiles. On 1/29/20 7:29 PM, Gunnar Wolf wrote: > I mean - We should encourage people to use /bin/sysusers. Now, if > systemd-sysusers grows a piece of functionality that open-sysusers > is not willing to adopt (or vice versa) Thanks for considering the "or vice versa" possibility!!! :) > following past examples, I > believe a package set to predepend on systemd-sysusers should be able > to call /bin/systemd-sysusers — And a package set to predepend on > open-sysusers can do likewise. This feels reasonable to me. Even better if this goes into the policy. I've read many telling about a potential new functionality that would not be implemented here or there. However, my guts feeling is that this feels like a kind of stable API that isn't intended to grow very much, and hopefully, will be of low maintenance. Let's see what the future shows... Cheers, Thomas Goirand (zigo) P.S: Just a quick digression: I really dislike the fact that I've constantly read people saying "what if opensysusers lags behind". And what about if I decide to contribute a super nice functionality that systemd-sysusers authors didn't think about? Could everyone at least attempt to consider that this is a possibility as well? That innovation doesn't come *only* from systemd? Also, best would be if we keep both compatible, and hopefully, this will be the case over a long period of time.
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 1:50 PM, Raphael Hertzog wrote: > On Wed, 29 Jan 2020, Thomas Goirand wrote: >> echo 'u radvd - "radvd daemon"' | \ >>systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf > > Does opensysusers support this use case? Yes it does. > There's no need to predict the future, you must analyze the > current situation and go forward from there. Of course we are planning for the future. Let's say an important feature appears to be needed (this is just a point or argumentation at this time, please everyone: don't add unnecessary FUD), then of course, it's always possible to fill the gap and implement the missing feature. The clear goal is for opensysusers to become a full replacement of the systemd implementation. > As for the > service creating users during boot, you can provide a debconf > question giving the option to the user to install an override > of systemd-sysusers.service which actually calls opensysusers. The intend is for opensysusers to be a full replacement, I don't see why we should bother users with some annoying debconf prompt that they probably wont be able to understand without a an extensive knowledge of the situation. > And when we get to the point where the lack of systemd-sysuvers is a > problem, we can always patch programs to use /bin/create-system-users > instead of systemd-sysusers. I'm unsure what your above proposal is, so let's expand a little bit. Sorry if it appears I'm distorting your words (that's not the intent). This reasoning can make sense, if we agree that we should use something else than /bin/systemd-sysusers and standardize on something else like /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is *the* way to do things, and using /bin/systemd-sysusers becomes a bug of severity "serious" (policy violation). However, imposing everyone (for current or future use of sysusers) to handle a specific case for opensysusers is IMO *not* the way to go. And this is the very point of this bug entry. Cheers, Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/29/20 11:34 AM, Raphael Hertzog wrote: > On Tue, 28 Jan 2020, Thomas Goirand wrote: >> This is exactly what should be avoided. It's perfectly fine to try to >> use opensysusers with systemd if one wants. In fact, that's exactly the >> best way we could do to be able to test it. Also, dpkg-divert is really >> ugly, and something you use as the last resort, when all other options >> have been exhausted. > > It's not that ugly if you consider that you are in an experimental phase > where you want to test opensysusers. > > Also you seem to imply that the common interface is the systemd-sysusers > binary. I don't think that this is necessarily the case. The common > interface is the file format. The name of the program creating the users > is not important as long as it's properly hooked in the packaging system > and boot sequence. Hi Raphael, I'm replying to you, but it goes also for Phillip Kern too, which had a similar answer. My idea is to have a single entry point for programs to call the sysusers binary. If we collectively decide that it's going to be called /bin/foo, then by all means, let's do that. But I don't think it's reasonable to say it's going to be called /bin/systemd-bar, and nobody can take over this path. This is the wrong answer to the problem. I do agree that the data file is the interface, but can you predict *ALL* the cases where /bin/systemd-sysusers is called? As much as I understand, it could be called by: - something debhelper adds to postinst - something the maintainer adds manually to postinst - the init system itself And more disturbingly, it could be called by any program that just wants to add a user the same way one would just call useradd or adduser. The man page for systemd-sysusers even gives a very clear example: echo 'u radvd - "radvd daemon"' | \ systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf which clearly, looks like something someone would write in a shell script, manually calling /bin/systemd-sysusers, from anywhere, maybe even from a running program / daemon (I haven't seen any designed limitation, have you?). So I am in the opinion that "as long as it's properly hooked in the packaging system and boot sequence" simply doesn't work in this case, as systemd-sysusers could be called from virtually anywhere. As for the use of dpkg-divert, as you wrote above, it's ok for experimentation, but I do think it's making a disservice to our users to use that as the proper interface to implement. The update-alternatives has the very nice advantage that it clearly shows the current status of the system, and that it can be very easily tweaked, by hand or by some kind of automation. It's also super easy to go from one state of the system to another, compared to reinstalling / uninstalling a package. Cheers, Thomas Goirand (zigo)
Bug#947847: please install systemd-sysusers using update-alternatives
Anthony DeRobertis
> It's different than awk because the decision the admin is making
> ("which init system do I want to run"?) isn't done through
> alternatives. So you can't use the alternatives system to coordinate
> swapping all the different bits together.
You are mixing things here. We are *not* talking about init systems, but
about sysusers, which can be used with any init systems.
> It seems retty reasonable to me that the systemd maintainers don't
> want to support systems which are running arbitrary combinations of
> systemd with alternatives to some parts.
Absolutely nobody is asking them to do that. I'm just asking for a
solution to easily replace /bin/systemd-sysusers. There are 2 solutions,
one is to have /bin/systemd-sysusers packaged separately, though this
would probably be micro-packaging, which I'm not a fan of. The other
solution is to use update-alternatives. I'm fine with both solution, I
just don't think it's fine to say "get away, my implementation is
better", and leave no reasonable solution to install something else.
> Strikes me as there is a possible solution, though: have opensysusers
> dpkg-divert it and put a shell script in its place that checks which
> init system is running, and exec's the right sysusers based on that.
This is exactly what should be avoided. It's perfectly fine to try to
use opensysusers with systemd if one wants. In fact, that's exactly the
best way we could do to be able to test it. Also, dpkg-divert is really
ugly, and something you use as the last resort, when all other options
have been exhausted.
> This wouldn't affect systemd-only machines (as opensysusers would not
> be installed at all), and would do the right thing if someone has
> installed two init systems to, e.g., consider switching.
Again, you are mixing things (ie: what type of init system and
re-implementation of an independent component of systemd). We should be
able to allow to run opensysusers if systemd is running (exactly, why
not?). This is desirable, at least for testing. It would also be
desirable to use systemd-sysusers with other init system if one wants
(also: why not?).
> It'd need to be a script that the systemd maintainers feel reasonably
> confident will always run systemd's implementation when systemd is
> running, to avoid the mixed implementations issue.
Not at all. Systemd maintainers have no say if someone wishes to
implement things in another way, the same way there's gawk and mawk,
implementing the same thing. If we don't allow such things, then really,
Debian is doomed.
I am not buying into the "we will have wrong bug reports" argument. We
constantly get many types of wrong reports in the BTS. We just shall do
sensible bug triaging in a correct way, that's it.
Cheers,
Thomas Goirand (zigo)
P.S: Note that this bug also concerns systemd-tmpfiles, the very exact
same way, though I believe one single bug is enough to address both
cases which are similar.
Bug#947847: please install systemd-sysusers using update-alternatives
On 1/25/20 5:05 PM, Michael Biebl wrote: > Control: tags -1 + wontfix > > Hi Thomas > > On Tue, 31 Dec 2019 17:29:29 +0100 Thomas Goirand wrote: >> Package: systemd >> Version: 244-3 >> Severity: important >> >> Hi, >> >> As I'm packaging opensysusers (see ITP: #947846), I would like my >> package to also provide /bin/systemd-sysusers. Please install this >> binary on another location, so that both systemd and opensysusers can >> implement it. I am very much fine to have systemd have the priority over >> opensysusers if you believe it should (I'm open to discussion about >> priorities). > > Thanks for your interest in systemd-sysusers. > After thinking more about this, I don't consider renaming > systemd-sysusers and installing it via alternatives as a good idea. > > When systemd is installed and used, we definitely want to use its own > implementation. > > My recommendation would be to install the opensysusers implementation > under a different binary name. > > Alternative init systems can then decide to support sysusers by calling > that opensysusers binary during boot. > debhelper, should it get sysusers support, should generate code which > calls the correct binary depending on the current circumstances. > > Regards, > Michael > > > Hi Michael, It is my view that what you're proposing would be a lot more work for on valid reason. I'm therefore re-assigning the bug to the tech-ctte, asking them to decided instead. It is my view that using update-alternatives is *very* easy to implement, so that we can share the /usr/bin/systemd-sysuser location. Besides the fact that, with the way you're suggesting, we'd need to fix debhelper (which I don't think is reasonable, as it wont be the only place to handle multiple cases, I'm foreseeing...), there's also the concern that you don't seem to agree that it'd be ok for one to use opensysuser instead of the systemd implementation if systemd is running. I do not agree with this, and I believe it is up to the users to decide what to do, even if we, as an operating system, must provide sensible defaults (which also can be discussed, but that's not the point of this bug report). Moreover, I don't see why /usr/bin/systemd-sysusers would be any different from let's say /usr/bin/awk. The update-alternatives system is there exactly to handle the case we're facing today. So, tech-ctte, please decide. Cheers, Thomas Goirand (zigo)
Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
On 06/14/2015 05:10 PM, Don Armstrong wrote: > On Sun, 14 Jun 2015, Thomas Goirand wrote: >> Therefore, I'm tempted to raise this to the technical committee >> (putting their list as Cc). Does anyone see a reason why I am >> mistaking here? > > Does a patch exist which can enable lz for orig.tar? Isn't it what this is doing? https://bugs.debian.org/600094 https://bugs.debian.org/556960 > Otherwise, I guess some of us could be involved to help clarify > communication, but anyone can do that, really. I'm not at a stage where I want to involve the CTTE right now. I still would prefer to gather opinions and see where it goes. Thomas Goirand (zigo) -- 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/557e9503.6010...@debian.org
Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
On 06/13/2015 10:55 AM, Paul Wise wrote: > On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote: >> I've been using xz compression for a long time, but I see a big defect >> which is today pushing me to turn it off for the .orig.tar file. The >> issue is that depending on the version of xz-utils, it produces a >> different output. >> >> We use "git archive" within the PKG OpenStack team to generate this >> tarball (which is more or less the same as pristine-tar, except we use >> upstream tags rather than a pristine-tar branch). The fact that xz >> produces a different result makes it not reproducible. As a >> consequence, it is very hard for us to use this system across >> distributions (ie: use that in both Debian and Ubuntu, or in Sid & >> Jessie). We need consistency. >> >> As a friend puts it: >> >> "This is a fundamental problem/defect with xz. This (and a lot of >> other such defects, e.g. non-robustness of xz archives that easily >> lead to file corruption etc) are the reason that there is lzip (and >> which is why gnu.org has, on a technical basis, decided that lzip is >> official gzip-successor for gnu software releases when they come in >> tarballs). >> >> So it'd be super nice to have LZIP support in dpkg, and use that >> instead of xz, archive wide. >> >> Your thoughts everyone? Is there any reason why we wouldn't do that? >> >> Cheers, >> >> Thomas Goirand (zigo) > > It was already rejected by the dpkg maintainers twice. > > https://bugs.debian.org/600094 > https://bugs.debian.org/556960 Reading these bugs, am I right that the archive already supports lzip for the orig.tar file? Because that's my issue: I don't really mind if we use xz for the compression of the .deb files, but I need consistency when generating the orig.tar. Though, I had a try, and it doesn't look like dpkg-source -x supports the .lz format unfortunately. Now, regarding the fact that the maintainer closed the bugs, I see 2 issues the way he did it. 1/ First, he sites the fact that lzip isn't popular enough as the only reason (did I miss another point of argumentation?). Well, it's backed-up by the GNU project as the successor of gzip, and also, I believe Debian is influential enough so that we may not have to care about it. Also, a wise technical choice of this kind shouldn't be driven by a popularity contest. 2/ Guillem wrote "that's at the maintainer's discretion" (ie: to close the bug). Well, here, the whole of Debian is depending on this kind of decision, so I don't agree that this decision is only at the discretion of the maintainer. Therefore, I'm tempted to raise this to the technical committee (putting their list as Cc). Does anyone see a reason why I am mistaking here? Cheers, Thomas Goirand (zigo) -- 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/557cb7ed.3060...@debian.org
Bug#746715: the foreseeable outcome of the TC vote on init systems
Thanks Ian, this is exactly what I think as well, and you expressed it a way better than I would have. Thomas -- 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/53691267.5000...@debian.org
Bug#746715: the foreseeable outcome of the TC vote on init systems
On 05/06/2014 05:11 PM, Raphael Hertzog wrote: > I don't believe that he is intentionnally uncooperative but he makes it > difficult to cooperate with him unless you agree with him on everything. I don't think this has to do with agreeing with him or not. I believe he is unfriendly with unfriendly people, and I don't think you count as one of his friend, given the way you've interacted with him in the past. Thomas -- 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/5368c24c.5090...@debian.org
Bug#746715: the foreseeable outcome of the TC vote on init systems
Steve Langasek wrote: > Yes, and I think it was wrong that the bug was closed by an upload to > experimental instead of to unstable when there was nothing > experimental about it. Daniel is just being extra careful, using experimental a bit more these days, to avoid the more discontentment (I don't think there's the need of explaining the background and history of his situation). It is my opinion that it isn't a good idea to point finger at him for the extra care to not break anything. As for supporting multiple init systems, I'd be pleased if the TC was expressing about it, and especially that it is the duty of maintainers to accept patches for them. So I'm all with you on that Steve. I just regret the course of events, and the fact that Daniel looked uncooperative, when I'm convinced that he is. Thomas -- 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/5367bf6e.8000...@debian.org
Bug#746715: Shocking read ...
I'm really stoned by reading this bug. Daniel is nicely proposing to accept patches from Steve, and re-add support for Upstart, and he just wrote that Steve could have just get in touch. - Why are we loosing time to discuss the timeline of uploads, to see if there was upstart support at some point or not? What's the point of doing this? - Why this bug isn't just closed, and the issue just discussed between Steve and Daniel, so that a technical solution can be found? Daniel seems to agree to have upstart support, so what are we discussing exactly in this bug? - Why are some people like Andreas making dangerous allusions to other maters that seem unrelated, with no reference? I don't think such gratuitous accusation this is welcome in this bug (or in fact, anywhere in Debian). Or is it just OK because this is Daniel that we're talking about? If so, that's unfair. If Daniel wrote: "Removing upstart hacks, they are ugly and upstart is dead now." probably that's what he felt (eg: that upstart is dead). He's probably just wrong about it, and we should "Assume good faith" (ref: our code of conduct). [And, by the way, I do agree that what the Debian policy proposes at 9.11.1 is an ugly hack, and that Upstart should know better...] We've just adopted a code of conduct, were we should "Be respectful", "Assume good faith", and "Be collaborative". I know Daniel well, and I believe he is a nice person, which is trying to do all of the above, and do what is technically right. It'd be nice if the persons interacting with him also tried to act in this way. For me, the next course of action is: - Close this bug - Let Steve and Daniel work out reintroduction of Upstart in his package - Have everyone calm down and stop useless finger pointing Cheers, Thomas Goirand (zigo) -- 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/53651027.7070...@debian.org
Bug#727708: OpenRC + Hurd status
Hi, Just a short message to inform everyone that, with the latest sysvinit package from Sid (eg: 2.88dsf-47) and the latest OpenRC package from Experimental (eg: 0.12.4+20131230-8), then Hurd just boots fine with OpenRC! :) Here's how to do it: apt-get install initscripts sysv-rc sysvinit \ sysvinit-core sysvinit-utils update-alternatives --config runsystem The later command tells hurd to use sysv-rc (otherwise it continues to use the Hurd specific boot hack thing...). Then just install OpenRC on top of that: apt-get install openrc I'm not sure installing sysv-rc is even needed. Probably installing OpenRC first, then the other sysvinit packages would work as well. There's nothing more to it: it just works (tm)! :) Hoping that the status update and our porting efforts are appreciated, Cheers, Thomas Goirand (zigo) P.S: My experience with Hurd was ok-ish, though the "console randomly doesn't come up" bug was really frustrating, especially considering that Hurd only uses ext2. :( -- 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/52f1f03d.3070...@debian.org
Bug#727708: The tech ctte isn't considering OpenRC at all
On 01/19/2014 08:15 PM, Ian Jackson wrote: > How mature a system is and how well-developed in Debian are relevant > factors If we're making a competition of how long has an given init system been in Debian, then for sure, OpenRC looses. However, on all the tests I did, I see no major issue with OpenRC. Could you point to specific issues that you've encountered? Otherwise, what do you have in mind exactly, apart from "this is too new, so I don't trust it and therefore refuse to even try it"? > and it's not unreasonable to set a deadline, at which the > state of the system in Debian will be the basis of our technical > evaluation. What's difficult for the TC, is that your decision also impacts the future, not only the present. Only considering what we have right now isn't unfortunately enough. I do hope that you are also considering the possible outcomes of current developments, and paths which has been taken by upstream. I believe it has been the case already, for example, logind, udev, gnome, etc. and their future support (using this or that init system) has been part of this discussion. It doesn't seem reasonable to just ignore future plans, and incoming features which are currently in active development (see below about s-vision patch, which I believe is a very good example illustrating what I'm saying here). On 01/19/2014 08:15 PM, Ian Jackson wrote: > * The daemon does not double-fork; it runs in the foreground of >of its initial process. Something like start-stop-daemon then? :) See also the command_background directive (in the man openrc-run). On 01/19/2014 08:15 PM, Ian Jackson wrote: > * The daemon's parent process (part of the init system) keeps >track of it, so the init system knows whether the process >is still running. First, OpenRC isn't stateless like sysv-rc to begin with (try "rc-status" to see what daemon is running). Status are kept in /run/openrc/started using symlinks to /etc/init.d, and OpenRC uses (optionally) cgroups to shutdown daemons, if that's what you ask. Then, the answer to this question is even more definitively "yes", if you use this patch: https://github.com/qnikst/openrc/compare/s-vision which uses monit for the process supervision. If you don't know monit, well this probably means you haven't played much with servers. Monit has been in Debian since 2002. It is a very mature tool which is great on the server side. One of the very cool feature of Monit, is that it includes email reports (so you know a daemon actually crashed), and actual service functionality testing (like, is apache returning "hello world!" when querying this URL, for example...), which none of the other init system (to the best of my knowledge) implements yet. It is to me a far more superior approach than just checking for a daemon to be just "running" (but maybe crashed in a CPU-burn loop...). I'm talking about a *working patch* here, not just "future plans". If I didn't add it as a debian/patches add-on, this is because version 0.13 of OpenRC is supposed to be out soon, and it's my understanding that it would be including it. So I do prefer to wait for the new upstream release, but it's going to be there soon. Not taking this into account isn't, IMO, reasonable. On 01/19/2014 08:15 PM, Ian Jackson wrote: > * The daemon's stderr goes somewhere reasonable. Hum... By default, I honestly don't know what would be the behavior of a daemon doing some output to stderr. However, I believe it'd be really trivial to do in the command= statement of a runscript. Something like: command="foo >/var/log/foo.log 2>&1" or using the command_arg directive should be enough (I haven't tested, but this seems reasonable). Thomas Goirand (zigo) -- 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/52dcdf3c.4040...@debian.org
Bug#727708: logind working without systemd
Sun, 19 Jan 2014 13:42:40 +0200, Russ Allbery > Hopefully, logind will continue to work without systemd and people > will volunteer to maintain the necessary packaging for that > configuration, and none of this will be a problem. I really wish you were right Russ. Because that's not what upstream is doing (since systemd 205, it's not the case), and Debian package maintainers have stated this as an argument in the favor of systemd. I would very much like the tech ctte to express itself on this topic on the final statement (whatever default init system is chosen). Thomas -- 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/52dbe12b.7040...@debian.org
Bug#727708: The tech ctte isn't considering OpenRC at all
On Fri, 17 Jan 2014 20:41:32 -0800, Don Armstrong wrote: > I should point out that I have not extensively examined openrc I have to say that I'm really disappointed by the tech ctte attitude toward OpenRC in general. I pointed out to bdale (privately) as well that this was unacceptable. I've seen *many* quotes like this one: Fri, 17 Jan 2014 16:46:43 +0100, Christoph Anton Mitterer wrote: > I haven't really looked in depth at OpenRC or other solutions, since > from the descriptions made by other people, I think it's not > comparable to systemd/upstart. Christoph, you don't *think*, you've just *heard of* from others (which may be systemd or upstart supporters). Please learn to think by yourself!!! Unfortunately, it seems it's going to be the way OpenRC will be evaluated: because some people *pretended* that OpenRC wouldn't fit the bill, it's just discarded without even having a look at how it works, its features, and its implementation. That OpenRC isn't the best, I can agree to *read* that, even if this isn't my opinion. That it has less feature, I agree, but I don't think the tech ctte choice should be driven by the number of features, but by a set of requirements, and then choose the best implementation for them. But that OpenRC just hasn't been considered just because of rumors is really unacceptable. It is my strong opinion that, because OpenRC is the only one which has been ported to all Debian arch, and that because it has all the features *that we need* (if you include the plugin patch for s-vision and monit, which I'm currently evaluating and should be ready in days/weeks), and because of the way it is implemented (eg: very light and easy to understand/maintain), it is the best choice. Don, please do your work and evaluate properly OpenRC. Otherwise, step down and do not participate to the vote. Same goes for all tech ctte members please! On Fri, 17 Jan 2014 16:19:45 +0100, Josselin Mouette : > That, I can definitely agree with. Although it is a shame that OpenRC > chose a non-declarative format. Joss, please stop posting stupid remarks about OpenRC. You don't know it, and you don't seem to want to know it. That's the 2nd post in a week that shows it, this is enough. OpenRC does have a declarative format, it is just not mandatory and you can continue to use init scripts if you like. Here's an example (from my blog, implementing the startup for rsyslogd): http://thomas.goirand.fr/blog/?p=147 Note that the sheebang should be replaced by /sbin/openrc-run since runscript was renamed (because of clash with the program from minicom). If you don't call this declarative, then you aren't being honest. On Fri, 17 Jan 2014 16:19:45 +0100, Josselin Mouette : > Oh, really? > Then can you explain why > https://bugs.gentoo.org/show_bug.cgi?id=391945 > has not been marked as fixed? It is the view of the upstream maintainers that the corner case where this happens doesn't happen in real life, so that bug can be ignored. This has already been stated many times, and I'm sure you've heard about it. I thought we were not having the debate this way. It seems you love flame wars and can't help yourself. CAN YOU STOP NOW ??? Cheers, Thomas Goirand (zigo) -- 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/52db96ca.3010...@debian.org
Bug#727708: OpenRC now works on GNU/Hurd! :)
Hi, It's with great joy that I can announce here that OpenRC now supports GNU/Hurd. I have just added a few patches which were worked out with upstream (you can look at them, it's really trival FTBFS fixing...), tested it, and I can happily say it works. The only thing that bothers me a bit is that the ANSI output isn't so pretty, but I guess this is fixable and a minor problem. On the Thu, 16 Jan 2014 17:18:24 +0100, Josselin Mouette wrote: > This assumes that OpenRC can be fixed to have parallel boot, otherwise > this is a big regression from the current insserv setup. This is just plain wrong, OpenRC perfectly supports parallel booting, it's just that the output on the screen is very ugly for the moment (that as well can be fixed, I suppose). Also, I'd like to point out to everyone that the OpenRC runscripts are stored in /etc/init.d. This means that if someone wants to support OpenRC and use a runscript instead of a traditional init.d shell script, that someone will also have to support whatever we will choose as default. Let me explain to make sure everyone gets it... Let's say you rewrite /etc/init.d/foo, and transform it from a init.d traditional sysv-rc script to an OpenRC runscript in your package. If the init system is systemd, then systemd will *not* understand the OpenRC runscript. This means that you will also have to write a systemd unit file, if you want to write /etc/init.d/foo as an OpenRC runscript. The same would of course apply to Upstart. Though I think that writing a systemd unit file, plus an OpenRC runscript, is still more easy and strait forward than writing a single init.d sysv-rc shell script. So, if we are to switch to systemd as default (same would apply if we choose Upstart), IMO the policy should be that package maintainers have 2 choices: 1/ Write a standard LSB-header SysV-rc init script, which will of course work with any init system (sysv-rc, OpenRC, systemd, Upstart, file-rc...) 2/ If the /etc/init.d/foo is an OpenRC runscript (which we should, IMO, push for since traditional scripts have some many problems which I can't even lest in this mail, and we all agree about that), then the package maintainer *must* provide support for systemd (or upstart, if we choose that as default). IMO, the above would be the best way forward for Debian if we want to continue to support our ports. Cheers, Thomas Goirand (zigo) -- 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/52d92517.5010...@debian.org
Bug#727708: additional OpenRC information: OpenRC now in Debian Experimental!
On 01/04/2014 01:42 AM, Ian Jackson wrote:
> Thomas Goirand writes ("Bug#727708: additional OpenRC information: OpenRC now
> in Debian Experimental!"):
>> OpenRC is now in Debian experimental! \o/
>
> Good, thanks.
>
>> I of course welcome anyone to try OpenRC and report bugs.
>
> Can you point me to the relevant reference documentation ?
>
> Thanks,
> Ian.
Hi Ian,
I'm not sure what kind of doc you are looking for. If you want to know
how to install it, well, it's just an "apt-get install openrc" plus a
tricky first reboot. Otherwise, read further.
You can first have a look over here:
https://wiki.debian.org/OpenRC
Though I just have made some edits to make it up-to-date, that page is
still a work in progress, and would need much improvements, like how to
write runscripts and so on.
There's also this from Gentoo upstream:
http://wiki.gentoo.org/wiki/OpenRC
As much as I know, most of the available documentation is available from
the set of man pages from the OpenRC project. Here's a list of available
manpages:
einfo.3 openrc.8 rc_config.3 rc_find_pids.3 rc_runlevel.3 rc-service.8
rc_stringlist.3 service.8 openrc-run.8 rc_deptree.3 rc_plugin_hook.3
rc_service.3 rc-status.8 rc-update.8 start-stop-daemon.8
They are not all installed by the Debian package yet, so you may want to
have a look in the man folder of the source package.
You can to start reading the man page for openrc-run, which describe how
to write OpenRC "runscripts". A runscript is what can replace init
scripts, eg you would replace #!/bin/sh by #!/sbin/openrc-run. FYI,
openrc-run is the new name of /sbin/runscript. It was renamed because of
the clash with the command line from minicom. I guess we'll keep the
therm "runscript" for a while still, even if it's really referring to
"openrc-run" now.
But probably, the most easy way to learn how to make runscripts is to
read what's been done in Gentoo. Inside the openrc source package, under
the init.d script, there's a bunch of runscripts which you can read as
examples. When reading them, keep in mind that these are rather complex,
and most of the daemons in Debian will not need that complexity.
If you need to know more, let me know.
Cheers,
Thomas Goirand (zigo)
--
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/52c7db86.8090...@debian.org
Bug#727708: additional OpenRC information: OpenRC now in Debian Experimental!
On 01/03/2014 01:25 AM, Russ Allbery wrote: > As I mentioned in some of my previous notes, I was unable to evaluate > OpenRC in a meaningful way during my general experiments for a few > reasons. My impression was formed based on previous discussion and what > documentation I could find, which was fairly minimal. > > Thomas Goirand sent me considerably more information, including some > details about OpenRC project goals that corrects information in my > original writeup. With his permission, I'm including that here for the > benefit of everyone else who is following this debate. > > Thomas, please follow up with anything that I left out or anything else > that you think people should be aware of. Well, there's something that people should be aware of... OpenRC is now in Debian experimental! \o/ Also: * I have solved the problem with reinstalling the initscript package (it was only a missing /etc/runlevels/single folder, which by the way is now populated with the correct symlinks so single user mode also works from now on). * The first reboot can be done using: for file in /etc/rc0.d/K*; do s=`basename $(readlink "$file")` /etc/init.d/$s stop done That fits on a single line, so the postinst script of OpenRC just warns that this command should be performed by the user when migrating from sysv-rc to OpenRC. When doing this, the first shutdown is kind of clean. While not perfect (yet), that's a workaround. Unfortunately, with sysv-rc, there's no way to know which daemon is started, so it's also impossible to stop them cleanly. Though probably attempting to stop them all should work. I'm open to any suggestion to make this better, and maybe have a way to build a script that users could call directly. Note that when migrating back from OpenRC to sysv-rc, there's no such a problem, it just works (since sysv-rc is stateless). I of course welcome anyone to try OpenRC and report bugs. Cheers, Thomas Goirand (zigo) P.S: I'd like to publicly thank Patrick Lauer, Benda (李明宇), Bill Wang, Roger Leigh, WilliamH & qnikst (sorry, I only know the IRC nicks of these last 2 persons) for their help and support when porting OpenRC to Debian. -- 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/52c6f4f3.5020...@debian.org
Bug#727708: initsystem decision process: Finalizing position statements before December 6th.
On 12/02/2013 09:40 AM, Don Armstrong wrote: > As discussed in the most recent CTTE meeting, we expect all of the > position statements to be finalized no later than this week. I believe > that only the OpenRC statement is not yet finalized. Hi Don, That's not correct, I have stated it was done (after I confirmed that with upstream). Sorry if I didn't make this clear enough. So please go ahead! :) Thomas -- 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/529c1305.5030...@debian.org
Bug#727708: init system question before the technical committee
On 11/22/2013 04:56 AM, Steven Chamberlain wrote: > Hi, > > On 10/11/13 18:23, Russ Allbery wrote: >> What is the current status of the other position statements from the >> perspective of their maintainers? Do people have a feel for when they'll >> consider their positions finalized, at least pending Technical Committee >> feedback and questions? > > Sorry to be so late with this. I've made some small, final changes to > this position statement and I'd like to call it 'complete': > https://wiki.debian.org/Debate/initsystem/multiple > > I don't really feel that any "contra $initsystem" sections or rebuttals > are needed on this page and it reads nicer this way. And I'm too tired > to argue this much more; the debate has already taken far more energy > than I would like. > > Thanks, > Regards, Hi, I have the go-ahead from OpenRC upstream (eg: Patrick Lauer) so please consider the OpenRC page as finalized as well. Cheers, Thomas Goirand (zigo) P.S: Sorry for the delay. As I wrote previously, I had personal and professional events which delayed this task. -- 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/52958c09.6080...@debian.org
Bug#727708: Strong argument for OpenRC
Hi, I got a *new* argument in the favor of OpenRC: http://youtu.be/zoNoi8BgQjs Yes, we made it work in Debian GNU/kFreeBSD! :) Upstream was very friendly helping to do this last night and this morning. Now, the next blocker would be renaming /sbin/rc to /sbin/openrc, though upstream pretends it shouldn't be hard to do, and they told me they will work on it. I unfortunately (and of course, I'd say) can't upload to Debian until this is fixed, though it's in collab-maint for those who want to try. I warmly welcome Hurd folks to try porting it too. Thomas Goirand (zigo) -- 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/5270babd.9030...@debian.org
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi there! I've been asked to write about OpenRC here. I'm a bit reluctant to do it, but feel that it's my duty as I've been mentoring the OpenRC GSoC project this summer. Well, it's been a month the OpenRC package is waiting in the FTP NEW queue (after a successful GSoC project), so it's a bit silly to tell about something which isn't even in Debian yet... Though if anyone wants to test it, it's in /git/collab-maint/openrc.git on Alioth. Anyway, the main point of OpenRC, IMO, is that it can work on non-linux platforms. But at this point, it is hard to make a case for it, since the porting work (well, I should rather say the no-FTBFS work... as it should be only a mater of configuring the build environment) hasn't been done yet. :( Note that OpenRC already works on some (non-Debian) BSD platforms, and that it should be trivial to have it to build on kFreeBSD and Hurd, though I didn't (and probably wont in the next few weeks/months, due to professional duties and personal events) have time to work on this. Though when this is done, OpenRC will be a drop-in replacement, with normally very little trouble to take care of. I of course welcome anyone to work on these ports. With a bit more goodies than with sysv-rc (for example, cgroups support for the platforms who supports it), OpenRC can be seen as an evolution of it, with more features. As for my own opinion on #727708, I'd like the tech committee to decide we *must* continue to support something that works on kFreeBSD and Hurd (either sysv-rc, or OpenRC when it's fully working on all arch) as a requirement in the Debian policy, at least if we don't have an upstart working port for Hurd / kFreeBSD (if this ever happens). It is to be noted that it's Systemd upstream opinion as well that Debian has no choice but to support something else than Systemd (sysv-rc, OpenRC,...) scripts for platforms which wont ever be supported by Systemd (I discussed about that with Lennart during Debconf). Even if there's no such a decision from the tech-ctte, some ways of starting daemons must be done for the non-linux Debian archs. And OpenRC could be adopted for them (in the absence of Upstart / Systemd), to simplify writing of these init scripts and bring more features. So, whatever the tech-ctte decides, OpenRC, in my opinion, makes sense! :) I also would like to wish good luck to the tech-ctte. Whatever you will decide, I will support it. I wouldn't like to be in your seats, and I hope everyone will also support your final decision. Hoping that the work on OpenRC will be useful for Debian, Cheers, Thomas Goirand (zigo) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJSbA5ZAAoJENQWrRWsa0P+YYUP/37zqCtcornktT3xb7LKC4w7 ZdDig/g6cGW1JbL90q/6OPSN0CDUiVcF66HkP5RXk6jUG9CBm5OMmkz2+VX3THLR Vhnyd/t5dQiyBLGgSO9YI4I9DizppasYjRpqsK7O3bI7cfmGgg8xyBk6CL3Kblvm D7+jvRbBwdt+HqJccHsM4+n3mUgJFLOajVwU2E8Mp7TFY3bRwIyXWDPsE+7q0Jxi 1F1sS/bBxtaBOlj3tEAMRxLHH74bwKiT5VTo114ygQTu8ylsZ8hSCnNuDFSAm7mk 0TL28xaD1bA7VN2VwYd41J/KIWHel+0In5fG7FOIX1DGf543Fyei+CfpaINAHS+7 Yt8X2C/EFJr/4dERXTrxhxSN9T0B8fRvXwe1I6KEvcoyzIsEKjJO/yJxmr8NNrVA w5Qp/jjLfrL82HlUIdvva4OonFCHGIVZkP+KFjTYMnKUJ9mlOnqCIF7m+cfH7ZkR RFfodY3eWAiVY+Nq2SJ0EB9R+cslxXovotNvmMZQvagLIhlLC+qXMGTkV6VvXHbF B0nVT6qCGmuDHQSUBCCeGy7nEKU1ObRcyfW3YJ0tiXmOTBuCBltHJpOiV4OwBcMK 7b20W8AtAyTbdtheksoUS4TSg25LOAQfeP0Gk0AVDV7nDDGLDVcCJ6L84JBjcu03 5wvRVoh1K0uf/pC/jWM9 =E/op -END PGP SIGNATURE- -- 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/526c0e5c.7010...@debian.org
Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
Oh, also, it seems that some people seem to believe that it may be possible to run with more than one hypervisor *at the same time* with nova. Tollef Fog Heen wrote that. Well, it would be a nice feature, but no, it's not possible with Nova, AFAIK. Could we avoid this? It doesn't help the discussion. Thomas -- 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/516fba54.4080...@debian.org
Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
On 04/18/2013 02:52 PM, Tollef Fog Heen wrote: > ]] Thomas Goirand > > (Cc-ing you, since I don't know if you're subscribed. Apologies for the > extra copy if you are.) I am not subscribed indeed, thanks. >> You guys are writing this as if it was impossible to switch from one >> hypervisor to another. Yet this is simply not the case. You can easily >> switch from one type of hypervisor to another with the current packages >> (by editing /etc/nova/nova-compute.conf manually and installing the >> dependencies manually as well). My point is just that multiple packages >> make it possible to automate the switch in the config file and >> dependencies by simply doing apt-get. I think this is an important >> feature and I don't want to see it go. > > It sounds wrong to use dependencies where dpkg-reconfigure will do. You don't get it (I may have explain badly...). If one installs nova-compute-kvm, he will be expecting it to have kvm installed, and work out of the box. If there was only dpkg-reconfigure, then I would have to actually *remove* the dependencies on kvm, and let our users solve the dependencies manually. I don't want to do that. I think dependencies are important and help our users. I think that integrators who run puppet scripts also don't want things to suddenly change and break their scripts, or have the setup very different in Debian vs other distro. I think it's worth the added 0.016% binaries. Though having dependencies doesn't mean you cannot edit the config file and use nova-compute-kvm to run the XCP flavor of Nova if you apt-get manually the correct dependencies and edit the configuration files. It's weird to do that, I personally wouldn't and I don't see any use case for it. But it seems that it's what you want to do, and I'm just saying that it is possible, if you like to mess with things. >> If we consider that I'm requesting 5 more binary packages, and that we >> have 30 000 packages in Debian, we are talking about 0.016% more binary >> packages in Debian. I can't believe that only for 0.016% more binaries >> is so unbearable for the archive. > > It's pushing the knife ever so slightly deeper into the wound. The > problem, as Russ has pointed out isn't your five extra packages or > somebody else in particular's packages. It's the cumulative weight of > all of them. Yes, in an ideal world this shouldn't be a problem, but > until somebody comes up with a fix, that's what we have to work with. You are missing the hole point of why I was unhappy with the FTP masters to block my package before the OpenStack summit. Since the very beginning, I asked about having my package accepted, then we can discuss later. That unless you still think that adding 0.016% more binary packages *temporarily* until we have an agreement, is adding too much load on the infrastructure in the short term. I still think all these binary packages are needed, but if we could not agree, at least I think it wasn't too much to ask to solve the problem later. Especially when absolutely all the other packages were approved. I'm talking about 48 source packages here, plus many other python module which I updated during the last 6 months release cycle of OpenStack. It is sad that it is impossible to ask for a bit of teamwork, so that we meet some political goals helping Debian adoption. Thomas -- 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/516fb55f.8020...@debian.org
Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
On 04/17/2013 02:49 PM, Tollef Fog Heen wrote: >> For testing, I would understand. But for going on production, it doesn't >> make sense to install things for more than one hypervisor in a single >> system. > > I think it does: I might be interested in running less trusted code in > KVM, since it provides more isolation, and more trusted code in lxc, > which provides less isolation, so running both lxc and kvm at the same > time certainly makes a ton of sense to me. You guys are writing this as if it was impossible to switch from one hypervisor to another. Yet this is simply not the case. You can easily switch from one type of hypervisor to another with the current packages (by editing /etc/nova/nova-compute.conf manually and installing the dependencies manually as well). My point is just that multiple packages make it possible to automate the switch in the config file and dependencies by simply doing apt-get. I think this is an important feature and I don't want to see it go. If we consider that I'm requesting 5 more binary packages, and that we have 30 000 packages in Debian, we are talking about 0.016% more binary packages in Debian. I can't believe that only for 0.016% more binaries is so unbearable for the archive. >> Because otherwise it doesn't work (if I remember well, it took me a full >> month last year to find this out). Or are you pointing out that I could >> ship these files already with the +x bit? Though, if that is your view, >> how much would you rate this seriousness? IMO, not more than wishlist. > > You should ship them with the +x bit already. I'd rate it serious or > important, since you're breaking dpkg-statoverride. Indeed. I never wrote it shouldn't be fixed. Though in my view it shouldn't be a blocker for approving nova 2013.1, first because the bug is already in the older versions of the package, and because nova 2013.1 fixes #700620. I believe it is a lot more annoying than just this dpkg-statoverride thing, which I will not have time to fix until next week when I'm back at home anyway. > (I'd love for Lintian to grow a check for changing permissions of > shipped files so we could get rid of that completely. I don't think it > has it yet.) Agreed. I think I would have spot the remaining hack from last year when I was trying to have OpenStack + XCP work together. Thomas -- 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/516f9425.6000...@debian.org
Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
On 04/16/2013 03:58 AM, Joerg Jaspert wrote: > On 13182 March 1977, Thomas Goirand wrote: > >> Note that the upstream changelog issue was quickly solved (and I agreed >> with the FTP masters view on it), though remains the "problem" of having >> too many binaries, according to the FTP masters. > > Ay. I go into the reasons for that somewhere down below. > >> I decided to leave up to before the OpenStack summit to the FTP masters, >> so that they could approve Nova. With no reply from them, which made me >> miss my dead line, I am left with no other option but to escalate the >> issue. > > Whyever do you set yourself such a deadline, depending on other stuff > you can't control? > > Also, if your goal would be to get the packages accessible for others - > reprepo, dpkg-scan* and co are all not hard to use. I do that already since last autumn. Here's the latest build: deb ftp://archive.gplhost.com/debian grizzly main deb ftp://archive.gplhost.com/debian grizzly-backports main This things uses Jenkins CI: on every git push, packages gets rebuilt and pushed (on a more private URL which I don't advertize about, it only show on the IRC channel). Once I'm satisfied with the packages (after installation tests of all of them), I start a script to publish all packages on the above repositories. This workflow is also very convenient for testing things, and helped me to avoid uploading crap to Debian. So yes, I'm doing that already. Yet I would still prefer to have things in the Debian repositories. > Now, lets go on. > >> Now, I'm seeing that, as this mail went public when it should never have >> been, it's making the situation worse... :( > > Nope. > >> I hope that the original issue can be solved never the less, and that >> the communication with the FTP masters can be restored in a sane way. > > We are always happy with sanity. We don't see it often enough. Thanks. > Now, as we have it here anyways: I stay by what I said. The amount of > splitting you did is nothing that the Debian archive should get. It's > all nice that upstream may like it, but we are talking about Debian, not > Upstream. Not just upstream. Integrators and users as well. They are my priority, just like for everyone in Debian. > 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 of > archive/testing/pts/bugs/whatnot. So we have to decide between an > excessive split and something that makes sense. > > The nova packages consist[1] mostly of one file in /usr/bin with the size > between 1500 and 3000 bytes, or worse - one file in /etc between 45 and > 222 bytes - or even nothing (nova-volume). I am on the side of Russ Allbery here. Ideally, as a developer, I shouldn't have to worry about this, too much, and here is IMHO too much. The infrastructure problems which Debian runs into shouldn't clash with the convenience users either, to the point where Debian would be a very special case with packaging different from other distro, and breaking existing puppet scripts others are already maintaining (for Debian and/or Ubuntu). > Lets pick one set out here. nova-compute-*. Those seem to ship config > files for compute nodes of different types. lxc, kvm, qemu, whatever. > We question two things here: That it is neccessary to split them into > one <100byte file per package ones, and that they all have to conflict > with each other. As you know, a package isn't only made with what files it holds. It also contains precious dependencies. By asking to switch to a single package, you are removing the possibility to have dependencies that make sense. Package: nova-compute-kvm Depends: python-libvirt, libvirt-bin, kvm I don't want to just document this, OpenStack is complicated enough already, adding installation of dependencies as a manual thing matching configuration files or debconf values would be annoying. > The second part is something for a important bugreport > - why do you presume to tell me I might not want qemu and uml, or > qemu/kvm or whatever on one machine? I may not be able to run it at same > time, but why may I not install them? For testing, I would understand. But for going on production, it doesn't make sense to install things for more than one hypervisor in a single system. > Now, lets have one technical point too. Why are you doing a chmod +x > unconditionally in postinst on all the plugin files you just shipped > with the nova-xcp package? And similar in the -network? Because otherwise it doesn't work (if I remember well, it took me a full month last year to find this out). Or are you po
Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
On 04/15/2013 11:07 PM, Ian Jackson wrote: > If you and your collaborators think the conversation with ftpmaster is > essentially over, and want to escalate to the TC I hope it's not, and that the TC thing can be avoided. Thomas -- 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/516c2a2c.2020...@debian.org
Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
On Mon Apr 15 2013 05:13:40 AM PDT, Adam D. Barratt wrote: > On 15.04.2013 12:49, Thomas Goirand wrote: > > The following DDs have already agreed with my view on the mater: > [...] > > - Mehdi Abaakouk > > I may be missing something here, but Mehdi doesn't appear to be a DD > according to db.d.o. > > Regards, > > Adam My bad indeed. Thomas -- 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/1366028419.1884.52.camel@Nokia-N900-42-11
Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
Hi, I have no words to express how stupid I feel right now. The effect of my mail is the exact opposite of what I wanted to achieve. What I wanted to do was reaching the tech committee *members* only (and not the public list) and Lucas, then ask how I could manage the emotional situation. Which is why I wrote about what my feelings were with Ganneff, and how the exchange turned out. I thought I would get valuable advices about how to deal with it. It was never my intention to bring this publicly, and even less to do public accusations. The fact that I wrote this mail while being jet-laged, woken up in the middle of the night by it, is probably linked to writing to the wrong address (eg: a public list, instead of only reaching the CTTE members). It was never my intention to make the communication worse with the FTP Masters, or even harm the Debian project as a whole by opening some ctte bugs which would have been public (we are much better of solving things without it). I wanted to try everything possible before turning back to such extreme ways of solving things. Now, I'm seeing that, as this mail went public when it should never have been, it's making the situation worse... :( I hope that the original issue can be solved never the less, and that the communication with the FTP masters can be restored in a sane way. Finally, I hope that all parties involved will accept my apologies. Thomas -- 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/516c1e97.2080...@debian.org
Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
On 04/15/2013 08:49 PM, Raphael Hertzog wrote: >> As a consequence, I am questioning the motivation behind all this, and > > This is the part where you cross the line that you should not have > crossed. Yeah, publicly, I shouldn't have. Yet, I was trying to ask friends for help, because I could feel some big tensions which was hard to handle alone. To Ganneff, sorry. >> Now, I would like some advice on how to move forward. Leaving this rot >> isn't an option for me. > > If I were in the openstack team, I would personally query ansgar > privately, saying that I'm sorry for the harsh tone that got used and ask > him whether he will approve the packages now that the changelog has been > factorized in the -common package or if there's any other remaining issue > beside the multiple binary package for which multiple persons voiced their > support. I did ask Ansgar on IRC, but got no answer. Though not recently, after others have voiced their support. >> To the ctte: What would be considered a reasonable delay before >> submitting a bug to the ctte? > > It entirely depends on the kind of interactions that you manage to have > with ftpmasters. > > But I would advise you to not bring the issue to the -ctte as long as > communication with ftpmasters is happening and as long as forward progress > is being made. I believe it was stalled, which is why I asked for advices. > I would also suggest you to step down in the communication with ftpmasters > and leave it up to someone else on the Openstack team, someone that is > less emotionnaly engaged than you. That is probably a good advice, though I'm the one who does most of the work and who need to upload. Thomas -- 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/516c144b.6020...@debian.org
Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
On 04/15/2013 08:50 PM, Lucas Nussbaum wrote: > But in that case, couldn't you just use an unofficial repo in the > meantime, or point to a VCS? This has already been done. >> To all of you: what advice can you give to escalate this issue in the >> best way possible? > > Avoiding ad hominem attacks would be a good start. As I just wrote, I wanted to ask for advices to a few people, my message would have been different if I wanted to write to a public list. Again, sorry for this. Thomas -- 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/516c12d4.4060...@debian.org
Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
On 04/15/2013 08:36 PM, Ian Jackson wrote: > I would prefer it > if you stopped throwing around public accusations of ill will unless Hi, This is a *mistake* which I just did. I was intending to send a mail to the ctte memebers, and not to the list. I feel truly sorry for that. I was in fact, trying to ask for advices, precisely to avoid any public laundry washing. :( Please everyone, excuse me for that big mistake. Thomas -- 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/516c125b.2020...@debian.org
FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
Dear ctte, dear (new) DPL, After I had almost all of my packages approved just right before the Openstack summit which starts in few hours now, the FTP masters decided that it was wise to block my Nova package just 5 days before the summit, for a reason which IMO isn't good enough. Please read this thread: http://lists.alioth.debian.org/pipermail/openstack-devel/2013-April/002257.html Note that the upstream changelog issue was quickly solved (and I agreed with the FTP masters view on it), though remains the "problem" of having too many binaries, according to the FTP masters. The following DDs have already agreed with my view on the mater: - Ola Lundqvist - Julien Danjou - Mehdi Abaakouk They are all involved in the packaging of OpenStack and are OpenStack users, and therefore have a good understanding of the project. I decided to leave up to before the OpenStack summit to the FTP masters, so that they could approve Nova. With no reply from them, which made me miss my dead line, I am left with no other option but to escalate the issue. So, before I summit a bug to the ctte and escalate this issue, I would like some advices from both the new DPL and the ctte. I would like first the new DPL to express his view: is this the role of the FTP masters to overrule the technical opinion of a DD? Do they have the rights to block a package just on the ground that they only don't like how many binary packages it contains? Shouldn't they use, like every other DD, the BTS and the project lists to discuss such a technical issue? Note that I am already very upset about what happened because it puts me in a less good position to discuss with Canonical folks about a joined effort for the packaging of OpenStack, here at the summit in Portland. I have expressed this concern publicly on the OpenStack packaging list, and to the FTP master themselves, with absolutely no reaction from them. It seems they don't care, or are willingly ignoring my repeated requests. As a consequence, I am questioning the motivation behind all this, and asking myself if we aren't seeing here (yet) another instance of miss-behavior from Ganneff, who probably disliked the fact that I defended my friend when he expelled him, and when I questioned the possibilities of getting rid of the NEW queue in a debian-devel thread. I have of course no proof to back this up, and will probably never know if this really is an act of revenge, though I would like both the ctte and the DPL to take note of the event as (very) inappropriate. I would also like to point that the tone from Ganneff isn't acceptable. From someone who is both DSA, FTP Master and DAM (why so many powerful roles on a single pair of hands btw?), this isn't to be expected. For the moment, I will just ignore this, but if it was to happen again anytime soon, I will act upon it. Now, I would like some advice on how to move forward. Leaving this rot isn't an option for me. To the ctte: What would be considered a reasonable delay before submitting a bug to the ctte? To the DPL: could the role of the FTP masters be clarified? I have discussed multiple times with other DDs, and it seems that I'm not alone thinking they are doing more than their mandates allows, when rejecting packages on technical grounds (while their role is only validating the licensing part of packages). Is this as well the view of the DPL? Whatever the DPL thinks, could we have somewhere clear roles defined and written on a simple document? To all of you: what advice can you give to escalate this issue in the best way possible? Cheers (from my hotel room in Portland), Thomas Goirand (zigo) P.S: Congrats to Lucas. I'm truly satisfied you are our new DPL, and I feel sorry that the first interaction I have with you as DPL is for bringing this kind of shitty problem. -- 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/516be936.4030...@goirand.fr
