Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
2014-11-29 22:25 GMT+01:00 Svante Signell : > On Sat, 2014-11-29 at 22:01 +0100, Philipp Kern wrote: >> On 2014-11-29 21:30, Steve Langasek wrote: >> > Debian releases when it's ready. If large numbers of our users are >> > going to >> > have a bad experience with jessie as a result of being switched to >> > systemd, >> > then we should take appropriate steps to address that, even if that >> > means >> > unfreezing the installer. >> >> Sure. But where is the evidence for that? Is there a bug that has been >> agreed upon to be RC? >> >> > I am not saying that making init systems a choice in the installer is >> > the >> > right solution here; I don't think that it is. But I also don't think >> > that >> > the release freeze can reasonably be an argument against it. >> >> Not even the release freeze, rather the d-i freeze. Unless this is RC >> for d-i, that is > > Ok, I've tried to no avail. Debian is no democracy (maybe never was). It never was a democracy - it was and is a meritocracy, described as "the reign of knowledge"[1]. And we are going quite well with that. [1]: http://debian-handbook.info/browse/wheezy/sect.debian-internals.html#idp5715200 -- 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/caknhny9tvwok2yyutyjmokta+yh+uyk0sga8dralf8gjzmi...@mail.gmail.com
Re: successful upgrade to jessie - thanks!
Felipe Sateler writes: ... > This is indeed unfortunate. Because runlevel[234] are links to > multi-user.target it means that distinctions between those runlevels are > not preserved. It also means that the ability to differentiate between > graphical.target and multi-user.target is almost lost for systems where the > dm does not provide a native systemd unit, because the sysv generator will > generate links from runlevel[2345].target.wants/ to the dm. > > This is the case with kdm: > > % cd /run/systemd/generator.late > % ls -l runlevel[2345].target.wants/kdm.service > lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel2.target.wants/kdm.service -> > /run/systemd/generator.late/kdm.service > lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel3.target.wants/kdm.service -> > /run/systemd/generator.late/kdm.service > lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel4.target.wants/kdm.service -> > /run/systemd/generator.late/kdm.service > lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel5.target.wants/kdm.service -> > /run/systemd/generator.late/kdm.service > > > Unless a user has disabled kdm in runlevels [234], there is no way to boot > the system without starting kdm. Is this not really a consequence of the combination of the fact that: Firstly, Debian Policy has left runlevels mostly alone, with the intent that local admins can do what they like with 3 & 4, and probably 5, because we default to 2 where we run everything that's installed, including graphical stuff; and secondly systemd seems to be using the more conventional assumption that runlevel 5 is the graphical one, and lower numbers run the non-graphical stuff only. It seems to me that we could: Make systemd link runlevel 2 to graphical.target, and 3,4 & 5 to multi-user.target, or perhaps in an attempt to be slightly less confusing to outsiders, how about: 2 & 5 --> graphical 3 & 4 --> multi-user Ensure that all graphical stuff (so display managers basically) get rid of their 234 runlevel start links, and change our default to 5 (cannot see that going well on upgrades TBH, might have been doable if we'd started about 5 years ago) Ensure that all display managers ship native systemd units before release. The last of these seems likely to at least partially address the problem at hand, because it'll make it possible to use the multi-user.target to avoid starting X, but does not fix the potential runlevel confusion. Given that we do not have well defined distinctions between runlevels, and the runlevels in systemd don't actually map directly to the old runlevels anyway, but rather go via the multi-user and graphical targets, should we not just remove the runlevel targets to avoid this confusion (or do they get used elsewhere)? I'd think that we need to tell people when upgrading that, if they've done things that are important to them involving special meanings for runlevels 2345, they need to work out how to port those things to systemd, or opt to stick with sysvinit for now. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY pgpd8FoeCXHEm.pgp Description: PGP signature
Bug#771475: ITP: libfap6 -- APRS parser
Package: wnpp Severity: wishlist Owner: "Iain R. Learmonth" Package: wnpp Severity: wishlist Owner: "Iain R. Learmonth" * Package name: libfap Version : 1.4 Upstream Author : Tapio Aaltonen, OH2GVE * URL : http://www.pakettiradio.net/libfap/ * License : GPL Programming Lang: C Description : APRS parser libfap is a C port of the Ham::APRS::FAP Finnish APRS Parser (Fabulous APRS Parser) Perl module. As the original Perl code, libfap parses normal, mic-e and compressed location packets, NMEA location packets, objects, items, messages, telemetry and most weather packets. For more description, see the Perl module. Note that libfap5 is currently packaged in Debian and this is a new upstream version with a new soname. -- 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/20141129230103.7488.68339.report...@lepton.shiftout.net
Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie
[I've removed the blatant trolling from the subject line.] Marc Haber wrote: > With all the technical issues in systemd popping up just now, we have > frozen prematurely. On the contrary, that's precisely what the freeze is *for*: to stop taking new development that doesn't fix bugs (and potentially introduces new ones), while accepting changes that fix bugs, in an effort to reduce the number of bugs and put out a release. In Linux terms: the merge window has closed, time to focus on stability and bugfixes and put out a release. Personally, I'm quite impressed by the speed and quality of the efforts by the systemd team to triage and fix issues. - Josh Triplett -- 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/20141129224149.GA5600@thin
Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
On Sat, 29 Nov 2014 12:30:49 -0800, Steve Langasek wrote: >On Sat, Nov 29, 2014 at 08:14:07PM +0100, Philipp Kern wrote: >> On Sat, Nov 29, 2014 at 07:15:08PM +0100, Svante Signell wrote: >> > One claim is changed, see below. > >> > On Fri, 2014-11-28 at 12:56 +0100, Svante Signell wrote: >> > > Hello, > >> > > In summary: >> > > a) Upgrades should _not_ change init: whatever is installed should be >> > > kept. >> > > b) New installs should get systemd-sysv as default init with a debconf >> > > message about alternative init systems. > >> > Since there is no interest in adding a debconf message on new installs, >> > I wish for a menu entry in the advanced part of the installer to be able >> > to install a new system with sysvinit-core or upstart! > >> That's even more unlikely than to add a debconf message (which would be >> package-owned). Yes, debian-installer is frozen. This would add new >> udebs, new strings, new everything. We're actually trying to release. > >Debian releases when it's ready. If large numbers of our users are going to >have a bad experience with jessie as a result of being switched to systemd, >then we should take appropriate steps to address that, even if that means >unfreezing the installer. > >I am not saying that making init systems a choice in the installer is the >right solution here; I don't think that it is. But I also don't think that >the release freeze can reasonably be an argument against it. Amen. With all the technical issues in systemd popping up just now, we have frozen prematurely. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1xupbp-0002gh...@swivel.zugschlus.de
Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
On Sat, 2014-11-29 at 22:01 +0100, Philipp Kern wrote: > On 2014-11-29 21:30, Steve Langasek wrote: > > Debian releases when it's ready. If large numbers of our users are > > going to > > have a bad experience with jessie as a result of being switched to > > systemd, > > then we should take appropriate steps to address that, even if that > > means > > unfreezing the installer. > > Sure. But where is the evidence for that? Is there a bug that has been > agreed upon to be RC? > > > I am not saying that making init systems a choice in the installer is > > the > > right solution here; I don't think that it is. But I also don't think > > that > > the release freeze can reasonably be an argument against it. > > Not even the release freeze, rather the d-i freeze. Unless this is RC > for d-i, that is Ok, I've tried to no avail. Debian is no democracy (maybe never was). ctte do as you feel there are no alternative solutions, just state the fact with your decision EOT. -- 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/1417296351.6826.13.ca...@gmail.com
Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
On 2014-11-29 21:30, Steve Langasek wrote: Debian releases when it's ready. If large numbers of our users are going to have a bad experience with jessie as a result of being switched to systemd, then we should take appropriate steps to address that, even if that means unfreezing the installer. Sure. But where is the evidence for that? Is there a bug that has been agreed upon to be RC? I am not saying that making init systems a choice in the installer is the right solution here; I don't think that it is. But I also don't think that the release freeze can reasonably be an argument against it. Not even the release freeze, rather the d-i freeze. Unless this is RC for d-i, that is. Kind regards Philipp Kern -- 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/fb3501d01e459459d6fc914e13e8a...@hub.kern.lc
Bug#762194: Proposal for upgrades to jessie
* Svante Signell , 2014-11-29, 21:27: Debian will not be as it was historically Indeed! Debian is going to be more awesome than it historically was (with or without systemd overhead). -- Jakub Wilk -- 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/20141129205008.ga1...@jwilk.net
Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
On Sat, 2014-11-29 at 21:27 +0100, Svante Signell wrote: > But it does not seem like you are realizing what is > happening unfortunately. Debian will not be as it was historically due > to this issue. Maybe the new DDs are to young to learn from history? Please don't patronise people. Just because someone disagrees with you, it doesn't mean that they're naive and unseeing and would be so much better off if you could just lift the mist from in front of their eyes. I'll stop contributing to the noise myself now, apologies to everyone else. Regards, Adam -- 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/1417293389.2472.6.ca...@adam-barratt.org.uk
Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
On Sat, Nov 29, 2014 at 08:14:07PM +0100, Philipp Kern wrote: > On Sat, Nov 29, 2014 at 07:15:08PM +0100, Svante Signell wrote: > > One claim is changed, see below. > > On Fri, 2014-11-28 at 12:56 +0100, Svante Signell wrote: > > > Hello, > > > In summary: > > > a) Upgrades should _not_ change init: whatever is installed should be > > > kept. > > > b) New installs should get systemd-sysv as default init with a debconf > > > message about alternative init systems. > > Since there is no interest in adding a debconf message on new installs, > > I wish for a menu entry in the advanced part of the installer to be able > > to install a new system with sysvinit-core or upstart! > That's even more unlikely than to add a debconf message (which would be > package-owned). Yes, debian-installer is frozen. This would add new > udebs, new strings, new everything. We're actually trying to release. Debian releases when it's ready. If large numbers of our users are going to have a bad experience with jessie as a result of being switched to systemd, then we should take appropriate steps to address that, even if that means unfreezing the installer. I am not saying that making init systems a choice in the installer is the right solution here; I don't think that it is. But I also don't think that the release freeze can reasonably be an argument against it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20141129203049.gc16...@virgil.dodds.net
Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
On Sat, 2014-11-29 at 20:19 +, Adam D. Barratt wrote: > On Sat, 2014-11-29 at 20:40 +0100, Svante Signell wrote: > > This is another nail in the Universal OS coffin: Let's move to devuan, > > please! > > You are of course free to do that. This discussion is about what Debian > should do, however. If you wish to discuss Devuan, please do so in a > more appropriate forum. Yes, I'll do that. But it does not seem like you are realizing what is happening unfortunately. Debian will not be as it was historically due to this issue. Maybe the new DDs are to young to learn from history? -- 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/1417292862.6826.11.ca...@gmail.com
Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
On Sat, 2014-11-29 at 20:40 +0100, Svante Signell wrote: > This is another nail in the Universal OS coffin: Let's move to devuan, > please! You are of course free to do that. This discussion is about what Debian should do, however. If you wish to discuss Devuan, please do so in a more appropriate forum. Regards, Adam -- 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/1417292348.2472.4.ca...@adam-barratt.org.uk
Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
On 29-11-2014 19:40, Svante Signell wrote: [...] > This is another nail in the Universal OS coffin: Let's move to devuan, > please! Use Debian as upstream (as long as it lives) > > Yes, next Debian release is lendows, not jessie :( Thanks! We appreciate less noise on these lists and on the next release - which it's currently frozen, although you don't care. Good luck. -- Melhores cumprimentos/Best regards, Miguel Figueiredo -- 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/547a1846.7010...@debianpt.org
Re: Technical committee acting in gross violation of the Debian constitution
> Zbigniew Jędrzejewski-Szmek writes: > On Sat, Nov 29, 2014 at 06:33:44PM +, Ivan Shmakov wrote: > Zbigniew Jędrzejewski-Szmek writes: […] >>> The second part, making systemd portable, has already been widely >>> discussed. There are significant technical reasons why systemd is >>> Linux only. And the potential "recepients", like BSD, don't seem >>> to be interested anyway. >> Unless I be mistaken, that also /does/ mean Debian. That is: Debian >> GNU/kFreeBSD and Debian GNU/Hurd. > Yes, the technical reasons apply. The other reasons apply too, I > think: /kFreeBSD and /Hurd ports are interested in staying close to > their upstream projects and certainly don't have the manpower to take > on systemd porting on their own. My point is that Debian is bound to support non-Systemd installs as long as the two statements below remain true: • Debian supports non-Linux installs; • Systemd is Linux-only. And this is about the only thing about Systemd I do care of. (Curiously, from this point of view, being only available for Linux is actually the Systemd feature of most importance to me.) As for Systemd being the default (on Debian GNU/Linux, specifically), – I guess I shouldn’t bother. GNOME is also the default, but I cannot readily recall ever having it running on my Debian installs. […] -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- 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/871tolpz7z@violet.siamics.net
Re: Technical committee acting in gross violation of the Debian constitution
Martin Steigerwald writes: > Oh, holy… this… isn´t… true? Is it? No, it isn't. -- 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/87iohxzsnc.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me
Re: Technical committee acting in gross violation of the Debian constitution
Am Samstag, 29. November 2014, 20:30:07 schrieb Svante Signell: > On Sat, 2014-11-29 at 19:12 +0100, Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Nov 29, 2014 at 11:51:56AM +0100, Martin Steigerwald wrote: > > > Am Samstag, 29. November 2014, 01:32:22 schrieb Zbigniew Jędrzejewski- Szmek: > > New dbus client library is also slated to become > > public when its ready and kdbus is upstreamed. Various dbus apis > > are documented and stable. > > Have you seen this? > http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11 > -23T09_26_01.txt Oh, holy… this… isn´t… true? Is it? -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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/24869919.e9fro6jZMz@merkaba
Re: Technical committee acting in gross violation of the Debian constitution
On Sat, Nov 29, 2014 at 08:30:07PM +0100, Svante Signell wrote: > On Sat, 2014-11-29 at 19:12 +0100, Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Nov 29, 2014 at 11:51:56AM +0100, Martin Steigerwald wrote: > > > Am Samstag, 29. November 2014, 01:32:22 schrieb Zbigniew > > > Jędrzejewski-Szmek: > > > New dbus client library is also slated to become > > public when its ready and kdbus is upstreamed. Various dbus apis > > are documented and stable. > > Have you seen this? > http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt I have, and I wasn't particularly impressed. The guy has trouble figuring out what "LockSession(session)" could possibly mean. He criticizes the spec (from 2003) for being hard to implement and then libsystemd-bus for implementing it. He also misses the fact that d-bus performance has very little to do with the overhead of 4 bytes in the message header, but rather the latency caused by multiple context switches, user space querying /proc to gather information, repeated decodings of a message as it is passed along, and the occasional transfer of large buffers. So yeah, it's an uninformed rant with a vaguely defined target. Zbyszek -- 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/20141129194901.gd23...@in.waw.pl
Re: Technical committee acting in gross violation of the Debian constitution
Hi, Svante Signell writes: > Have you seen this? > http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt I started reading and I just had to stop after the first few sentences, where the author quotes the specification clearly out of context to imply a contradiction that is not there (he first quotes a sentence describing dbus as a binary protocol and then quotes a sentence describing the authontication protocol (which is only a very small part of the dbus-protocol, though the quote does not show this part) as being text-only. Really classy). The author is obviously a troll of the worst kind and I hope you do not think that this is an even remotely credible source. Best, Axel Wagner -- 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/87mw79zt85.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me
Re: Technical committee acting in gross violation of the Debian constitution
On Sat, 2014-11-29 at 20:27 +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Nov 29, 2014 at 06:33:44PM +, Ivan Shmakov wrote: > > > Zbigniew Jędrzejewski-Szmek writes: > > > > […] > > > > > The second part, making systemd portable, has already been widely > > > discussed. There are significant technical reasons why systemd is > > > Linux only. And the potential "recepients", like BSD, don't seem to > > > be interested anyway. > > > > Unless I be mistaken, that also /does/ mean Debian. That is: > > Debian GNU/kFreeBSD and Debian GNU/Hurd. > Yes, the technical reasons apply. The other reasons apply too, I think: > /kFreeBSD and /Hurd ports are interested in staying close to their > upstream projects and certainly don't have the manpower to take on > systemd porting on their own. > > > Sorry for jumping into this discussion without any thorough > > reading, but I have mentioned this point a few times already at > > (other) mailing lists and on IRC, so if I got it wrong, I’d like > > to be corrected, so that I won’t spread confusion any further. > Please don't do that. Those threads are long enough already, without > rehashing things which can be googled in 30s. The best for kFreeBSD and Hurd would be to abandoning the Debian ship. It is sinking :( (just let the devuan people get things in order first) -- 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/1417290209.6826.9.ca...@gmail.com
Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
On Sat, 2014-11-29 at 20:14 +0100, Philipp Kern wrote: > On Sat, Nov 29, 2014 at 07:15:08PM +0100, Svante Signell wrote: > > One claim is changed, see below. > > > > On Fri, 2014-11-28 at 12:56 +0100, Svante Signell wrote: > > > Hello, > > > > > In summary: > > > a) Upgrades should _not_ change init: whatever is installed should be > > > kept. > > > b) New installs should get systemd-sysv as default init with a debconf > > > message about alternative init systems. > > > > Since there is no interest in adding a debconf message on new installs, > > I wish for a menu entry in the advanced part of the installer to be able > > to install a new system with sysvinit-core or upstart! > > That's even more unlikely than to add a debconf message (which would be > package-owned). Yes, debian-installer is frozen. This would add new > udebs, new strings, new everything. We're actually trying to release. This is another nail in the Universal OS coffin: Let's move to devuan, please! Use Debian as upstream (as long as it lives) Yes, next Debian release is lendows, not jessie :( -- 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/1417290006.6826.7.ca...@gmail.com
Re: Embedded systems and systemd
On Sat, 2014-11-29 at 17:10 +0100, Simon Richter wrote: > Hi, > > On 29.11.2014 08:37, Tollef Fog Heen wrote: > > > I'm not Simon, but one valid argument I've heard is that embedded stuff > > has a tendency to get stuck on old vendor kernels, something that > > doesn't work so well when systemd uses newer kernel interfaces. > > Correct, and I don't see the situation improving much outside the hacker > community. > > Embedded board support packages are supposed to be supported for many > years, For some value of 'support'. > so vendors generally branch off the then-current stable kernel > when the device goes on sale, and do not follow updates afterwards, > because the alternative would be supporting each customer with the > kernel version that was current when they bought the device, because > integrators are not interested in updating their kernels either. The alternative is working upstream, and on the LTSI, so that BSPs are only necessary for early samples. > There are a few devices that have proper support in mainline kernels, > such as the Raspberry Pi, The Raspberry Pi is not supported in mainline kernels, at least not in a useful way. > but these have a completely different target > audience; for most of the devices out there running Linux there is no > real incentive for the vendor to ship updated kernels, nor a critical > mass in the community to keep up to date. It is up to the customers to demand this. (And if end users find they are exposed to known security issues because product and SoC manufacturers don't feel any moral obligation to update them, a few lawsuits might get their attention.) Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less. signature.asc Description: This is a digitally signed message part
Re: Technical committee acting in gross violation of the Debian constitution
On Sat, 2014-11-29 at 19:12 +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Nov 29, 2014 at 11:51:56AM +0100, Martin Steigerwald wrote: > > Am Samstag, 29. November 2014, 01:32:22 schrieb Zbigniew Jędrzejewski-Szmek: > New dbus client library is also slated to become > public when its ready and kdbus is upstreamed. Various dbus apis > are documented and stable. Have you seen this? http://gentooexperimental.org/~patrick/weblog/archives/2014-11.html#e2014-11-23T09_26_01.txt -- 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/1417289407.6826.5.ca...@gmail.com
Re: upgrading to jessie broke usb_storage on a mode switched device
On Sat, 2014-11-29 at 12:20 +0100, Tomas Pospisek wrote: [...] > So in these logs we see that: > > 1. when I plug in my smartphone > 2. the kernel tells me he has noticed it and correctly reports the >newly discovered device to the log > 3. also the usb-storage module reports that it is seeing a new storage >device on the USB bus. Also correct. > 4a. next the mtp-probe reports that the new device is not a MTP device. > Which is not really totally correct, because the device *is* a MTP > device, but it only hasn't been mode-switched to that mode of > operation. But maybe that's just semantical hair splitting on my > part, and does not matter here - I don't know. I think we can't generically tell what other modes might be available. > After that nothing more happens. Did you expect the phone to be switched to MTP mode? Or is that controlled only by the phone? > Now when I do "rmmod usb_storage && modprobe usb_storage" then > everything runs exactly like it did before, except, that: > > 4b. in this case mtp-probe apparently doesn't have a look on the newly > appeared device. No new device has appeared. > 5. instead usbcore tells me that it >"registered new interface driver usb-storage" > 6. and subsequently some part (which one?) of the system scans >the available SCSI devices > 7. and then some part (which one?) of the system has a look at the >newly discovered SCSI device and then > 8. makes the SCSI device known and available to the user as /dev/sdb* > > Now my question: > > Q: Who in the Linux ecosystem is responsible for triggering or >preventing usbcore as in 4b. to have a look at the USB devices? > > Is that someone udev? Device enumeration and matching devices to drivers is all done in-kernel. (Userland can override device/driver matching to some extent, but rarely does.) udev is responsible for loading driver modules, creating device nodes under /dev, and so on. It can also run arbitrary commands, which could include triggering a mode switch if possible. > To me it appears that once 4b. is done, that triggers the next cascade > of actions, which ultimately leads to the device on the USB bus being > registered as a block device under /dev/sdb. And is that what you expected to happen automatically (after 3)? It is hard to understand why it didn't happen then but only after reloading the driver. Perhaps the phone's USB mass storage implementation doesn't work if the usb-storage driver probes it too soon after it's attached. This might need a workaround in the driver. > All of this is of course speculation without any knowledge of how stuff > works in reality, so could be pure imagination. > > My working hypothesis is that once I know the answer to the Q: above, > I'll know the culprit and will either/or/and be able to dig further or > report a bug against it. > > ? > *t It's the kernel; 'reportbug kernel' should work. Ben. -- Ben Hutchings Q. Which is the greater problem in the world today, ignorance or apathy? A. I don't know and I couldn't care less. signature.asc Description: This is a digitally signed message part
Re: Technical committee acting in gross violation of the Debian constitution
On Sat, Nov 29, 2014 at 06:33:44PM +, Ivan Shmakov wrote: > > Zbigniew Jędrzejewski-Szmek writes: > > […] > > > The second part, making systemd portable, has already been widely > > discussed. There are significant technical reasons why systemd is > > Linux only. And the potential "recepients", like BSD, don't seem to > > be interested anyway. > > Unless I be mistaken, that also /does/ mean Debian. That is: > Debian GNU/kFreeBSD and Debian GNU/Hurd. Yes, the technical reasons apply. The other reasons apply too, I think: /kFreeBSD and /Hurd ports are interested in staying close to their upstream projects and certainly don't have the manpower to take on systemd porting on their own. > Sorry for jumping into this discussion without any thorough > reading, but I have mentioned this point a few times already at > (other) mailing lists and on IRC, so if I got it wrong, I’d like > to be corrected, so that I won’t spread confusion any further. Please don't do that. Those threads are long enough already, without rehashing things which can be googled in 30s. Zbyszek > FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A Ah, you're not really looking for answers. Why didn't you put that in a more visible place, and not in the footer so I only see it after writing a response? [A purely rhetorical question, no need to answer.] -- 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/20141129192713.gc23...@in.waw.pl
Re: Bug#762194: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
On Sat, Nov 29, 2014 at 07:15:08PM +0100, Svante Signell wrote: > One claim is changed, see below. > > On Fri, 2014-11-28 at 12:56 +0100, Svante Signell wrote: > > Hello, > > > In summary: > > a) Upgrades should _not_ change init: whatever is installed should be > > kept. > > b) New installs should get systemd-sysv as default init with a debconf > > message about alternative init systems. > > Since there is no interest in adding a debconf message on new installs, > I wish for a menu entry in the advanced part of the installer to be able > to install a new system with sysvinit-core or upstart! That's even more unlikely than to add a debconf message (which would be package-owned). Yes, debian-installer is frozen. This would add new udebs, new strings, new everything. We're actually trying to release. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Technical committee acting in gross violation of the Debian constitution
> Zbigniew Jędrzejewski-Szmek writes: […] > The second part, making systemd portable, has already been widely > discussed. There are significant technical reasons why systemd is > Linux only. And the potential "recepients", like BSD, don't seem to > be interested anyway. Unless I be mistaken, that also /does/ mean Debian. That is: Debian GNU/kFreeBSD and Debian GNU/Hurd. Sorry for jumping into this discussion without any thorough reading, but I have mentioned this point a few times already at (other) mailing lists and on IRC, so if I got it wrong, I’d like to be corrected, so that I won’t spread confusion any further. […] -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- 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/8761dxq2k7@violet.siamics.net
Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie (lendows 1)
One claim is changed, see below. On Fri, 2014-11-28 at 12:56 +0100, Svante Signell wrote: > Hello, > In summary: > a) Upgrades should _not_ change init: whatever is installed should be > kept. > b) New installs should get systemd-sysv as default init with a debconf > message about alternative init systems. Since there is no interest in adding a debconf message on new installs, I wish for a menu entry in the advanced part of the installer to be able to install a new system with sysvinit-core or upstart! -- 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/1417284908.6826.3.ca...@gmail.com
Re: Technical committee acting in gross violation of the Debian constitution
On Sat, Nov 29, 2014 at 11:51:56AM +0100, Martin Steigerwald wrote:
> Am Samstag, 29. November 2014, 01:32:22 schrieb Zbigniew Jędrzejewski-Szmek:
> > On Thu, Nov 27, 2014 at 10:02:06PM +0100, Martin Steigerwald wrote:
> > > And well, I also wonder why systemd --user functionality is in the *same*
> > > binary than the PID 1 stuff… but well… I brought this upstream to no
> > > avail.
> >
> > OK, since this is a different forum, let me go over the reasons once again.
> >
> > The code paths in systemd which differ between --system and --user are
> > relatively small. One part that is the table of paths where to load
> > units from (/etc/systemd/system vs. /etc/systemd/user, /run/systemd/system
> > vs $XDG_RUNTIME_DIR/systemd/user, etc). Another part says (grossly
> > simplyfying) if ("--system" && !test_mode && !virtualized_in_container())
> > setup_filesystems();
> > But those are just a few (important, but still) parts of the code. The
> > majority, like the unit dependency logic, starting of processes,
> > notifications from services, opening of sockets, watching of paths,
> > etc, etc, are all shared. Actually systemd --user is probably closer
> > to systemd --system running in a container than to systemd --system
> > running on the host, because both run without full privileges and
> > simply skip mounting of various things and other low-level setup.
> >
> > In this scenario it is natural to structure the code as a single binary
> > that conditionalized parts of it logic as necessary.
>
> Thank you for your explaination. I do not agree, as it still seems to be done
> this way out of technical convenience. And I think thats not enough of a
> reason. And, in addition to that this is PID 1, not the usual application –
> and even there… in KDE / Plasma world developers are spending *a lot of
> energy* over the last years and still to separate out things which leads to
> KDE Frameworks 5, i.e. to specifically do things that aren´t convenient in
> the
> short run.
Hi,
you seam to treat "technical convenience" as something of not
particular importance. But in software development "technical
convenience" is often the thing that makes project that is finished in
reasonable time and fun to work at and maintainable without tearing your
hair out.
You are essentially arguing that systemd developers (which includes me
btw) should take upon themselves additional work to maintain stable
APIs for internal components and also port systemd to other systems. The
first one is quite a lot of work, but feasible. It would probably by
less useful than you think though. The parts that are generally useful
and stable, like journal client API, logind client API, some utilities
that were in libsystemd-daemon, libsystemd-id128, are already provided
as shared libraries. New dbus client library is also slated to become
public when its ready and kdbus is upstreamed. Various dbus apis
are documented and stable. The parts that remain are really internal
and fast-changing stuff. I mentioned config file parsing and string
handling - those are not general purpose functions, they support
*systemd* config file syntax and are refactored and changed whenever
it is useful for the rest of the code. It's true that they could be
useful for other projects, but at a fairly heavy price. It would come
in two "installments": one, developers would have to diverge from work
on new features, bug fixes, documentation, or whatever, and spend
"*a lot of energy*" on this and the bugs it introduces by itself
instead. And two, fixed API for low-level internal stuff would create
a gorset and slow down systemd development. You could argue the same
for the linux kernel, but Linus is pretty adamant about not providing a
stable internal API.
The second part, making systemd portable, has already been widely
discussed. There are significant technical reasons why systemd is
Linux only. And the potential "recepients", like BSD, don't seem to be
interested anyway.
So yeah, we'll have to agree to disagree.
> However, some questions:
>
> So the systemd --user functionality does not add much to the binary size? And
> is the detection of the use case systemd binary runs in reliable? What
> additional failure cases for the necessary PID 1 functionality does combining
> these functionalities create?
Detection is trivial: getpid() == 1. From the top of my head, I don't recall
problems going in this direction. There were a few bugs the other way - where
--user or --test modes would attempt to do more stuff then they should, because
some part of the code was not properly conditionilized.
>
> > > At least the logind stuff appears to be separate:
> > Yes, logind does not share many high-level code paths with the systemd
> > binary, so it is natural to keep them separate.
> >
> > OTOH, systemd and systemd-logind use the same primitives like string
> > handling, configuration file parsing (including the logic of drop-in
> > directories and /etc-overrid
Re: successful upgrade to jessie - thanks!
On Sat, 29 Nov 2014 11:36:20 +0100, Marc Haber wrote: > On Sat, 29 Nov 2014 08:34:46 +0100, Matthias Urlichs > wrote: >>Marc Haber: >>> It's learning and understanding more than just a few bizarre new >>> concepts. >>> >>I learned. I (think I) understand. But I do not think these fancy new >>concepts are bizarre at all. If anything, they make my life way easier. >> >>If anything, IMHO using words like "bizarre" isn't exactly conductive to >>rational dialogue … > > If we actually plan to release a distribution where a central piece of > software behaves contrary to its documentation, "bizarre" seems quite > logical to me. > > Right now, we have an init system that has something named "runlevel3", > which makes people say "Yeah, finally a concept that I am already > familiar with" and then find themselves stymied when this "something" > does something quite different from the something we used to know as > "runlevel3". Same goes for a something for which its documentation says > "non-graphical" with another something called "graphical", with no > visible differences between those two things' behavior, a system running > X. > > This is only a mild nuisance if everything is fine, but if a system dies > when X starts up, not having a clear way to prevent X from coming up is > bad. This is indeed unfortunate. Because runlevel[234] are links to multi-user.target it means that distinctions between those runlevels are not preserved. It also means that the ability to differentiate between graphical.target and multi-user.target is almost lost for systems where the dm does not provide a native systemd unit, because the sysv generator will generate links from runlevel[2345].target.wants/ to the dm. This is the case with kdm: % cd /run/systemd/generator.late % ls -l runlevel[2345].target.wants/kdm.service lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel2.target.wants/kdm.service -> /run/systemd/generator.late/kdm.service lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel3.target.wants/kdm.service -> /run/systemd/generator.late/kdm.service lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel4.target.wants/kdm.service -> /run/systemd/generator.late/kdm.service lrwxrwxrwx 1 root root 39 Nov 28 08:24 runlevel5.target.wants/kdm.service -> /run/systemd/generator.late/kdm.service Unless a user has disabled kdm in runlevels [234], there is no way to boot the system without starting kdm. -- Saludos, Felipe Sateler -- 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/m5d1e0$eal$2...@ger.gmane.org
Re: Technical committee acting in gross violation of the Debian constitution
> Josselin Mouette writes: […] > Desktops (not only GNOME) use a very tiny bit of systemd, interfaces > that could be provided elsewhere. Is that “use” as in “if available” or is that actually “require and be sure to die unless provided”? (Please forgive my ignorance here, – my “desktop” runs Openbox ever since I’ve switched off TWM c. 2008, and I’m pretty sure that Openbox does not “use” Systemd or any related services.) > The real purpose of systemd is to provide a modern init system. I believe that the word “init” is misleading at best in this context. The SysVinit-based system traditionally used in Debian was indeed /mostly/ concerned with bringing the system up – that is, “initing” the system. On the contrary, Systemd seems to try to also encompass monitoring, time synchronization, user sessions, and, I presume, a load of other tasks. If anything, it seems to deserve something like Master Control Program for its name, – not something as mundane as an “init system.” -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- 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/87a93aotd9@violet.siamics.net
Re: Technical committee acting in gross violation of the Debian constitution
Hi, Cameron Norman writes: > Do you really think logind and systemd are the only pieces of C > software that struggle with strings or config parsing? Those are > definitely a couple of things that could be split out into a separate > library so we all do not have to either (a) suffer through it, > tediously writing another solution or (b) throw our software in > systemd's git repo and use the same release cycle and license and all > the other implications of being in the same repo (including not having > commit access to your own software automatically). > > The config aspects especially so. It would be very positive if > software knew they could just depend on a really simple library and > get config parsing for basically free, since then users would > eventually only have to know how to write one config format and > software would only have to know how to read (parse) that same one. There already are libraries to do that. For example libconfuse. If you ask why not everyone (or systemd) uses them, the answer is the same as to why one cannot blame the systemd people for not refactoring their parser into a separate library: Everyone has different requirements of a config file format and having one for all is hardly feasible. Really, I have the feeling that once we start criticising that systemd does not factor out their config-file parsing into a stable and separately maintained library, we are really just grasping at straws in finding flaws with it. Best, Axel Wagner -- 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/87tx1iylht.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me
Re: Embedded systems and systemd
Hi, On 29.11.2014 13:41, Alastair McKinstry wrote: > I'm heartened that some developers are doing the work to make > non-systemd remain a > viable option in debian, but for it not to degenerate into "the systemd > way / the less maintained > and tested non-systemd way", we need to promote the APIs and preserve them. Indeed, and I'm fairly confident that we still have a large enough group of maintainers interested in running traditional or alternative init systems that we can pull this off by simply running the systems ourselves and submitting patches, similarly to the way Debian ports are run. That does mean that maintainers should integrate these patches, even if they personally feel that this is a pointless exercise, because to other people, it isn't. Debian has always been great at choosing "both" when presented with two options, let's keep it that way. Simon signature.asc Description: OpenPGP digital signature
Re: Embedded systems and systemd
Hi, On 29.11.2014 08:37, Tollef Fog Heen wrote: > I'm not Simon, but one valid argument I've heard is that embedded stuff > has a tendency to get stuck on old vendor kernels, something that > doesn't work so well when systemd uses newer kernel interfaces. Correct, and I don't see the situation improving much outside the hacker community. Embedded board support packages are supposed to be supported for many years, so vendors generally branch off the then-current stable kernel when the device goes on sale, and do not follow updates afterwards, because the alternative would be supporting each customer with the kernel version that was current when they bought the device, because integrators are not interested in updating their kernels either. There are a few devices that have proper support in mainline kernels, such as the Raspberry Pi, but these have a completely different target audience; for most of the devices out there running Linux there is no real incentive for the vendor to ship updated kernels, nor a critical mass in the community to keep up to date. Simon signature.asc Description: OpenPGP digital signature
Re: curl and certificate verification in jessie
[ not sure what's the point of CCing debian-devel, but I kept it. I removed Ian from the chain though, since he hasn't been much involved with curl lately ] On sab, nov 29, 2014 at 01:10:20 +0100, Peter Palfrader wrote: > Hi, > > I recently started to move parts of debian.org's infrastructure to jessie. I > noticed a regression with software using curl to do https with certificate > verification. > > On wheezy, this works: > > | weasel@mipsel-manda-01:~$ cat /etc/apt/apt.conf.d/puppet-https-buildd > | Acquire::https::buildd.debian.org::CaInfo > "/etc/ssl/servicecerts/buildd.debian.org.crt"; > | weasel@mipsel-manda-01:~$ tail -n1 > /etc/apt/sources.list.d/buildd.debian.org.list > | deb https://buildd.debian.org/apt/ wheezy main > > I.e., I can use a local copy of the expected end-entity certificate to > authenticate a https server. > > On jessie this no longer works: > > } Err https://buildd.debian.org wheezy/main mipsel Packages > } server certificate verification failed. CAfile: > /etc/ssl/servicecerts/buildd.debian.org.crt CRLfile: none I assume that this is using apt-transport-https, which in turn uses libcurl3-gnutls. > Is this intentional, or is that a bug in either gnutls, curl, or the software > using these libraries? AFAICT this is due to the gnutls26 -> gnutls28 switch. Using libgnutls-dev to build curl instead of libgnutls28-dev makes it possible to point CURLOPT_CAINFO to a single leaf certificate and have the verification succeed. FWIW the current behaviour is the same with openssl. I don't know if there's a reason for it though. Cheers signature.asc Description: Digital signature
Re: Embedded systems and systemd
❦ 29 novembre 2014 12:41 GMT, Alastair McKinstry : > One concern I'd have is the lack of flexibility to produce a cut-down > system. The option of "a dedicated init=/custom-program", but lack of > an ntpd, for example, because ntp has been absorbed into systemd's > orbit and other ntpd's bitrotted. Unlikely to happen since systemd-timesyncd is not a full NTP daemon. It lacks ability to act as a server. -- /* Identify the flock of penguins. */ 2.2.16 /usr/src/linux/arch/alpha/kernel/setup.c signature.asc Description: PGP signature
Re: Embedded systems and systemd
> Why, precisely, do you foresee future problems with embedded systems > development? Personally, I'm looking forward to a much easier time > building future embedded systems using systemd, or the occasional > too-small-for-anything-else embedded system (that couldn't run standard > sysvinit or Debian for that matter) using a dedicated > init=/custom-program. One concern I'd have is the lack of flexibility to produce a cut-down system. The option of "a dedicated init=/custom-program", but lack of an ntpd, for example, because ntp has been absorbed into systemd's orbit and other ntpd's bitrotted. I'm heartened that some developers are doing the work to make non-systemd remain a viable option in debian, but for it not to degenerate into "the systemd way / the less maintained and tested non-systemd way", we need to promote the APIs and preserve them. > > - Josh Triplett > > - Alastair -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered. -- 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/5479bf03.8040...@sceal.ie
BSP in Alcester, GB, 16-18th January 2015
Hi, I will host a small BSP at my home in January over the weekend of 16th - 18th. Regrettably, I do not have enough room for more than a handful of attendees, so I have invited some that I know are interested. If you would particularly like to attend, please mail me privately and I'll see what we can do. (Alcester isn't particularly convenient if you don't have a car, although we do have ways around that.) -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
curl and certificate verification in jessie
Hi, I recently started to move parts of debian.org's infrastructure to jessie. I noticed a regression with software using curl to do https with certificate verification. On wheezy, this works: | weasel@mipsel-manda-01:~$ cat /etc/apt/apt.conf.d/puppet-https-buildd | Acquire::https::buildd.debian.org::CaInfo "/etc/ssl/servicecerts/buildd.debian.org.crt"; | weasel@mipsel-manda-01:~$ tail -n1 /etc/apt/sources.list.d/buildd.debian.org.list | deb https://buildd.debian.org/apt/ wheezy main I.e., I can use a local copy of the expected end-entity certificate to authenticate a https server. On jessie this no longer works: } Err https://buildd.debian.org wheezy/main mipsel Packages } server certificate verification failed. CAfile: /etc/ssl/servicecerts/buildd.debian.org.crt CRLfile: none Instead, I have to trust the corresponding root certificate or an intermediate (#771404). I noticed a similar issue with git, where using the EE-certificate or an intermediate as http.sslCAInfo fails to authenticate the server (#771170). Is this intentional, or is that a bug in either gnutls, curl, or the software using these libraries? I suspect that other users of curl/gnutls might be affected as well, and that saying "I only trust this exact certificate" is not a crazy and rare use-case. Thus, I'd like to learn more here and ideally have this resolved for jessie. Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- 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/20141129121020.gy20...@anguilla.noreply.org
Re: upgrading to jessie broke usb_storage on a mode switched device
So, since there hasn't been any reaction to this, let me try to ask a few additional questions, that might help me to find out where to dig next: Am 27.11.2014 um 18:53 schrieb Tomas Pospisek: > Am 27.11.2014 um 17:12 schrieb Thomas Goirand: >> On 11/27/2014 09:28 PM, Tomas Pospisek wrote: >>> Hello, >>> >>> after upgrading to jessie(-with systemd) connecting my mobile to the >>> latop as a usb storage device stopped working. >>> >>> I do have to "rmmod usb_storage && modprobe usb_storage" in order for >>> the usb storage devices to become visible every time. >>> >>> What is the suggested procedure from here on short of filing a bug >>> against "general"? I do not have an idea which component between >>> systemd/udev/usb_modeswitch/the kernel/or other is at fault here, if >>> even it's the fault of a single package at all. Where does the bug >>> belong to? Is this more appropriate for debian-user? >> >> This sounds like an udev/systemd issue. Do you have any kind of logs to >> provide? Does "dmesg" says something? Anything in the syslog^W systemd >> journal? > > Yes, /var/log/messages looks like this: > > Nov 27 13:46:41 hier kernel: [28652.975203] usb 4-1.1: new high-speed USB > device number 26 using ehci-pci > Nov 27 13:46:41 hier kernel: [28653.068821] usb 4-1.1: New USB device found, > idVendor=12d1, idProduct=1037 > Nov 27 13:46:41 hier kernel: [28653.068831] usb 4-1.1: New USB device > strings: Mfr=2, Product=3, SerialNumber=4 > Nov 27 13:46:41 hier kernel: [28653.068836] usb 4-1.1: Product: Android > Nov 27 13:46:41 hier kernel: [28653.068840] usb 4-1.1: Manufacturer: Android > Nov 27 13:46:41 hier kernel: [28653.068844] usb 4-1.1: SerialNumber: > 4C8BEFBC3276 > Nov 27 13:46:41 hier kernel: [28653.069822] usb-storage 4-1.1:1.0: USB Mass > Storage device detected > Nov 27 13:46:41 hier kernel: [28653.070344] scsi15 : usb-storage 4-1.1:1.0 > Nov 27 13:46:41 hier mtp-probe: checking bus 4, device 26: > "/sys/devices/pci:00/:00:1d.0/usb4/4-1/4-1.1" > Nov 27 13:46:41 hier mtp-probe: bus: 4, device: 26 was not an MTP device > Nov 27 13:46:42 hier usb_modeswitch: switch device 12d1:1037 on 004/026 > > And that's that. Now when I do "rmmod usb_storage && modprobe usb_storage" > the log continues like this: > > Nov 27 13:46:55 hier kernel: [28666.858764] usbcore: deregistering interface > driver usb-storage > Nov 27 13:47:01 hier kernel: [28672.635113] usb-storage 4-1.1:1.0: USB Mass > Storage device detected > Nov 27 13:47:01 hier kernel: [28672.635615] scsi16 : usb-storage 4-1.1:1.0 > Nov 27 13:47:01 hier kernel: [28672.635915] usbcore: registered new interface > driver usb-storage > Nov 27 13:47:02 hier kernel: [28673.633832] scsi 16:0:0:0: Direct-Access > LinuxFile-CD Gadget PQ: 0 ANSI: 2 > Nov 27 13:47:02 hier kernel: [28673.634382] scsi 16:0:0:1: Direct-Access > LinuxFile-CD Gadget PQ: 0 ANSI: 2 > Nov 27 13:47:02 hier kernel: [28673.634813] scsi 16:0:0:2: CD-ROM > LinuxFile-CD Gadget PQ: 0 ANSI: 2 > Nov 27 13:47:02 hier kernel: [28673.636127] sd 16:0:0:0: Attached scsi > generic sg2 type 0 > Nov 27 13:47:02 hier kernel: [28673.636856] sd 16:0:0:1: Attached scsi > generic sg3 type 0 > Nov 27 13:47:02 hier kernel: [28673.637294] sd 16:0:0:0: [sdb] Attached SCSI > removable disk > Nov 27 13:47:02 hier kernel: [28673.640180] sr1: scsi3-mmc drive: 0x/0x caddy > Nov 27 13:47:02 hier kernel: [28673.641721] sr 16:0:0:2: Attached scsi > generic sg4 type 5 > Nov 27 13:47:02 hier kernel: [28673.642690] sd 16:0:0:1: [sdc] Attached SCSI > removable disk > Nov 27 13:47:11 hier kernel: [28682.358352] sd 16:0:0:0: [sdb] 2310144 > 512-byte logical blocks: (1.18 GB/1.10 GiB) > Nov 27 13:47:11 hier kernel: [28682.363018] sdb: > Nov 27 13:47:13 hier kernel: [28684.404459] sd 16:0:0:1: [sdc] 62333952 > 512-byte logical blocks: (31.9 GB/29.7 GiB) > Nov 27 13:47:13 hier kernel: [28684.411152] sdc: sdc1 > Nov 27 13:47:23 hier kernel: [28695.050516] FAT-fs (sdc1): utf8 is not a > recommended IO charset for FAT filesystems, filesystem will be case sensitive! > Nov 27 13:47:23 hier kernel: [28695.075737] FAT-fs (sdc1): Volume was not > properly unmounted. Some data may be corrupt. Please run fsck. So in these logs we see that: 1. when I plug in my smartphone 2. the kernel tells me he has noticed it and correctly reports the newly discovered device to the log 3. also the usb-storage module reports that it is seeing a new storage device on the USB bus. Also correct. 4a. next the mtp-probe reports that the new device is not a MTP device. Which is not really totally correct, because the device *is* a MTP device, but it only hasn't been mode-switched to that mode of operation. But maybe that's just semantical hair splitting on my part, and does not matter here - I don't know. After that nothing more happens. Now when I do "rmmod usb_storage && modprobe usb_storage" then everything runs exactly like it did before, except
Bug#771415: ITP: libarray-heap-perl -- perl module implementing heaps/priority queues
Package: wnpp Severity: wishlist Owner: Slaven Rezic * Package name: libarray-heap-perl Version : 3.1 Upstream Author : Marc Lehmann * URL : https://metacpan.org/release/Array-Heap * License : Artistic & GPL Programming Lang: Perl Description : perl module implementing heaps/priority queues There are a multitude of heap and heap-like modules on CPAN, you might want to search for /Heap/ and /Priority/ to find many. They implement more or less fancy datastructures that might well be what you are looking for. This module takes a different approach: It exports functions (i.e. no object orientation) that are loosely modeled after the C++ STL's binary heap functions. They all take an array as argument, just like perl's built-in functions push, pop etc. The implementation itself is in C for maximum speed. -- 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/20141129104527.1170.15840.reportbug@eserte
Re: splitting source packages
Am Samstag, 29. November 2014, 10:49:34 schrieb Martin Steigerwald: > Am Donnerstag, 27. November 2014, 16:50:12 schrieb Neil Williams: > > On Thu, 27 Nov 2014 16:24:12 +0100 > > > > Matthias Urlichs wrote: > > > Hi, > > > > > > Neil Williams: > > > > By having separate source packages, a stable API becomes mandatory. > > > > > > You're correct in that it is easier to keep an API stable when you > > > have separate repositories. But that is not a hard requirement. There > > > are other ways to keep APIs stable. Like, for instance, publishing a > > > specification (once you _have_ a stable API) and sticking to that. > > > > Programmers are lazy, we all know this. If a #include "local.h" will > > fix a scoping problem, someone will do it. Keeping to an external > > specification intended for "others" without rigorous code review is no > > fun either. > > > > So, in practical terms, separate source repositories become all but > > essential. > > > > > But when things are in flux and you're in the process of figuring out > > > what the API should look like in the first place, having multiple > > > places to update, which can and will get out of sync, is no fun. > > > > It can also be when this approach is actually of the most value as it > > protects against regressions and complex failures. A stable API > > protects *against* having to update multiple places at the same time - > > you add functionality without removing the old functionality, so the > > external source packages can migrate in their own sweet time. Being out > > of sync is only a problem if the API is not sufficiently stable or > > comprehensive. We have symbols files for this kind of thing - at least > > in some languages... ;-) Fill the deprecated code with warnings if you > > have to but keep to the API. Fix the components in the order of the > > severity of the problems with the old code as used in that component. > > > > The whole point of a stable API is that backwards and forwards > > compatibility is retained until such time as there are no extensions or > > components using that support - at which time the base library goes for > > a SONAME transition and everyone is happy. Deprecate old functionality > > without removing the functions, add new functions, migrate through the > > components gradually. Simple. > > > > Start with the API. It's not as if a package which is considered ready > > for release into the stable suite of multiple distributions can > > possibly be in such a state of flux that an API cannot be constructed. > > If it is, the package is release-critical buggy by definition. Broken by > > design (or lack of). > > > > Yes, in the first proof of concept days when maybe you aren't even sure > > which language(s) or build system to use and it only exists on your own > > system or a personal VCS repo - then there can be sufficient flux to > > prevent an API being designed. However, packages in Debian are > > generally quite a long way on from that point - especially if those > > packages are to be considered as part of a stable distribution release. > > > > Let's move away from upstreams who make it hard to put their software > > into a collection in a flexible and stable manner. Push back and > > explain the benefits of small, compartmentalised source packages and a > > stable API. It will make the work of the release team easier and it > > will make it easier for developers to improve the code more generally. > > +1 > > Technical convenience is not enough. In my oppinion that is. There are different oppions. All of them are valid. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Bug#771414: ITP: bbbike -- route planner for cyclists
Package: wnpp Severity: wishlist Owner: Slaven Rezic * Package name: bbbike Version : 3.18 Upstream Author : Slaven Rezic * URL : http://bbbike.sourceforge.net * License : Artistic & GPL Programming Lang: Perl Description : route planner for cyclists BBBike is an information system for cyclists in Berlin and Brandenburg (Germany), and, using OpenStreetMap and the BBBike @ World project, for more than 200 cities around the world. It has the following features: * Displays a map with streets, railways, rivers, parks, altitude, and other features * Finds and shows routes between two points * Route-finder can be customized to match the cyclist's preferences: fastest/nicest route, take wind directions and hills into account, etc. * Bike power calculator * Automatically fetches the current weather data -- 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/20141129105638.5726.93478.reportbug@eserte
Re: Technical committee acting in gross violation of the Debian constitution
Am Samstag, 29. November 2014, 01:32:22 schrieb Zbigniew Jędrzejewski-Szmek:
> On Thu, Nov 27, 2014 at 10:02:06PM +0100, Martin Steigerwald wrote:
> > And well, I also wonder why systemd --user functionality is in the *same*
> > binary than the PID 1 stuff… but well… I brought this upstream to no
> > avail.
>
> OK, since this is a different forum, let me go over the reasons once again.
>
> The code paths in systemd which differ between --system and --user are
> relatively small. One part that is the table of paths where to load
> units from (/etc/systemd/system vs. /etc/systemd/user, /run/systemd/system
> vs $XDG_RUNTIME_DIR/systemd/user, etc). Another part says (grossly
> simplyfying) if ("--system" && !test_mode && !virtualized_in_container())
> setup_filesystems();
> But those are just a few (important, but still) parts of the code. The
> majority, like the unit dependency logic, starting of processes,
> notifications from services, opening of sockets, watching of paths,
> etc, etc, are all shared. Actually systemd --user is probably closer
> to systemd --system running in a container than to systemd --system
> running on the host, because both run without full privileges and
> simply skip mounting of various things and other low-level setup.
>
> In this scenario it is natural to structure the code as a single binary
> that conditionalized parts of it logic as necessary.
Thank you for your explaination. I do not agree, as it still seems to be done
this way out of technical convenience. And I think thats not enough of a
reason. And, in addition to that this is PID 1, not the usual application –
and even there… in KDE / Plasma world developers are spending *a lot of
energy* over the last years and still to separate out things which leads to
KDE Frameworks 5, i.e. to specifically do things that aren´t convenient in the
short run.
However, some questions:
So the systemd --user functionality does not add much to the binary size? And
is the detection of the use case systemd binary runs in reliable? What
additional failure cases for the necessary PID 1 functionality does combining
these functionalities create?
> > At least the logind stuff appears to be separate:
> Yes, logind does not share many high-level code paths with the systemd
> binary, so it is natural to keep them separate.
>
> OTOH, systemd and systemd-logind use the same primitives like string
> handling, configuration file parsing (including the logic of drop-in
> directories and /etc-overrides-/run-overrides-/usr/lib), and a bunch
> of other utility functions, which are provided by the shared systemd
> libraries, so it is much easier to develop them in a single repository.
>
> I hope this explains things.
None of like string handling and configuration file parsing seems to be that
special that it needs to be implemented (again?) just for systemd in my
oppinion. The problem of INI file parsing has been solved before, the problem
of string handling as well, a dozen of times maybe.
Well, I hear your explaination and I value your point of view. I acknowledge
it.
Yet, I do not agree.
So maybe at this time, we can just keep it at that. Especially as these are
upstream decisions.
But, in the end here it is about how Debian deals with upstream decisions like
this, and I think here it is where the gross disagreements are.
I personally would feel much more comfortable about systemd, if its upstream
developers made the necessary work for modularization, cross platform
portatibility and so on. Cause not doing so creates *additional* work and
*codepaths* in other software as long as systemd provides functionality that
other software would use like logind as ConsoleKit replacement.
KDE and GNOME if to stay portable need several code paths for using systemd on
Linux and something else elsewhere additional stuff, like the session handling
things. Thus systemd pushes responsibility for platform adaptability upwards
in the stack, and urges other systems to re-implement the same interfaces…
without, actually having seeked any agreement on those with the BSD or Hurd
folks.
And that concerns me. Its a mechanism to offer new functionality with a new
software (systemd), then try to convince others to use it, and then requiring
all other platforms where systemd does not run to play catch up and use the
same interfaces or try to port higher level application which rely on this
functionality themselves. And I think I am perfectly able to proove this kind
of behavior of systemd upstream by providing links.
But enough of this, technical arguments have been made already. Let me try to
move beyond that:
Now, you can acknowledge my concern or not.
But I think in either case it is healthy for me to accept you have or having
explained a different oppinion (is it yours?). And healthy for you to accept
that I have a different oppinion.
I still do not see any solution for the concerns and polarity the way systemd
upst
Re: successful upgrade to jessie - thanks!
On Sat, 29 Nov 2014 08:34:46 +0100, Matthias Urlichs wrote: >Marc Haber: >> It's learning and understanding more than just a few bizarre new concepts. >> >I learned. I (think I) understand. But I do not think these fancy new >concepts are bizarre at all. If anything, they make my life way easier. > >If anything, IMHO using words like "bizarre" isn't exactly conductive >to rational dialogue … If we actually plan to release a distribution where a central piece of software behaves contrary to its documentation, "bizarre" seems quite logical to me. Right now, we have an init system that has something named "runlevel3", which makes people say "Yeah, finally a concept that I am already familiar with" and then find themselves stymied when this "something" does something quite different from the something we used to know as "runlevel3". Same goes for a something for which its documentation says "non-graphical" with another something called "graphical", with no visible differences between those two things' behavior, a system running X. This is only a mild nuisance if everything is fine, but if a system dies when X starts up, not having a clear way to prevent X from coming up is bad. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1xufo0-0006iy...@swivel.zugschlus.de
Re: successful upgrade to jessie - thanks!
On Sat, 29 Nov 2014 09:09:19 +0100, Matthias Urlichs wrote: >Marc Haber: >> Which significantly changes things in Jessie since the majory of >> services is still started via the old rcX.d mechanism, and thus >> starting to runlevels behaves completely different from what users >> expect. >> >Well, I wouldn't expect runlevel 2 to start a graphical desktop either. >But it does; my /etc/inittab states that "2" is the default runlevel >and an unmodified /etc/init.d/gdm3 contains > ># Default-Start: 2 3 4 5 > >So, sorry, but the default behavior is already broken for a whole lot of >users – who simply fail to notice. There is _no_way_ I can boot my desktops >to a sane multi-user state (i.e. no X11 or *dm, if one of these decides to >act up and wedge the system) without jumping through hoops, and there has >not been one for ages. I have my runlevel 3 configured to not start kdm for ages, for exactly the reason that there might be situations where one wants to debug issues that survice when starting up X. It was unexpected to have this taken away from me when my system was upgraded to systemd. >At least systemd's named targets actually mean something. Which makes the surprise even worse when the symbolic name does not match the exact behavior. >> This is bad. > >Please consider that Fedora has changed their init system twice, so far. >Their world did not end when they did that, so please don't assume that >it will when we switch. I didn't. We even survived the libc5 => glibc move, and that was much less painful than what our users are facing once we have pushed the prematurely frozen jessie out of the door. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1xufhc-0006hk...@swivel.zugschlus.de
Re: [Pkg-javascript-devel] Javascript trigger design
Le vendredi 28 novembre 2014 à 20:46 +0100, Jonas Smedegaard a écrit : > Quoting Thorsten Glaser (2014-11-28 13:20:36) > > On Fri, 28 Nov 2014, Thomas Goirand wrote: > > > >> It's been a long time I've been thinking about it, and I believe that > >> the only way to do this, would be to use triggers. Though I have > >> never > > > Look at libjs-protoaculous which combines prototype and scriptaculous > > into one (possibly minified) js file. In (our inhouse version of) > > FusionForge, we just depend on it, and it contains all the trigger and > > dependency magic needed for that. > > Just looking at the package name that seems not an ideal aproach: Should > we then make packages for each combination of libraries to be merged > together, or am I missing a more clever logic? Or do you perhaps point > at that package not suggesting duplicating it but instead cherry-picking > triggers for a system-wide structure? I suggest bundling javascript, stylesheets, images, assets in general should be done using a custom, per-package, makefile (or makefile target). Something in postinst ? You can't standardize upon absence of standard. Jérémy. -- 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/1417255814.3889.3.ca...@melix.org
Re: splitting source packages
Am Donnerstag, 27. November 2014, 16:50:12 schrieb Neil Williams: > On Thu, 27 Nov 2014 16:24:12 +0100 > > Matthias Urlichs wrote: > > Hi, > > > > Neil Williams: > > > By having separate source packages, a stable API becomes mandatory. > > > > You're correct in that it is easier to keep an API stable when you > > have separate repositories. But that is not a hard requirement. There > > are other ways to keep APIs stable. Like, for instance, publishing a > > specification (once you _have_ a stable API) and sticking to that. > > Programmers are lazy, we all know this. If a #include "local.h" will > fix a scoping problem, someone will do it. Keeping to an external > specification intended for "others" without rigorous code review is no > fun either. > > So, in practical terms, separate source repositories become all but > essential. > > > But when things are in flux and you're in the process of figuring out > > what the API should look like in the first place, having multiple > > places to update, which can and will get out of sync, is no fun. > > It can also be when this approach is actually of the most value as it > protects against regressions and complex failures. A stable API > protects *against* having to update multiple places at the same time - > you add functionality without removing the old functionality, so the > external source packages can migrate in their own sweet time. Being out > of sync is only a problem if the API is not sufficiently stable or > comprehensive. We have symbols files for this kind of thing - at least > in some languages... ;-) Fill the deprecated code with warnings if you > have to but keep to the API. Fix the components in the order of the > severity of the problems with the old code as used in that component. > > The whole point of a stable API is that backwards and forwards > compatibility is retained until such time as there are no extensions or > components using that support - at which time the base library goes for > a SONAME transition and everyone is happy. Deprecate old functionality > without removing the functions, add new functions, migrate through the > components gradually. Simple. > > Start with the API. It's not as if a package which is considered ready > for release into the stable suite of multiple distributions can > possibly be in such a state of flux that an API cannot be constructed. > If it is, the package is release-critical buggy by definition. Broken by > design (or lack of). > > Yes, in the first proof of concept days when maybe you aren't even sure > which language(s) or build system to use and it only exists on your own > system or a personal VCS repo - then there can be sufficient flux to > prevent an API being designed. However, packages in Debian are > generally quite a long way on from that point - especially if those > packages are to be considered as part of a stable distribution release. > > Let's move away from upstreams who make it hard to put their software > into a collection in a flexible and stable manner. Push back and > explain the benefits of small, compartmentalised source packages and a > stable API. It will make the work of the release team easier and it > will make it easier for developers to improve the code more generally. +1 Technical convenience is not enough. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: Embedded systems and systemd
Hi, Tollef Fog Heen: > I'm not Simon, but one valid argument I've heard is that embedded stuff > has a tendency to get stuck on old vendor kernels, something that > doesn't work so well when systemd uses newer kernel interfaces. > That attitude is unfortunately not limited to "traditional" embedded systems; I made the mistake of buying a heap of ODROID-U2 cubes before I learned that they have no plans to upstream their kernel changes. :-( > Apart from «don't use new kernel interfaces» (something that upstream > won't do, ditto for adding workarounds fro old kernels), I don't really > see this as easily fixable. > Mmh. If we're talking about > > building future embedded systems using systemd then presumably that system's kernel is new enough. Otherwise, a legacy system running sysVrc will presumably continue to do so _and_ Debian will probably continue to ship sysVrc files that are good enough for embedded systems (*), so I guess I don't really . (*) IME one key feature you might not need on embedded systems is a way to reliably shut down services, as the things tend to simply get unplugged or disconnected. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: ITP: cruft-ng -- program that finds any cruft built up on your system / rewrite in C
> > Here is my ITP for my rewrite of cruft's engine. > > I think you might want to email debian-mentors, with a sponsorship request > (an RFS bug), rather than debian-devel, that is intended as a mailing list > for technical discussions. > See https://mentors.debian.net/sponsors Ok thanks for advice, It's already in the NEW queue. I posted here on purpose: this a remake of a native debian package, and a long term goal - I mean : since 1998[1] - was to have some of it functionality moved in dpkg itself. Here is a more detailed proposal that only pickup the lowest hanging fruit, that would be completely optional and left to each packager choice: https://wiki.debian.org/Cruft/purge TL;DR: move some of postrm scripts "rm -f" lines in machine-readable files than can also be re-used by "dpkg -S" [1] https://lists.debian.org/debian-policy/1998/04/msg00089.html -- 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/15240458.dnBom6Q025@antec
Bug#771403: ITP: willie -- simple, lightweight, open source, easy-to-use IRC utility bot
Package: wnpp Severity: wishlist Owner: "Antoine Beaupré" * Package name: willie Version : 4.5.1 Upstream Author : Michael Yanovich, Edward Powell, Elad Alfassa... * URL : https://github.com/embolalia/willie * License : EFLv2 Programming Lang: Python Description : simple, lightweight, open source, easy-to-use IRC utility bot Upstream description: Willie is a simple, lightweight, open source, easy-to-use IRC utility bot, written in Python. It's designed to be easy to use, easy to run, and easy to make new features for. Willie comes with a ton of ready-made features for you to use. It can leave notes for people, give you reminders, check RSS feeds, and much more. Willie also comes with a fully-documented and easy-to-use API, so you can write your own features. There's also an easy tutorial you can follow along with, to help you learn. Developing for Willie is a great way to familiarize yourself with Python. It's easy to start, but there's no limit to the cool things you can do with it. I find the software interesting because it is a modern, elegantly designed yet minimal Python-based IRC bot. It compares favorably to the already packaged supybot: https://github.com/embolalia/willie/wiki/Comparison-to-other-bots I would be happy to have co-maintainers and I am unlikely to work on this in the very short term, but I will probably get around to work on this for $WORK eventually anyways, so this is an ITP. Note that Willie is a derivative of Phenny, which itself is a derivative of Jenni (or something like that). There are some optional Python dependencies for this bot, some of which are not packaged in Debian: https://github.com/embolalia/willie/wiki/System-Requirements Specifically, I couldn't find the praw package. But that's not a blocker since it's optional and only used for reddit. Otherwise the package seems pretty straightforward Python packaging with a daemon, which also has a systemd service file and an easy auto-configuration tool. The package would probably need to just create a user to sandbox the bot and tell the admin to run the config wizard and we'd be done with this package. -- 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/20141129082632.25235.90987.report...@marcos.anarc.at
Bug#771401: ITP: ruby-redis-rack -- Redis Store for Rack
Package: wnpp Severity: wishlist Owner: Balasankar C * Package name: ruby-redis-rack Version : 1.5.0 Upstream Author : Luca Guidi * URL : https://github.com/redis-store/redis-rack * License : Expat Programming Lang: Ruby Description : Redis Store for Rack -- 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/20141129081842.8258.22516.reportbug@sasalam
Re: successful upgrade to jessie - thanks!
Hi, Marc Haber: > Which significantly changes things in Jessie since the majory of > services is still started via the old rcX.d mechanism, and thus > starting to runlevels behaves completely different from what users > expect. > Well, I wouldn't expect runlevel 2 to start a graphical desktop either. But it does; my /etc/inittab states that "2" is the default runlevel and an unmodified /etc/init.d/gdm3 contains # Default-Start: 2 3 4 5 So, sorry, but the default behavior is already broken for a whole lot of users – who simply fail to notice. There is _no_way_ I can boot my desktops to a sane multi-user state (i.e. no X11 or *dm, if one of these decides to act up and wedge the system) without jumping through hoops, and there has not been one for ages. At least systemd's named targets actually mean something. > This is bad. Please consider that Fedora has changed their init system twice, so far. Their world did not end when they did that, so please don't assume that it will when we switch. I fully expect that almost all of users will not notice. The rest will have to heed the "you have customized your init defaults" warning we still need to implement – and either test before they leap, or decide to stay with sys5 until they are in a position to fix problems on-site. -- -- Matthias Urlichs signature.asc Description: Digital signature
