Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)
Le 12 févr. 2014 15:41, "Andreas Tille" a écrit : > > Hi, > > On Wed, Feb 12, 2014 at 04:11:41PM +0900, Charles Plessy wrote: > > Le Wed, Feb 12, 2014 at 12:06:42AM -0500, James McCoy a écrit : > > > > > > That being said, I don't have access to most of the packages. Even if I > > > did, it feels "dirty" to go and commit to a couple hundred packages I > > > have no involvement with instead of adapting two pieces of software to > > > deal with both path names. > > > > Hi James, > > > > you already have commit access to the Debian Med packages, like all other > > Debian developers. Please go ahead ! > > I take this "go ahead" for "yes, I accept the move". While I would have > no problems with this I wonder if it is appropriate to simply go on here > without at least informing Debian Science and DebiChem who also maintain > some d/upstream files. If I might have sounded against the move in the > past my main problem was that the affected parties were not included into > the decision making process. Lintian vive pièce of advice for using debian/upstream file I think the problem will more important than you think Bastien > So I have put the relevant mailing lists in CC to at least give people > lurking there some heads up and a slight chance to insist. > > I would say: If nobody will insist until after the weekend we might go > ahead. And for the actual action I agree with Charles that I see no > problem if James would simply commit a change to Debian Med repositories > (SVN and Git). That's fine and would save us (me or Charles) some work > and is perfectly possible permission-wise. > > Kind regards > > Andreas. > > PS: I think I did not got any answer to my question about further plans > for the debian/upstream/ dir. I would be really happy to understand > the big picture to make sure we will not again invent something which > needs to be changed later on. > > -- > http://fam-tille.de > > > -- > To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/20140212143924.ga21...@an3as.eu >
Re: Multirelease, something like Multiarch.
On Fri, Feb 21, 2014 at 09:31:56AM -0600, Mike Mestnik wrote: > Now we've a similar situation for releases and even distributions. We can > run multiple releases using a chroot for each, but perhaps this system can > be improved on. This doesn't seem particularly Debian-specific, so I'm not sure this list is the right place to hold such a discussion. You may be interested in Bedrock Linux[0] which seems to be doing pretty much what you describe. 0: http://www.bedrocklinux.org/ Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)
On Sat, Feb 22, 2014 at 10:07:42AM +0900, Charles Plessy wrote: > you are very welcome to migrate the ‘debian/upstream’ files of the Debian Med > packaging team. Please do not worry about the ‘debian/upstream-metadata.yaml’ > files. > > Since a large share of the ‘debian/upstream’ files are in Debian Med packages, > this will give the momentum for the whole migration. Ok. I'll update my repository list this weekend and run through the changes then. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)
Le Wed, Feb 12, 2014 at 03:39:24PM +0100, Andreas Tille a écrit : > > I would say: If nobody will insist until after the weekend we might go > ahead. And for the actual action I agree with Charles that I see no > problem if James would simply commit a change to Debian Med repositories > (SVN and Git). That's fine and would save us (me or Charles) some work > and is perfectly possible permission-wise. Hi James, you are very welcome to migrate the ‘debian/upstream’ files of the Debian Med packaging team. Please do not worry about the ‘debian/upstream-metadata.yaml’ files. Since a large share of the ‘debian/upstream’ files are in Debian Med packages, this will give the momentum for the whole migration. It would be very useful to do is sooner than later. For instance, there is an entry proposed to the Developers News that mentions ‘debian/upstream’ path. I would much prefer to resolve that issue before sending it. Have a week-end, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20140222010742.ga6...@falafel.plessy.net
Re: Bug#727708: Linux Security, Red Hat and Systemd Conspiracy
Hi, Thorsten Glaser writes: > Georgy Demidov dixit: >>Debian user here. This is my first and last letter about the bug >>#727708. I feel this is important to share. > > http://mid.gmane.org/1393001326.916837...@f432.i.mail.ru > > Thank you for sharing this. This was very appreciated, and I think > everyone involved in current GNU/Linux affairs ought to read it. Hmm, not sure. I get the impression there's another conspiracy involved: systemd provides additional features (like NoNewPrivs) that aren't readily provided elsewhere. I very much suspect people close to the three letter agencies are interested in making these *not* available to the large mass of people. But their mails are too easy to look through (which confuses me)... Ansgar *scnr* -- 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/87r46wvzr4@deep-thought.43-1.org
Bug#739724: ITP: ruby-tinder -- Ruby wrapper for the Campfire API
Package: wnpp Severity: wishlist Owner: Jonas Genannt -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: ruby-tinder Version : 1.9.3 Upstream Author : Brandon Keepers * URL : http://github.com/collectiveidea/tinder * License : MIT Programming Lang: Ruby Description : Ruby wrapper for the Campfire API Tinder is a library for interfacing with Campfire, the chat application from 37Signals, allowing you to programmatically manage and speak/listen in chat rooms. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJTB9hLAAoJEPBM7/YBbP/QDpEQAJwD6i3hRsV/MyFnb3sIr33B d9HMNDJ3dlDfv8mOAxGGiQiVUeBdvEUVtyOYIRu+VBEOcqGIZ3DTZqGFKzD39Sil 0Fu5OS1+3ndMPe7BUn18JL4Ppp9AspmPAQVZZE8t2OqXOkpziuS44+K4fJxb87EC jcPFrcK6bFO/QMhITxgoKRlsmW8O+LAy47/vgZ4wMUJuw82QxQhVs3hW2GqocRPI gMys5owsf1ArXMUtvq/IPoZW1RJDoAj69GkrvhFq/JkIuAJ1VYFY3BHugq6G92zE dUzug0oBJemffIiKaoHVbgeYcbi7wizXql/bcQzB2uLGgHASwmYfq7dwnGcaF8DD yF9uw/BUP/OFv9+udzMVnzAU231k4aw9gbEn/1g5m6/EfJGmLnMpvmhZXYEHn9BE fptT4dzYsuwza+A73LDQMv0Q7a8oIdA5JmMc4kBBdXSWQxa+aenFT4FaAQmczZsF 6x66wHiHn9PrD1iHrK/EFZys21BQlB5WfF9vLkUQW1IBdEGc6+L2fUMbU81i8xe1 xrba9F2NzckcSxWZ3RPpMDN0wLtTb0BZWrJndVRgfOCV04FoQ7uITJLKfKog0qIj 3NKTclLuTUL1QG0aWJyeFdh7/WXa9+YeXSM1wl96E8DHUPIJvt5tW1znYY0kH/wd KP3yWBqm1E4pog2kJtHj =+AeM -END PGP SIGNATURE- -- 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/20140221225051.9146.31033.report...@swetlana.brachium-system.net
Re: default init on non-Linux platforms
On 02/21/2014 11:38 PM, Kevin Chadwick wrote: > previously on this list hero...@gentoo.org contributed: > >>> And grepping through the output of "ps" or similar is not what >>> I would consider reliable and robust either. >> >> Nod. grepping `ps` is what we should avoid at all cost. > > All cost? While I like OpenRC and thanks to Gentoo for it and like > your mention of each to there own (I am no old-nerd by the way). I have > to disagree. Kevin, I don't think you understand the reasoning behind this. Again, the problem the init system has to solve here is being able to track a process with a 100% accuracy, so whatever automated mechanisms you have configured when certain situations occur, they have to find the correct process to work on as to not kill the daemon instance you actually still need. And, to my current knowledge, this is not possible without a mechanism like CGroups. Whether you rely on PID files or grep through the output of "ps" or use "pidof", either of them are fragile and prone to fail. I elaborated in my actual real-life case how PID files are prone to failure - I am aware that the situation with the full filesystem shouldn't occur in the first place, but, well administrators are just humans after all - and, using "ps" to track the process you are looking for to be able to restart, stop or kill it, can obviously be easily tricked into failure as well. Just imagine some other (malicious) process using the same name as well or when you need to control different instances of the very same process. "pidof" might help when you have the full path. But how does that keep you from working on the wrong instance? I have been looking for a solution of solving that problem without CGroups, but I haven't really found one yet. Do you know one? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/5307d8ff.1000...@physik.fu-berlin.de
Re: default init on non-Linux platforms
previously on this list hero...@gentoo.org contributed: > > And grepping through the output of "ps" or similar is not what > > I would consider reliable and robust either. > > Nod. grepping `ps` is what we should avoid at all cost. All cost? While I like OpenRC and thanks to Gentoo for it and like your mention of each to there own (I am no old-nerd by the way). I have to disagree. If a service fails I am more interested in why and what will happen if it restarts and not is it back-up already. For that, I would use redundant servers which in any way you look at it and especially for high availability situations must be more reliable than trying to restart a failed service blindly that may not operate as it should when it does. Functional externally generated tests like https returned this file are most valuable for monitoring services and I don't really see your point or the major benefit at all, especially if it involves increased kernel complexity. cgroups doesn't break that, worth it, question for me personally. However whilst I have found the reasoning by the CTTE to have been rather disappointing and superficial and I am unlikely to ever use systemd due to having fundamental issues with it. If a major concern was portability and many of you have your heart set on systemd then although it goes against my desires and technical concerns then perhaps pgroups are worth a mention. http://marc.info/?l=openbsd-misc&m=135313692911156&w=2 how can someone write this and not explain why a process managing pgroups can't achieve the same results? pgroups is going to be the first alternative for someone instinctively looking for a portable alternative, so i'm genuinely interested in knowing why they've discarded the idea i am, however, aware of differences *unrelated* to writing a systemd like appliance. pgroups do not provide per item hostname and other virtualization facilities in freebsd jails/linux cgroups, but what about *relevant* differences? something weak like "the index for for cgroups is wide enough to fit an UUID"? in other words, something that *doesn't* require a completely new api? http://marc.info/?l=openbsd-misc&m=135314269712851&w=2 therefore the requirement for cgroups is completely arbitrary also of interest: * early versions of systemd documentation advised daemon authors not to double fork. presumably cgroups wasn't in the radar at the time * several (all?) openbsd daemons have options for not double-forking. some of these daemons have the gall of preceding systemd -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ -- 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/163088.43505...@smtp102.mail.ir2.yahoo.com
Re: Bug#727708: Linux Security, Red Hat and Systemd Conspiracy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA384 Georgy Demidov dixit: >Debian user here. This is my first and last letter about the bug >#727708. I feel this is important to share. http://mid.gmane.org/1393001326.916837...@f432.i.mail.ru Thank you for sharing this. This was very appreciated, and I think everyone involved in current GNU/Linux affairs ought to read it. bye, //mirabilos - -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (MirBSD) iQIcBAEBCQAGBQJTB8wOAAoJEHa1NLLpkAfgCvIP/A650/sVYmdaIfEhmLz7wi0a PuUrbkzFA/Y/ijWIS/nhdD171A+YboUZe/o0oVWcyqy8gv6PtbPKK0Ge08kNkUx5 HMjIusoTlKNvBBe2m1KG/t27DDQSGL6nbeiqZ8w65k3GQhCwk7JY9aibc9R76I+w hHAw71zmxdRfm38BJZjsQCI0QCcaH/jryQgdzLeUCAGsncULu+Uj7hjvv5tMJ7b3 GpS6aoq0ijqvxQVyY2qeCVFgxSHR5MnBQ7I+Dwr2kXslWfUwdjm5vMKTXzE4W08z ym0z35E5a2dqZBkLnUnq3zaqyLmXRjvGTmxHcZI33WAOHUNN5AhA9J3YtJnxDb+S munMyeFr/TxzC8J5SvvWo4FLK9VeFc4+PiZiLtU6vF8os1OxC0Fyt77TVhtlaMBb 50TYcaElIIwGp6OXMO4XhMJ7VMs3qlBD4N4iwRJsyJzr9aEfVvXs4fvfsUVKD4Fw stQ119kte4wfyXwvFBaUGro2uYNPq3LViKIe6cgMnd6jZWZ9L2dSjSKsyftRouBJ OmRnjtUmiQVXfmpYWUpxrEGLK4TnD8F2P7tytdcbt67PCez+Wi4bM4d84w8rHMVF HhYljYs//kk2UBqqxJwTbToCoqhonNyjBK/edYksX+CoqjskZVu3sujLTxUTREvh fO6EZhExtJwg7Hrc2Yn5 =9EIg -END PGP SIGNATURE- -- 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/pine.bsm.4.64l.1402212155480.28...@herc.mirbsd.org
Re: Bug#727708: Linux Security, Red Hat and Systemd Conspiracy
This particular statement was taken out of context: On Friday, February 21, 2014 20:48:46 Georgy Demidov wrote: [...] > Linus Torvalds about Lennart Poettering: “Two-faced lying weasel” would be > the most polite thing I could say. But it almost certainly will involve a > lot of cursing. When Linus wrote this (in Oct 2012), it was specifically about a bug in udev concerning deadlocking if moudule_init() did a request_firmware() which apparently broke in udev182. [1] Linus was really pissed off because this issue had dragged on for months and Kay had apparently ignored patches to fix it [2]. I don't personally think this was because of malice or conspiracy -- it's far more likely to be some kind of technical misunderstanding or a design issue than anything else. [1]: https://lkml.org/lkml/2012/10/2/303 [2]: https://lkml.org/lkml/2012/10/3/484 -- Chris -- Chris Knadle chris.kna...@coredump.us -- 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/1488975.ZTTClMYzO7@trelane
Re: Bug#739706: ITP: python-iso8601 -- Simple module to parse ISO 8601 dates
* Tristan Seligmann , 2014-02-21, 17:36: * Package name: python-iso8601 Version : 0.1.8 Upstream Author : Michael Twomey * URL : https://pypi.python.org/pypi/iso8601 It's already in Debian: http://packages.qa.debian.org/p/python-iso8601.html -- Jakub Wilk -- 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/20140221173351.ga4...@jwilk.net
Linux Security, Red Hat and Systemd Conspiracy
Hi! Debian user here. This is my first and last letter about the bug #727708. I feel this is important to share. Quote from Soylent News [1]. Former cypherpunk shares his conspiratorial view on Linux security [1] : Since then, more has happened to reveal the true story here, the depth of which surprised even me. The GTK development story and the systemd debate on Debian revealed much corporate pressure being brought to bear in Linux. [...] Some really startling facts about Red Hat came to light. For me the biggest was the fact that the US military is Red Hat's largest customer: >"When we rolled into Baghdad, we did it using open source," General Justice >continued. "It may come as a surprise to many of you, but the U.S. Army is >'the' single largest install base for Red Hat Linux. I'm their largest >customer ." ( 2008 ) [3] This is pretty much what I had figured. I'm not exactly new to this, and I figured that in some way the military-industrial/corporate/intelligence complex was in control of Red Hat and Linux. [...] But I didn't expect it to be stated so plainly. Any fool should realize that "biggest customer" doesn't mean tallest or widest, it means the most money. In other words, most of Red Hat's money comes from the military and, as a result, they have significant pull in its development. In that respect, the connection between the military and spying agencies, etc. should be obvious. Next, the FOSDEM: NSA Operation ORCHESTRA Annual Status Report is well worth watching in its entirety (including the Q&A at the end). To me, this turned out to be a road-map detailing how Red Hat is operating on Linux!" Linus Torvalds about Lennart Poettering: “Two-faced lying weasel” would be the most polite thing I could say. But it almost certainly will involve a lot of cursing. "Systemd propaganda: It's a crap!" - Gentoo Dev Patrick Lauer [5] [1] http://soylentnews.org/article.pl?sid=14/02/20/031231 [2] http://igurublog.wordpress.com/2014/02/17/biography-of-a-cypherpunk-and-how-cryptography-affects-your-life/ [3] http://archive09.linux.com/feed/61302 [4] http://video.fosdem.org/2014/Janson/Sunday/NSA_operation_ORCHESTRA_Annual_Status_Report.webm [5] http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10-29T13_39_32.txt
Multirelease, something like Multiarch.
Hello, Multiarch gives the ability to store libraries in the main root lib directories from different architectures and this allows applications to co-exist on the same system. Some applications are compiled for amd64 while others are for i386 and perhaps x32. This could have been done using chroots and for a long time prior to Multiarch it was. The problems of, what happens when a i386 app loads a library for amd64 were handled. Now we've a similar situation for releases and even distributions. We can run multiple releases using a chroot for each, but perhaps this system can be improved on. Along comes the idea of supporting Multirelease. Certainly there is a lot to work out and I'm sure there will be plenty of ideas and good solutions. Cheers.
Bug#739706: ITP: python-iso8601 -- Simple module to parse ISO 8601 dates
Package: wnpp Severity: wishlist Owner: Tristan Seligmann * Package name: python-iso8601 Version : 0.1.8 Upstream Author : Michael Twomey * URL : https://pypi.python.org/pypi/iso8601 * License : MIT (Expat) Programming Lang: Python Description : Simple module to parse ISO 8601 dates This module parses the most common forms of ISO 8601 date strings (e.g. "2007-01-14T20:34:22+00:00") into datetime objects. For a more featureful parser, look at python-dateutil instead. This package is a dependency of the python-cryptography test suite; I will be maintaining it in the Debian Python Modules Team SVN repository. -- 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/20140221153612.30212.21309.report...@lorien.mithrandi.net
Bug#739705: ITP: python-pretend -- Library for stubbing in Python
Package: wnpp Severity: wishlist Owner: Tristan Seligmann * Package name: python-pretend Version : 1.0.7 Upstream Author : Alex Gaynor * URL : https://pypi.python.org/pypi/pretend * License : BSD Programming Lang: Python Description : Library for stubbing in Python Pretend is a library to make stubbing with Python easier. Stubbing is a technique for writing tests. You may hear the term mixed up with mocks, fakes, or doubles. Basically a stub is an object that returns pre-canned responses, rather than doing any computation. This package is a dependency of the python-cryptography test suite, I will be maintaining it in the Debian Python Modules Team SVN repository. -- 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/20140221153221.28307.15513.report...@lorien.mithrandi.net
Re: pulseaudio related problems....
On 02/21/2014 03:28 PM, Mario Lang wrote: > No, you have summarized it pretty neatly. > I just don't consider an X11 program a true alternative to a ncurses tool. Did you give pulseaudio-utils a try then? They don't require X. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/5307680a.2080...@physik.fu-berlin.de
Re: pulseaudio related problems....
Paul Gevers writes: > On 21-02-14 10:57, John Paul Adrian Glaubitz wrote: >> On 02/21/2014 09:29 AM, Mario Lang wrote: >>> I am sorry, both are not an option for me, since alsamixer is a ncurses >>> program, and pavucontrol apparently requires $DISPLAY to be set. >>> >>> I guess that explains why the accessibility community has >>> problems with PA. >> >> What's wrong with the accessibility mechanisms provided in GNOME >> (screen reader, magnifier)? (Serious question). I had the impression >> that accessibility works rather well in GNOME and upstream actually >> puts efforts into making that happen. > > I think the point of Mario is that people like him don't have a DE, but > work from console. I haven't checked, but apparently pavucontrol needs > an X-session to show itself. Of course ALSA has the same problem that if > you don't hear it you can't change it, but at least it doesn't require > an DE just to change your sound settings (to get it to work). > > Maybe I haven't understood Mario's remark and I am fully wrong. No, you have summarized it pretty neatly. I just don't consider an X11 program a true alternative to a ncurses tool. Having to get X11 + a11y configured just to be able to *properly* adjust a volume slider is just hilarious. -- CYa, ⡍⠁⠗⠊⠕ -- 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/87r46w7d5u@fx.delysid.org
Bug#739700: ITP: python-smstrade -- Python library and command line tool to send SMS via the smstrade service
Package: wnpp Severity: wishlist Owner: Jan Dittberner * Package name: python-smstrade Version : 0.2.1 Upstream Author : Jan Dittberner * URL : https://pypi.python.org/pypi/smstrade/ * License : MIT Programming Lang: Python Description : Python library and command line tool to send SMS via the smstrade service This library implements a wrapper for the SMS sending API of smstrade.eu. The package also provides command line tools to send SMS as well as get the current account balance. The package can be used in scenarios such as alerting from monitoring tools. -- Jan Dittberner - Debian Developer GPG-key: 4096R/558FB8DD 2009-05-10 B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD http://portfolio.debian.net/ - http://people.debian.org/~jandd/ signature.asc Description: Digital signature
Re: default init on non-Linux platforms
Dear Adrian, John Paul Adrian Glaubitz writes: > On 02/21/2014 01:00 PM, hero...@gentoo.org wrote: >>> So, OpenRC actually also relies on files - like System V Init - to >>> track the state of a service? Isn't that approach somewhat unreliable >>> and hacky? >> >> I bet you are going to tell me the only reliable and non-hacky way to >> track the state of a service is not forking/writing to files but >> starting it foreground by a long-living daemon. I agree with you. > > Well, I was thinking about something like CGroups. I don't like the > idea of having to rely on files for an init system to be able to > track the processes it has started. > > 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. > > At my department, we stumbled right over this design when the /var > filesystem was full and System V Init could no longer create PID > files to be able to track services, yet it started services without > complaining. > > Since we had to restart our dhcpd several days on a particular day, > System V Init was unable to track whether the daemon was already > running and we ended up with several dozen instances. > > Sure, it's probably a bug in the init script used as it didn't > check for enough disk space and wasn't failing when the disk is full. > But again, this is a core component depending on external scripts > being bug free which is not the correct approach when you are > aiming for something robust. Thank your for sharing with us your real life story. I can reasonate with it: having a dhcpd malfunctioning and hundreds of people complaining about the resulting unstable network is no fun at all. How to cope with this will be a matter of personal taste. You might think a robust framework will make it fool-proof. While I might think running a central dhcp server along with something else which possibly fill up the /var is questionable itself. I appreciate both. >> OpenRC leverages cgroups when available. We are also working on a plugin >> framework for external supervisors such as djbtools, runit and s6 (maybe >> launchd, smf, systemd, ... as well if they're hackable) to do this >> foreground status tracking while integrated with OpenRC: We are not >> there yet though. > > Can external supervisors like djbtools or runit actually reliably track > processes and if, yes, how? From my understanding, it's impossible > to be able to really track a process once it has started when > you don't have the possibility to use something like CGroups as > services could always just double-fork. The tracking has to be > done through a mechanism provided by the kernel, doesn't it? I've meant "foreground", the opposite of double-fork, which has been discussed in the list, like: http://article.gmane.org/gmane.linux.debian.devel.general/152538 This does not require a special tracking mechanism in the kernel. Double-fork is not a reliable way to track process. People invented it as a hack back in history (from BSD community if I remember it right). > And grepping through the output of "ps" or similar is not what > I would consider reliable and robust either. Nod. grepping `ps` is what we should avoid at all cost. >> These advanced features are optional. We can still use the unreliable >> and hacky way of trakcing files when the task is trivial, like a >> personal VPS or laptop which do not care much about running sshd/httpd >> for 3 years non-stop. > > Sure, I fully agree. But there are actually many enterprises who > need something with 99% service availability. Our department > runs a webserver, a login node for 1200 users and a large compute > clusters with over 200 nodes and an SGI UV1000 (1024 CPUs, 2 TiB), > so we need something which is able to control resources and track > processes. Many enterprises and websites run Debian. Yes, though I am a casual user, I actually had systemd and monit to supervise httpd in one of our mirror servers. And I myself am even using a computing cluter running RHEL5 (for stability and paid customer service). So I am quite sharing the view with you. Different people in different situations have different needs: Using a bad old pid-file tracking, or no tracking at all is like wearing jeans at home, or even naked. It happily coexists with the situation of wearing suites doing public speech. --- super light-hearded, just for fun, don't take it seriously --- modern activists: com'on, just us, or you'll not be supported. (com'on, wear suites, or you're out) old nerds: fine, we will support ourselves. (fine, we will find somewhere comfortable to be naked) --- end --- Hope this explains why I am devoting to something alternative and even counter-advertised as suboptimal. Let's coexist and have fun. This universe is ultimately a friendly place to live in after all. Coming back to our starting point: service relying on file-tracking is hackish and is recommended to be avoided in serious business in preferre
Re: default init on non-Linux platforms
On 02/21/2014 01:00 PM, hero...@gentoo.org wrote: >> So, OpenRC actually also relies on files - like System V Init - to >> track the state of a service? Isn't that approach somewhat unreliable >> and hacky? > > I bet you are going to tell me the only reliable and non-hacky way to > track the state of a service is not forking/writing to files but > starting it foreground by a long-living daemon. I agree with you. Well, I was thinking about something like CGroups. I don't like the idea of having to rely on files for an init system to be able to track the processes it has started. 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. At my department, we stumbled right over this design when the /var filesystem was full and System V Init could no longer create PID files to be able to track services, yet it started services without complaining. Since we had to restart our dhcpd several days on a particular day, System V Init was unable to track whether the daemon was already running and we ended up with several dozen instances. Sure, it's probably a bug in the init script used as it didn't check for enough disk space and wasn't failing when the disk is full. But again, this is a core component depending on external scripts being bug free which is not the correct approach when you are aiming for something robust. > OpenRC leverages cgroups when available. We are also working on a plugin > framework for external supervisors such as djbtools, runit and s6 (maybe > launchd, smf, systemd, ... as well if they're hackable) to do this > foreground status tracking while integrated with OpenRC: We are not > there yet though. Can external supervisors like djbtools or runit actually reliably track processes and if, yes, how? From my understanding, it's impossible to be able to really track a process once it has started when you don't have the possibility to use something like CGroups as services could always just double-fork. The tracking has to be done through a mechanism provided by the kernel, doesn't it? And grepping through the output of "ps" or similar is not what I would consider reliable and robust either. > These advanced features are optional. We can still use the unreliable > and hacky way of trakcing files when the task is trivial, like a > personal VPS or laptop which do not care much about running sshd/httpd > for 3 years non-stop. Sure, I fully agree. But there are actually many enterprises who need something with 99% service availability. Our department runs a webserver, a login node for 1200 users and a large compute clusters with over 200 nodes and an SGI UV1000 (1024 CPUs, 2 TiB), so we need something which is able to control resources and track processes. Many enterprises and websites run Debian. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/5307451b.1010...@physik.fu-berlin.de
Re: default init on non-Linux platforms
Dear Adrian, John Paul Adrian Glaubitz writes: > So, OpenRC actually also relies on files - like System V Init - to > track the state of a service? Isn't that approach somewhat unreliable > and hacky? I bet you are going to tell me the only reliable and non-hacky way to track the state of a service is not forking/writing to files but starting it foreground by a long-living daemon. I agree with you. OpenRC leverages cgroups when available. We are also working on a plugin framework for external supervisors such as djbtools, runit and s6 (maybe launchd, smf, systemd, ... as well if they're hackable) to do this foreground status tracking while integrated with OpenRC: We are not there yet though. These advanced features are optional. We can still use the unreliable and hacky way of trakcing files when the task is trivial, like a personal VPS or laptop which do not care much about running sshd/httpd for 3 years non-stop. Thanks for the insight. Benda -- 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/86eh2w8ylo@moguhome00.in.awa.tohoku.ac.jp
Re: pulseaudio related problems....
Hi, John Paul Adrian Glaubitz: > There are a couple of command line utilities to control Pulse Audio in > the package "pulseaudio-utils". But I haven't used it that much to be > able to assess whether it provides the features Mario needs. > "pacmd" allows you to enumerate outputs, set their volumes, and set the default output. Among other things. So an accessibility setup tool can easily say "press one" on the first channel (paplay -d NAME AUDIOFILE), "press two" on the second, etc., and then set the default to whatever the user actually heard (and wants). -- -- Matthias Urlichs -- 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/20140221113741.gk3...@smurf.noris.de
Re: pulseaudio related problems....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/21/2014 11:56 AM, Paul Gevers wrote: > I think the point of Mario is that people like him don't have a DE, > but work from console. I haven't checked, but apparently > pavucontrol needs an X-session to show itself. Of course ALSA has > the same problem that if you don't hear it you can't change it, but > at least it doesn't require an DE just to change your sound > settings (to get it to work). There are a couple of command line utilities to control Pulse Audio in the package "pulseaudio-utils". But I haven't used it that much to be able to assess whether it provides the features Mario needs. Cheers, Adrian - -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTBzT2AAoJEHQmOzf1tfkTSCcP+wapy+OdUjO4kXp9tKv1cU01 VsUJV5V5QsouuL52mHaExtwQtYf87Vc3guWqKmbm5I5gOz42RQqo6ctMkz/hvMt2 TXwkqF5q65pPE7NFO9galY8xF6EngxegxHJT8SZuc3r8hLn2XMPgnw+J217inOXl 87UKz201Wrvu6ImPX80ha8JB5TzAyl5SqYsO5ESG2qwhdv7Wlf/nxrePItZRt6DX Jgy3qNHQpqHFLYyE67fQBfHQpbQtmSjDTmg0Y1DalkwUryTLimfoQylyKOmfIOEE H8AhpVeg1oKavGJipYBpaWnolKdNn9OkvZIii4PLHG/cNZMqz1w6wLb1CNeXGnct g0mNMPVBSEXduvTiE5RqrVGkVWuDbESfXl+FTYX4W2u6jUxmrIz6KyLAVhc89RS9 crDNCiYoFxYDr8CrfbMaCHyZn3H0AHWiozktggQsg5i5W2gxDeAIDGhmF3QQQeNF ruUitwkDKlGTkQerLtY/HZKFThNAeYx0WkCqIeQQkLQMvV7+kfeVCMcq8lYo6CFk hHDcai6QciSOaSRWtCJm5VTgIXJQ3Jf2OIQ0zhI/c3b66bfvfMshbxBRzH3LLYgf jdEpCFtnpRErrc59ylHBBd07Gcrkpz3V0ls/JXyQolduYgr3RtehOy9kovyJrk/G GZSeeDm9HzWH7om+IGD8 =bZQ7 -END PGP SIGNATURE- -- 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/530734f6.10...@physik.fu-berlin.de
Re: pulseaudio related problems....
Say that I use a screen reader. Someone helps me installing debian, configures the volume level to non-zero and then I am on my own. After a while some package decides to install PA, then the audio is gone, then I'll need someone to come over a second time to help me with that. So yes it applies to ALSA as well, but it's harder to configure and since it tends to get installed by surprise, it can break things in unexpected moments. -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/ -- 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/1665459.ZkWPCHGbdR@vulcano
Re: pulseaudio related problems....
On 21-02-14 10:57, John Paul Adrian Glaubitz wrote: > On 02/21/2014 09:29 AM, Mario Lang wrote: >> I am sorry, both are not an option for me, since alsamixer is a ncurses >> program, and pavucontrol apparently requires $DISPLAY to be set. >> >> I guess that explains why the accessibility community has >> problems with PA. > > What's wrong with the accessibility mechanisms provided in GNOME > (screen reader, magnifier)? (Serious question). I had the impression > that accessibility works rather well in GNOME and upstream actually > puts efforts into making that happen. I think the point of Mario is that people like him don't have a DE, but work from console. I haven't checked, but apparently pavucontrol needs an X-session to show itself. Of course ALSA has the same problem that if you don't hear it you can't change it, but at least it doesn't require an DE just to change your sound settings (to get it to work). Maybe I haven't understood Mario's remark and I am fully wrong. Paul signature.asc Description: OpenPGP digital signature
Re: pulseaudio related problems....
On 02/21/2014 11:38 AM, Jean-Christophe Dubacq wrote: > Not the same accessibility. And the screen reader will not work if PA > does not work. > This is quite difficult to debug remotely; if the user cannot describe > the output of > commands, then we are doomed. Doesn't this perfectly apply to ALSA as well? Having to rely on using a screen reader when trying to debug problems with your sound card sounds like a chicken-and-egg question to me. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/53072f62.4000...@physik.fu-berlin.de
Re: pulseaudio related problems....
Le 2014-02-21 09:57, John Paul Adrian Glaubitz a écrit : On 02/21/2014 09:29 AM, Mario Lang wrote: I am sorry, both are not an option for me, since alsamixer is a ncurses program, and pavucontrol apparently requires $DISPLAY to be set. I guess that explains why the accessibility community has problems with PA. What's wrong with the accessibility mechanisms provided in GNOME (screen reader, magnifier)? (Serious question). I had the impression that accessibility works rather well in GNOME and upstream actually puts efforts into making that happen. Not the same accessibility. And the screen reader will not work if PA does not work. This is quite difficult to debug remotely; if the user cannot describe the output of commands, then we are doomed. -- 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/d5b89c3d8296a02c6cb1edd96d75b...@oberon.tenebreuse.org
Bug#739684: ITP: r-other-nitpick -- peak identification for mass spectrometry data
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-other-nitpick Version : 2.0 Upstream Author : Marc Kirchner * URL : http://hci.iwr.uni-heidelberg.de/MIP/Software/nitpick.php * License : LGPL Programming Lang: R Description : peak identification for mass spectrometry data This R package allows reliable extraction of features from mass spectra and helps in the automated analysis of proteomic mass spectrometry (MS) experiments. . This is the NITPICK implementation for peak picking in MS spectra. This package is maintained by the DebiChem team at git://anonscm.debian.org/debichem/packages/r-other-nitpick.git -- 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/20140221103418.11281.8106.report...@mail.an3as.eu
Re: default init on non-Linux platforms
On 02/21/2014 04:20 AM, hero...@gentoo.org wrote: > OpenRC needs a proper directory structure in /run/openrc to track the > status of services. It is handled by init.sh and friends, you may need > to hack that. So, OpenRC actually also relies on files - like System V Init - to track the state of a service? Isn't that approach somewhat unreliable and hacky? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/53072a4c.7090...@physik.fu-berlin.de
Re: default init on non-Linux platforms
On 20/02/14 19:37, Ondřej Surý wrote: > I have split openrc into openrc and openrc-sysv moving the conflicting > parts to openrc-sysv on my system, and it install just fine If sysv-rc's invoke-rc.d and update-rc.d should be treated as generic glue shared by multiple inits (which they probably should, since they already support all of sysv-rc/insserv, Upstart, systemd) then it might make more sense to move them to sysvinit-utils, and include openrc support in them there. According to `apt-file search invoke-rc.d`, the only implementations of invoke-rc.d or update-rc.d in Debian are sysv-rc, file-rc and openrc (plus an update-rc.d in multistrap which I assume is some sort of wrapper); systemd and Upstart both rely on the one from sysvinit. file-rc appears to be basically dead, and hasn't been updated for dependency-based boot. Upstart already has a hard dependency on sysv-rc. Perhaps systemd (or at least systemd-sysv) should have that as well, or Breaks: file-rc, or something, since I doubt file-rc's update-rc.d deals with systemd units; systemd currently depends on initscripts, which depends on sysv-rc|file-rc. I'll open a bug. S -- 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/530722b0.9000...@debian.org
Re: pulseaudio related problems....
On 02/21/2014 09:29 AM, Mario Lang wrote: > I am sorry, both are not an option for me, since alsamixer is a ncurses > program, and pavucontrol apparently requires $DISPLAY to be set. > > I guess that explains why the accessibility community has > problems with PA. What's wrong with the accessibility mechanisms provided in GNOME (screen reader, magnifier)? (Serious question). I had the impression that accessibility works rather well in GNOME and upstream actually puts efforts into making that happen. Cheers, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/53072324.1090...@physik.fu-berlin.de
Bug#739677: ITP: trac-navadd -- Add custom items to main and meta navigation bar in Trac web application
Package: wnpp Severity: wishlist Owner: Daniel Kahn Gillmor * Package name: trac-navadd Version : 0.3 Upstream Author : Ryan J. Ollos * URL : https://trac-hacks.org/wiki/NavAddPlugin * License : BSD Programming Lang: Python Description : Add custom items to main and meta navigation bar in Trac webapp This plugin allows customization of the Trac web application's navigation bars by adding custom links, either to main or meta navbars. -- 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/20140221085734.17364.25534.report...@alice.fifthhorseman.net
Re: pulseaudio related problems....
John Paul Adrian Glaubitz writes: > I think most people simply don't configure PulseAudio correctly. > They have the assumption that sound cards are still simple devices > with one input jack and one output jack and any application using it > just has to find the sound card and output its audio signal. > > It's not as simple as that anymore. Modern audio codecs have tons of > options and volume controls, and - from my experience - most problems > to PulseAudio relate to the sound card being incorrectly configured. > > To resolve this problem, people then try to use tools like alsamixer > and naturally, since alsamixer doesn't know anything about PulseAudio, > it cannot fully configure it. > > So, in order to be able to properly configure PulseAudio, install > "pavucontrol" or use the sound preferences in GNOME3 or MATE (with > the package mate-media-pulse being installed). I am sorry, both are not an option for me, since alsamixer is a ncurses program, and pavucontrol apparently requires $DISPLAY to be set. I guess that explains why the accessibility community has problems with PA. -- CYa, ⡍⠁⠗⠊⠕ -- 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/878ut4zx4r@fx.delysid.org
Re: C++ testing library
Hi, On Thu, 20 Feb 2014, Jan Gloser wrote: > Earlier this week I wanted to find a C++ testing library. I tried gtest and > cppunit but both of them seemed way too much overkill for my needs. You can try cpputest too. You might find it better for your needs. At least I never had any feeling of bloat/overkill while using it. > Now I'm thinking. Is there some way for me to make a package from this code > (possibly after polishing up) and push to the debian apt repository? Is > there somebody who can guide me through this process? I would like to reuse > it and install via apt. It's always possible but it will be hard to make a case for it given that we have plenty of good C++ testing libraries already. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140221082913.gd14...@x230-buxy.home.ouaza.com
