Bug#741573: #741573: Menu Policy and Consensus
Sam Hartman hartm...@debian.org wrote: That seems very unlikely to me. Diversity is an important part of Debian. I think it is likely that the TC is going to value the Debian Menu as long as Bill or someone else is going to work on it. I would expect us to value the menu enough to enable those who want to contribute to it to do so. Given the state menu is in, reading this is… flabbergasting, to say the least. I would answer tons of things, but fortunately they have already been put together concisely: http://islinuxaboutchoice.com/ I think that's consistent with the consensus proposal that you asked us to consider in this bug. The consensus proposal was, in order to preserve some bits of Bill’s ego, to let menu die slowly by stopping to require mandatory entries for a useless menu system that only a handful of obscure window managers are still able to display. Now that Bill has made very clear, by completely giving in to ridicule, that his ego should not be a problem, Charles is merely proposing to accelerate that process and avoid pain for everyone. -- Joss -- 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/1437747652.13194.42.ca...@dsp0698014.postes.calibre.edf.fr
Bug#741573: Two menu systems
Hi, Le lundi 30 juin 2014 à 13:59 -0700, Keith Packard a écrit : One of the arguments that I had heard expressed against supporting applications shipping .desktop files is that it would reduce the number of applications offered in existing menu packages; I'm hoping that my draft addresses this question by demonstrating that the .desktop format offers a proper superset of the information found in menu files, and that package maintainers could mechanically convert their existing menu files into .desktop files without loss of information. One of the problems I have with your proposal, compared to Charles’ original patch, is that it encourages maintainers of hundreds of (IMHO useless) menu files to port them to the desktop format. We don’t need menu entries for bc or python, unless they are NoDisplay=true. This should be obvious, but currently we have trad menu entries for them. The proposed wording for the policy (which is the result of a compromise work between desktop maintainers and policy editors) handles this by stating maintainers must set appropriate NoDisplay/OnlyShowIn/NotShowIn fields, but experience shows maintainers are not cooperative in this matter (hence gross hacks such as gnome-menus-blacklist). I'm afraid that my notion of a transition plan was expressed implicitly in the proposal rather than explicitly. In any case, the transition plan I had in mind was pretty simple: 1. Implement .desktop parsing support in the existing 'menu' package so that packages providing only .desktop files would be incorporated into menu programs without further change. That part of the plan is obvious: replace the current “menu” package by https://wiki.archlinux.org/index.php/Xdg-menu 2. Transition packages from providing menu files to providing .desktop files, deprecating support for the menu file format within the archive over time. [snip] I'd love to see so many programs in my menu that menu program developers are encouraged to figure out how to reasonably select entries in menus so that we can get to some kind of intentional preferential listing mechanism, rather than the ad-hoc selection that we have today. Experience shows it doesn’t work. You can have ad-hoc selection after time (either automatic or manual), but you need something that works out of the box. Three-level nested menus with hundreds of entries are not something to present a new user, regardless of her proficiency. However, I don't think that Policy is a sound place to make user interface design decisions, and that we should naturally defer how to present the provided application set to the menu program developers. I believe this part of Policy should focus on stating what application developers are expected to provide for the menu system, and then let the menu program do 'something sensible' with the provided data. Agreed. [snip] I think this distinction is entirely an artifact of the current split between packages, some of which install only a menu file, and some of which install both menu and .desktop files. I would hope that by encouraging all packages to deliver only .desktop files, we'll see developers thinking about sensible ways to present hundreds of applications to their users. There is a sensible way: not present the useless ones. Use NoDisplay=true everywhere appropriate. I don’t think presenting the whole contents of /usr/bin in a menu is helpful in any way to anyone. Cheers, -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1404164217.14436.476.camel@dsp0698014
Bug#746715: the foreseeable outcome of the TC vote on init systems
Le samedi 03 mai 2014 à 10:31 +0200, Daniel Baumann a écrit : first of all: why haven't you just talked to me? you know more then well that i've kindly and quickly responded to all your bug reports, on and offline. #746715 sounds like shooting with a nuclear weapon on little glitch. Wild guess: because the Technical Committee is being treated as a personal playground by a couple developers. Maybe they should read the Constitution, especially §6.3.6. Ironically enough, this advice applies most to the person who originally wrote it. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1399135724.7081.6.ca...@kagura.malsain.org
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Le jeudi 30 janvier 2014 à 22:43 +0400, Sergey B Kirpichev a écrit : https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv Since you forgot to paste the first sentence, let me add it here. “Sysvinit was never designed to cope with the dynamic/event-based architecture of the current Linux kernel. The only reason why we still use it today is the cost of a migration.” Is this all? Yes, this is all. Anyone who knows how Linux works doesn’t consider sysvinit a viable choice today. There is no need for lengthy argumentations, because there is nothing to argue against. -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1391157525.18551.921.camel@dsp0698014
Bug#727708: TC resolution revised draft
Hi Neil, Le vendredi 31 janvier 2014 à 11:55 +, Neil McGovern a écrit : On Fri, Jan 31, 2014 at 09:33:33AM +0100, Josselin Mouette wrote: Given the Condorcet voting method is susceptible to tactical voting, I'm not sure what you mean here, could you care to elaborate? Wikipedia has a nice description of how tactical voting works: http://en.wikipedia.org/wiki/Tactical_voting#Types_of_tactical_voting In the current example, a voter can rank insincerely her init system choices after #1, in order to give less chances to the one she would have ranked #2 sincerely. With only two realistic options (systemd / upstart), this problem doesn’t exist. But introducing more options on the ballot, it becomes possible to obtain a rigged outcome. The vote being public, it is all the more easier to see how you should rank other options than your preference in order to defeat them all. Cheers, -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1391177210.18551.977.camel@dsp0698014
Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.
Le jeudi 30 janvier 2014 à 21:38 +0400, Sergey B Kirpichev a écrit : [Lots of crap] Where is the list of problems for sysvinit we intend to solve? https://wiki.debian.org/Debate/initsystem/systemd#sysvinit_.2B-_insserv -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1391104022.18551.905.camel@dsp0698014
Bug#727708: multiple init systems - formal resolution proposal
Le mercredi 29 janvier 2014 à 19:03 +0200, Adrian Bunk a écrit : No, you are not. There are several features in systemd that GNOME uses. One of them is user sessions, for which there will indeed be a fallback in place. But it is not the only one. Can you provide a list of features without a fallback in place? At least logind, timedated, hostnamed, localed, the boot control interfaces. With a very widespread level of failure depending on the unavailable interface. Assuming jessie will support multiple init systems, why would GNOME need a dependency on systemd? Because it needs logind. https://lists.debian.org/debian-ctte/2014/01/msg00360.html Would making any init system other than systemd the default for jessie automatically exclude GNOME from being considered as an option for the default desktop in jessie? There are solutions for a non-systemd init. They are technically wrong, but they are realistic (basically it means using logind v204). But there are no realistic solutions for having GNOME support multiple init systems in jessie. Cheers, -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1391017271.18551.799.camel@dsp0698014
Bug#727708: multiple init systems - formal resolution proposal
Le mercredi 29 janvier 2014 à 20:00 +0200, Adrian Bunk a écrit : What *basic functionality* exactly is missing in GNOME 3.10 without logind? Note that I am not referring to bugs that are not yet sorted out like * Switch from consolekit to systemd-logind sessions. For some reason gnome-shell 3.10 unlocking fails with consolekit... 3 months ago in gdm3 - I am referring to basic functionality that is simply missing in GNOME 3.10 without logind. You have the answer to your own question above. Unlocking the screen sounds like pretty basic functionality. Gnome-shell uses GDM for screen locking, and GDM heavily relies on logind nowadays. There is fallback code that uses ConsoleKit, but it has been untested for several major releases, and now fails even for trivial things. Add to that the fact that ConsoleKit itself has been unmaintained for quite some time, making it unsuitable for a new stable release that needs maintenance for several more years -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1391019449.18551.804.camel@dsp0698014
Bug#727708: multiple init systems - formal resolution proposal
Le mercredi 29 janvier 2014 à 20:43 +0200, Adrian Bunk a écrit : You have the answer to your own question above. Unlocking the screen sounds like pretty basic functionality. Your statement was I also have to insist that GNOME 3.10+ *needs* a working logind even for basic functionality My bad. I was under the impression you wanted a serious discussion. Sorry for contributing to the noise, everyone. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1391022321.14103.0.camel@tomoe
Bug#727708: multiple init systems - formal resolution proposal
Le mardi 28 janvier 2014 à 08:16 +0100, Ansgar Burchardt a écrit : Adrian Bunk b...@stusta.de writes: You are forgetting the best technical solution, which is what gnome-session is actually implementing at the moment: session_tracking=systemd (with fallback to ConsoleKit) [1] No. My question isn't about logind, but about using a user systemd session to supervise processes started by the session. IIRC both GNOME and KDE were mentioned to consider this feature. I wouldn’t worry much about such features, at least not for jessie. They will most likely be fallbacks, and in the unlikely case they are at build time, we could always put the two binaries in the same package with dynamic detection, thus working around this requirement. The real problem is logind. The requirement proposed by Ian is not implementable: http://lists.debian.org/1390155797.29928.17.camel@tomoe -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1390899144.18551.661.camel@dsp0698014
Bug#727708: multiple init systems - formal resolution proposal
Le lundi 27 janvier 2014 à 16:59 +, Ian Jackson a écrit : I hereby propose the following resolution: 1. Support for sysvinit is mandatory in jessie. 2. Debian intends to support multiple init systems, for the foreseeable future, and so long as their respective communities and code remain healthy. Nothing outside of an init system's implementation may require a specific init system to be pid 1. Since this resolution would override the will of each maintainer to make his package depend on whatever init system the software depends on, it requires a 3:1 majority according to Constitution §6.1.4. -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1390844134.18551.602.camel@dsp0698014
Bug#727708: multiple init systems - formal resolution proposal
Le lundi 27 janvier 2014 à 17:48 +, Ian Jackson a écrit : Josselin Mouette writes (Bug#727708: multiple init systems - formal resolution proposal): Since this resolution would override the will of each maintainer to make his package depend on whatever init system the software depends on, it requires a 3:1 majority according to Constitution §6.1.4. No, because this is exercising our power to set technical policy, 6.1.1. I will send an updated version. Oh well, you can of course add non-implementable clauses to the policy. But I trust the release team to accept the necessary exceptions for the system to actually work. In which case, if you wish to override them at that point, it will require a 3:1 majority. kthxbye, -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1390845292.18551.610.camel@dsp0698014
Bug#727708: On diversity
Le lundi 20 janvier 2014 à 01:17 +1000, Anthony Towns a écrit : c) logind or an equivalent service implementing the freedesktop.org systemd/logind api should be available under all supported init systems and architectures in Debian. It should be provided via a virtual package fdo-logind and packages (such as desktop managers) expecting logind to be available should Depend on fdo-logind I think this is the right approach for logind. This way, the only implementation would be systemd as PID1, but if the proponents of alternative init systems actually wrote another implementation, it would be available. The one thing that is not handled this way is versioning, because later versions of GNOME could require newer APIs. I also have to insist that GNOME 3.10+ *needs* a working logind even for basic functionality, and that starting with v205, logind *needs* systemd as PID 1. You might disagree with the implementation details that lead to this situation, but you should not expect either of these facts to change before jessie. This is why the idea to fully support more than one init system is never going to hold. * Either we upgrade systemd to a recent version and have (at least) GNOME depend on systemd as PID 1. * Either we keep systemd at version 204, we don’t use it as PID 1 (because it would be madness to be so lagging in versions), we find people willing to do long-term maintenance on the components we use (probably Canonical), and we have this discussion again for the next release when the reverse dependencies require newer versions of systemd. * Either we remove systemd from Debian with all its reverse dependencies (including at least GNOME). Currently I have no idea of how (and by whom) any other option than those three would be implemented, making any decision stating otherwise untenable. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1390155797.29928.17.camel@tomoe
Bug#727708: On diversity
Le vendredi 17 janvier 2014 à 08:47 +, Thorsten Glaser a écrit : Besides what Russ said: Debian isn’t about Linux. Debian is the universal operating system. Just because you don’t understand that sentence doesn’t mean you can use it to justify whatever convoluted position of yours. An operating system is universal if it can be used for all purposes. An operating system that supports several kernels and init systems, but all incompletely, letting the user choose between different ways of failing to boot, is not universal. It is irrelevant to any serious use case. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1389971621.21140.4.camel@tomoe
Bug#727708: Bits from linux.conf.au
Le jeudi 16 janvier 2014 à 08:44 -0700, Bdale Garbee a écrit : I understand your point, but the more I learn about OpenRC the more likely it seems to me that supporting it as an enhancement of sysvinit makes sense as the other init system than just sysvinit alone. This assumes that OpenRC can be fixed to have parallel boot, otherwise this is a big regression from the current insserv setup. If your real point is pick systemd *or* upstart and don't try to assert that we should support both, I can easily agree with that. Amen. -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1389889104.28396.581.camel@dsp0698014
Bug#727708: init system discussion status
Le dimanche 05 janvier 2014 à 01:37 +, Dimitri John Ledkov a écrit : Patching upstream unit files to change paths is trivial, but even better would be to convince upstream to substitute in the proper path when building the unit file. Oh that indeed would be wonderful, why did systemd upstream advocate for hardcoded paths in so many projects then, instead of atleast runtime detected?! How is this suppose to work with 3rd party recompiled packages and e.g. installed in opt? previously just adding opt to PATH, or droppings things into /usr/local/, enabled to use custom compiled ad-hoc replacements as desired by deployments. blah.service.in: ExecStart=@bindir@/blah --no-fork How complicated is that? -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1388929704.12103.2.camel@tomoe
Bug#727708: init system discussion status
Le samedi 04 janvier 2014 à 12:47 +, Ian Jackson a écrit : Uoti Urpala writes (Bug#727708: init system discussion status): Your earlier wording sounds like it was talking about the former (installable) and Ian's proposal definitely was (explicitly mentioning package fields), but the fully working you use now sounds like it's about the latter. Thanks for pointing this out. My proposal is too weak in this respect. I intended to make the stronger statement. I think systemd-ui is part of the systemd init system so falls into the exception. Of course that means that nothing else should depend (functionally or in package dependencies) on it. There is no way that, for example, some of the GNOME control center applets will work at all without systemd. It is already hard enough to imagine that we would have to ship packages without the appropriate dependencies on systemd; expecting them to have the same functional coverage without it is simply insane. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1388850388.8090.3.camel@tomoe
Bug#727708: init system thoughts
Hi Colin, Le mercredi 01 janvier 2014 à 17:17 +, Colin Watson a écrit : Basically, systemd would be more compelling to me if it tried to do less. I don't expect to persuade systemd advocates of this, as I think it amounts to different basic views of the world, but the basic approach here is probably the single biggest factor influencing my position. I'm referring to features that I don't think we'll need, not to logind et al. Could you list the features you don’t think we’ll need in the list from the wiki? * Reliable service management through cgroups * Logging features * Multi-seat * Defense-in-depth security features * Centralized service startup and monitoring * timedated/hostnamed/… * D-Bus API for service control * Transparent virtual environment support * Watchdog * Initramfs support * Introspection and debugging * Configuration-less system * User sessions I’m curious as to what features you consider not relevant for Debian. Thanks, -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1388655231.7783.467.camel@dsp0698014
Bug#727708: init system other points, and conclusion
at version 204, stripped of stuff that doesn’t work with upstart. -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1388660325.7783.763.camel@dsp0698014
Bug#727708: loose ends for init system decision
Le jeudi 02 janvier 2014 à 18:30 +, Ian Jackson a écrit : I would hope that we can standardise on a single API to the system's single cgroup writer. I have already explained why this is not going to happen. The cgroups API in systemd is already part of the core systemd interface and subject to the stability promise. The only other existing implementation (cgmanager) is merely wrapping in D-Bus the existing kernel API, which is going to die when a single writer becomes necessary. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1388691962.3098.3.camel@tomoyo
Bug#727708: init system other points, and conclusion
Le jeudi 02 janvier 2014 à 14:27 -0800, Steve Langasek a écrit : For several years the GNOME Team ignored section 9.7 of Policy, concerning integration with the MIME handling system. They did this in favor of implementing the related freedesktop.org on the grounds that the fd.o standard is technically superior (and less work, since it was already implemented upstream). [snip] What struck me in that discussion is that at no point did the GNOME maintainers raise this issue on debian-devel or debian-policy to ask for help with this integration problem. You forgot to mention that the actual bug at hand affected only a small, although quite vocal, number of users – vocal users with a lot of time to spend on debian-devel (and now debian-ctte) being a recurrent issue in Debian nowadays. The maintainer for mime-support had been aware of the problem for more than three years without any change happening. There was a failure of Debian as a whole to have let this part of the policy rot for such a long time, and I’ll admit to my share of responsibility in letting that happen, but certainly not to the whole of it. I still stand on the opinion that, after such a long time, aggressive removal of legacy MIME files was a right course of action. I'm merely giving voice to a view widely held among Debian developers who would in fact be more than happy to contribute to improving GNOME's integration in Debian, if only they believed this help would be welcomed by the current package maintainers. Vague, unsubstantiated, false claims. Again. I do not recall the members of the team rejecting the help proposed by other contributors, apart from a handful of people who obviously failed to meet the technical standards to contribute to any Debian package. If there are any developers who would be happy to contribute to GNOME packaging but are afraid their help will be refused, any member of the team will be happy to soothe their fears. We have always been inclusive, since, as a former DPL said, “what can’t you undo?” Anyway, I have serious doubts about your allegation that manpower issues are related to the current team members, unless you want to extend this criticism to most core packaging teams. I might have to remind you that the kernel, glibc, KDE, GNOME, Xfce and Xorg maintainers have all repeatedly and publicly stated their lack of contributors and difficulty to handle bug reports. I don't think it's a coincidence that over the past two years, over a quarter of all the issues decided by the TC have related to GNOME packages. “Over a quarter” being three issues, two of them being the same. And let’s not mention some TC member’s behavior regarding the handling of that one, shall we? That's nothing more than hostage taking, especially when there would be no difficulty getting cycles for the integration bugs with GNOME and whatever init system Debian standardized on... *provided that* the GNOME maintainers showed themselves open to this work instead of blocking it. From Joss's reply to my message, it seems altogether too likely that he *would* block such work. This is not what I wrote. I implied that I would not contribute to it in any way. I know this is the point of view of some other members of the Debian GNOME team, but maybe not all of them. You’d have to ask them individually. Given the general tone of your message, I might have to remind you that I am not the GNOME team, especially since I have not been providing much packaging help during the last months. The reason why I’m the one doing most of the talking is that other people have been so disinterested, demotivated, or even disgusted, by the confrontational tone of any public discussion about GNOME, freedesktop or systemd that they don’t even want to talk about it anymore. Therefore, you should not think I am the most likely person to block such changes or abandon the ship while it is sinking. This kind of attitude is making Debian the fun topic to talk about among upstreams, not the major Linux player we should be. Debian as a whole needs to rethink how it can be more friendly to some important upstream projects, or we will simply stop being the “universal” operating system. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1388708242.3098.93.camel@tomoyo
Bug#727708: init system other points, and conclusion
Le mardi 31 décembre 2013 à 18:31 +, Ian Jackson a écrit : Ansgar Burchardt writes (Bug#727708: init system other points, and conclusion): What about the cgroup management functionality that newer versions of logind require? Should the systemd maintainers also reimplement it in upstart? This is a somewhat separate issue, but: I think bundling the single cgroup writer into systemd is a very poor design choice. I think the bad consequences of that choice should be borne by the people who made it. By writing this, it strikes me that you must have seriously misunderstood some fundamental concepts of systemd. The new logind behavior is unrelated to the “single cgroup writer” matter, because there is no single cgroup writer as of today. I spent quite some time to summarize facts on cgroup management at Andreas’ request, and it seems you haven’t even read them. I find this very rude from a member of the technical committee to not try to understand the technical issues before deciding what other people are supposed to do. Which brings me to the other point: you are not going to decide what people want to spend their time on. If systemd is selected as the default, the systemd maintainers are not going to ask Steve to fix their upgrades problem for them. And if upstart is selected, you will certainly not ask members of the systemd community - from which Debian would have just excluded itself - to fix Debian’s problems with not having systemd. For an example I know, if having a working GNOME on Linux means a dependency on systemd, then it will have a dependency on systemd. If the TC overrules that, like it did the last time one of its members felt offended by a dependency in a package he doesn’t use, the alternative will have to be developed and made available by someone. From my discussions so far with other members of the GNOME team, that someone will not be a member of that group. Let’s say that GNOME migrates to systemd user sessions, like what is planned for GNOME 2.12 (yes, the version we intend to ship in jessie, ain’t that sweet). You can decide to cripple GNOME with Ubunbu patches instead, but that won’t be GNOME anymore; just an unbranded Ubuntu desktop. And you will not ask the people who spend their time providing a serious, upstream-friendly alternative to that desktop to spend it on dumping Ubuntu packages in Debian instead. So unless the TC wants to remove a great number of packages from the archive, you need to take into account the fact that some voluntary manpower is required to implement your decision. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1388520832.5187.31.camel@tomoe
Bug#727708: upstart and upgrading from sysvinit scripts
Le mercredi 01 janvier 2014 à 01:54 -0008, cameron a écrit : On Tue, Dec 31, 2013 at 5:56 PM, Josselin Mouette j...@debian.org wrote: I am a bit confused here. You wrote in the upstart position statement, almost at the top: “Upstart supports both bus activation and socket activation.” I actually added that to the statement. I did so because it has legitimate uses, and because it is something that a number of people have expressed interest in using. Thanks for the explanation. That makes the upstart position much more consistent. Apologies to Steve for putting words in his mouth without looking at the wiki history. Now it would be even better if random strangers didn’t modify the position statements to add items that knowingly misrepresent the statement maintainer’s point of view, before barging in the discussion and telling developers what they need to do. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1388542878.6302.32.camel@tomoe
Bug#727708: upstart and upgrading from sysvinit scripts
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 that lazy activation is not the purpose of socket-based activation, and that using socket-based activation does not require you to pay the service startup penalty at the time of first connection. However, this is not borne out by my experiments with systemd on Fedora (which I would presume to be the go-to source for best practices of systemd service activation). On Fedora 20, after enabling the sshd and rsync service+socket units (both installed but disabled by default on Fedora per their policies on running services out-of-the-box) and rebooting, I find that both port 22 and port 873 are bound by pid 1. Only upon connecting to the socket does systemd actually spawn the server (in the case of sshd, it spawns it as 'sshd -i', so has to start up the server anew on each connection; in the case of rsyncd, the .service definition is completely incompatible with socket-based activation and any attempt to connect results in the rsyncd.socket unit landing in a 'failed' state). I’m not sure you can conclude that socket activation is broken from such investigations. It looks to me that: * Fedora deliberately used an inetd-like sshd setup, which is more suitable for a workstation to which you don’t ssh much, but not for a production server. * You found a bug in Fedora’s rsyncd unit files. If you don’t want lazy activation, you just need to add a WantedBy=multi-user.target. This way, sockets will be bound by systemd at the earliest possible time, and passed to the daemon as it is started, but it will be started regardless of an incoming connection. This is described in more detailed in the “systemd for administrators” series: http://0pointer.de/blog/projects/socket-activation2.html -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1388312467.10544.22.camel@tomoyo
Bug#727708: systemd as cgroup writer
Hi Andreas, Le samedi 21 décembre 2013 à 08:48 +0100, Andreas Barth a écrit : 1. Does systemd (or a part of the systemd project) need to be the single cgroup writer and if so, why? It does not… so far. The only thing currently required is for cgroups consumers to adhere to the shared guidelines¹ different projects agreed upon. As of today, there is no impact for us. What is changing is that the kernel cgroups developers want to fix the current mess cgroupfs has become². The identified solution is to only allow one cgroupfs hierarchy to be mounted and to let it be managed only by one process. The future kernel API has not been completely stabilized yet, but that much is clear. If you use systemd, this cgroups arbitrator has to lie in systemd itself. This is because systemd already starts all services as part of cgroups from PID 1. Otherwise, you can use another arbitrator such as cgmanager. Both have chosen the approach to provide the cgroups functionality as a D-Bus API to cgroups consumers (which makes a lot of sense). As I understand the transition plan, it goes this way: 1. Migrate cgroups consumers to a D-Bus API instead of using cgroupfs directly. 2. Stabilize the new kernel API and start providing it in the kernel. 3. On a switch day, the cgroups arbitrator starts mounting cgroupfs with the new API. Consumers still accessing the old API stop working. 4. The old kernel API is deprecated and eventually removed in the distant future. Systemd developers are getting ready to part 3 by working closely with the kernel cgroups developers. It is not clear to me whether cgmanager will be able to do the same: from my discussions with more knowledgeable people, it is merely exposing the current cgroups API in D-Bus calls. This approach cannot work transparently when the API changes. Therefore, we might only have one available cgroups arbitrator in the end: systemd. ① http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups/ ② http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign 2. What problems do arise from there for other parts of the linux ecosystem? These other parts have to migrate to a D-Bus-based interface. The problem is that systemd and cgmanager developers have not been able so far to agree on a common API. The consequences for those cgroups-consuming services are easy to infer. * Some services will only support systemd. * Some will use more complex code in order to support both. * Some will wait until a “standard” emerges and will not work towards the transition. With the systemd API being already available³ and part of the stability promise⁴, the only way this can happen is for cgmanager to start providing a systemd-compatible API, which in turn is unlikely since these are just extensions to the base API controlling systemd itself. Expect Red Hat, Samsung or Intel to provide patches if one of their products includes a relevant package. I think this is already the case for libvirt and LXC. ③ http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ ④ http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1387628136.24917.40.camel@tomoyo
Bug#727708: systemd jessie - jessie+1 upgrade problems
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 systemd-shim package), but because logind 205 has a new dependency on systemd as cgroup manager, which is architecturally incompatible with other consumers of cgroups in the ecosystem. This needs to be resolved before logind v205 can reasonably be adopted, because it's broken by design and needs to be worked around. The new logind is not “broken by design”. Using the cgroups tree is the most correct and secure way to identify which processes are permitted to access specific devices or services. You might disagree with the idea of a single cgroups manager or prefer a less secure mechanism in order to handle corner cases (that have yet to be described), but that doesn’t make the design less correct. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1387491979.21380.15.camel@tomoe
Bug#727708: systemd jessie - jessie+1 upgrade problems
Hi Adrian, Le mercredi 18 décembre 2013 à 13:34 +0200, Adrian Bunk a écrit : That point you bring up is semi-orthogonal to the upgrade decision, but it also brings up two important points that have to be considered: 1. What is the governance model of the systemd community? This might be a bit polemic, but I'd fear that your enough of the rest of the community after having carefully considered our arguments decides might end up being the same as if Lennart decides it does not match his vision of how things should work. This is a red herring that has been recurrently agitated, on the basis of the PulseAudio experience, but so far it has never proven to have any basis in reality. Just because Lennart is a developer in both projects, doesn’t mean they have the same governance model. Systemd’s development is driven by the needs of its users. It has even incorporated a lot of Debian’s needs, despite our choice so far to delay its inclusion. It has used some of Debian’s good practices (e.g. /etc/hostname or /etc/timezone) as a basis for standardization across other distributions. This is a real issue since systemd is attempting to absorb a lot of essential Linux functionality, giving whoever makes the decisions in systemd a lot of power over policies affecting all distributions using systemd. Things work the other way round. Debian will have more weight in the future of systemd if we adopt it. It is unreasonable to ask an upstream project to conform to your policies if you don’t even use it. We need to play with the community: embrace systemd, and use that weight in the decisions affecting its future. Let’s consider the kdbus example in this light. If Debian is a major systemd player, it is more likely that upstream will support a fallback to the old dbus-daemon until a kdbus-enabled kernel makes it to a stable Debian release, or at least makes it easier for us to maintain that fallback. If Debian does not pick systemd, what is the point for upstream in making their software more complex for the benefit of nobody? Maybe it will not work. Maybe the cost for upstream will be too high regardless. I might have to remind you that the sarge→etch upgrade had a locked-in upgrade of udev and the kernel. The world did not crumble, and we didn’t abandon our policies just because we had to make an exception. (Actually this upgrade was much smoother than the python shit in squeeze→wheezy.) We made it work that time, and if, despite our efforts, we have to make another exception, we will make it work again. Leaving out important features until a hypothetical date, just because we fear our own skills and ability to provide smooth upgrades, doesn’t sound like a great plan to me. systemd upstream only reluctantly supports the option to have a separate /usr (as currently mandated by Debian policy), and I would not be surprised if that gets dropped any time if it becomes an obstacle for development of any part of systemd. This is another red herring. The Debian code to support a split /usr by mounting it from the initrd is simple, and not likely to be broken by any new developments. I see much irony in seeing people fear for non-Linux ports, for one of which we have maintained easy patches for years allowing for a merged /usr, and at the same time argue that maintaining a split /usr for Linux will be hard. And now you bring up the point that Debian should reconsider the lenght of it's release cycles if systemd upstream decides to not support upgrades between distribution releases as far apart as Debian's. [3] Well, of course we should reconsider the length of our release cycle (and make it 3 years like major OS players do), but this is irrelevant to the choice of an init system. The more I think about it, the more I wish the TC would decide: * jessie will continue to use sysvinit, and the TC will re-evaluate the situation after the release of jessie This option does not look realistic to me. At least the upstart proponents have outlined a strategy to keep software depending on systemd interfaces working in jessie. Cheers, -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1387369188.8542.119.camel@dsp0698014
Bug#727708: systemd jessie - jessie+1 upgrade problems
Hi, Le mercredi 18 décembre 2013 à 16:26 +0200, Adrian Bunk a écrit : We already seem to agree that the statement in the systemd position statement that does not have any impact on the ability to upgrade systems is not correct. No, we do not. I have already explained why I believe the kdbus question (and maybe similar ones) will arise whether we switch to systemd or not. I do not consider keeping an arbitrary number of packages at the wheezy version an appropriate answer, regardless of the choice of init systems. You also deliberately omitted to quote the part where I explained why this is less likely to happen if we actually become part of the systemd community instead of judging their work on our standards. What exactly is the list of features that are lost as of today if Debian uses in jessie the logind from the systemd 204 package in unstable and perhaps work Ubuntu has done for a non-systemd system? Quoting myself from the debate page: “Many discussions are centered on systemd-logind as in being the only problem to address by other proposals, wildly proposing seemingly easy-to-develop replacements.” If you have other questions relevant for the discussion at hand, please go ahead, but I will not jump into arguments running in circles. We systemd proponents have spent a lot of time summing up the functional reasons why we want systemd on our Debian systems, with logind being one reason among dozens; you could have read them before asking the same question again. -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1387378233.8542.141.camel@dsp0698014
Bug#727708: systemd jessie - jessie+1 upgrade problems
Hi Russ, Le mardi 17 décembre 2013 à 12:26 -0800, Russ Allbery a écrit : Is there actually any implementation other than glib2.0 and libdbus that would be affected by a switch to kdbus? This is an interesting question. Josselin, is GNOME (for example) likely to acquire a hard dependency on kdbus through some mechanism? I don't understand the plumbing of this stuff well enough to know where the dependencies could surface. That doesn’t seem very likely to me. In terms of library API, kdbus doesn’t change anything, so there is no need for applications to depend on it. There could be indirect problems, though. * The session bus daemon will probably be started by systemd (using kdbus) when GNOME migrate to systemd user sessions. The old code should still work for some time, but we might have to hold back some packages, and lose some benefits. * Since kdbus is much faster, applications might start to rely on that and lose performance on systems without kdbus. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1387314190.21380.7.camel@tomoe
Bug#727708: systemd (security) bugs
Le lundi 02 décembre 2013 à 11:22 +, Ian Jackson a écrit : I don't think that's entirely true. I think it is fair to look at the security history of other parts of the same project as indicative regarding code quality. There are two implied assumptions here: * that the same people are developing all components; * that develolpers have the same attention to code quality and security in all components they work on. I don’t think either of them applies to systemd. -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1386002708.24216.1389.camel@dsp0698014
Bug#727708: systemd (security) bugs
Le lundi 02 décembre 2013 à 13:41 -0700, Bdale Garbee a écrit : Josselin Mouette j...@debian.org writes: There are two implied assumptions here: * that the same people are developing all components; * that develolpers have the same attention to code quality and security in all components they work on. I don’t think either of them applies to systemd. Right, this succinctly captures one of my biggest concerns about systemd. Could you please elaborate on this concern? Is it about the large number of developers, or about the fact they treat important pieces of code more carefully? -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1386025428.9475.0.camel@tomoyo
Bug#727708: systemd (security) bugs (was: init system question)
Le vendredi 29 novembre 2013 à 17:55 +0100, Josselin Mouette a écrit : Indeed, systemd has not been written with security in mind. Obviously, such a subjective judgment of valor does not mean the same to me as to other developers. It is easy to quote it out of context and say “oh, look! some systemd advocate said that it is insecure! of course MY init system of choice is more secure!”, but it is merely a fallacy since we are not talking about the same thing. Therefore, I have to retract this statement. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1385801042.26957.30.camel@tomoyo
Bug#727708: systemd (security) bugs (was: init system question)
Le jeudi 28 novembre 2013 à 13:43 +, Ian Jackson a écrit : In summary, I agree with Andrew Kanaber's view that the security and bug history of systemd is worrying. Personally, I find the flow of bugs (including security bugs) for moderately recent software the sign of a healthy project. A simple look at a few packages in the BTS will show that packages with lots of reported bugs are packages with lots of users and features, regardless of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come to mind as being full of bugs, including security bugs. Indeed, systemd has not been written with security in mind. Neither have sysvinit nor upstart, AFAICT. Yes, it would be better if *all* developers had a better grasp of secure programming, but on the other hand, asking the first people to use some advanced kernel interfaces to understand all their security implications is unfair. Just like we don’t hold the Mozilla developers responsible for security issues in brand-new Javascript engines that maybe 10 developers in the world could understand. As Michael mentioned, systemd has a broader scope than alternatives. You’d have to use a system providing similar features as a basis for a fair comparison, and such a system doesn’t really exist in the Unix world. If you only take into account the features that are also provided by upstart or sysvinit/insserv, you won’t find that many of these bugs apply. Compare that to the number of unfixable bugs in sysvinit due to broken design. Cheers, -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1385744139.24216.1151.camel@dsp0698014
Bug#727708: systemd (security) bugs (was: init system question)
Le vendredi 29 novembre 2013 à 17:11 +, Ian Jackson a écrit : Josselin Mouette writes (Bug#727708: systemd (security) bugs (was: init system question)): Personally, I find the flow of bugs (including security bugs) for moderately recent software the sign of a healthy project. A simple look at a few packages in the BTS will show that packages with lots of reported bugs are packages with lots of users and features, regardless of the quality of their code: Linux, X, Iceweasel, GNOME, KDE all come to mind as being full of bugs, including security bugs. All of those components are to a greater or lesser extent optional. Linux is optional? X is optional? Not for everyone. (X is a bad example anyway, because, unlike the rest, it *has* a bad security design.) What we are being asked is to make use of systemd mandatory. It doesn’t mean that all of systemd’s features should be enabled on all machines. The reason why embedded manufacturers are sponsors for systemd’s development is that it means less code, and therefore less bugs (security or not), than alternatives. Indeed, systemd has not been written with security in mind. What an alarming comment on a program which has ultimate privilege, is intended to be universally deployed even in the most demanding security environment, crosses security boundaries (without, IMO, a sufficient justification), and is being touted as the single systemwide manager for security features like cgroups ! Only an extreme minority of Debian packages have been written with security in mind. Not all packages can be OpenSSH or Postfix, and we have to live with that fact, because we need the features in other packages (starting with a kernel and libc). Neither have sysvinit nor upstart, AFAICT. I will leave the upstart maintainers to comment on this in more detail, but sysvinit has had remarkably few security bugs for a program of its vintage. This is because it has very few, and very restricted, interfaces to untrusted parts of the system. And of course, there has never been any buggy init script. Again, your comparison doesn’t make any sense since you don’t compare similar functionality scopes. Just like we don’t hold the Mozilla developers responsible for security issues in brand-new Javascript engines that maybe 10 developers in the world could understand. The security record of web browsers is indeed atrocious. It is the result of a persistent swamp of bad design decisions, hideous overcomplexity, plain bad code, and lack of attention to mitigation measures. Google's efforts in this area are to be applauded, even though I have serious privacy problems with Google. I’m afraid you don’t entirely understand why the security record of web browsers looks atrocious. Because of a swamp of bad decisions *from web developers and designers*, backed by users, browsers have to cover a functional scope that far exceeds in complexity any other kind of software. A typical browser has to include several virtual machines, graphical/layout toolkits, JIT compilers, advanced cryptographic software, all of which have to work with heaps of untrusted data. When taking all of that into account, as much as I hate dealing with them, I have to admit the security record for several browsers is good, and it’s because they *are* developed with security in mind. It is very alarming that web browsers are being presented as the security benchmark for our new init system. It is quite alarming that a member of the Technical Committee demonstrates lacks in security knowledge while at the same time using security bugs as a measure for comparing solutions. This “security” discussion has nothing to do with the case in point, though. If you have specific points you want addressed by the systemd position (like how systemd’s upstream designs user interfaces to avoid security bugs, or handles security alerts), please state them clearly and I will do my best to gather information for you and answer them. -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1385749113.24216.1192.camel@dsp0698014
Bug#727708: init system question before the technical committee
Hi Ian, Le jeudi 31 octobre 2013 à 15:01 +, Ian Jackson a écrit : Perhaps it would be good if the camp leader(s) for each camp would reply with a summary of: - the status of their own main arguments: are you mostly done, or do you expect to add more substantial points - the status of their rebuttals: subject of course, to any future changes by the other camps, how close are you to having what you consider a good answer to the other camps' points ? With some help from the other systemd proponents, I have added today what I consider the final touch for the systemd statement page. It is now mostly finished, including the rebuttals, and should only need new updates for spelling mistakes or minor inaccuracies. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1383393052.3011.5.camel@tomoyo
Bug#727708: Init systems: arguments for the CTTE
Hi, since this is the time to submit arguments before the CTTE can discuss things internally and hopefully reach a decision, I’d like to say a few words. It won’t be a surprise if I say systemd should be the default init systems for the Linux architectures for jessie and, unless another solution arises, the only supported option for jessie+1. I say this as a systems engineer, because systemd is great software. I’m not going to list all systemd features, but there are many of them I want to see on my production servers. In addition, the command-line interface is awesome, and the unit file description is straightforward. I say this as a package maintainer, too. Systemd is becoming a de facto standard in Linux distributions (at least Fedora, SuSE and Arch), and is getting excellent upstream support in many packages. So far, only Gentoo uses OpenRC (and it doesn’t have most of the features I’d like to have), and only Ubuntu uses Upstart. Therefore using OpenRC would mean maintaining many patches on our own, and using Upstart would mean that our upstream would become Ubuntu. As a side note, I think upstart’s CLA dismisses it as software of choice for our core system. I know it’s not the only important piece of software in Debian with a CLA. I still stand on this point. I have experienced a real world CUPS nightmare because of Apple’s CLA, and I would be all for ditching CUPS as default too if we had a decent alternative. Finally, I say this as one of the GNOME packages’ maintainers. GNOME in jessie will need systemd as the init system to work with all its features, just like it needs the network configuration to be handled by NetworkManager. While it is (and can remain) possible, just like in the NM case, to install it without systemd and lose functionality, I think it is unreasonable to ask for a default GNOME installation without it. Some people have argued this functionality can be reimplemented on top of Upstart or OpenRC. These people should be ready to show the code and to commit on maintaining it in the long term before it can be considered as a possible alternative. Finally, a word about kFreeBSD. I know systemd and upstart have not been ported to kFreeBSD (and despite claims that upstart developers would accept patches, so far they don’t exist). However, we are talking about a major feature leap for Linux, and having kFreeBSD interfere in the decision would be unfair to Linux users. My gut feeling is that, despite the original enthusiasm I shared, kFreeBSD was branded a release architecture too soon, or at least for a too broad set of packages. Most packages have never been tested on non-linux, and a large portion of those does not work. A possible approach would be to restrict these architectures to a defined set of packages and maintain OpenRC or insserv scripts for these packages. In all cases, this should be worked on after reaching a decision for the Linux init system. Thanks for reading, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1382953008.10661.63.camel@tomoyo
Re: [CTTE #688772] Dependency of meta-gnome on network-manager
Le lundi 25 février 2013 à 11:43 -0800, Don Armstrong a écrit : 4. We overrule the decision of the meta-gnome maintainers to add a dependency from gnome to network-manager-gnome; this dependency should be removed. If in the opinion of the NM maintainer (and before the release of wheezy the Chair of the Technical Committee or an individual delegated by the Chair in consultation with the Release Team) the concerns raised in §4 of the CTTE decision #681834 have been addressed through technical means (e.g. by preventing the starting of NM as discussed in #688772), the meta-gnome maintainers may freely adjust the dependencies as usual. Can we consider that the changes in NetworkManager 0.9.4.0-9 are OK on this matter? -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1361901393.10692.8.camel@tomoe
Bug#688772: gnome Depends network-manager-gnome
Hi, Le jeudi 25 octobre 2012 à 00:13 +0200, Joerg Jaspert a écrit : On 13009 March 1977, Josselin Mouette wrote: In the current situation, I do not feel bound by any decisions the committee might make. You know, if it really comes to one more CTTE decision around NM and Gnome, which you don't like - the above is a pretty clean resignation from the project. Which would be a shame - but still, directly violating one of our core documents? Seriously? I’m not the one who has violated the Constitution so far. The CTTE, on the other hand, is currently acting in direct violation of Constitution §6.3.6. No discussion was ever attempted after the upload of meta-gnome3 1:3.4+2 which implements the decision for bug#645656. There is consensus among the GNOME team that this is the correct course of action, and no one has requested a decision from the TC apart from Ian himself. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1351156798.3536.403.camel@pi0307572
Re: Problems emailing the pkg-gnome-maintainers list
Hi, for the record, after discussing this with other members of the team, I just lifted Ian’s ban on the pkg-gnome-maintainers mailing list. Please keep in mind that this list is for discussing maintenance of GNOME packages and receiving bug reports, not for trolling the maintainers or insulting their intelligence. Thanks, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1351171030.3536.667.camel@pi0307572
Bug#688772: gnome Depends network-manager-gnome
Le mercredi 24 octobre 2012 à 09:57 +0200, Andreas Barth a écrit : This whole crusade by the ctte is so ridiculous, but unfortunately I can't laugh about that anymore. Where is there a crusade? I don't see any. Maybe you should remove that blindfold of yours? And btw, it doesn't help to replace reason by emotion. Reason has abandoned this discussion long ago. This has always been about people who don’t even use GNOME but who won’t accept the idea that we would install NM on other people’s computers. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1351067906.3536.261.camel@pi0307572
Bug#688772: gnome Depends network-manager-gnome
Let me comment on the proposals again. Le mardi 23 octobre 2012 à 15:16 -0700, Don Armstrong a écrit : 2. Our intent, as stated in the rationale section of our previous decision (#681834, paras 3 and 5), is that squeeze users who have gnome installed but not network-manager do not find that network-manager becomes installed when they upgrade to wheezy. There lies the real disagreement. Our very intent is that squeeze users who have gnome installed but not NM *do* find that NM becomes installed when they upgrade to wheezy. (Actually we should have done that for the lenny→squeeze upgrade but vocal people already won that time.) The fact that it could potentially, in very specific to-be-described cases, break something, should be documented in the release notes. Everything else Ian and you have proposed derives from the fact that you want to force NM out. B 4. We overrule the decision of the meta-gnome maintainers to add a Bdependency from gnome to network-manager-gnome; this dependency Bshould be replaced with a dependecy on network-manager-gnome (= B0.9.4) | wicd. Seriously, WTFF? Is it just a show-off option to make us think it’s better to use a Recommends instead? B 5. Bugs in network-manager-gnome which break the functionality of Bexisting /etc/network/interfaces rules are to be considered RC. Not replacing /e/n/i means that NM will not detect your connection, and as such your desktop will be unusable. If your intent is to generate RC bugs, congratulations, but that will not help with the release. And as for Ian’s hateful prose… 8. We specifically forbid anyone from introducing in wheezy, or in sid until wheezy is released: a. Any new or enhanced dependencies, or any other mechanisms, which increase the likelihood of network-manager being installed; b. Any new or enhanced user-facing warnings, imprecations, or other kinds of message regarding the alleged desirability or requirement to install network-manager; c. Any change which in any way impairs (or further impairs) the functioning of systems with GNOME components installed but without network-manager; d. Any change which is contrary to the spirit or intent of either our previous resolution in #681834 or this resolution. without first obtaining the permission of at least one member of the Technical Committee. Does it really need commenting? 9. It is disappointing that this proposed solution to the problem was not mentioned during the TC discussion. If it had been, it could have been accepted or rejected by the TC at the time. Maybe more communication would have occurred if this discussion had been driven by a reasonable person. 10. We remind everyone that the Constitution requires members of the project not to work against decisions properly made according to the project's governance processes. On this occasion we do not feel it necessary to refer anyone to the Debian Account Managers asking for a review of their status. I still stand on the stance that Ian’s behavior is unacceptable; and proposing this kind of passive-agressive wording in a TC decision is part of the problem. He should step down from the committee or be forced to do so. In the current situation, I do not feel bound by any decisions the committee might make. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1351068709.3536.275.camel@pi0307572
Bug#688772: gnome Depends network-manager-gnome
Le vendredi 12 octobre 2012 à 19:51 +0100, Ian Jackson a écrit : The simpler hypothesis is that there is no reason. I should expand on that, because it makes it sound like I think the gnome maintainerss' behaviour is entirely inexplicable. Don’t worry, it just sounds like yourself. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1350071715.8217.4.camel@tomoe
Bug#688772: gnome Depends network-manager-gnome
Le vendredi 12 octobre 2012 à 21:07 +0200, Stefano Zacchiroli a écrit : For lack of a better synopsis, the argument there is because recommends do not behave properly across upgrades. And also, the purpose of metapackages is to ship dependencies. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1350073354.8217.7.camel@tomoe
Bug#688772: gnome Depends network-manager-gnome
Le vendredi 12 octobre 2012 à 13:06 -0700, Don Armstrong a écrit : Continuing to attack Ian like this is not helpful. Please stop. No, you please stop. You should be glad there is one remaining GNOME maintainer willing to talk about the crusade. Seeing Ian talk his usual crap is a good way to reduce this number further. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1350073704.8217.12.camel@tomoe
Bug#688772: gnome Depends network-manager-gnome
Hi Don, Le vendredi 05 octobre 2012 à 11:36 -0700, Don Armstrong a écrit : On Thu, 27 Sep 2012, Josselin Mouette wrote: Recommends are not enough to ensure that packages are installed, especially upon upgrades. For example regarding NM, we definitely *want* people who upgrade from squeeze to get NM installed. What is still missing is the technical rationale for this desire. If there were specific technical reason(s) why everyone who uses gnome should have NM installed, then it would weigh more for forcing NM to be installed if the gnome meta package was installed. The reason is that GNOME includes NM. Just like it includes gnome-shell or whatever module. It’s not just an upstream decision: GNOME without NM is a stripped down GNOME, with reduced functionality in many modules. We consider GNOME as a tightly integrated environment, with components made to work together. The metapackages are here to install this integrated environment (which, despite that, differs from upstream on other matters), and not just some random set of packages. The code that makes it actually *work* without NM installed was added for kFreeBSD – incidentally, by the same NM maintainer whose work has been repeatedly thrown into mud in the discussions. His intent was certainly not to give people an excuse to cripple down the Linux ports. We do not consider this requirement to be optional on architectures where it can be satisfied. From what I know so far, the primary rationale appears to be that gnome upstream considers NM part of gnome, and so it should be installed. I believe the CTTE addressed this rationale in §2 of the decision. We decided that unacceptable upgrade behavior outweighed this, as outlined in §5 and §6. I disagree with the contents of §5 and §6. The release notes are here precisely for this kind of cases. The reason why NM was only optional is that historically (in lenny and before) it was buggy and wrongly designed; which no longer applies. The resolution also doesn’t mention which problems upgrading from a squeeze system without NM to a wheezy system with NM causes. The cases for potential breakage are rare (if they exist at all), and administrators of systems with complicated network setups have all reasons to read the release notes before upgrading blindly. For these reasons, I consider resolution #681834 to be driven by religious motives rather than technical ones, and that it was conducted in haste. I have not said anything so far because the wording allows (and again, I thought this was intentional) for the compromise to move the dependency to the gnome package. But if people from either side start questioning this compromise, I am afraid they are going to do a lot of harm to the project. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1349478487.11930.30.camel@tomoyo
Bug#688772: gnome Depends network-manager-gnome
Le vendredi 05 octobre 2012 à 16:46 -0700, Don Armstrong a écrit : On Sat, 06 Oct 2012, Josselin Mouette wrote: The code that makes it actually *work* without NM installed was added for kFreeBSD – incidentally, by the same NM maintainer whose work has been repeatedly thrown into mud in the discussions. So, besides the important goal of a complete gnome experience, there's no other technical reason why NM must be installed? Why would there be? The very purpose of metapackages is to define the complete gnome experience. For other packages, dependencies indicate what is required by what. I disagree with the contents of §5 and §6. What in particular about §5 and §6? * The affirmation that this will cause undesirable upgrade behavior is grossly exaggerated. * The reason for the historical Recommends instead of Depends is not mentioned, while this history is used as an excuse for the whole decision. * The claim that NM can be replaced by another component without functionality loss is preposterous. * The excuse of the squeeze→wheezy upgrade serves as a basis for a seemingly irrevocable decision that affects all future versions of GNOME metapackages. It's inflammatory to accuse others of having religious motives.[1] I personally have no interest in punishing, persecuting, or otherwise attacking the gnome maintainers or any other maintainer in Debian, and I would be surprised if all of the other members of the CTTE don't feel the same way. Yet you should wonder why there is such a broad consensus among GNOME maintainers that NM should be a dependency, while most people pursuing the goal of NM removal are not even GNOME users. I don’t think what we do with GNOME affects autopkgtest, curl or hashalot. We all want Debian to be a technically excellent distribution which users want to use, and while we *often* have very different ideas on what that actually means, we have come to those ideas by honest means. Ideally, yes. However I feel obliged to question the honesty of people spreading misinformation before using this misinformation to request CTTE decisions. But if people from either side start questioning this compromise, I am afraid they are going to do a lot of harm to the project. We're all on the same side together. Looking at Ian’s last proposal, I’m afraid not. 8. We specifically forbid anyone from introducing in wheezy, or in sid until wheezy is released: a. Any new or enhanced dependencies, or any other mechanisms, which increase the likelihood of network-manager being installed; b. Any new or enhanced user-facing warnings, imprecations, or other kinds of message regarding the alleged desirability or requirement to install network-manager; c. Any change which in any way impairs (or further impairs) the functioning of systems with GNOME components installed but without network-manager; I’m having a hard time not seeing this as religious, but I’m ready to listen to other explanations. 1: Additionally, the negative connotation is offensive to the many people who are involved in or use Debian who have religious beliefs. People being offended because of their imaginary friend, just like people being offended by at the idea of not developing Debian like System V, are officially Not My Problem™. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1349483553.11930.55.camel@tomoyo
Re: Please do not unblock gnome-meta just yet
Le mardi 25 septembre 2012 à 15:51 +0100, Ian Jackson a écrit : I am going to try to get the TC to pass another resolution specifically overruling this further decision by the gnome-core maintainers. Good luck for your crusade. You might well end up ridding of all GNOME maintainers, that would be a great achievement. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1348587405.30505.37.camel@pi0307572
Abusive and obnoxious behavior
I’ve just read Ian Jackson’s latest proposal: http://lists.debian.org/debian-ctte/2012/09/msg00040.html So it turns out he: * assessed that the CTTE’s decision was not implemented correctly, irregardless of the position of people actually interested by the initial request (Noel David Torres Taño and Adam Borowski); * used his position in the CTTE to immediately suggest a decision without even discussing first, being simultaneously requesting and proposing; * proposed a decision which goes far beyond the CTTE’s power, being completely unrelated to the problem at hand (§6); * proposed to reprimand a developer, which goes far beyond the power of the CTTE; * is being publicly agressive against GNOME maintainers by assuming they act in bad faith, which brings unneeded tensions in the project. I don’t think any of this is acceptable behavior for a DD in a position of responsibility. Therefore, Ian, I suggest that you resign from the Technical Committee. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1348591048.30505.70.camel@pi0307572
Re: Abusive and obnoxious behavior
Le mardi 25 septembre 2012 à 19:28 +0200, Andreas Barth a écrit : * Josselin Mouette (j...@debian.org) [120925 18:37]: I’ve just read Ian Jackson’s latest proposal: [...] If you mean by your subject that the words This should be in compliance with the Crusade. in a changelog and changes file are not acceptable: You are absolutly right. Maybe you could take a deep breath and look back at how this issue was handled, at the sole request of a small group of people, about software they don’t even use, and you might re-consider your opinion on using the word “crusade”. I’m still looking for a better word, but I haven’t found yet. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1348597002.10391.6.camel@tomoe
Bug#681687: missing mime entry
Le jeudi 26 juillet 2012 à 12:50 +0100, Ian Jackson a écrit : 4. We do not disagree with the Release Team's assessment that the failure of the evince package to provide a mime type entry is a release critical bug. Before you vote on that: with the maintainer’s hat, I’d appreciate if the ruling could also make explicit which MIME types it applies to. From what I understand, it is only application/pdf, not the 20 other MIME types that evince can handle, nor their non-standard aliases (like application/x-pdf) which are handled automatically by the XDG system. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1343306381.3540.98.camel@pi0307572
Bug#681687: Bug#658139: Bug#681687: Bug#658139: missing mime entry
Le mercredi 18 juillet 2012 à 16:52 -0700, Russ Allbery a écrit : Michael Biebl bi...@debian.org writes: On 18.07.2012 11:14, Neil McGovern wrote: For info, I do not consider all packages missing a mime file to be RC buggy. I consider #658139 RC. And what is the reason that makes evince special and distinguishes it from other packages which never shipped a mime file or no longer do? It leads to PDF files being opened in Gimp, which you must agree is very surprising behavior. This is a completely unrelated issue. Gimp opening PDFs is a bug in gimp, not a bug in evince. Furthermore, it only happens with the XDG system outside GNOME/KDE, not with the old MIME system, since gimp doesn’t ship a legacy MIME file. I’d appreciate if the release team and CTTE could avoid basing their decisions upon such misinformed claims. Thanks, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1342991716.24016.12.camel@tomoyo
Re: Bug#587956: netbase: Does not cleanup bindv6only upon upgrades
reopen 587956 reassign 587956 tech-ctte thanks Le samedi 03 juillet 2010 à 19:15 +0200, Marco d'Itri a écrit : On Jul 03, Josselin Mouette j...@debian.org wrote: You wanted it to behave in a buggy way, then. That doesn???t make it less a bug. I stand by my position. If you still disagree, feel free to bring the issue to the CTTE. If that’s the only way to get a bug fixed, then so be it. Quick summary for the committee: netbase removed the infamous bindv6only=1 setting in the latest version, but the file remains upon upgrades from affected versions. I do not consider this RC since it doesn’t affect upgrades from lenny nor new installations, but the broken version remained for a long period of time in testing. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Bug#573745: python maintainance: next steps
Le samedi 22 mai 2010 à 10:53 +0200, Andreas Barth a écrit : As already pointed out by Joss in another email, is Matthias being granted with a veto vote? Can he indefinitely veto people willing to join such team even if others are OK with them? If that's the case, we believe this simply won't work and would kill democracy. For the initial setup, I'd like to have only people in the team that are ok by Matthias and are ok by the people who appealed to the tech ctte. If that doesn't work out, we'll have to just decide anyways of course. I’m only speaking for myself here, but I’m not OK with Matthias as part of the core team. I think that's fair for an start. If you really want to start afresh, you should consider pushing your reasoning to the limit: including only people that are OK by both Matthias and the people who appealed. That list includes neither Matthias nor myself. That would be fair. And that would ensure that people would try to think up new solutions out of the box, instead of re-hashing arguments from the past. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you eat pasta without sauce, it is nothing `- short of communism.” -- Marie -- 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/1276586785.11884.12.ca...@meh
Bug#573745: python maintainance: next steps
(Note: this email expresses my personal opinions only, not those of the other proponents.) Le mardi 11 mai 2010 à 23:08 +0200, Andreas Barth a écrit : However, there have been some talks within the tech ctte and with different people inside the Debian python community. That needed time, and we prefer to get to a resolution a bit later than to one that doesn't work. I doubt we can get to a final decision as of now. First of all I’d like to express my sadness to see these discussions, again, having being conducted privately. We have now several years behind us that show this is a bad idea, and the CTTE, asked to resolve this matter, chose to adopt the same technique. The complaints are mostly non-technical. Re the technical parts, e.g. the discussion within Debian about where to store files brought two upstream proposals (PEPs) which would fix some disagreements in an good and forward way. You shouldn’t be too optimistic about the upstream proposal, since it only allows to do a tenth of the needed job. There’s a huge work remaining if we want to drop the symlink farms, starting with dealing with a way to handle which versions are supported by which file. I don't want to loose Matthias contributions to python within Debian and the python community. This is completely irrelevant, unless Matthias threatened to stop contributing unless he can keep setting the rules. But I know the CTTE wouldn’t take such “don’t touch my garden” blackmail into account, of course. In order to be able to get things going within the python community, we should establish a python core team that is trusted by all people involved. Trusted by all people involved definitly includes trusted by Matthias as current python maintainer, and trusted by the people who signed the request to the technical committee (of course, in worst case I'm willing to just decide on the membership of the core team). (There is an obvious conclusion who can't be member of the core team.) So far for now. Comments? It means giving a veto power to Matthias about who can or cannot contribute, while not giving this power to others. Which really, really doesn’t make much difference with a situation where he can decide alone which contributions can go in. I think that practically speaking, it won’t change a thing. Oh, a completely unrelated comment: it looks to me that the Python 2.6 transition is going to delay the squeeze freeze date. Anyone has some pop-corn? -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling -- 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/1273677860.11764.31.ca...@tomoe
Bug#573745: python maintainance: next steps
Le mercredi 12 mai 2010 à 23:28 +0200, Andreas Barth a écrit : I don't want to loose Matthias contributions to python within Debian and the python community. This is completely irrelevant, unless Matthias threatened to stop contributing unless he can keep setting the rules. But I know the CTTE wouldn’t take such “don’t touch my garden” blackmail into account, of course. I would expect that deciding to remove him from being maintainer would demotivate him - at least that would be a natural thing to happen. This line of reasoning is fallacious. I could reverse it and talk about people who are demotivated because they feel the current maintainer is incompetent. How could this help guiding the decision? It means giving a veto power to Matthias about who can or cannot contribute, while not giving this power to others. Eh, where does that proposal give Matthias veto power? If Matthias can refuse someone to be part of the core team because he doesn’t trust that person, that’s a veto power. Cheers, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling -- 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/1273712299.2528.6.ca...@tomoe
Bug#402793: tech-ctte: gst-ffmpeg links with its own private ffmpeg copy
Package: tech-ctte Severity: normal Hi, I kindly ask the Technical Committee to rule on the gstreamer0.10-ffmpeg case. The gstreamer0.10-ffmpeg package includes its own private ffmpeg copy and is built against it. Upstream's rationale is that ffmpeg's API and ABI aren't stable and that they need a frozen version. Linking to another ffmpeg version often requires changes to the code and means the software cannot be as widely tested as the upstream version. However, the multiple copies of ffmpeg in the archive have been responsible for a security nightmare during the sarge stable cycle. The security team has asked to replace all such private copies by dynamic linking to the debian ffmpeg packages. For example, this is holding mplayer out of etch. As I explained in the following thread: http://lists.debian.org/debian-devel/2006/12/msg00138.html linking to this ffmpeg version is not very complicated, and I asked the maintainers to migrate to it before the etch release. I submitted bug #402090 which contains a clean patch that I'm also in the process to make accepted upstream. However the maintainer does not want any such change before the release, and it turned out soon that we would not come to an agreement on this matter. Which is why I'm forwarding this issue to the Technical Committee. Regards, -- Josselin Mouette/\./\ Do you have any more insane proposals for me? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
