Re: Bug#736485: ITP: oslo.rootwrap -- allows fine filtering of shell commands to run as root
On 01/24/2014 08:06 PM, Marco d'Itri wrote: On Jan 24, Thomas Goirand z...@debian.org wrote: Unlike other Oslo deliverables, it should not be used as a Python library, but called as a separate process through the oslo-rootwrap command. Is this really important enough to be part of the package description? Upstream is currently reviewing it's doc, so the long description will change as soon as this is re-written. This is scheduled to happen soon (but maybe after the package is in Sid). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52e35ee3.6060...@debian.org
Bug#736573: ITP: python-rtslib-fb -- object API for managing the Linux LIO kernel target
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-rtslib-fb Version : 2.1.45 Upstream Author : Andy Grover agro...@redhat.com * URL : https://github.com/agrover/rtslib-fb * License : Apache-2.0 Programming Lang: Python Description : object API for managing the Linux LIO kernel target The rtslib-fb package is an object-based Python library for configuring the LIO generic SCSI target, present in 3.x Linux kernel versions. . The rtslib-fb package is a fork of the rtslib code written by RisingTide Systems. The -fb differentiates between the original and this version. Ensure to use either all fb versions of the targetcli components -- targetcli, rtslib, and configshell, or stick with all non-fb versions, since they are no longer strictly compatible. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140125080158.17143.41020.report...@buzig.gplhost.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 11/06/2013 07:00 AM, Paul Tagliamonte wrote: If you want to hold your own system back, there's nothing stoping you (and your rights granted by f/oss software allow you to do so). And there's nothing stopping you from contributing to OpenRC either, if you feel, like me, that it's free of big-corp interest, that supporting non-linux ports is the ethical thing to do, and that OpenRC deserves attention despite some of its problems, and lack of some important features. I don't remember seeing any commits or patch from you ... Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52e41a61.7040...@debian.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 11/06/2013 09:33 PM, Gergely Nagy wrote: Switching to systemd/upstart/OpenRC will not mean the rest will be dropped. Whatever the decision we take, I really wish we deprecate sysv-rc in the favor of OpenRC. It would really make sense, even if systemd or Upstart becomes the default. Also, I would really love to get help on actually making it *easy to switch* from one init system to another, though we aren't there at all. Shutting down daemons cleanly on the first shutdown on all calses, after switching, isn't easy. Contributions welcome! Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52e41efe.6070...@debian.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On 11/06/2013 10:14 PM, Thorsten Glaser wrote: but the propo- nents of systemd, upstart *and* openrc (to a lesser amount) alike *all* want to *not* keep supporting init scripts). Just FYI, here's my view... I'd love to have a patch in OpenRC so that we'd have something like /etc/init.d.openrc that would contains overrides runscripts for sysv-rc scripts in /etc/init.d, so that they would both co-exist (like, if OpenRC sees they have the same name, use the one in /etc/init.d.openrc). However, we don't have such a feature yet. If we never have such a patch available, then yes, I'd be for sysv-rc scripts to die, which can only happen if we impose the support of either Upstart or systemd: in which case init.d scripts could be converted to OpenRC runscripts, because OpenRC would be the only left consumer of them if we decide sysv-rc is deprecated. The later is a likely scenario, but I'd prefer the former. Feel free to contribute! :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52e42110.7090...@debian.org
Re: Two line init.d scripts? Sure, that will work!
On 02/06/2014 05:31 AM, Petter Reinholdtsen wrote: Hi. A few months ago I drafted an idea to rewrite init.d scripts to use a common implementation and only specify the unique parts in the init.d scripts themselves. That draft can be found on URL: http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html . The idea is to let init.d scripts look like this: #!/lib/init/init-d-script ### BEGIN INIT INFO # Provides: daemon # Required-Start:$remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: nice daemon # Description: Provide service to others ### END INIT INFO DAEMON=/usr/sbin/daemond Short and to the point, and in the simple case only list the path to the daemon to start. The code to implement init.d scripts is moved to /lib/init/init-d-script, and the redundant code spread across /etc/init.d/ can be dropped. A few days ago I picked up the idea again, and wrote a more complete draft of the /lib/init/init-d-script. The code is available in the simpler-init-scripts in the sysvinit GIT repository, available from URL: http://anonscm.debian.org/gitweb/?p=collab-maint/sysvinit;a=shortlog;h=refs/heads/simpler-init-scripts . I've tested it on a few packages, and believe the code is ready for wider testing. The main target group for this feature are the majority of packages with init.d scripts, the ones starting a single daemon. There are around 1000 packages in Debian with init.d scripts. Around 100 of them start stuff using rcS.d/, and tend to be quite complex. Most of the rest start a simple daemon and are based on different generations of /etc/init.d/skeleton. The target for this feature is the latter group. The reason I bring this up on debian-devel@ is twofold. First, I want to gather feedback on the idea. Will it work for your package, or are some more hooks needed? Second, I wonder where such script best would belong. My initial idea is to put it in the initscripts package, installed on almost all Debian systems, but I suspect sysvinit-utils is a good place too. I plan to use the system in the initscripts package, and am relucant to add new dependencies to it, as this would make the new dependency a required package. Comments? Well, you've been trying to reimplement OpenRC... with less features! Don't bother, switch to OpenRC, and call it a day... :) Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f3688d.5010...@debian.org
Re: Two line init.d scripts? Sure, that will work!
On 02/06/2014 07:36 AM, Petter Reinholdtsen wrote: [Russ Allbery] It's probably worth mentioning that this is basically the path down which OpenRC went, except that OpenRC has taken the concept somewhat further to allow the dependencies to be specified in code instead of comments (using special shell functions). You may want to take a look at their syntax, since it's extremely close to what you're doing but possibly a bit more fleshed out. Yeah, I discovered that OpenRC had a similar approach, but without staying compatible with our current set of scripts in /etc/init.d/. [1] Sorry... what?!? :) It's perfectly compatible. You just decide what you want to (re-)implement or not. In fact, that's one of the very strong point of OpenRC: it allows a very smooth migration away from sysv-rc, where one can decide what to re-write or not. The two goals I had in mind were to allow us to migrate individual scripts to this system without having to replace sysv-rc, file-rc, or any of the other implementations currently running init.d scripts (ie stay compatible with the current LSB based init.d script format) Since last summer, OpenRC has full support for LSB headers. Also, I believe that OpenRC is the only init system replacement which allows to mix dependencies with LSB or it's own implementation. and reduce the code duplication between init.d scripts. OpenRC can't provide both these, as far as I can see. Look again! :) It solve a lot of other problems for sure. :) Yes. This approach also make it easier to identify the simple init.d scripts, and possibly also make it easier to integrate them with for example systemd and upstart by providing a replacement for the init-d-script script or by extending init-d-script. Unfortunately, it doesn't, because there will be problems with dependencies, as much as I understand. Cheers, Thomas [1] Because there's readers not assuming good faith: no pun intended, just huge surprise to read that... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f369f4.6060...@debian.org
Re: Two line init.d scripts? Sure, that will work!
On 02/06/2014 05:31 AM, Petter Reinholdtsen wrote: Hi. A few months ago I drafted an idea to rewrite init.d scripts to use a common implementation and only specify the unique parts in the init.d scripts themselves. That draft can be found on URL: http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html . The idea is to let init.d scripts look like this: #!/lib/init/init-d-script ### BEGIN INIT INFO # Provides: daemon # Required-Start:$remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: nice daemon # Description: Provide service to others ### END INIT INFO DAEMON=/usr/sbin/daemond By the way, I forgot to mention: the shebang thing replacement was painful in OpenRC, so we recently made it so that we don't need to replace it by /bin/openrc-run (previously called runscripts)... :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f36ae0.9060...@debian.org
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
On 02/06/2014 07:06 PM, Petter Reinholdtsen wrote: Since last summer, OpenRC has full support for LSB headers. Also, I believe that OpenRC is the only init system replacement which allows to mix dependencies with LSB or it's own implementation. That is not the case. Both systemd and upstart allow this as well. I knew that both systemd and upstart can use LSB header scripts. But I read that upstart (at least) would launch these only at the end of the boot process, not mixing them in the boot order with upstart jobs. Can any Upstart specialist (Steve maybe?) can tell if this is right or wrong? What is systemd doing exactly with the LSB dependencies? With OpenRC, what happens is that the LSB headers are transformed into the internal syntax of OpenRC (eg: use, need, after, provide, etc.), which makes it possible to have LSB header scripts be integrated within the ordering calculation, just as if they were native OpenRC runscripts. They are also involved in the dependency loop breaking system that has recently been added to OpenRC. BTW, Debian has a way too many LSB header scripts with Required-Start: $all, which is very bad. A decent init system has to deal with this, and there's no sane way to do so but arbitrarily breaking what the author of the script wrote. A lintian warning telling that $all is just bad would be a very nice thing. How does systemd upstart deal with this pile of garbage that Required-Start: $all is? Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f38ff3.7010...@debian.org
Re: Two line init.d scripts? Sure, that will work!
On 02/06/2014 08:34 PM, Simon McVittie wrote: it'll look rather similar to systemd; and by the time you've sorted out circular dependencies, it'll have about the same level of coupling between components as systemd. Why that? Dependency loops just have to be broken at run time when calculating the boot order, I don't see why this would introduce high coupling between components. Could you explain? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f396ff.7080...@debian.org
Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)
On 02/06/2014 10:59 PM, Sergey B Kirpichev wrote: $all obviously (as you point out) doesn't work well. Semantically, it doesn't make sense to have more than one script depending on $all. What I should use instead? Use case: http://packages.qa.debian.org/m/monit.html Usually, you want to start this service last and stop first. Let's say you want to run monit in Hurd, then it must *not* start last. The last one must always be the hurd console. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f3bdec.8050...@debian.org
Re: Process spervision with Monit support in init systems (was: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!))
On 02/07/2014 03:58 AM, Tollef Fog Heen wrote: ]] Sergey B Kirpichev Are you trying to sell me yet another init or do you suggest some alternative solution *with* Debian's sysvinit, not using Should-Start/Stop: $all? If the first, please stop. If the second - please go ahead. No. I'm pointing out why $all doesn't do what you want. «$all» means «after everything else has started» and if you have two of those, you have a loop. Loops are bugs. In your particular case (and sysvinit), I'd say the admin should just add dependencies on the monit script for the monitored services since I don't think sysvinit support dynamically generating those dependencies on boot. (If it does, I'm sure somebody will chime in with how to do it for sysvinit.) With systemd, I'd say a generator that adds After+Wants: $monitored_services would be the right (and better) solution (this would also solve the shutdown problem). I assume upstart has a reasonable way to solve this, but I'm not familiar with what it should be. The only viable solution is to integrate monit support inside the init system, like what's currently happening in OpenRC: http://qnikst.github.io/posts/2013-11-06-openrc-supervision.html with patch available here: https://github.com/qnikst/openrc/compare/s-vision Note that it is on my todo list to evaluate this patch, but I didn't have the time to do that work yet. Any contribution would be welcome from anyone willing to test it, and see if it integrates well with the current OpenRC package. Note that this has verry little to do with *process* supervision, like it would be done with s6 (http://skarnet.org/software/s6/) which is also on the OpenRC upstream todo list. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f44bac.70...@debian.org
Re: The meaning of $all in init.d scripts dependencies (Was: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!))
On 02/07/2014 05:22 PM, Petter Reinholdtsen wrote: And according to Thomas, OpenRC assume scripts depending on $all also depend on other scripts depending on $all, conclude there is a loop and try to break the loop at some random point in the perceived loop. That is correct, however, the way it is done currently, it does approximately what one would expect in Debian! :) Anyway, that's not a clean implementation. So, thanks a lot for this definition matching sysv-rc. So this may lead to newer code. The author of lsb2rcconf (eg: Dmitry Yu Okunev) will work on it. What will be done is scanning all LSB header scripts for $all, and fix the conversion to the OpenRC internal format (at least that's what he wrote on IRC). Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f4b801.7010...@debian.org
Bug#738151: ITP: python-hplefthandclient -- HP LeftHand/StoreVirtual HTTP REST Client
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-hplefthandclient Version : 1.0.1 Upstream Author : Kurt Martin kurt.f.mar...@hp.com * URL : https://pypi.python.org/pypi/hplefthandclient * License : Apache-2.0 Programming Lang: Python Description : HP LeftHand/StoreVirtual HTTP REST Client This is a Client library that can talk to the HP LeftHand/StoreVirtual Storage array. The HP LeftHand storage array has a REST web service interface. . This client library implements a simple interface to talk with that REST interface using the python httplib2 http library. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140208061359.6486.10657.report...@buzig.gplhost.com
Bug#738160: ITP: python-savannaclient -- Client for OpenStack Hadoop cluster as a Service
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-savannaclient Version : 0.4.1 Upstream Author : OpenStack Development Mailing List openstack-...@lists.openstack.org * URL : https://github.com/openstack/python-savannaclient * License : Apache-2.0 Programming Lang: Python Description : Client for OpenStack Hadoop cluster as a Service Savanna project aims to provide users with simple means to provision a Hadoop cluster at OpenStack by specifying several parameters like Hadoop version, cluster topology, nodes hardware details and a few more. . This package contains the command line client and the clien Python module. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140208083337.23787.81278.report...@buzig.gplhost.com
Bug#738325: ITP: python-pyvmomi -- VMware vSphere Python SDK
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-pyvmomi Version : 5.5.0 Upstream Author : Parth Gala parthg...@gmail.com * URL : https://github.com/vmware/pyvmomi * License : Apache-2.0 Programming Lang: Python Description : VMware vSphere Python SDK pyVmomi is a Python SDK for the VMware vSphere API that allows you to manipulate ESX, ESXi, and vCenter using scripts. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140209072052.26968.82825.report...@buzig.gplhost.com
Bug#738328: ITP: python-seamicroclient -- Client library for Seamicro chassis API
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-seamicroclient Version : 0.1.0 Upstream Author : Rohan Kanade rohan.kan...@izeltech.com * URL : https://github.com/seamicro/python-seamicroclient * License : Apache-2.0 Programming Lang: Python Description : Client library for Seamicro chassis API Python client for consuming SeaMicro REST API v2.0 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140209081934.5093.79981.report...@buzig.gplhost.com
init.d script not using !/bin/sh
Hi, While we can discuss during literally *years* about which init system to use, I think it's more productive to try to improve what we have in packages, so I'd like to talk about that. One thing that bothers me is that some of our sysv-rc init.d scripts aren't using /bin/sh as interpreter. For example, on my laptop, the only one that I have is MySQL. Then after fixing the shebang and running checkbashism, I can only see: possible bashism in /etc/init.d/mysql line 86 (echo -e): echo -e $ps_alive processes alive and '$MYADMIN ping' resulted in\n$ping_output\n | $ERR_LOGGER -p daemon.debug That's it... So that's a typical case where it should be possible to fix things, and get rid of bash. If possible, I'd like to make a survey of what kind of interpreter packages are using for /etc/init.d scripts. How can I do that? Note that this would make OpenRC maintainer's life more easy, and avoid ugly hacks. Is it too late to fix this as a release goal, so that we get every init script to use /bin/sh? Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f77f29.1080...@debian.org
Re: init.d script not using !/bin/sh
On 02/09/2014 11:22 PM, Clint Byrum wrote: Excerpts from Thomas Goirand's message of 2014-02-09 05:14:17 -0800: Hi, While we can discuss during literally *years* about which init system to use, I think it's more productive to try to improve what we have in packages, so I'd like to talk about that. One thing that bothers me is that some of our sysv-rc init.d scripts aren't using /bin/sh as interpreter. For example, on my laptop, the only one that I have is MySQL. Then after fixing the shebang and running checkbashism, I can only see: possible bashism in /etc/init.d/mysql line 86 (echo -e): echo -e $ps_alive processes alive and '$MYADMIN ping' resulted in\n$ping_output\n | $ERR_LOGGER -p daemon.debug That's it... So that's a typical case where it should be possible to fix things, and get rid of bash. Is that really an important goal to spend our time on? IMO, it all depends on how much non-sh scripts we have to fix. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f7b8bb.50...@debian.org
Bug#738511: ITP: python-trollius -- port of the Tulip project on Python 2.7
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-trollius Version : 0.1.4 Upstream Author : Guido van Rossum gu...@python.org * URL : https://bitbucket.org/enovance/trollius/ * License : Apache-2.0 Programming Lang: Python Description : port of the Tulip project on Python 2.7 Trollius is a portage of the Tulip project (asyncio module, PEP 3156) on Python 2. Trollius works on Python 2.6-3.4. It has been tested on Windows, Linux, Mac OS X, FreeBSD and OpenIndiana. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140210053559.29619.57679.report...@buzig.gplhost.com
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 12:33 AM, Sam Hocevar wrote: On Mon, Feb 10, 2014, Craig Bransworth wrote: Fuck systemd from the bottom of my heart. Fuck it. Fuck it. FUCK SYSTEMD. I do not want to learn systemd. I do not want to deal with systemd. I hate the way it does things. I hate the way their community works. Hi Craig. And thank you for your interest in Debian and its init system. Have you heard of the OpenBSD project? (http://openbsd.org/) It's a free, functional and secure operating system. It looks exactly like the kind of project you'd enjoy, because it does not use systemd or upstart. It also has a friendly and very open community that I'm sure you'd find welcoming. Kind regards, Excuse me, but this reply isn't appropriate, just as much as the OP. Redirecting him to another Unix distribution isn't the thing to do. Instead, you should have informed the OP that we will continue to support not only systemd, upstart, or whichever becomes the default. Because that's the plan. And nobody will force anyone to use the default settings, just like nobody is forced to use the default desktop. Even after one of the init systems is declared as default for Jessie, we will welcome testers for the *other* init systems, just like we do for any other package in Debian (file-rc anyone? :)). Also, I wouldn't be against some help with OpenRC packaging. There's lots of Debian specific patches that are hard to test on each platforms (kFreeBSD is, if I'm not mistaking, broken by the last upload). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f90ac0.6080...@debian.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 02:41 AM, John Paul Adrian Glaubitz wrote: On 02/10/2014 06:47 PM, Clint Byrum wrote: It is pretty ridiculous to me to consider the basic plumbing on the system as replaceable as the thing that decides where on the screen my shortcut to Google search for lolcatz goes. I fully agree on that and other DDs already mentioned that in the ITP for OpenRC as well. Most users won't actually be able to tell what kind of init system they want, they just want a reliable, fast and secure solution. That's what should be kept in mind when making that decision. It's like being able to customize internal parts of your cars engine when ordering one from your dealer. Customers don't care who the manufacturer of your ignition system is as long it's the best possible one. (Yes, I know comparisons with cars are bad ;)). That's partly not truth. Some customers care, and do customization of their car. Neglecting reliability and maintainability for the sake of being able to choose such a core component is a bad idea. I do not think it's really feasible to maintain several init systems, it just affects too many components of the system. It's just up to the volunteers, which was my message. If some of us car, it's going to be possible. If there's not enough interest, then you are right. We don't even manage to maintain two versions of ffmpeg (the original and the fork) even though many users actually prefer the original. How should this even work with the init system then? Maybe no DD cares enough for ffmpeg? On 02/11/2014 04:10 AM, John Paul Adrian Glaubitz wrote: Again, I do not understand how our users will actually profit from being able to choose their init system. It doesn't mater, we don't force our thinking on you. Nor it's a good idea that you try to convince everyone that they should adopt *your* choice. I believe there's been enough discussion so that you will agree not everyone shares your view on systemd. I don't see it as a problem anymore. Can you imagine this being an option in Debian Installer just like you can configure your time zone or filesystems? What would you write to the description texts of the different choices? Ubuntu users have a choice of installer: the Debian one and the standard Ubuntu one. I don't use the standard Ubuntu installer, though I have no pb with others using it. It's crazy just to think about it. I don't see any craziness, it's just like all of Debian: volunteer based, and depending on everyone's motivation and involvement. Do we allow users to choose their FireWire stack, WiFi or Audio Driver stack in the kernel? There were several alternative implementations of these, yet we only provide one of each. I don't see why we would explicitly forbid this choice (which has nothing to do with what we provide by default). Last time I checked, it was possible for our users to rebuild their own kernel. We even provide some userland tools for that. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f9a514.6020...@debian.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 12:53 PM, Clint Byrum wrote: Excerpts from Thomas Goirand's message of 2014-02-10 20:20:36 -0800: On 02/11/2014 04:10 AM, John Paul Adrian Glaubitz wrote: Do we allow users to choose their FireWire stack, WiFi or Audio Driver stack in the kernel? There were several alternative implementations of these, yet we only provide one of each. I don't see why we would explicitly forbid this choice (which has nothing to do with what we provide by default). Last time I checked, it was possible for our users to rebuild their own kernel. We even provide some userland tools for that. In the case of init system choice, having choice means having packages that work poorly with the non-default init system. Nobody wants to forbid OpenRC or Upstart. Having all four working init systems is a lot like having kFreeBSD and Hurd. However, the reason we can have kFreeBSD is basically POSIX. Some things don't work, but the majority of things do work. There is a long standing set of rules that things play by for the most part, and when they diverge, that is a choice they make. By and large these init systems work nothing like eachother. So having lots of them, means having lots of variation in init scripts, or having a lowest common denominator init format which AFAIK does not exist and would not achieve anything a switch away from sysvinit is intended to solve. So, perhaps if we teach Upstart and OpenRC to read systemd unit files, and they all can be expected to behave similarly, this will work out. Otherwise, giving everyone a choice just makes work for little gain. You are talking as if we were starting from zero. Reality: all of our packages support both sysv-rc and OpenRC. We only have to maintain that, which is anyway important for our non-linux ports, and none of us have a crystal ball to predict how it will happen. I don't think it's a good idea to just give-up, or to spread the word that we should (give-up) before things even happen. The situation with upstart or systemd, if not chosen as default, will be quite different, since not all packages are supporting them directly right now. One of these 2 will suffer from the choice of default init system. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f9d91e.8040...@debian.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 03:09 AM, Vitaliy Filippov wrote: Excuse me, but this reply isn't appropriate, just as much as the OP. Redirecting him to another Unix distribution isn't the thing to do. Instead, you should have informed the OP that we will continue to support not only systemd, upstart, or whichever becomes the default. Because that's the plan. And nobody will force anyone to use the default settings, just like nobody is forced to use the default desktop. It seems that in case of systemd it may end being forced, doesn't Gnome 3 depend on it? We have between 40 and 50 window managers in Debian. Nobody forces you to use Gnome. How about switching to TWM! :) I have another idea - maybe systemd could be split in parts in Debian? I think it would fix some objections. This has been discussed at large already. It would. But neither upstream nor the Debian package maintainers wish to have (or wish to do the work so that) systemd (is) split into relevant independent parts. This is a shame, because that's the most controversial issue, but that's a a view which can be defended: they believe in the current design, where each component is used by another. I.e. for example, systemd-journal looks like the most bloated part of systemd to me, with its binary log format, QR codes and built-in HTTP server - so maybe it could be disabled via a patch? Or even packaged separately so you can choose whether to install it? Is anyone familiar with systemd code - does it look possible and/or simple task to you? As much as I understood, systemd-journal is the part which is the most optional, and which you can avoid completely currently. Problem is: we have no idea how long this is going to be truth (as it happened with logind and other components). I don't think it is reasonable to expect Debian systemd maintainers will do the work of separating each components to make them independent. They haven't stated that this is what they want to do. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52f9dbb1.7000...@debian.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 04:31 PM, Clint Byrum wrote: One point of moving to a system like upstart or systemd is that the sysvinit scripts do not run as scripts. They are little tiny declarative files that run all or most in C. This speeds up boot, but only makes sense if all of the early stage boot things make use of it. Leaving most things to just use the sysvinit compatibility layer means not realizing one of the more important benefits of the default init system if it should in fact turn out to be systemd. I agree with the above. So at best you're talking about maintaining two for every daemon. That is still roughly twice the maintenance work and twice the testing. Yes, that's my proposal, and as well deprecate sysv-rc in the favor of OpenRC, and allow OpenRC runscript files *only* if there's support for the default init system (because this way the default init system will not use them, so the runscript format is possible). Yes, testing and maintenance will be double the amount of work, which is why I wrote that it will all depend on contributions. I didn't write support for it would be mandatory, but on best effort basis, which I think is fair. Also, that will enable support for our non-linux ports. Not saying I like it, but that is where choice hurts Debian. Perhaps having the choice will also help Debian enough to make it worthwhile. That's what I believe, yes. On 02/11/2014 05:03 PM, Andrei POPESCU wrote: According to Russ Allbery, it's easier to maintain both systemd and upstart declarations than one sysv init script. s/sysv init/sysv-rc/ --- Please don't do this mistake, it's really sysv-rc that uses the init scripts, and OpenRC, which has a declarative format, still uses sysvinit. Anyway, to some degree, I agree with Russ here, which is why I think we should replace sysv-rc by OpenRC completely at some point (which is when we have stabilized support for *all* arch, which isn't the case right now, latest Hurd patches broke support for kFreeBSD). On 02/11/2014 05:31 PM, John Paul Adrian Glaubitz wrote: On 02/11/2014 09:02 AM, Thomas Goirand wrote: The situation with upstart or systemd, if not chosen as default, will be quite different, since not all packages are supporting them directly right now. One of these 2 will suffer from the choice of default init system. What? That's not true. As people have explained here before - even directly to you - both Upstart and systemd have perfect backwards compatibility with sysvinit scripts. You missed one very important word: *directly*. Probably I should have write *natively*. Sorry for this. On 02/11/2014 05:27 PM, John Paul Adrian Glaubitz wrote: No, it's absolutely not. You can have the choice for the interior design, the paint job, the radio, the type of engine and comfort features, but you certainly cannot have the choice on internal parts like the ignition system or starter motor. Furthermore, if you do decide to replace these parts on your own, you will end up losing your car manufacturer's warranty. The car analogy can only go so far... My point was saying that people do customize things, and do it. That's a way more the case with computers than with cars. On 02/11/2014 05:27 PM, John Paul Adrian Glaubitz wrote: And since there are virtually no volunteers for OpenRC besides you and the other two OpenRC maintainers, Roger and Benda, it will be unsupported at some point when you guys step down. That's truth for every bit of Debian, however, package gets orphaned, adopted, etc. Please don't through this type of argument, especially when we have co-maintainers already. On 02/11/2014 05:27 PM, John Paul Adrian Glaubitz wrote: I have seen you asking for help on OpenRC so many times during these discussion, but I am yet to see people raise their hands and say Yes Thomas, I am going to help you! Yet, it happened. Not in this list though... On 02/11/2014 05:27 PM, John Paul Adrian Glaubitz wrote: All I read are statements from you like Yes, it would work in general if we had someone to implement it, I don't have the time right now unfortunately. Please read the debian/changelog of OpenRC in Experimental, and measure the work that has been done so far. I don't think this counts for nothing, and I really see progress. Hurd kFreeBSD support, and lsb2rcconf comes to mind. Plus this doesn't include all what has been done before the package entered Debian. It's not *my* choice, systemd is the choice of the majority of the Linux community. OpenRC and upstart are used in Gentoo and Ubuntu only (ChromeOS doesn't really count in that context, it's a more or less closed system by Google), while virtually every other of the large distributions has adopted systemd. Using something which is not widely adopted and has very few supporters in the development community means that if any of the OpenRC or Upstart people will decide to retire, these systems will lose much more development manpower than systemd does
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/11/2014 07:23 PM, Olav Vitters wrote: IMO (and I'm an interested part / GNOME dude, so no say): blocking progress is bad. So if someone wants to add OpenRC scripts to packages and maintenance is low: as packager you should be allowing that to happen. As long as the time required on packagers part is minimal. Only by not blocking progress things can move to working nicely. But that also means that it really falls under the task of people interested in something different to make such change happen. At the moment there is too much blocking progress going on IMO Yes, I agree with what's above. On 02/11/2014 08:13 PM, John Paul Adrian Glaubitz wrote: Yes, but we are not talking about hypothetical things. I am also not planning my life for the case that I am winning the lottery tomorrow. Chances to win the lottery are 1 against 14 000 000 (at least in my country). Claiming this kind of odds for supporting OpenRC is IMO an overstatement, especially considering that we have LSB header scripts for *all* of our packages right now. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fa49b2.5020...@debian.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/12/2014 03:01 AM, John Paul Adrian Glaubitz wrote: Why not stop here with OpenRC and call it day? You cannot always win in life :). Short version: Why don't you just call it a day, and let me work on what I wish? What is your problem with me working on it??? Longer version: Part of why I work on OpenRC is because I find it fun, when I'm tired of doing the OpenStack packaging (which is maybe 75% made of very repetitive Python module packaging) and need recreation with my computer. And doing so, I believe it's producing something useful, and which seems to gather some interest (which is very hard to evaluate how much), which is enough to motivate me. That you don't believe in the technology is a well established point, and we all got it. Nobody needs another occurrence of this. And the fact that you don't find this work useful will not change *ANYTHING* to this Adrian. Even with all what you wrote, you didn't succeed in destroying the fun I have hacking OpenRC. This is the first instance I see in Debian of someone trying to convince another person to *not* work on something. Please give up trying to convince me not to do what I do, I'm a grown up, and I can decide for myself. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb6350.8080...@debian.org
Re: OpenRC
On 02/12/2014 04:10 AM, Simon McVittie wrote: Wasn't there some plan to have OpenRC look for its runscripts in a parallel directory alongside init.d as well as in init.d itself, and treat /etc/openrc-init.d/foo (or whatever) as a replacement for /etc/init.d/foo? Then you could just say OpenRC runscripts go in /etc/openrc-init.d, LSB-style init scripts[1] go in /etc/init.d and everything Just Works. This is currently just an idea, but it's not implemented (and nobody has yet stated intention to start implementing this). I honestly believe it wouldn't be more than a few lines of C code (it doesn't seem hard to change a loading path, right? hum... I'm sure it will be different when looking at the actual code! :)), so it doesn't have my focus right away now. If you're keen on using OpenRC, I would strongly recommend that approach. systemd ignores /etc/init.d/foo if it finds a corresponding foo.service in its own directory, and that feature has made it easy to add systemd units (.service files) per-package without needing much special coordination. Upstart doesn't do that (/etc/init.d/foo has to be patched to not do anything if it detects that init is Upstart and /etc/init/foo.conf exists) which has given it much more complicated Policy implications. If LSB-style init scripts disappear completely after jessie, OpenRC runscripts could in principle move to /etc/init.d at that point, although I don't really see much benefit in that. S [1] i.e. the ones that work equally well (or equally badly, depending on your point of view) with sysv-rc, file-rc, insserv, Upstart, systemd, OpenRC etc. Probably you are right and I should review my priorities! :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb6480.8020...@debian.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/12/2014 01:27 AM, John Paul Adrian Glaubitz wrote: Don't get me wrong, I really appreciate what you and the other maintainers are working on. But I think that it's not leading anywhere. That's entirely your view, and it's fine if you have it. Though *we got your point* Adrian, no need to insist more. It's perfectly fine if we do not agree. The only advantage I have with OpenRC is its portability IMO, it's not, though I believe it is useless to discuss it with you. This very sentence is the proof of that. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb6dcb.5020...@debian.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/12/2014 09:31 PM, John Paul Adrian Glaubitz wrote: On 02/12/2014 01:49 PM, Thomas Goirand wrote: On 02/12/2014 01:27 AM, John Paul Adrian Glaubitz wrote: Don't get me wrong, I really appreciate what you and the other maintainers are working on. But I think that it's not leading anywhere. That's entirely your view, and it's fine if you have it. Though *we got your point* Adrian, no need to insist more. It's perfectly fine if we do not agree. Dude, it was you who has been constantly posting on that topic, not me. Look at the debian-ctte archives. You're - again - behaving as if you're somewhat more important than I am. Don't be so derogative and arrogant, it's utterly annoying. Especially when you say WE as if you're talking for everyone else. If you ask me to shut up about this discussion, then you yourself should do it as well. Don't be such an hypocrite. The only advantage I have with OpenRC is its portability IMO, it's not, though I believe it is useless to discuss it with you. This very sentence is the proof of that. Please, Thomas, just stop discussing this topic and I will do so as well. Please, for the sake of peace, ACCEPT that the TC has made their choice and the choice was NOT OpenRC. From where exactly did you made up that I didn't accept the TC decision? I wrote already to some of them that I did accept it *before* they did it (whatever the decision was). Please stop making-up... Ian Jackson was clear enough, and his input was valuable. I do not regret I asked. And don't take this as the message to stop working on what you like, but as the message that the TC has made a decision and you should stop questioning it. We seriously need to move on! Again, I don't want to discuss this anymore. Adrian On 02/12/2014 09:16 PM, John Paul Adrian Glaubitz wrote: Good. At least you're being honest now. To sum up what Adrian wrote, according to him, I'm: - derogative - arrogant - utterly annoying - hypocrite - and finally, I wasn't honest before Well done... ! Anything else? Adrian, your insults aren't welcome in this list. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fb86b7.9030...@debian.org
Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.
On 02/12/2014 11:01 PM, John Paul Adrian Glaubitz wrote: Again, are you the listmaster or DPL or what? I thought you were smarter and would understand you went too far and should stop. Though if the only way to stop your insults is to go to the DPL or the listmaster, I believe I wont even have to do it myself (I don't think I should anyway, since I'm involved): someone else will be upset by your wording in a public Debian list and will report you. yet you claim those are insults. You will have a hard time convincing anyone that saying that someone is derogative, arrogant, utterly annoying, hypocrite and dishonest is not insulting. Your problem is that you can't accept defeat. I have *no problem* with it, or anything else. I don't think I have lost anything, or that there's even a defeat. The above sentence is very silly, because it paints a very wrong picture of what happened. I accepted OpenRC wouldn't be taken as default even before it happened. If you think that's what I wrote, then you miss-interpreted. https://lists.debian.org/debian-ctte/2014/01/msg00340.html What lead me to write was that: - bdale wrote to me that he didn't evaluate OpenRC - Russ wrote wrong statements on public list or blogs (I can't remember which one it was, I believe it was his blog) - Don stated he didn't spent much time with it or something similar So, because this was a repeated pattern, I posted that message. I asked for the TC to properly evaluate OpenRC, and explain why it wouldn't be the choice. I was very pleased by Ian Jackson's technical response, which helps us for our (future) development. I don't see anything wrong in that, and I believe what I asked for was legitimate. Also, please count how often you posted to debian-ctte and how often I posted to debian-ctte. I tried to not post too much in this bug, and let the TC do its work. I posted 10 messages to #727708, out of which 5 were talking about the current status of OpenRC, which I believe was appreciated by the TC (at least bdale seemed happy of these messages). In these messages, I wasn't talking about anything else. I have counted around 43 messages from Josselin Mouette, why don't you complain about him posting too much? (note: I took Joss as a random example, and I have no problem with him posting on the TC bug...) Besides this, I'm the person behind the proposal of OpenRC, and there was some direct inquiries, so I don't think 10 messages is a lot. You can also see that Russ seemed happy about the corrections I contributed to his statements, since he didn't evaluate OpenRC properly either (at least at the beginning, not sure later on). Bdale also seemed pleased with the reported status about Hurd support and so on. Gosh, why do I even have to justify myself... This is crazy. Adrian, look at the posts from Olav Didier. I think they are representative of the fact that your personal attacks toward me, leading to what I wrote above, is of very little interest to anyone. Yet, if you are again repeating the same pattern, your next move will be: coming back after your insults, posting some more (why not, since the listmasters accepted the previous ones?), then more critics of what I do or did which will include wrong statement and reality distortion, and then writing hey, I already wrote that we should stop... it's not me who don't want to stop. That's not the way you get to a more relaxed atmosphere. Pushing me to justify myself on my behavior isn't the way to go either. If you are sending direct attacks publicly, don't you think it's to be expected that I reply to public accusations? I'm not asking you to stop discussing here, even about the init system. I've asked you to stop your insult and direct attacks toward me in public lists. This leads to nowhere, and annoys everyone. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fc69e6.2000...@debian.org
Re: systemd2init PoC
On 02/14/2014 07:01 PM, Ondřej Surý wrote: Hey all, I have hacked together a PoC systemd2init shell script on top of augeas-tools (you need at least jessie version) to autogenerate sysv-rc script out of simple service file. It can handle: Environment EnvironmentFile ExecStart ExecReload PidFile Description Right now you need to put the service file to: debian/lib/systemd/system/name.service and run systemd2init.sh name and it should generate debian/name.init.dh It's really a proof of concept, but since we have libconfig-augeas-perl available in the archive, I guess it can be rewritten into dh_systemd_init with little effort (if you don't hate perl) and included in dh-systemd package. The git repository is located at ssh://git.debian.org/git/collab-maint/systemd2init.git, feel free to update, rewrite, etc. O. That's cool. I certainly will have a look into it. What about exploring Ian Jackson's idea, which was to hack a debhelper that would generate things for multiple init systems? Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52fe2a10.3080...@debian.org
Re: pulseaudio related problems....
On 02/17/2014 02:52 PM, Andreas Tille wrote: Hi, On Sat, Feb 15, 2014 at 09:05:42PM +0100, John Paul Adrian Glaubitz wrote: I'll agree with that. Audio really should just work unless the hardware configuration is particularly strange. +1 +1 So, if your computer has several sounds cards - which is the case when you have both a sound card and HDMI audio - how is PulseAudio supposed to know which sound card to use? This is in no way different to plain ALSA. I have no idea whether this remark is helpful but this thread inspired me to give pulseaudio another chance on one of my boxes (I had deinstalled previously on all boxes where sound stoped working at some point in time randomly). Despite I gave pavucontrol and pasystray a try to configure pulseaudio my box remained silent (in *any* control I tried). It seems as long as there is no button saying please give me any sound this is not helpful.s My trouble might be connected to my choice to use xfce and perhaps it is wrong to blame pulseaudio exclusively. I know that I should go to some user list to ask for help and do not expect it here. I just want to confirm that there is some problem with pulseaudio even if you try to configure it and my personal way to deal with this is to kick pulseaudio again. Kind regards Andreas. I do use pulse myself, and I have learnd how to go around its issues, and kind of like pulse. However, the fact that multiple DDs, which I do consider all as computer experts, failed to have a working setup, can only lead to the conclusion that there's something wrong which has to be fixed, especially if it comes by default with Debian. If DDs can't go around the issues and just feel that it's not worth spending more time, imagine with someone that isn't a computer expert... I'm also convinced that it should be possible to have a working default pulse setup. Emitting sound on all available sound output by default, and making sure that the level isn't zero upon install, seems like a sensible thing to do. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5301b5a5.7050...@debian.org
Re: pulseaudio related problems....
On 02/17/2014 03:57 PM, John Paul Adrian Glaubitz wrote: Exactly what I have been thinking all the time. And I find the argument all DDs are computer experts, so if they can't get it working it must be broken a particularly bad one. No, that's not what I wrote. I wrote that it's too complicated for the average user, and that in some situations, it doesn't work out of the box. Not that it's broken: I do believe pulse can work (it works for me, and I'm reasonably happy with it, so...). Your tendency to rewrite things that I write in a wrong way is annoying. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/530220f0.2060...@debian.org
Re: pulseaudio related problems....
On 02/17/2014 04:02 PM, John Paul Adrian Glaubitz wrote: Well. You can't blame PulseAudio if you have an .asoundrc in your home directory which configures your sound card incorrectly. Oh !!! Now I do remember why my pulseaudio system works. It's because I followed to the letter this howto: http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PerfectSetup/ Well, having a look at it, it seems it changed quite a bit. But that's what I followed. The question is: why don't we have this by default in Debian? Why would it be up to the user to configure each and every software to use the correct audio stack? IMO, it'd be great if we had consistency. I hope this helps, Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/53022416.5020...@debian.org
Re: pulseaudio related problems....
On 02/17/2014 11:03 PM, John Paul Adrian Glaubitz wrote: I don't see how I am rewriting things in a wrong way. Do you want to argue about the exact meaning of broken now? Indeed, words are important. For me, when I read broken it means bugs upstream, and I'm convince the problem is configuration, which is a completely different thing. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5302380e.4030...@debian.org
Re: default init on non-Linux platforms
On 02/18/2014 10:15 PM, Ondřej Surý wrote: Hi, I don't really want to open another can of worms, but what's the opinion of non-Linux ports maintainers on default init? Or maybe I should turn it another way: If we have working OpenRC on kFreeBSD and GNU Hurd, can I do: Depends: systemd | openrc if I want to get rid of non-declarative init scripts in my daemon packages? O. I'd like to widen this topic. We're not there yet (I still need to do some more tests with Hurd, and fix a few problems), but I will soon upload OpenRC to Sid. Once I consider OpenRC ready for it, would it be ok to just replace sysv-rc by OpenRC, and transform sysv-rc into a transitional package? What is the opinion of other DDs? Is there anyone which would like to keep the old featureless sysv-rc? Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/53037464.4030...@debian.org
Re: default init on non-Linux platforms
On 02/18/2014 11:08 PM, Guus Sliepen wrote: On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote: On 02/18/2014 10:15 PM, Ondřej Surý wrote: [...] If we have working OpenRC on kFreeBSD and GNU Hurd, can I do: Depends: systemd | openrc if I want to get rid of non-declarative init scripts in my daemon packages? [...] Once I consider OpenRC ready for it, would it be ok to just replace sysv-rc by OpenRC, and transform sysv-rc into a transitional package? What is the opinion of other DDs? Is there anyone which would like to keep the old featureless sysv-rc? My opinion is that maintainers should still provide sysv init scripts until it is decided that Debian does not support sysvinit any more. The TC decided that systemd will be the default init system on Linux, not that it would be the only init system. Dropping support for sysv init scripts now means that you are burning the bridge before you finished crossing it. You are IMO missing the point. I'm not proposing to drop support for init scripts, but remove sysv-rc. That's very different! We could continue to have init scripts but have OpenRC to use them. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5303831c.4020...@debian.org
Re: default init on non-Linux platforms
On 02/18/2014 11:38 PM, Didier 'OdyX' Raboud wrote: Le mardi, 18 février 2014, 22.55:32 Thomas Goirand a écrit : Once I consider OpenRC ready for it, would it be ok to just replace sysv-rc by OpenRC, and transform sysv-rc into a transitional package? What is the opinion of other DDs? Is there anyone which would like to keep the old featureless sysv-rc? I think we should focus on one init system change at a time. Having the good-old sysvinit setup still working in a satisfactory manner is nice while preparing Jessie: that's what Wheezy has and therefore has to be supported to upgrade to Jessie (think partial upgrades, full-upgrade-not-rebooted-yet, etc etc). When testing crazy stuff with systemd, I know I can always fallback to sysvinit if I broke any .socket or .service unit I'm working on. It will be slower and feel old, but would most certainly boot and provide me with comfortable ways to debug. If that was changed to OpenRC, we'd exchange the sysvinit safety net that all got to know in exchange for a brand new safety net that we don't really know yet. Moving to OpenRC as the secondary init for Jessie looks like changing the two wheels of a bike at the same time. I'd widely prefer to keep sysvinit (as old it might feel) for Jessie, especially as transition point from Wheezy and have these discussions again after Jessie is released. That shouldn't stop you from providing the best OpenRC integration in Debian, be it for the ports or in preparation for jessie+1. Cheers, OdyX Didier, what you are saying above make sense, I haven't really thought about a timeline though. If everyone agrees to have Jessie+1 as a target for sysv-rc deprecation, that's fine to me. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/53038a6e.3010...@debian.org
Re: default init on non-Linux platforms
On 02/18/2014 11:10 PM, Jonathan Dowland wrote: On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote: Once I consider OpenRC ready for it, would it be ok to just replace sysv-rc by OpenRC, and transform sysv-rc into a transitional package? What is the opinion of other DDs? Is there anyone which would like to keep the old featureless sysv-rc? What problem does that solve? In this way, we'd have only 2 init systems to take care of, and we could start replacing init.d scripts by OpenRC runscripts *IF* there's a systemd service file. Otherwise, we have to keep init.d scripts just in case someone is running sysv-rc. So keeping sysv-rc would block progress and force anyone to keep writing/maintaining init.d LSB header scripts. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/530390a7.1050...@debian.org
Re: default init on non-Linux platforms
On 02/18/2014 11:38 PM, Didier 'OdyX' Raboud wrote: Le mardi, 18 février 2014, 22.55:32 Thomas Goirand a écrit : Once I consider OpenRC ready for it, would it be ok to just replace sysv-rc by OpenRC, and transform sysv-rc into a transitional package? What is the opinion of other DDs? Is there anyone which would like to keep the old featureless sysv-rc? I think we should focus on one init system change at a time. Having the good-old sysvinit setup still working in a satisfactory manner is nice while preparing Jessie: that's what Wheezy has and therefore has to be supported to upgrade to Jessie (think partial upgrades, full-upgrade-not-rebooted-yet, etc etc). When testing crazy stuff with systemd, I know I can always fallback to sysvinit if I broke any .socket or .service unit I'm working on. It will be slower and feel old, but would most certainly boot and provide me with comfortable ways to debug. If that was changed to OpenRC, we'd exchange the sysvinit safety net that all got to know in exchange for a brand new safety net that we don't really know yet. Moving to OpenRC as the secondary init for Jessie looks like changing the two wheels of a bike at the same time. I'd widely prefer to keep sysvinit (as old it might feel) for Jessie, especially as transition point from Wheezy and have these discussions again after Jessie is released. That shouldn't stop you from providing the best OpenRC integration in Debian, be it for the ports or in preparation for jessie+1. Cheers, OdyX Actually, thinking about it a 2nd time, I think there would be a major drawback in delaying to Jessie +1. If we decide that sysv-rc goes away, then starting at the Jessie release, we don't have to care anymore about LSB header scripts. Meaning that we could write systemd service files, plus OpenRC runscripts (for those who cares about OpenRC, or our non-linux ports). If we delay it, this means that we'd have to keep maintaining LSB header scripts in Sid for all the life of Jessie (for those who cares about non-linux ports or having OpenRC / sysv-rc support). Thoughts anyone? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/53039439.4060...@debian.org
Re: default init on non-Linux platforms
Hi, I'm replying to everyone in a single mail, I hope that's fine. I'm therefore a bit repeating myself, sorry for that. On 02/19/2014 02:18 AM, Didier 'OdyX' Raboud wrote: Le mercredi, 19 février 2014, 00.56:07 Thomas Goirand a écrit : On 02/18/2014 11:10 PM, Jonathan Dowland wrote: On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote: Once I consider OpenRC ready for it, would it be ok to just replace sysv-rc by OpenRC, and transform sysv-rc into a transitional package? What is the opinion of other DDs? Is there anyone which would like to keep the old featureless sysv-rc? What problem does that solve? In this way, we'd have only 2 init systems to take care of, and we could start replacing init.d scripts by OpenRC runscripts *IF* there's a systemd service file. Yes. And three different daemon-starting syntaxes to manage the Wheezy- to-Jessie upgrades. Again, for Jessie, I don't think it's reasonable to change the default init _and_ replace the common baseline. I, for one, am not going to replace my awkward-but-working sysvinit scripts by anything but systemd/upstart unit files and that is doomed to happen in jessie+1 [0]. I agree. My idea is that we shouldn't change any init.d script in the favor of OpenRC before sysv-rc is deprecated by one of the new stable release. [0] Can we haz a release name? It's been years that I've been asking that we have the release name a way sooner. Ideally, one release earlier, so that we can prepare for the new name soon enough (and not fix things during the freeze). But the release team doesn't seem to agree with this! :) On 02/19/2014 01:33 AM, Gergely Nagy wrote: From a maintainer PoV, I already maintain sysvinit scripts for wheezy, and upstream, they will have to be maintained for the forseeable future anyway, so maintaining it for Jessie is exactly zero work on my part. Adding OpenRC to the mix (something I'm not familiar with, and I'm not really interested in getting to know better, either) is an extra burden I wouldn't want to do myself. Then great, because I am not proposing to change any init.d script right now, at least not before OpenRC officially replaces sysv-rc. And OpenRC is fully compatible with init.d scripts, transforming them into runscript is optional, and IMO, not something we should do before sysv-rc is gone. I wouldn't say no to a patch adding an OpenRC runscript, of course, but I'd rather not do it myself. Thanks! On 02/19/2014 02:12 AM, Didier 'OdyX' Raboud wrote: Le mercredi, 19 février 2014, 01.11:21 Thomas Goirand a écrit : Actually, thinking about it a 2nd time, I think there would be a major drawback in delaying to Jessie +1. If we decide that sysv-rc goes away, then starting at the Jessie release, we don't have to care anymore about LSB header scripts. Meaning that we could write systemd service files, plus OpenRC runscripts (for those who cares about OpenRC, or our non-linux ports). If we delay it, this means that we'd have to keep maintaining LSB header scripts in Sid for all the life of Jessie (for those who cares about non-linux ports or having OpenRC / sysv-rc support). I don't think that's true. If we decide that sysvinit scripts (hence LSB headers) have to be supported in jessie but are deprecated, then jessie+1 can start to drop them completely (given reasonable replacement for non-init defaults of course). Dropping them in the jessie suite would complicate the upgrade path from Wheezy for no reason that I would value high enough. One of us is not understanding the other here. I believe this should be because I don't express myself well enough (this wouldn't be the first time...). So I'll try once more: I thing we should *not* replace any LSB header init.d scripts before Jessie, and make them mandatory for the release. At the same time, I think we should replace sysv-rc by OpenRC for Jessie [1]. This way, after the release, we'd be sure there wouldn't be any sysv-rc setup out there, and replacing LSB headers would be possible (and recommended). On 02/19/2014 06:07 AM, Adam Borowski wrote: Idea: someone is working on a service-runscript interpreter, for a subset of common functionality. If that tool could have a validator that returns ok if there's no unsupported stanza, what about running that validator in lintian and screaming if validation fails but there is no runscript? This way, there'd be three kinds of packages: * LSB only * service that's palatable for OpenRC * service + runscript This would greatly simplify preparing for deprecation of sysv-rc. Hopefully somewhere to the tune of 90-95% packages having just one daemon definition. Such a reduction of work could make dropping sysv-rc in jessie viable. I think this could be a good idea to have such a tool. I see 3 ways to implement it. 1/ A userland tool to generate stuff once in the debian folder: this would mean, *not* a debhelper script, but really something that the maintainer
Bug#739481: ITP: python-zake -- provides a set of testing utilities for the kazoo library
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-zake Version : 0.0.14 Upstream Author : Joshua Harlow harlo...@yahoo-inc.com * URL : https://github.com/yahoo/Zake * License : Apache-2.0 Programming Lang: Python Description : provides a set of testing utilities for the kazoo library Zake is a python package that works to provide a nice set of testing utilities for the kazoo library. . It includes the following functionality: * Storage access (for viewing what was saved/created). * Kazoo *mostly* compatible client API. * Sync/transaction/create/get/delete... commands. * Listener support. * And more... . It simplifies testing by providing a client that has a similar API as the kazoo client so that your tests (or applications/libraries that use kazoo) do not require a real zookeeper server to be tested with (since this is not available in all testing environments). Note: This package is needed by the latest release of python-taskflow, which is one of the new key libraries of OpenStack. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140219074309.79244.77925.report...@buzig.gplhost.com
Re: default init on non-Linux platforms
On 02/19/2014 10:44 PM, Michael Biebl wrote: I'd like to add that switching to openrc breaks the SysV/LSB support in systemd. Openrc doesn't use the /etc/rc?.d/ directories to create the symlinks which signal if a service is active for a given runlevel. (those symlinks are created in /etc/runlevel/* afaics) This means systemd doesn't consider the SysV/LSB init script as enabled and won't start it on boot. Oh, that's interesting! First, yes, OpenRC uses /etc/runlevel, with the folders below that being the *names* of the runlevel (which IMO is a way more user friendly than just numbers). FYI, we have: shutdown=0, recovery=1, reboot=6, and everything-else=default. So we do have these 4 directory names, and OpenRC doesn't care about /etc/rc?.d. Could you expand the above text and give a bit more explanations / details? :) So, systemd is still using /etc/rc?.d. Could you tell exactly what it uses out of /etc/rc?.d, and what for? Does it only needs to see them as S??script-name in runlevel 2 or 4 (or whatever it uses...)? If systemd needs links in /etc/rcX.d, then I think it should be possible to hack something. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5304c91a.1090...@debian.org
Re: default init on non-Linux platforms
On 02/19/2014 10:47 PM, Michael Biebl wrote: Am 19.02.2014 00:52, schrieb Russ Allbery: Henrique de Moraes Holschuh h...@debian.org writes: They *HAVE* to be provided by the active init system. They are an impedance matching layer (aka stable API) used by maintainer scripts to interface with the active init system. If you look at the existing implementation, you'll find that the version provided by sysv-rc already supports systemd, upstart, and sysv-rc itself. So this isn't precisely true. If we stick with the current model, then some (probably essential) package just needs to provide those implementations and accept patches to work with new init systems, but each init system doesn't need to provide its own version. There are some advantages to providing only one version with knowledge of all of the init systems given that we're supporting init system switching, and therefore may need to set up state for init systems that aren't currently running so that switching can work properly. A good example is registering an init script with insserv so that the correct S and K links are created even if the system is currently booted with a different init system. If you look at e.g. update-rc.d enable|disable, it currently has support for systemd, upstart and sysv-rc. So whenever you enable a service, this state is kept in sync across the different init systems (assuming the service in question ships native support for other init systems). I don't find equivalent functionality in openrc's implementation of update-rc.d How come? I just took what was in the sysinit package! Or probably, what you are talking about is new features, which I should merge it back into the OpenRC version? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5304e46b.8050...@debian.org
Re: default init on non-Linux platforms
On 02/19/2014 11:53 PM, Simon McVittie wrote: I suspect the right thing would be to share one implementation of update-rc.d(8), invoke-rc.d(8) and possibly service(8) between all supported init implementations, provided by either src:sysvinit or src:init-system-helpers. Surprisingly, service is shared among all init systems (it's in sysvinit-utils), while the other 2 are not. I agree we should have a common interface and make sure one daemon remains enabled / disabled in all init systems. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5304e53b.9050...@debian.org
Re: default init on non-Linux platforms
On 02/20/2014 02:10 AM, Kevin Chadwick wrote: Do people use all those runlevels? As much as I know, there's only 4 in use (using names of OpenRC here, since OpenRC has named runlevels): - shutdown (runlevel 0) - recovery (runlevel 1) - reboot (runlevel 6) - default (often, everything else, but most of the time, it's runlevel 2 or 4) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5305efed.4020...@debian.org
Re: default init on non-Linux platforms
On 02/20/2014 09:02 PM, Tom H wrote: What features does sysvinit+openrc have that sysvinit+sysv-rc+insserv doesn't have? Just to name a few: - getting rid of the ugly LSB headers - cgroup supports to kill processes - rc_hotplug (a hotplugged service is one started by a dynamic dev manager when a matching hardware device is found). - Checks if a daemon is really started by start-stop-daemon - Dependency loop breaking system - Named runlevels (I already talked about that) - Stateful system (see rc-status) - Dependency caching system (so you wont have to wait for its calculation at next boot) - ... (that's from top of my head, I may have forget some...) And of course: - minimalistic declarative runscripts, instead of huge init.d scripts. A quick example that I wrote myself is available here: http://thomas.goirand.fr/blog/?p=147 You may find more examples inside the source code of openrc (in the Debian source package for example), under init.d.misc. Interestingly, in it you may see that simple things are very simple, but it's also possible to make complex runscripts when needed (yes, the hard reality, sometimes means that complex things are needed at boot time). What's coming: - monit integration in runscripts (so you can have monit to restart crashed services, and send emails when they do). We already have patches available for it, so it's taking a good shape. - s6 (or equivalent) process monitoring. This is still under discussion upstream. There's some goodies which are more Gentoo oriented, like their network integration, but I don't think it's worth mentioning as I don't think these features would be useful for Debian, unless someone works on adapting them (for example, to read /etc/network/interfaces instead of whatever Gentoo uses). Also, we have an ALIVE UPSTREAM TEAM, and an evolving project, which is IMO important (is there anyone still working on sysv-rc apart from a few Debian maintainers? my understanding is: we're alone now...). Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/53061128.1080...@debian.org
Re: default init on non-Linux platforms
On 02/20/2014 10:45 PM, Didier 'OdyX' Raboud wrote:
Le jeudi, 20 février 2014, 22.28:56 Thomas Goirand a écrit :
On 02/20/2014 09:02 PM, Tom H wrote:
What features does sysvinit+openrc have that
sysvinit+sysv-rc+insserv doesn't have?
Just to name a few:
- getting rid of the ugly LSB headers
They might be ugly, but they encode the dependency tree; by what are
they replaced in OpenRC?
There's of course dependencies in OpenRC. You have the choice: either
you keep the LSB headers, either you write it the OpenRC way (IMO,
prefered...). In OpenRC, you just use functions of the openrc-run
interpreter. For exaample:
depend()
{
use dns
need localmount
after bootmisc ntp-client
}
The need expresses a Required-Start:, and use, a Should-Start:.
- cgroup supports to kill processes
On non-Linux ports ?
cgroup are optional, and obvious, not in use in kFreeBSD (see
/etc/rc.conf for its activation).
On 02/20/2014 10:52 PM, Ansgar Burchardt wrote:
I'm curious: does OpenRC allow processes to leave the cgroup? For
example, when killing the ssh service, I do not want to kill active
connections. With systemd, pam_systemd takes care of this. How does it
work on OpenRC?
Sorry, I don't know. You can try if you're curious! :)
On 02/20/2014 10:52 PM, Ansgar Burchardt wrote:
Doesn't it still use the (unmaintained?) sysvinit? But then, that's
only a part that probably doesn't need much maintainance anyway.
Correct, and I agree. The /sbin/init binary is anyway very small. As
much as I can tell, it is built only out of src/init.c and src/utmp.c,
which together represent 3162 lines of C code currently. That's antic
code from 1991! :)
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53062fb1.3000...@debian.org
Re: default init on non-Linux platforms
On 02/23/2014 07:32 PM, Jonathan Dowland wrote: On 21 Feb 2014, at 12:22, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de wrote: I agree and understand that this was the way to go back in the old days, but we shouldn't be using that on current setups. But you aren't planning on running openrc at all, are you? No, he's just planning on more pointless critics. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5309ed56.1060...@debian.org
Re: default init on non-Linux platforms
On 02/23/2014 07:36 PM, Marco d'Itri wrote: On Feb 23, Jonathan Dowland j...@debian.org wrote: But you aren't planning on running openrc at all, are you? Who is? Seriously, would you mind stepping forward? http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrcshow_installed=onwant_legend=onwant_ticks=onfrom_date=2014-01-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1 What I see here is an handful of people wasting the time of a lot of other people to further their own pet project. http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysv-rcshow_installed=onwant_legend=onwant_ticks=onfrom_date=2014-01-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1 sysv-rc wins... With useless stats, we can say useless things. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5309ee85.4090...@debian.org
Re: default init on non-Linux platforms
On 02/23/2014 08:57 PM, John Paul Adrian Glaubitz wrote: On Sun, Feb 23, 2014 at 08:50:13PM +0800, Thomas Goirand wrote: http://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysv-rcshow_installed=onwant_legend=onwant_ticks=onfrom_date=2014-01-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1 sysv-rc wins... With useless stats, we can say useless things. Two things: - virtually everyone installs systemd in parallel, not by installing systemd-sysv as this means you don't have an easy way of going back to System V Init in case you shoot yourself into the foot; you just install the package and point your init to the systemd binary - System V Init is the current default, of course it's installed on virtually all systems http://qa.debian.org/popcon-graph.php?packages=systemd+upstart+openrcshow_installed=onwant_legend=onwant_ticks=onfrom_date=2014-01-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1 Those are the proper stats to be used and you clearly see the trend. And like your pet project - OpenRC - my pet project - the m68k port - isn't very popular either: http://popcon.debian.org/stat/submission.png And I am not complaining that we're not making it a stable release, simply because it's pointless with a documented user base of 9. Adrian Marco and yourself are *a way* off topic. Please at least have the decency to rename the subject of the tread to systemd fanboys flamewar yet-again bashing OpenRC just for fun or something similar (but preferably: don't just do that in this list, and avoid replying about anything related to OpenRC, since we all know what type of non-productive content it's going to be). On 02/23/2014 09:04 PM, John Paul Adrian Glaubitz wrote: Well. OpenRC was up for discussion as the default init, wasn't it? Yes, *was*. Now, move on, we're not discussing this anymore. If you didn't notice the subject of this thread, it is: default init on non-Linux platforms On 02/23/2014 09:06 PM, John Paul Adrian Glaubitz wrote: I'm out, the weather is too nice :). Exactly: you have better things to do. So please stay out (of this thread and anything else related to OpenRC) and never come back. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/530a0f23.3070...@debian.org
Re: default init on non-Linux platforms
On 02/21/2014 03:37 AM, Ondřej Surý wrote:
mkdir -p /run/openrc
touch /run/openrc/softlevel
and then it still doesn't work as expected:
root@howl:/etc/init.d# /etc/init.d/rsyslog start
* WARNING: rsyslog is already starting
root@howl:/etc/init.d# /etc/init.d/rsyslog stop
* ERROR: rsyslog stopped by something else
root@howl:/etc/init.d# /etc/init.d/rsyslog status
* status: stopped
root@howl:/etc/init.d# ps uax | grep rsyslo[g]
root 6743 0.0 0.0 52592 1752 ?Ssl 20:28 0:00
/usr/sbin/rsyslogd -n -c5
root 6764 0.0 0.0 7768 856 pts/0S+ 20:28 0:00 grep
rsyslog
Thomas, would it be possible to make openrc-run work even when the
openrc doesn't replace /etc/init.d/rc{,S}? Or does it need too much from
openrc infrastructure, so my idea is just too crazy?
I'm not sure about how much work it would be, or how easy it would be to
implement, but the more I think about it, the more I think it'd be great
to do this.
The only problem I'd see, is that we'd have to keep the LSB headers,
since startpar / insserv would still only understand that. Though that's
probably the least annoying part. If at least we can rewrite the rest of
the scripts using the runscripts simplification, and have this available
by default in Jessie, then it'd be awesome. Switching between OpenRC and
sysv-rc can be dealt with later then (since what's important is to have
runscript support as early as possible).
I'll see with the rest of the contributors what they think about it, but
Benda seem to be positive about the fact it's doable. I'd also like to
patch sysv-rc so that it could write in /run/openrc/started, so that we
get a list of running daemon when switching to OpenRC (and avoid the
hack of parsing with for file in /etc/rc0.d to do a manual shutdown
after the switch).
Cheers,
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/530a110c.8070...@debian.org
Re: default init on non-Linux platforms
On 02/24/2014 04:29 AM, Marco d'Itri wrote: On Feb 23, Thomas Goirand z...@debian.org wrote: Marco and yourself are *a way* off topic. Please at least have the decency to rename the subject of the tread to systemd fanboys flamewar yet-again bashing OpenRC just for fun or something similar (but preferably: don't just do that in this list, and avoid replying about anything related to OpenRC, since we all know what type of non-productive content it's going to be). This is not about systemd or any other init system. This is about how much additional work the five OpenRC users will cause to other developers. Probably you missed the point. Maybe because you don't really know what OpenRC is about and what it does. Let's say we don't bring in new packages, then it's 100% supported *right now* in Debian, using the already existing LSB header init scripts. If there's new packages, then it's probably more easy to use the simplified runscripts rather than the traditional sysv-rc LSB header init.d scripts. Also, it is my understanding that we wouldn't force anyone to add support unless a patch is provided. I have no problem with that rule. What additional work are you therefore talking about? It'd be actually less work. The goal here is to *simplify* the maintenance of init scripts (as well, for non-linux ports), by making it possible to use the OpenRC syntax instead of the one of LSB header scripts which everyone wants to get rid of. OpenRC addresses the needs of about the 160k current users of sysv-rc. This has nothing to do with the 800 systemd users (note: if you didn't get it, I well know this is silly stats, I'm just using the same kind of argumentation to show how pointless it is to use these stats in such a way). Now that systemd is to become the default init system, at least let us discuss peacefully about ways to address the problem of its non-availability on some ports, and how to deal without systemd (also on linux ports), for those who don't want to use it. If you aren't interested in this topic, just don't read. Nobody forces you to do so. The topic well identifies the content of the thread. Also, if I were bashing it just for fun then I would not forget mentioning its Gentoo origin. Very constructive. Thanks. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/530af289.8090...@debian.org
Bug#739966: ITP: python-ibm-db-sa -- SQLAlchemy support for IBM Data Servers
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-ibm-db-sa Version : 0.3.0 Upstream Author : IBM Application Development Team open...@us.ibm.com * URL : https://pypi.python.org/pypi/ibm_db_sa * License : Apache-2.0 Programming Lang: Python Description : SQLAlchemy support for IBM Data Servers IBM_DB_SA implements the SQLAlchemy specification for supporting the IBM Data Servers: DB2. Note: this package is needed by the last version of SQLAlchemy migrate, which has been broken by the upload of SQLAlchemy 0.9. So indirectly, we need this package to fix about 18 packages which will otherwise be stuck in Sid. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140224122952.25039.35985.report...@buzig.gplhost.com
Re: default init on non-Linux platforms
On 02/28/2014 01:10 AM, Tom H wrote: Just to name a few: - getting rid of the ugly LSB headers Beauty is in the eye of the beholder. The Short-Description and Description LSB fields are useless, but I don't find Debian's LSB headers and Gentoo's squiggle-delimited stanzas any more beautiful or uglier than the other. What's important is that they do the job of allowing their respective rc routines order the startup - and they both do so. IMO, it's better because less verbose. I just feel like the syntax is better, also because it's integrated with the rest of the runscript syntax, but that might be consider not so important, I can agree with that to some degree. - Dependency loop breaking system What does this mean? That there are bugs in the dependency headers in the 1000-odd initscripts in Debian where openrc can work through the problem and insserv send you to the BTS? This means that OpenRC goes through the use links (Should-Start, in the LSB header format), and see if it needs to remove one of them in order to break the dependency loop, and have a somehow satisfying boot order. Note that this is only a feature available in a Debian specific patch for the moment (not upstreamed yet). In Debian, that's located in debian/patches/0020-dependency-loop-resolver.patch if you want to have a look. I hope we can have this upstreamed soon before 0.13 is released. Is the mini-runscript style as experimental as Petter's 2-line sysv-rc script? It's not. It's just that with OpenRC, you can decide to implement *or not* the start() and stop() function. If you don't, then OpenRC will use its internal function instead. Anyway, ifupdown and netifrc are pretty much equivalent. And I don't see the point of having Debian switching to the Gentoo style of things, so we agree! :) Finally, there's the issue of parallel boot. Debian has it in squeeze and wheezy with insserv. Has openrc fixed rc_parallel? Yes. The dependency loop breaking system fixed it. What's remaining to be fixed though, is the text output which is (very) ugly when the parallel booting is activated. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531016d7.60...@debian.org
Re: Backports, Stable releases, Testing, Oh my!
On 02/28/2014 09:40 AM, Michael Gilbert wrote: On Wed, Feb 26, 2014 at 12:36 PM, Peter Samuelson wrote: [micah] it feels like a bit too aggressive pressure for my tastes. I've seen a lot of developers of packages who have found out their package will be removed from testing, but don't have the time to resolve the situation before it gets removed, resulting in much pulling of hair. If only we had some kind of a setup where, a few days after you upload a fixed version of something, it could reenter testing. Then maybe all that hair trauma wouldn't be needed. Is 10 days really too long? The only consequence of having a package removed from testing really is the 10 day delay to get it back after the next unstable upload (assuming remaining the remaining rc bugs were fixed). Best wishes, Mike AFAICT, it's 5 days now. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53101b27.5080...@debian.org
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
I salute this effort! :) On 03/04/2014 02:13 AM, Gunnar Wolf wrote: As keyring maintainers, we no longer consider 1024D keys to be trustable. We are not yet mass-removing them, because we don't want to hamper the project's work, but we definitively will start being more aggressively deprecating their use. What does this mean? Is there a schedule in place? Also, how many 1024D keys are still in the keyring? Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53154d5c.2060...@debian.org
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
On 03/04/2014 09:24 PM, Jeremy T. Bouse wrote: If any DDs are in, or will be, the Atlanta area and would like to get together for a key signing I would be more than welcome to get together Most likely, I will attend the OpenStack summit in Atlanta [1] next May (from 12th to 16th). Even if I'm not there, there will most likely be a lot of DDs that will attend the event (from the top of my head: James Page Robert Collins at least, probably even more). I'll be happy to sign your key if you show up to the event. Even if you're just at the door and don't want to pay the entry fee, that should be fine too, though since it's next to where you are, I would recommend you to attend the whole week: there's a lot to learn there. Cheers, Thomas Goirand (zigo) [1] http://www.openstack.org/summit/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5315e455.6060...@debian.org
Bug#740805: ITP: python-croniter -- provides iteration for datetime object with cron like format
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-croniter Version : 0.3.4 Upstream Author : Matsumoto Taichi taich...@gmail.com * URL : https://github.com/kiorky/croniter * License : Expat Programming Lang: Python Description : provides iteration for datetime object with cron like format Croniter is a python module to provide iteration for datetime object. Given a cron tab text entry as input, it Croniter will output all the dates matching the definition. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305072518.10944.98925.report...@buzig.gplhost.com
Bug#740806: ITP: python-oslo.vmware -- VMware library for OpenStack projects
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-oslo.vmware Version : 0.2 Upstream Author : Vipin Balachandran vb...@vmware.com * URL : https://github.com/openstack/oslo.vmware * License : Apache-2.0 Programming Lang: Python Description : VMware library for OpenStack projects This package is part of the Oslo project, which aims at providing unified Python libraries across all of OpenStack. It provides a VMware library for OpenStack projects. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305074903.14452.59740.report...@buzig.gplhost.com
Re: jquery debate with upstream
On 03/11/2014 11:16 PM, Ian Jackson wrote: Debian have a certain definition of Freedoms [...] Whose freedom is impaired, and in what way, by the presence of these useless but ignored files in the tarball ? In one of my package, I had openssl.dll in the source tarball (it was of course removed later on). Would you consider it ok as well to have it in a source package, as long as it's not used during the build? And what about a windows .exe? Is it different from having a minified .js that is also not in use? Cheers, Thomas (note: this is not sarcasm or whatever, this is a real case that I'm talking about, and I'm really interested in the opinion of Ian) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531f37bb.9050...@debian.org
Re: jquery debate with upstream
On 03/12/2014 05:16 AM, Sune Vuorela wrote: On 2014-03-11, Paul Tagliamonte paul...@debian.org wrote: On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote: I don't think this is a significant breach of the DFSG. Ah, but you do acknowledge this *is* a breach, even if a small one. So this comes down to where the line is, like I said. As a Debian Developer, I will uphold the DFSG except where it is inconvenient ? I actually think the DFSG is a great document and we shouldn't just stray from it because it is inconvenient. If I had to disregard the DFSG in some cases, I'd rather see rfc files in our files than sourceless javascripts. /Sune Oh, let's talk about this! :) I had once a package rejected because the doc contained a logo in PNG format, which had in its header clues that it has been generated. I later on just removed the logo in a +dfsg package... Added benefits to this? In my opinion, the package was just *less* good, it took some of my time, and users don't have an (ugly and generated) logo in the doc, and have instead a broken link in the HTML (cause I had better things to do than to fix this as well...). I think THAT went too far (but I do agree we should get rid of minified javascript files). As Paul wrote it, it's all about where we draw the line. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531fc8e8.5030...@debian.org
Re: jquery debate with upstream
On 03/13/2014 01:21 PM, Charles Plessy wrote: Le Thu, Mar 13, 2014 at 12:48:44AM -0400, Scott Kitterman a écrit : What percentage of free software in Debian main do you expect then? Hi Scott, I expect 100 % in the binary packages. On the other hand, the upstream tarballs are becoming temporary cruft that are not the preferred form for modification because they do not contain the typical revision information and comments found in version control systems used upstream. This was not the case when Debian was founded, but as the world evolves, we need to evolve. Actually, this is a very good case for doing git based packaging and using git archive based on tags. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53214aa3.90...@debian.org
Re: jquery debate with upstream
On 03/13/2014 01:37 PM, Scott Kitterman wrote: On Thursday, March 13, 2014 14:21:22 Charles Plessy wrote: Le Thu, Mar 13, 2014 at 12:48:44AM -0400, Scott Kitterman a écrit : What percentage of free software in Debian main do you expect then? Hi Scott, I expect 100 % in the binary packages. On the other hand, the upstream tarballs are becoming temporary cruft that are not the preferred form for modification because they do not contain the typical revision information and comments found in version control systems used upstream. This was not the case when Debian was founded, but as the world evolves, we need to evolve. Oh. So you think to meet the DFSG we need to provide a copy of the VCS repository since the tarball isn't the preferred form of modification? That would be a huge change. Far bigger than repacking a few tarballs. Well, we have debcheckout... :) Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53214e04.8030...@debian.org
Bug#741658: ITP: tuskar-ui -- control how and where OpenStack services are deployed - horizon plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: tuskar-ui Version : 0.0.9 Upstream Author : OpenStack Development Mailing List openstack-...@lists.openstack.org * URL : https://github.com/openstack/tuskar-ui/ * License : Apache-2.0 Programming Lang: Python Description : control how and where OpenStack services are deployed - horizon plugin Tuskar gives administrators the ability to control how and where OpenStack services are deployed across the datacenter. Using Tuskar, administrators divide hardware into resource classes that allow predictable elastic scaling as cloud demands grow. This resource orchestration allows Tuskar users to ensure SLAs, improve performance, and maximize utilization across the datacenter. . Tuskar services are available via a RESTful API and management console through which administrators are able to classify their hardware and define their datacenters. In addition, Tuskar components provide administrators with performance monitoring, health statistics, and usage metrics, aiding in capacity planning and hardware procurement decisions. . This package contains the OpenStack dashboard plugin. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140315021858.6731.97507.report...@buzig.gplhost.com
Re: jquery debate with upstream
On 03/13/2014 11:45 PM, Vincent Bernat wrote: ❦ 12 mars 2014 22:26 CET, Ben Finney ben+deb...@benfinney.id.au : The javascript world is difficult to deal with. They like embedded copies, they may not really care about API/ABI stability, even for big projects. Those are difficulties that we already have to deal with. We already work around them by using Debian package when possible but this makes the software we ship more buggy because we don't match the exact version that upstream uses. Right. This can only really improve by addressing the general problems you describe in that paragraph, which itself requires collaborating with upstream to join with us in expecting better interoperability from JS library developers. In the past, we have seen it is useless to try to convince an upstream they should do like we want to. We should wait for them to notice that this is the way to go or they will just start some hate campaign about how slow and deprecated we are. In my experience, this really depends on upstream, and you shouldn't generalize that much. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5323bb98.8020...@debian.org
Re: jquery debate with upstream
On 03/13/2014 04:57 AM, Jakub Wilk wrote: * Philipp Kern p...@philkern.de, 2014-03-12, 21:11: I still think it should be acceptable given that it's an open source project, it's clearly versioned from which source it comes and we check by not using the file that no changes have been done to the minification. I guess we could even go one step further and argue that the source for this is in fact in Debian. That would work only if the embedded copy was the same version as the packaged one. And there are lots of jQuery versions in the wild. In 20120817111437.ga8...@jwilk.net I suggested making a package that would bundle all the needed sources, but my proposal wasn't met with enthusiasm. I think it's a good idea, however, instead of packaging all version possible, would it be possible to identify which API is incompatible and package just as much as needed only? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5323ee7d.1010...@debian.org
Bug#742310: ITP: python-oslotest -- OpenStack test framework
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-oslotest Version : 0.1 Upstream Author : OpenStack developers openstack-...@lists.openstack.org * URL : https://github.com/openstack/oslo.test * License : Apache-2.0 Programming Lang: Python Description : OpenStack test framework OpenStack test framework that provides base classes and fixtures for creating unit and functional tests. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140322063711.16847.45822.report...@buzig.gplhost.com
How long should a transition last for a package only in Sid/Testing
Hi everyone! When there's a package transition for a package that is currently in Stable, it's obvious that the transition packages should be available on the next stable release. But when the package isn't in stable (yet), and is only in Sid/testing, how long should a transition package last? Until the next stable release? IMO it'd be bad to have a transition package introduced in the new Stable if the package wasn't in old-stable. Thoughts anyone? Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/532f064b.2080...@debian.org
Bug#742478: ITP: python-saharaclient -- Client library for Openstack Sahara API server
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-saharaclient Version : 0.6.0 Upstream Author : openstack-...@lists.openstack.org * URL : https://github.com/openstack/python-saharaclient * License : Apache-2.0 Programming Lang: Python Description : Client library for Openstack Sahara API server Sahara aims to provide users with simple means to provision a Hadoop cluster by specifying several parameters like Hadoop version, cluster topology, nodes hardware details and a few more. . This is a client for the Sahara which uses the OpenStack Image API. There's a Python API (the saharaclient module), and a command-line script (sahara). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140324071023.32188.81792.report...@buzig.gplhost.com
Bug#742586: ITP: python-rednose -- coloured output for nosetests
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-rednose Version : 0.4.1 Upstream Author : Tim Cuthbertson t...@gfxmonk.net * URL : http://gfxmonk.net/dist/0install/rednose.xml * License : BSD-3-clause Programming Lang: Python Description : coloured output for nosetests rednose is a nosetests plugin for adding colour (and readability) to nosetest console results. Rednose by default uses auto-colouring, which will only use colour if you're running it on a terminal (i.e not piping it to a file). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140325081940.8538.46256.report...@buzig.gplhost.com
Bug#742599: ITP: python-termstyle -- console colouring for python
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-termstyle Version : 0.1.10 Upstream Author : Tim Cuthbertson t...@gfxmonk.net * URL : http://gfxmonk.net/dist/0install/python-termstyle.xml * License : BSD-3-clause Programming Lang: Python Description : console colouring for python Termstyle is a simple python library for adding coloured output to terminal (console) programs. The definitions come from ECMA-048, the Control Functions for Coded Character Sets standard. Note: This package is needed by python-rednose (I've just opened an ITP for it), rednose is needed by python-sure, sure is needed by httpretty, and finally, httpretty is needed by python-keystoneclient (the OpenStack auth client). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140325102858.12618.6516.report...@buzig.gplhost.com
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* - and I can prove it)
On 03/25/2014 12:42 AM, Kevin Toppins wrote: Sorry for the intrusion into your world, but this *needed* to be said, and needed to be said on *this* specific list. Not correct. We didn't need another iteration of such a post. - the *future* of linux actually *does* depend on what - you - *do* here Correct. Which doesn't include reading or writing such a message. If you want thing to move on, stop posting useless messages, and start working on alternatives. For example, helping adding more features to OpenRC would certainly help a way more than this post. Writing an independent, init system agnostic, logind API compatible daemon would be another good thing to do. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5332ae91.9070...@debian.org
Re: systemd and Linux are *fundamentally incompatible* - and I can prove it
On 03/30/2014 02:51 AM, Jan Gloser wrote: Otherwise if you just personally disagree with the design of systemd and can't describe such a scenario, why not just migrate to Gentoo or BSD? This has been said a 100 times... There's no need to migrate away. systemd is not (and will not be) mandatory in Debian in the foreseeable future. Your can continue to use sysv-rc (or OpenRC, file-rc, Upstart...) if you like. The TC decision is *only* about the *default* init system. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5337a8f8.4020...@debian.org
Re: default messaging/VoIP client for Debian 8/Jessie
On 03/30/2014 05:04 PM, Daniel Pocock wrote: ZRTP - peer to peer encryption, like PGP for VoIP. Once again, it has been in Jitsi for ages but is not in Empathy[7] To me, this is the most important feature of them all, and is IMO mandatory nowadays. But do you know if Asterisk (or other VoIP servers) are configured to accept such important feature by default? On 03/30/2014 05:04 PM, Daniel Pocock wrote: JitMeet multi-party video conferencing solution[8] for WebRTC browsers You should remove the s at browsers. It only supports Chrome(ium). By the way, do you know if it's easy to setup conference calls the way there is with JitMeet / Hangout, but without a web browser, eg directly on a VoIP software? Can Jitsi do that? Cheers, Thomas P.S: I don't really care which client is the default, because I find the concept of default app bad in itself, and I think users should be given the choice, and it isn't the role of a distribution to choose for its users. However, if we *have* to have a default, probably Jitsi is a good choice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5337f218.60...@debian.org
Re: default messaging/VoIP client for Debian 8/Jessie
On 03/30/2014 06:55 PM, Matthias Urlichs wrote: Hi, Thomas Goirand: P.S: I don't really care which client is the default, because I find the concept of default app bad in itself, and I think users should be given the choice, and it isn't the role of a distribution to choose for its users. However, if we *have* to have a default, probably Jitsi is a good choice. Most new users don't know enough to choose. Excuse me to say it this way, but ... NO! I've read this too many times. You have absolutely no evidence of that. Apart maybe if you talk about your mum, which anyway wouldn't install Debian (or any other OS btw) herself. To me, it looks a lot more logic and probable that those who don't know just don't care about VoIP. Those who need a VoIP client will have enough knowledge to choose. My point above was only that I don't think it's a good idea to install so many stuff by default. It bloats the installer and make it difficult to fit on the 700 MB of the CD1. I very much prefer a more minimalistic approach. Empathy isn't only doing VoIP, it does lots of other (chat) protocol, and trying to compare it to Jitsi doesn't help IMO. I myself prefer pidgin + Ekiga than just Empathy (and I find Jitsi too heavy and slow), but that's just me. Ask 5 persons, and probably you will get 5 different answers (including Ekiga, Skype, Linphone, Mumble, you-name-it). So why even bothering installing anything by default? In the case of Empathy, my understanding was that the reason it was there, is because it's designed to integrate with Gnome. I don't think we can say the same thing with Jitsi (which integrates with nothing). I also find it a pain to add the Jitsi dependencies in the default setup: Depends: libjitsi-jni (= 2.4.4997-1), default-jre | java6-runtime, libunixsocket-java, libhttpcore-java, liblog4j1.2-java, libjmdns-java, libdnsjava-java, libmac-widgets-java, libfelix-main-java, libfelix-framework-java, libhttpclient-java, libhttpmime-java, libcommons-logging-java, libcommons-codec-java, libcommons-lang3-java, liblaf-widget-java, libdbus-java, libxpp3-java, libjzlib-java, libbcprov-java, libjna-java, libjgoodies-forms-java, libjson-simple-java, libjcalendar-java And yes, Java sux! :/ And it's going to take *a lot* of space on the CD1. This should therefore be discussed on the debian-cd list as well. I don't think that only the argument it's better because of this or that feature would be the only one (unfortunately). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53382588.3090...@debian.org
Re: default messaging/VoIP client for Debian 8/Jessie
On 03/30/2014 07:18 PM, Daniel Pocock wrote: On 30/03/14 12:29, Thomas Goirand wrote: On 03/30/2014 05:04 PM, Daniel Pocock wrote: JitMeet multi-party video conferencing solution[8] for WebRTC browsers You should remove the s at browsers. It only supports Chrome(ium). Most of my own WebRTC stuff started out only supporting Chromium but Firefox support was not hard to add as well. Chrome developers are also moving to be more Firefox-like (e.g. using DTLS-SRTP and dropping SDES) and that will force many projects to get in sync. I just hope JitMeet gets support for Firefox soon, and that we (also soon) be able to install it on any given server using Debian packages! http://packages.qa.debian.org/r/reconserver.html is trivial to use and compiles cleanly on wheezy, proper backport coming soon. Description-en: lightweight SIP conferencing service [... bla bla ...] It supports audio but not video or text. I would need both video, screen sharing text (mainly to cut/past URLs). Anything that doesn't have these features wouldn't work for what we need (eg: work video conferences with at least 10 persons). We don't care seeing all faces at once, but screen sharing is important (to be able to do demos, or show slides). Up to now, the only solution we've found acceptable is Mumble. Bonus: it can scale up to 50 participants (I never tested more people at once). No way you can do that with Hangout (with a Google enterprise account, the limit is 15). And as you know, Mumble does only voice. We would ALL be happy to switch to a free software solution. Asterisk has the MeetMe conferencing module If you don't need packages, there are additional options like FreeSWITCH conferencing. Same: I don't think we'd have video, screen sharing text chat with the above. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533827f4.2010...@debian.org
Re: systemd and Linux are *fundamentally incompatible* - and I can prove it
On 03/30/2014 08:02 PM, The Wanderer wrote: If it's been decided to continue to require package maintainers to provide traditional init scripts as well as systemd unit files - e.g. for Debian's non-Linux ports - then that benefit would be lost. This, also, has also been discussed. The consensus is that we shouldn't *force* anyone to provide / design anything but systemd support, however, everyone should also accept patches by those who care about non-linux ports or $alternative-init-system. If it hasn't, then I think it's entirely foreseeable that package maintainers will at some point stop providing traditional init scripts. They should absolutely *not* remove init scripts that are working. If someone does, I would advise to first politely ask him to revert the regression. And probably asking the TC to force the maintainer to do so if he refuses would be a good idea. Now, not providing an init script for a *new* package is something different. I would expect to soon see patches being sent to the BTS by non-linux port supporters, or people willing to use the package without systemd. Though what I wrote above is only what has been *discussed*, there was no formal decision of what must happen. I dislike this gray area. :( At that point, unless a means of producing init scripts from unit files (which, last I heard, had been judged impossible) has been found, the amount of work required to continue to run sysvinit would be far more than the terminology of changing the default implies. I don't agree. We currently, at this point, have 100% full support for sysv-rc LSB-header scripts. I don't see it going away that fast. To be doing more than changing the default here is not necessarily a bad thing, but we shouldn't be pretending that changing the default is all that's happening We haven't set into the stones of the Debian Policy Manual what init system *must* be supported by packages. Obviously, systemd being the default, it must be supported, but probably, through sysv-rc script is a way to support it. Not supporting sysv-rc is of course a bug, but of which severity? Wishlist? Release critical? We've been fighting on which init system should be the default, but I think those questions are even more important, and I don't have an answer to them. unless choosing something other than the default really is - and, barring another project-wide decision, is expected to indefinitely continue to be - as simple as installing one set of packages rather than another. See above: I'm unsure Debian Developers have yet a clear view of what should / must be supported, and what's going to happen in this regard. At least, it's not clear to me. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533830df.4010...@debian.org
Re: default messaging/VoIP client for Debian 8/Jessie
On 03/30/2014 10:33 PM, Ben Hutchings wrote: On Sun, 2014-03-30 at 22:09 +0800, Thomas Goirand wrote: Apart maybe if you talk about your mum, which anyway wouldn't install Argument from sexism? Don't you help your mum (which I except to know less about Debian than a DD would)? Most people do. I don't see any sexism here. To me, it looks a lot more logic and probable that those who don't know just don't care about VoIP. Those who need a VoIP client will have enough knowledge to choose. [...] And this sort of attitude is why Skype has won. Skype won because it is a very good software that works well. Not because it has been chosen by default by Linux distributions. If there was something as good as skype in the free software world, we wouldn't even have to bother: everyone would know about it and install it if it wasn't there by default. Thomas P.S: Anyway, if it's technically possible to get Jitsi in by default, I wouldn't oppose to that if others think it's the correct thing to do. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533997ac.3060...@debian.org
Re: default messaging/VoIP client for Debian 8/Jessie
On 03/31/2014 08:27 PM, Jean-Michel Nirgal Vourgère wrote: Empathy was lacking OTR encryption for text, last time I checked. Jitsi does support it ok, so I can continue to do secure chat with my existing contacts from pidgin (previously known as gaim). BTW, it'd be nice to have a backport of Jitsi. Not sure how much work that would be though (there must be lots of java dependencies...). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533a73bc.8040...@debian.org
Re: -- APT's New Version --
On 04/02/2014 06:14 AM, Ben Finney wrote: The deity team de...@lists.debian.org writes: Everyone else will find in this beta^Wbinary release the fulfilment of a longstanding dream: /usr/bin/apt provided by apt rather than java. I don't know, this all seems a bit hasty. What about all my shell scripts to work with the Java “apt” to turn it into my package manager? Have you no regard for backward-compatibility? I really first thought it has to do with the day of washing the lions ceremony [1]. I'd suggest avoiding such a date for announcements in the future. Anyway, I then checked the facts, and really ... \o/ !!! It feels great to use apt instead of apt-get / apt-cache, and the new colorful output is awesome (btw, will Dpkg::Progress-Fancy be on by default on the next update? I kind of like it...). *THANKS TO EVERYONE WHO WORKED ON APT* !!! Debian wouldn't what it is today without it. Thomas [1] https://upload.wikimedia.org/wikipedia/commons/f/fb/Washing_of_the_Lions.jpg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533ba502.6090...@debian.org
Re: systemd - some more considerations
On 04/03/2014 05:58 PM, Tollef Fog Heen wrote: Am I understanding you correctly that you don't think there are any situations where compiling out features from the kernel can lead to pid1 not working would be acceptable? I'd say the opposite way. Could you please explain in which case you find it acceptable to *just crash*, and render the system completely unusable, and possibly even not recoverable?!? Even without cgroup support, the way to handle the situation, IMO, would be to at least fall back to the shell with a comprehensive error message. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533d4c20.7090...@debian.org
Re: Debian default desktop environment
On 04/04/2014 09:55 PM, Undefined User wrote: 2014-04-04 10:52 GMT-03:00 Jonathan Dowland j...@debian.org mailto:j...@debian.org: We go over the same ground over and over. I'm increasingly in favour of *no* default. You must pick one from a list on install. Randomize the list if necessary. Perfect solution. Debian installer should provide you information about desktop environments and let the user choose it. There's only one problem with this approach: somebody has to actually implement it... [1] Thomas [1] And it's been years we're (uselessly) discussing it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533f8cc0.6010...@debian.org
Re: Debian default desktop environment
On 04/04/2014 10:42 PM, Stefano Zacchiroli wrote: On Fri, Apr 04, 2014 at 02:52:41PM +0100, Jonathan Dowland wrote: We go over the same ground over and over. I'm increasingly in favour of *no* default. You must pick one from a list on install. Randomize the list if necessary. And can I pass my granddad's phone call on to you when he is stuck choosing among names that are absolutely obscure to him like GNOME, Xfce, and KDE? If we are the universal OS, we shouldn't just focus on non-experts, we shall try to satisfy everyone. If someone implements the choice thing (after years we're talking about, I still have hope...), then it's probably a good thing to keep it in the expert mode only. Which of course leads to: we still have a default to decide, in the case of the non-expert mode. Then, maybe a GR for deciding which DE should be the default could be considered. It's not like the init system: I think every DD has enough knowledge to decide, especially because this is a very subjective choice with tastes and habits involved (TWM anyone? :)). I'm not sure I would like to take the burden of being the person proposing the GR and writing the text though, and I would prefer to first discuss if it is a good idea to do that (some may very dislike that idea). Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/533f8f6a.5000...@debian.org
Bug#743753: ITP: python-posix-ipc -- semaphores, shared memory and message queues
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-posix-ipc Version : 0.9.8 Upstream Author : Philip Semanchuk phi...@semanchuk.com * URL : http://semanchuk.com/philip/posix_ipc/ * License : BSD-3-clause Programming Lang: Python Description : semaphores, shared memory and message queues posix_ipc is a Python module (written in C) that permits creation and manipulation of POSIX inter-process semaphores, shared memory and message queues on platforms supporting the POSIX Realtime Extensions a.k.a. POSIX 1003.1b-1993. This includes nearly all Unices and Windows + Cygwin 1.7. Note: This package is a new dependency of Tuskar, which is already in Debian Experimental. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140406010056.23682.40747.report...@buzig.gplhost.com
Re: Debian default desktop environment
On 04/06/2014 05:06 AM, Matthias Klumpp wrote: Personally, I think we should offer a DVD instead of a CD as primary installation medium. For a desktop use, probably. For server setup, please don't. The CD1 is better than the netinst CD because... it doesn't need network! And I prefer a smaller thing. I'm also unsure all my KVM over IPs support images for DVDs rather than simply CD. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5342dfda.5040...@debian.org
Re: Debian default desktop environment
On 04/08/2014 01:34 AM, John Paul Adrian Glaubitz wrote: On 04/07/2014 07:26 PM, Thomas Goirand wrote: For a desktop use, probably. For server setup, please don't. The CD1 is better than the netinst CD because... it doesn't need network! You deploy your servers from a CD? Don't get me wrong, but installing from CD in an enterprise environment doesn't sound very professional to me. Note a CD, a CD image, booted from the KVM over IP using virtual media over LAN. That's a pretty common use case, especially using preseeding. And even if you want to install from CD, most modern servers provide a BMC with keyboard, mouse and video redirect over the network which also allows you to mount ISO files as virtual CDs. That's what I'm using yes. Probably you should have read my message up to its end, where I wrote: I'm also unsure all my KVM over IPs support images for DVDs rather than simply CD. In that case, you don't really care about whether it's a CD or DVD. Even if they do, I don't see the point in using images 6 times the size (takes longer to download and uses more storage for no improvement). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5342ed4c.1040...@debian.org
Re: Debian default desktop environment
On 04/08/2014 02:36 AM, John Paul Adrian Glaubitz wrote: No need to be rude about that, ok? I've re-read my posts about a dozen time, and I fail to see which part you thought was rude. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5343c873.7090...@debian.org
Re: Debian default desktop environment
On 04/08/2014 01:51 AM, Russ Allbery wrote: And, of course, non-free software from top to bottom. Not the case of Supermicro: free software, in outdated (and unsafe) versions, from top to bottom, and impossible for the customer to rebuild anything. I wonder if they will one day understand the point of free software, and community contributions. :( Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5343cc41.7000...@debian.org
Re: Proposing amd64-hardened architecture for Debian
On 04/15/2014 06:00 PM, Balint Reczey wrote: Hi, I have posted the following idea on my blog [7] to get comments from people not on this list, but obviously this is the mailing list where the proposal should be discussed. :-) - Facing last week's Heartbleed [1] bug the need for improving the security of our systems became more apparent than usually. In Debian there are widely used methods for Hardening [2] packages at build time and guidelines [3] for improving the default installations' security. Employing such methods usually come at an expense, for example slower code execution of binaries due to additional checks or additional configuration steps when setting up a system. Balancing between usability and security Debian chose an approach which would satisfy the most users by using C/C++ features [4] which only slightly decrease execution speed of built binaries and by using reasonable defaults in package installations. All the architectures supported by Debian aims using the same methods for enhancing security but it does not have to stay the same way. Amd64 is the most widely used architecture of Debian according to popcon [5] and amd64 hardware comes with powerful CPU-s. I think there would be a significant amount of people (being one of them :-)) who would happily use a version of Debian with more security features enabled by default sacrificing some CPU power and installing and setting up additional packages. My proposal for serving those security-focused users is introducing a new architecture targeting amd64 hardware, but with more security related C/C++ features turned on for every package (currently hardening has to be enabled by the maintainers in some way) through compiler flags as a start. Introducing the new architecture would also let package maintainers enabling additional dependencies and build rules selectively for the new architecture improving the security further. On the users' side the advantage of having a separate security enhanced architecture instead of a Debian derivative is the potential of installing a set of security enhanced packages using multiarch [6]. You could have a fast amd64 installation as a base and run Apache or any other sensitive server from the amd64-hardened packages! - What do you think? Would adding a new arch be feasible and a good solution? Cheers, Balint My take on this: start it if you wish, and see how it takes you. If it is successful enough, it will go to http://www.debian-ports.org/. If it has even more success, then probably it will go through the standard repository and be official part of Debian. Whatever happens, it will be interesting to see what kind of performance hit you get, and what kind of security enhancement there is. Just my 2 cents, Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/534d5b1a.3070...@debian.org
Re: lintian source-is-missing for jquery -- was Re: Bug#744699: Frets On Fire bug report 744699
On 04/25/2014 03:48 AM, Manuel A. Fernandez Montecelo wrote: a) the minified .js is still source code, by definition. I don't agree with this. On 04/25/2014 03:48 AM, Manuel A. Fernandez Montecelo wrote: It's interpreted in different implementations of an ISO-approved interpreted language, and it is valid code. It is compiled code, not *source* code. It's impossible to modify as-is. On 04/25/2014 03:48 AM, Manuel A. Fernandez Montecelo wrote: Even in obfuscated form, with minor transformations it's probably easier to understand that some other proper source code out there. No! :) On 04/25/2014 03:48 AM, Manuel A. Fernandez Montecelo wrote: So it can be argued that this lintian error is not correct, it is source code even if obfuscated, and open to interpretation in any case. Saying that source code is missing for a file that is actually proper source code is a special case and should be treated differently. This minified source code is as helpful as the output of a binary that has been decompiled. It is *not* something someone will work on, especially if there's the equivalent non-obfuscated source code available. On 04/25/2014 03:48 AM, Manuel A. Fernandez Montecelo wrote: b) The first lines of the unminified file clearly states the software projects, version, and URLs to get the non-minified versions, so if users want to modify the code, they can go there or take the version from their Debian system. In Debian, we don't package URLs, but human readable source code. If your source package doesn't include source code for *anything*, then it's a serious violation of the DFSG and social contract. On 04/25/2014 03:48 AM, Manuel A. Fernandez Montecelo wrote: This is vastly different to the normal idea of binaries without sources No it's not, it's exactly the same thing. On 04/25/2014 03:48 AM, Manuel A. Fernandez Montecelo wrote: There's value in the warning, in the sense that if one wants to modify the code, one would prefer to use the unminified version And therefore, the obfuscated code is considered non-DFSG free. On 04/25/2014 03:48 AM, Manuel A. Fernandez Montecelo wrote: So the presence of the file in the source tarball is not diminishing the freedom of users, and the actions proposed by lintian don't enhance user freedom, from my point of view. This is backward thinking. You'd better think this way: the presence of the file doesn't, in any way, help your users. Quite the opposite: it makes the source package bigger, and makes users look at files which they can't anyway modify. So why would you keep it? Realistically, the only reason is because it makes your maintainers life easier. Any other point of view is just wrong, IMO. On 04/25/2014 03:48 AM, Manuel A. Fernandez Montecelo wrote: and the dance of repackaging the upstream tarballs in this case, and probably for all uses of jquery, is a waste of time, and Debian users would see more benefits if contributors spent time elsewhere. This is only where I can agree with you. On 04/25/2014 03:48 AM, Manuel A. Fernandez Montecelo wrote: I don't think that overriding hides the problem... I do. Overrides are there only to cover false-positives. What is the reason for yours, if not hiding issues? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535a6616.9050...@debian.org
Re: what to do with wayland, python3, gdm3/systemd, ...
On 04/28/2014 06:16 PM, Osamu Aoki wrote: Hi, Questions are how Debian Jessie packages should be packaged with regards to configuration choices etc.: wayland support or not (I am skipping ones using libwayland-dev now) python3 support or not (Are we moving too?) X session autostart scripts under systemd I'm not sure about the other components, but I'm convinced that we should try as much as possible to support Python 3. It has been released in 2008, and upstream (for Python) is pushing for its adoption, and would like to deprecate Python 2. Sure, we wont deprecate Python 2 for Jessie, however, it seems reasonable to try to push for Python 3 adoption as well, and this means trying to package Python module with Python 3 support as much as possible. Whenever possible, pushing Python 3 patches upstream is also a good idea, IMO. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535e54ae.6070...@debian.org
Re: Hardened OpenSSL fork
On 04/21/2014 02:07 AM, Steven Chamberlain wrote: OpenBSD developers are extensively cleaning up OpenSSL 1.0.1g I'm not so sure if cleaning-up really means removing 90k lines of code without extensive checks. I'd very much prefer some unit tests added to the current code base, or a *long* audit process for example. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535f6937.8020...@debian.org
Re: OpenStack needs for backport repo (was: concurrent installation of different pkg versions)
On 04/26/2014 01:39 AM, Daniel Pocock wrote: There was even a debate about this on the backports list recently in the context of how to support different versions of OpenStack (not installed concurrently though, but just making perhaps the most recent 2 releases available to users on wheezy) For jquery, the issue is to have multiple versions of the same library installed at the same time in a single system. Since you're raising the topic, I feel like I should explain. This isn't the need of OpenStack, which is: - everyone uses Wheezy and an unofficial backport repository. - upstream is mooving too fast (6 months release cycle, deprecation of old-stable release after 10 months). - the OpenStack repository is huge (hundreds of megs), and so it makes sense to have something separate from standard backports. - all distributions are doing separate backport repos (Ubuntu cloud-archive, RedHat RDO, etc.) because of the same reasons above. This isn't new: Debian PPAMAIN would be the perfect fit. But its not looking like it's coming fast, which is why I asked the FTP masters what could be done now, though I didn't get a reply from them (too busy?). Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53605310.4020...@debian.org
Re: concurrent installation of different pkg versions
On 04/26/2014 01:39 AM, Daniel Pocock wrote: With all the talk about removing jquery from source packages, one thing that does arise is the question of how to support different jquery versions. This is not just a JavaScript issue though. Maybe we can have libjs-jquery-1.7 libjs-jquery-1.10 There's nothing that prevents us from manually deciding to have different versions installed at once: this is a packaging decision. We could have for example: From package libjs-jquery-1.7: /usr/share/javascript/jquery/1.7 From package libjs-jquery-1.10: /usr/share/javascript/jquery/1.10 This is the exact same thing that happens with .so libraries, and this should happen *only* when there's an API change (why would you want to keep an older version otherwise?). I strongly believe that this should be avoided as much as possible (for example with good communication with upstream so that they understand the needs of distributions), though there's some cases where probably it's impossible. I wouldn't like if we were generalizing the practice, but would understand and feel reasonable if we had a few cases of it, for example let's say 2 jquery versions at once max on a give system. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536055d2.2040...@debian.org
Re: A question about patches for upstream
On 05/03/2014 03:21 AM, Svante Signell wrote: Hi, Does the Debian guidelines give any hints on who is responsible to report a patch upstream? Is it the bug submitters or the Debian package maintainers responsibility (in addition to eventually apply them to the packages)? The first one who does it wins. :) Thomas P.S: Bonus point for a notice about the upstream report in the BTS, with the appropriate upstream tag and upstream BTS URL. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536651ef.6070...@debian.org
Re: Gerrit patch review, and gating (was: Call for help from KDE Team)
On 05/02/2014 06:17 PM, David Goodenough wrote: On Friday 02 May 2014 11:32:41 Maximiliano Curia wrote: ¡Hola Paul! El 2014-05-02 a las 08:40 +0800, Paul Wise escribió: On Fri, May 2, 2014 at 2:19 AM, Maximiliano Curia wrote: For quite a while now the KDE team has been severely understaffed. We maintain a lot of packages, with many different kinds of bugs, but we don't have enough people to do all the work that needs to be done. We have tools that help us automate the update to new upstream releases, but that's just the tip of the iceberg of our work and so we are writing to invite more people to get involved in the team and help us get KDE software in Debian into better shape. Have you invited the Kubuntu team to join you? I'll send a mail to the other derivatives I can find that use KDE. We've invited the Kubuntu team to merge their efforts with ours and use the same packaging vcs. The answer was positive, although the migration is a bit too far in the future. They sort of agree that they could migrate from launchpad bzr to git.debian.org, but as they are a larger group they separate junior and senior developers, requiring a review for each junior commit, for which they have a workflow and systems in place that won't be directly usable in git.debian.org. so the idea is to keep in sync most of our work, and see if we can figure out a way to merge it. Which translates to some overhead and a larger TODO list than an immediate help, but sure, once certain threshold in time invested is reached, both Debian and Ubuntu could benefit from it. Happy hacking, Sounds like a job for Gerrit. Currently not fully packages for Debian but I understand there is work being done one it. There is a github project at https://github.com/dnaeon/gerrit-debian which builds debs. David Someone starting a Debian package is a good idea, though IMO, it'd be nicer if gerrit could be properly packaged in Sid / Testing. Does anyone want to work on that? The above Debian package doesn't seem good after a quick look (for example, it build-depends on java6-runtime-headless which isn't in Sid anymore, depends on git-core instead of git, copyright file isn't right, etc.). If hands are raising for packaging gerrit and the necessary tools for building a gate, then I'd be happy to work on that as well (though I feel like I've got enough work with the packaging of OpenStack already, so my time would be unfortunately limited...). I've seen that the DSA are currently building an OpenStack cloud (using the new Icehouse packages). I'm not sure what will be its use, or what's the current plan, though it'd be a super nice idea to use it to setup Gerrit and some kinds of gating process (piuparts adequate comes to mind of course). This could be for example used for spawning VMs to do some checkings of each git commit on Alioth, with Gerrit as a tool for a patch review process. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/536850eb.70...@debian.org
Bug#748383: ITP: bash8 -- bash script style guide checker
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: bash8 Version : 0.1.0 Upstream Author : Mathew Odden locke...@gmail.com * URL : https://github.com/openstack-dev/bash8 * License : Apache-2 Programming Lang: Python Description : bash script style guide checker This program attempts to be an automated style checker for bash scripts to fill the same part of code review that pep8 does in most OpenStack projects. It started from humble beginnings in the DevStack project, and will continue to evolve over time. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140516181045.20025.64913.report...@buzig.gplhost.com
Bug#749108: ITP: python-os-cloud-config -- configuration seed and initialisation for TripleO OpenStack clouds
Package: wnpp Severity: wishlist Owner: Thomas Goirand z...@debian.org * Package name: python-os-cloud-config Version : 0.0.2 Upstream Author : Robert Collins rbtcoll...@hp.com * URL : https://github.com/openstack/os-cloud-config * License : Apache-2.0 Programming Lang: Python Description : configuration seed and initialisation for TripleO OpenStack clouds This package is part of the TripleO project. TripleO is a program aimed at installing, upgrading and operating OpenStack clouds using OpenStack's own cloud facilities as the foundations - building on nova, neutron and heat to automate fleet management at datacentre scale (and scaling down to as few as 2 machines). . This package contains the common code for tuskar and the seed initialisation logic, the post heat completion initial configuration of a cloud. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140524082524.11887.67290.report...@buzig.gplhost.com
