Re: PuTTY tips for Debian users
On 27/09/14 02:48, Stephen Powell wrote: I'm not sure that the Debian wiki is the right place for this information. Although there is a Linux port of PuTTY, 99% of PuTTY users are Windows users, including me. Although it may be used to login remotely to a Debian system, PuTTY itself is Windows software. Not only is there a Unix port of PuTTY, but that Unix port of PuTTY is maintained in Debian by Colin Watson. PuTTY currently does not support 256-color mode. See http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/256-colours.html for more information. You appear not to have read the whole page: "fixed-in: 2004-11-29 (0.58) (0.59) (0.60) (0.61) (0.62) (0.63)" and indeed, looking at the Window->Colours section of the configuration dialog in PuTTY 0.63 on a Debian jessie system, I see the option "allow terminal to use xterm 256-colour mode". -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54269789.6080...@zen.co.uk
Re: Challenge to you: Voice your concerns regarding systemd upstream
On 27/09/14 21:04, lee wrote: https://bugzilla.redhat.com/show_bug.cgi?id=990177 Your complaint about the interface is reasonable. The systemd developers' decision to not change the interface in response to your complaint was also reasonable. (The Fedora users mailing list thread you linked to suggests that I am not the only person outside the systemd development team who thinks that the interface was not sufficiently suboptimal to justify change.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54274456.4030...@zen.co.uk
Re: Let's have a vote!
On 28/09/14 16:29, Steve Litt wrote: I assume that implicit in your reply is that such a major version upgrade works well, and that over the years you don't get all sorts of accumulated software dust bunnies doing funny things to you. How many others here have experiences like Chris'? Well, this jessie-with-systemd system I'm using used to be a wheezy system. I changed my sources.list and upgraded things, and it all just *worked*. Couple of minor issues (the behaviour of something in xfce4-panel changed, so I had to add a "separator" element to get the clock and the systray and the workspace selector to continue appearing at the right-hand end where they belong instead of bouncing back and forth as I open and close windows), but pretty much painless. The only material hassle I've had with this Debian installation is entirely a result of using a closed graphics driver (because the libre driver for my hardware renders my video games incorrectly and at an unacceptable frame rate) whose upstream was slow to update for compatibility with the latest xorg; I am declaring that to be Not Debian's Fault. As another example, the multi-user system run by an acquaintance from university on which I have a shell account has been upgraded *many* times. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54282c75.6040...@zen.co.uk
Re: Challenge to you: Voice your concerns regarding systemd upstream
On 28/09/14 16:35, Lisi Reisz wrote: On Sunday 28 September 2014 14:21:13 Slavko wrote: For now it seems, that there is no chance to get DE without systemd in debian Nonsense!! You can have TDE for a start, and I am sure that there are others. The Trinity Desktop Environment is not, as far as I can readily determine, available *in* Debian, only *for* Debian. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542830e9.3050...@zen.co.uk
Re: Fwd: Re: cron in UTC?
On 29/09/14 17:13, Lisi Reisz wrote: On Monday 29 September 2014 17:01:31 Tony van der Hoff wrote: well, it's my understanding that the system (hardware) time is always UTC, but there is no way to set localtime to GMT (or UTC). Perhaps I'm misunderstanding you. Erm What do you think we who live near Greenwich do??? Set our software time zone to Western European Time, which is only the same as GMT in winter. (My desktop PC's hardware clock is also in WET, since I have a Linux/Windows dual boot system and Windows can't be relied on to play nice if the hardware clock doesn't reflect local civil time.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54299e45.7070...@zen.co.uk
Re: Let's have a vote!
On 30/09/14 02:06, Hörmetjan Yiltiz wrote: Would not save that much, actually, since almost everyone here uses Debian and are Debian users, and furthermore, hopefully, users who use Debian and Debian only. I very much hope that many people here do not use *only* Debian, because people with diverse ongoing experience of other operating systems are a good thing to have in an operating system's user community. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542a8373.4060...@zen.co.uk
Re: systemd-shim to be removed?
On 01/10/14 18:44, Slavko wrote: Dňa Wed, 01 Oct 2014 18:00:39 +0200 Sven Joachim napísal: No, it's because systemd-shim Breaks: systemd (<< 209), but testing has systemd 208-8. If you need systemd-shim (i.e. you're not using systemd as PID 1), wait with the dist-upgrade until systemd 215 migrates, which should happen in the next few days. And all these things are named as "systemd alternative" in Debian now and as argument that the systemd is not only one possible PID 1. "systemd" is the package that delivers /lib/systemd/systemd, /lib/systemd/systemd-logind, and some other such things. It's not the package that makes /lib/systemd/systemd run as PID 1. "systemd-shim" is the package designed to allow (e.g.) /lib/systemd/systemd-logind to run at least tolerably well when PID 1 is a program other than /lib/systemd/systemd. The new version of package "systemd-shim" happens to have ended up migrating from sid to jessie sooner than the version of package "systemd" that it's designed to work with. This kind of synchronization misfortune is a thing that *happens* in the "testing" branch of Debian (one can argue about whether it *should*, but that discussion seems to be at most only obliquely relevant to whether PID 1 implementations other than systemd are going to end up being usable in jessie-as-released). It is not, in my experience, the kind of thing that happens in the "stable" branch of Debian. As such, I'm not clear how this incident is in any way relevant to the complaint implicit in the remark "And all these things are named as "systemd alternative" in Debian now and as argument that the systemd is not only one possible PID 1." -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/542c5eb9.5000...@zen.co.uk
Re: libreoffice packaging dependency on gnome in Wheezy 7.6
On 06/10/14 16:01, Buchs, Kevin J. wrote: I have both libreoffice and libreoffice4.2 installed. I just want to keep the 4.2 version, but when I try to apt-get remove libreoffice, it wants to remove gnome. Why is gnome dependent upon libreoffice? Gnome doesn't depend on libreoffice. What's happening here is that the task-gnome-desktop metapackage depends on libreoffice (since the maintainers of that metapackage think that it's reasonable to do so). Gnome was installed because the task-desktop-gnome metapackage was installed; when task-desktop-gnome goes away, anything it depends on which is marked as automatically installed, and which nothing else depends on, will also be marked for removal. Try: aptitude unmarkauto gnome and see if apt stops wanting to remove gnome. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5432be4b.5090...@zen.co.uk
Re: upgrade from 7 to testing no longer possible
On 06/10/14 18:45, Steve Litt wrote: Oh Geez, I thought Plymouth was only an Ubuntu thing. Getting away from plymouth was about 40% of why I moved from Ubuntu to Debian. Conveniently, plymouth is optional in Debian, unless you're using upstart or docker.io. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5432d96c.2090...@zen.co.uk
Re: Prolem with external monitor
On 08/10/14 08:23, Bret Busby wrote: I have a 23" monitor, that I want to use with two of my laptop computers (not at the same time). I have a 15" laptop, with an i3 CPU, running Debian 6 LTS and GNOME2. [snip] The other laptop has a 17" display and an i7CPU, and is running Debian 7.x and LXDE. While I'm not sure how to go about resolving your problem, I will observe that you seem to have omitted an important piece of information about these two laptops: what GPU do they have? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5434e7c9.4090...@zen.co.uk
Re: find out why a package was installed
On 10/10/14 14:28, Rob Owens wrote: Is there an apt command that will tell me why package X was installed? For instance, was it manually installed, or installed as a dependency/recommends of package Y? aptitude why package-x will show you exactly one reason why package-x is installed. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5437e226.4090...@zen.co.uk
Re: question about systemd
On 10/10/14 18:15, PETER ZOELLER wrote: And this is being hard coded in my opinion since it forces it to be installed as a default with no other option given and required for example if you want to use Gnome. It turns out to be the case that cases where Gnome fails to operate correctly without systemd as PID 1 are in fact being treated as bugs: https://bugs.debian.org/release-critical/other/testing.html - the list of release-critical bugs in Debian jessie, which refers to: https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=759745 - a release-critical bug filed against gdm3, the X display manager provided as a component of Gnome 3. Failure of the Debian Installer to offer a convenient mechanism for selecting the init system to be installed can reasonably be argued to be a bug in the installer, which you might want to consider reporting. This system has been shown to be troublesome, is only one of many ways to handle the boot process, and forcing other distributions to either accept it or fall by the way side. A rather strong arm tactic of Microsoft. I loved Linux because of the freedom to choose, modify and configure it to what I want and need. Right now there are only two distro's left that do not use systemd and soon there will be none. This is madness. Systemd is a kludge, poorly designed, overly complex. and too convoluted leaving it open to being cracked and its host system compromised by the crackers of the world. It seems to me that if a cracker is in a position to exploit whatever attack surface systemd presents, your system has already been compromised. Until ALL the bugs are out and it has proven itself to be 100% stable and 100% secure it has no business being a part of a stable operating system. If that's your position, why are you using an operating system based on the Linux kernel? The Linux kernel has bugs, it is not 100% stable, and it is not 100% secure. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543903e2.9020...@zen.co.uk
Re: question about systemd
On 11/10/14 19:00, Nate Bargmann wrote: This is the question I have, what are the stated boundaries of the systemd project? Have any boundaries/goals been stated in terms of when systemd will be feature complete? What is the stated compliance to POSIX (Google doesn't seem to provide me good results)? In respect of the first two questions: I am not aware of any such firm statements having been made. In respect of your third question: Contrary to the implicit expectation that seems to be attached to this question, POSIX.1-2008 appears to have very little to say about how any of the things systemd does are supposed to work. For example, one might expect that since the System Interfaces volume of POSIX.1-2008 stipulates the existence of the syslog() library function, it might say something about the nature of system logging. What it turns out to say is: "The syslog() function shall send a message to an implementation-defined logging facility, which may log it in an implementation-defined system log, write it to the system console, forward it to a list of users, or forward it to the logging facility on another host over the network. The logged message shall include a message header and a message body. The message header contains at least a timestamp and a tag string." (quoted from http://pubs.opengroup.org/onlinepubs/9699919799/functions/syslog.html ) I believe the journal constitutes a compliant back-end to POSIX syslog(), no doubt much to many people's disgust. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54397ef6.7030...@zen.co.uk
Re: Bash usage: was implicit linkage
On 12/10/14 04:12, Peter Zoeller wrote: But the nice thing is shell scripting is simplistic easy to learn and understand. I refer the audience to David A. Wheeler's essay[1] on how to handle filenames correctly in shell scripts, and to the bug report that he filed against POSIX.1-2008[2] on the subject. From those, I take away the lesson that no, shell scripting is not simplistic, easy to learn, and easy to understand. It just *looks* simplistic, easy to learn, and easy to understand, in ways that make it a horribly effective footgun. [1] http://www.dwheeler.com/essays/filenames-in-shell.html [2] http://austingroupbugs.net/view.php?id=248 - If the people who curate the standard commit these kinds of errors when writing examples for the standard, what hope does J. Random User have? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543a3ce7.5000...@zen.co.uk
Re: [exim4] Testing and making sense of smtp output
On 12/10/14 14:52, lee wrote: Harry Putnam writes: Can any of you experienced exim4 hands interpret this output? Reading RFC-821 would tell you more. Reading RFC 2821 would be even better, since RFC 821 is obsoleted by RFC 2821. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543a9eeb.3070...@zen.co.uk
Re: Moderated posts?
On 12/10/14 15:53, lee wrote: And when they are filtered, does the sender get a message telling him that their message hasn't been delivered? The requirement in RFC 2821 (the successor to RFC 821 which you've recently been referring to) section 4.2.5 that a server which issues a 2yz completion status after final dot must return appropriate notification to the sender cannot be fulfilled is an unreasonable demand in the modern era. If you wait for all filtering to complete before issuing a response to final dot, your mail server is vulnerable to denial-of-service attacks unless you undercook your filtering; if you issue a 2yz status before filtering is complete, then send the notifications demanded by RFC 2821 if the deferred filtering results in a rejection, your mail server is now a public nuisance because of the amount of backscatter it generates. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543a9f9f.60...@zen.co.uk
Re: implicit linkage
On 12/10/14 01:43, lee wrote: Reco writes: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c?id=3731acf1acfb4a6eb68374a5b137f3b368f63381#n638 Ah, this is a wonderful example :) My assumptions about the code were right. Does all/most of systemd look like that? I'm not seeing a serious problem with that function. I mean, I can certainly think of better ways to write it, but I don't find it bad enough that I'd want to *bother* doing so. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543aaedc.5070...@zen.co.uk
Re: implicit linkage
On 12/10/14 18:13, John Hasler wrote: Martin Read writes: I'm not seeing a serious problem with that function. You have no problem with an 1800 line function? The thing that you are asking me if it is the case is not the thing I said. I have a problem with 1800 line functions in general; they're clearly undesirably long. I don't have a *serious* problem with 1800-line functions *in general*, though they're certainly on my list of things that should be refactored. Moving on to the specific case, I don't have a *serious* problem with that particular 1800-line function. It certainly merits refactoring (I can even see an obvious starting point for doing so), but it's not unreadable or hard to follow; it's just inconveniently long. But while we're on the topic of things I have a problem with, here's one: people choosing to interpret "I'm not seeing a serious problem with that function" as "I have no problem with that function" :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543ac220.8060...@zen.co.uk
Re: piece of mind (Re: Moderated posts?)
On 12/10/14 23:04, lee wrote: Bas Wijnen writes: Because for a GR, a member of Debian has to request it and it needs to be seconded by at least 5 other members (constitution 4.2.1, 4.2.7). This has not happened. I know, and I'm suggesting to omit this requirement. Technically, there *is* a way for a GR to be brought forward for discussion and voting without having six DDs supporting it: the Project Leader can personally propose it. The Project Leader has not done so, and the Debian Constitution does not place any obligation on the holder of the post of Project Leader to propose any particular General Resolution. Any change to these constitutional arrangements would require the Debian Constitution to be amended, which (per the Constitution) requires a General Resolution validly proposed under the existing arrangements and then passed by a 3:1 supermajority in the ensuing vote. I would argue in any event that it's probably inappropriate for the Project Leader to propose a General Resolution which has already been proposed by a DD and failed to receive the required number of sponsors. Then they shouldn't say in their social contract that the users and their needs are the priority. It is precisely *because* decisions in Debian are not made by the users-at-large, but only by the Debian developers, that the social contract by which the developers are expected to abide when working on the Debian project must explicitly state that the interests and needs of the users are important. This, of course, leads us to two interesting points: 1) the Debian Developers are themselves users of Debian 2) the Debian user community is not a monolithic entity whose constituent parts have uniform and identical interests and needs Besides, I very much doubt a proposal to redraft the DSC in a way that removed the passages about the importance of the users would receive even a 1:1 majority, let alone the 3:1 majority required to supersede one of the constitutionally-designated Foundational Documents. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543bd8c7.7070...@zen.co.uk
Re: Moderated posts?
On 14/10/14 00:47, Joel Rees wrote: There is a header for requesting automatic confirmation of delivery, but it tends to be abused by malicious junkmailers (spammers). MUAs are supposed to be able to disable it, but I haven't seen that option in an MUA settings dialog for a long time. I'm looking at a configuration dialog for handling emission of return receipts in Icedove right now (offering an option of "absolutely never", or alternatively a three-way distinction between categories of messages which can be set to "never", "ask me every time", and "always"). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543cddee.1090...@zen.co.uk
Re: piece of mind (Re: Moderated posts?)
On 14/10/14 13:54, Miles Fidelman wrote: Andrei POPESCU wrote: Have you actually looked into what depends on systemd? Trying to. As a start - anything that depends on udev and logging come to mind; Strictly speaking, yes, udev is part of the systemd suite. However, it is perfectly capable of being installed and run on a Debian jessie system without the rest of the systemd suite being installed; if it fails to work correctly in such a configuration, that is a bug and should be reported. As for logging, it turns out to be the case that Debian jessie only uses systemd-journald as part of its logging system if you are using systemd as PID 1. On otherwise-default Debian jessie systems where systemd is not PID 1, logging is handled directly by rsyslog, which is not in any way shape or form conceivably describable as being part of systemd. all services that require startup (hmm... I run a server, not a desktop - so that would be pretty much everything). Per the technical committee's formally stated expectation that maintainers will continue to support the multiple available init systems in Debian [1], it is clearly a reportable bug for (approximately) any package in Debian to not support init systems other than systemd. It would also be somewhat astonishing for most services, *particularly* those which would primarily be found in a server environment rather than on a desktop system, to depend on interfaces of systemd-logind, which is the main source of dependencies on a systemd suite component other than udev/libudev. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746715#278 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d2488.3050...@zen.co.uk
Re: piece of mind (Re: Moderated posts?)
On 14/10/14 14:33, Miles Fidelman wrote: Which brings us back to how upgrades and new installs will be handled - will there be an option to go right to sysvinit-core, or will we have to manually uninstall systemd and anything that depends on it? Getting all the metapackages and dependencies right could be a real pain. For *upgrades*, my understanding (as a user) is that you will be able to go straight to sysvinit-core by explicitly installing it before you invoke apt-get upgrade. For a belt-and-braces approach, you could also add an APT configuration fragment[0] pinning systemd-sysv to not be installable (so that *whatever* APT does, it won't involve systemd-sysv getting installed). I don't know what the process is expected/intended to be for new installations where a non-default init system is desired. [0] I've seen the relevant fragment posted recently, but I can't remember where and I don't remember the exact contents. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d3b2b.3010...@zen.co.uk
Re: piece of mind (Re: Moderated posts?)
On 14/10/14 15:56, Steve Litt wrote: On Tue, 14 Oct 2014 11:25:23 +0300 Andrei POPESCU wrote: Have you actually looked into what depends on systemd? PAM is enough for me, considering everything that uses PAM. They could have made their PAM plug compatible with the old PAM, but nooo. I find these statements confusing, and crave enlightenment. When I look up libpam-systemd on packages.d.o, I see the following sentence: "This package contains the PAM module which registers user sessions in the systemd control group hierarchy." and the following dependencies: dep: libpam-runtime (>= 1.0.1-6) Runtime support for the PAM library dep: libpam0g (>= 0.99.7.1) Pluggable Authentication Modules library Now, I may be being dim here, but it looks to me like that means that libpam-systemd is, in fact, plug-compatible with PAM. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d433a.6040...@zen.co.uk
Re: Conflict of interest in Debian
On 14/10/14 16:05, Scott Ferguson wrote: And how should we interpret that in light of your signature and constant plugging of your business on the list? Perhaps Joey Hess's signature holds the answer? I presume you mean Joel Rees (yes, I get their names mixed up occasionally too), since Joey Hess's signature just says "see shy jo". -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d4da1.1040...@zen.co.uk
Re: piece of mind (Re: Moderated posts?)
On 14/10/14 16:48, Steve Litt wrote: So are you saying I could use sysvinit or nosh as my PID1, drop in libpam-systemd and no other systemd components, and have all PAM functionalities run properly? Thank you for the clarification. The short and vague answer is "no"; PAM modules that depend on external programs for correct operation don't run properly if those programs aren't present. (pam_systemd is not the only such module that is part of Debian.) For a longer and more accurate answer, I refer to the pam_systemd(8) man page: If the system was not booted up with systemd as init system, this module does nothing and immediately returns PAM_SUCCESS. It appears, then, that the answer is that your other PAM modules will not be prevented from running properly, while the pam_systemd module's behaviour will be reduced to a no-op returning PAM_SUCCESS, presumably meaning that it won't cause any PAM failures but that programs which expect it to have done something useful will probably not work correctly. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543d5ee6.3020...@zen.co.uk
Re: piece of mind (Re: Moderated posts?)
On 14/10/14 22:56, Steve Litt wrote: On Wed, 15 Oct 2014 00:15:40 +0300 Andrei POPESCU wrote: As far as I understand none of the upstreams are actually requiring systemd itself (or more accurately systemd-logind), but the interfaces it is providing. I fail to see the distinction. As long as the interface is there (and works), they don't care how it's implemented. The interface is defined, and it certainly *looks* externally reimplementable. And it also seems to make sense (why should every Desktop Environment implement it's own solution for this?). Because you don't want to inextricably drag a giant monolith into your Desktop Environment just to do a few things. "If I have seen further than other men, it is by standing on the shoulders of giants." The alleged monolith does a bunch of (probably mostly neither interesting nor trivial) stuff for me. That means I don't have to do that stuff myself, and can concentrate on doing the things that are either interesting or trivial. Besides, the average DE is pretty beefy itself. And how were they handling this task before systemd? They were using ConsoleKit, which was orphaned upstream some time after systemd-logind came along. It's not like Desktops, Window Managers and whatever things like lightdm are called didn't exist before systemd. (For reference: things like lightdm, xdm, slim, gdm3, etc. are called "display managers", and have been since 1988.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543e2b7a.50...@zen.co.uk
Re: piece of mind (Re: Moderated posts?)
On 15/10/14 17:30, Steve Litt wrote: Pre-cisely. I see Red Hat's fingerprints all over that unmaintained status. If not for Red Hat, somebody would have picked up ConsoleKit. After all, as shown in http://spectrum.ieee.org/computing/software/whos-writing-linux , there's plenty of money floating around to pay for free software development. A question for you: Which funder of free software development do you believe would realistically stand to make a measurably-greater-than-unity return on investment (either in "reasonably foreseeable losses averted" or "reasonably foreseeable new profits obtained") by choosing to underwrite (or assign employees to) resumed development of ConsoleKit? I have a couple of observations which I think may be relevant: * The set of people hostile to systemd seems to include a lot of people who don't see much need for the likes of ConsoleKit either. * ConsoleKit isn't, in terms of its size, particularly intimidating; the actual C source code is only about 20% larger than the autotools-associated shell scripts. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543ecad3.8020...@zen.co.uk
Re: Openbox systemd-free
On 17/10/14 10:16, Mark Carroll wrote: Steve Litt writes: (snip) I'll also try to find a systemd-free alternative to LibreOffice, and to Gnumeric (Gnumeric will be tough, it's actually a good program). (snip) LibreOffice is enormously useful for Microsoft Office compatibility. Why on Earth does it require systemd? As far as I can easily and quickly determine, LibreOffice doesn't. I therefore conclude that if it does, it'd be because of a chain of dependencies (possibly involving at least one Recommends: step). As it happens, the same goes for Gnumeric. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5440ea10.1020...@zen.co.uk
Re: XFCE + Konsole - sorting by terminal title?
On 17/10/14 14:10, francis picabia wrote: The problem is with finding terminals. I often have over 60 open at once. The task bar or whatever it is called in XFCE stacks the open Konsoles, but the listing of them is probably by the order of which they were opened. I'd rather it was alphabetical, to save time jumping from one system to another. I'm sure others have the same issue. How is it managed? Do you just look up and down the list of Konsoles until you spot the hostname you want to switch to? The Preferences dialog for xfce4-panel's "Window Buttons" component (which implements the "task bar") has an option for controlling the sorting order, which offers the following options: Timestamp Group title and timestamp Window title Group title and window title None, allow drag-and-drop (This is on a Debian jessie system; I don't have a wheezy installation handy.) I believe either the third or fourth option would be the one you want. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5441185b.2010...@zen.co.uk
Re: GR proposed re: choice of init systems
On 18/10/14 02:38, Steve Litt wrote: I would add that it should be delegated to an interchangeable part through a well-specified thin interface, without global variables like dbus. Or, if there *must* be a global variable, at least make it purposed only for interaction between init and program, and not used by my music player to announce song titles. Conveniently, it appears that on my Debian jessie system, there are distinct system and session dbus-daemon instances. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54423a57.1060...@zen.co.uk
Re: Good news on claws-mail
On 18/10/14 16:29, Peter Nieman wrote: And I don't understand "TIA", unless it's Spanish. "Thanks In Advance" Well, I thought there was a strong relationship between systemd and dbus. Various parts of the systemd suite, including the systemd init daemon, use dbus to present its control interfaces. The dbus daemon does not require any of the executables of the systemd suite, though it does link against the library libsystemd which is maintained upstream as part of the systemd suite (and is provided in Debian as part of the 'libsystemd0' package). (Quite a few things that aren't part of the systemd suite and don't require any of the executables of the systemd suite to be installed link against libsystemd.) As far as I am concerned, I don't have the time right now to learn the officially accepted procedures of filing bug reports in Debian, It's fairly straightforward: https://www.debian.org/Bugs/Reporting The recommended procedure is to install the 'reportbug' package, then run the 'reportbug' program, *ideally* on the system where you are encountering the bug so that it has the best chance of submitting all the relevant information. (And honestly, if you don't have time to learn the officially accepted procedures of filing bug reports in Debian, I'm amazed you have the time to read debian-user in its current state.) I don't have the time for filing reports for all the bugs I find, and I also assume that you'd have to register somehow before being allowed to bring your reports to the maintainers' attention There is no registration requirement for reporting bugs in Debian. > (as they don't read users' opinions here), Quite a few Debian package maintainers do, in fact, subscribe to, read, and post the debian-user mailing list. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54429563.3000...@zen.co.uk
Re: GR proposed re: choice of init systems
On 19/10/14 17:45, Rusi Mody wrote: As for 'wounded ego': Do you have a wounded ego if a dead branch falls and smashes the windshield of your car? Or a Tsunami knocks off your seafront house? If you are taking offense, who are you offended by? Debian is not a person (as far as I know!) Debian is a project created by a group of people. It is not a force of nature. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5443eef9.2020...@zen.co.uk
Re: GR proposed re: choice of init systems
On 20/10/14 01:28, berenger.mo...@neutralite.org wrote: Did they successed with wayland? I just took a look at weston and it seems to be linked to stuffD... and with Dbus, when I thought I had read time ago things about them using a home-made bus, because they thought dbus was too heavy... I hope I'm wrong? A default build of the Weston reference Wayland compositor will link against libdbus, because the default build includes support for interacting with logind. It *appears* (from the options offered by the configure script) that building Weston with dbus and logind support is optional. Not being involved in the project, I have no information about how well-tested that configuration is and will leave any further commentary on the subject to people who have the relevant knowledge. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54450388.1020...@zen.co.uk
Re: How do I restore my desktop
On 21/10/14 13:31, j...@ageinggracefully.ca wrote: I run xfce on jessie/sid. I zapped my desktop when trying to stop a process using the task manager. This happened to me a few years ago and I've forgotten how I fixed it. I believe the program you want to run is "xfdesktop". -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544666ab.5090...@zen.co.uk
Re: Pacemaker/Corosync on testing
On 22/10/14 09:56, Denis Witt wrote: I wanted to take a look at systemd and pacemaker/corosync on Debian Jessie. I noticed that the pacemaker package has vanished. Instead you should install the crmsh package. This package recommends pacemaker which doesn't exists. That's strange. According to aptitude on my desktop machine, the package "pacemaker" is currently available in jessie at version 1.1.10+git20130802-4.1. Looking at the packages.qa.debian.org page for this package, I see that this version migrated to testing on 2014-10-21. Run apt-get update and look again. If it still isn't there, perhaps the Debian mirror you're using is out of date. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54477f37.1070...@zen.co.uk
Re: gftp bug #763314 workaround
On 22/10/14 11:28, rudu wrote: But here on my jessie box, I can't find any GTK+2.0 package to upgrade. So, what am I missing here ? The relevant package is "libgtk2.0-0". Note that the version number appears to have been mis-stated in message #37, and is 2.24.25-1, not "2.25.1". -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54479020.5060...@zen.co.uk
Re: Keep using Debian without GNOME and SystemD
On 22/10/14 08:37, Dimitrios Chr. Ioannidis wrote: What details do you think are neccecary ? Just grab a DI-b2 img, install xfce or lxde ( with the menu or with desktop= doesn't matter ) and then try to remove *all* the systemd utilities / libraries etc. dbus-daemon is linked against libsystemd in Debian jessie. That's not going to change at this point. The Debian package of xfconf (XFCE's configuration mechanism) depends on the package 'dbus-x11', which depends on the package 'dbus' (the one that contains dbus-daemon), implying that it requires a working dbus-daemon for correct operation. Looking at the upstream website for XFCE, I see that xfconf lists dbus as a *non-optional* dependency. (This is leaving aside the whole matter of one of the programs in the essential package 'bsdutils' now being linked against libsystemd as a result of a perfectly reasonable decision.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5447d601.8040...@zen.co.uk
Re: containers/chroot to allow ABI breakage is the wrong approach
On 24/10/14 10:12, Thomas Goirand wrote: On 10/21/2014 05:12 PM, Thorsten Glaser wrote: OpenBSD’s libc.so major number is 50 or something like that right now, because they – correctly – increment it on every incompatible change. The correct thing to do is to not do incompatible change. A wonderful aphorism. Now, what do you do when the only sane way to resolve a critical security vulnerability, or implement a feature demanded-with-good-reason by 95% of your users, is to make an incompatible change? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544a3dc8.5080...@zen.co.uk
Re: How To Prove Systemd Can|Cannot Be Jessie Default
On 25/10/14 15:31, Peter Nieman wrote: 3. There's no alternative to X so far, but there are several alternatives to systemd, and one of them has worked perfectly well for most people until the present day. I would take the "several alternatives" as tending to indicate that perhaps sysvinit + sysvrc does not work "perfectly well", but instead merely BALGE (By And Large Good Enough). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544bc3f8.50...@zen.co.uk
Re: Who's locking down the code?
On 27/10/14 14:37, John Hasler wrote: This is something called "util-linux-ng" which isn't even in Debian. The internet tells me that the current upstream incarnation of util-linux was called "util-linux-ng" between 2006-2010, and apparently has not had its mailing list renamed when the project itself was renamed to util-linux. https://anonscm.debian.org/cgit/collab-maint/pkg-util-linux.git/tree/README?h=debian-2.24 says 'Note that in years 2006-2010 this project used the name "util-linux-ng".' -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544e5bef.1010...@zen.co.uk
Re: Camera SD card mounting problems (defined by systemd)
On 31/10/14 21:31, The Wanderer wrote: If the mount failing isn't that critical, then the "right way" to fix the problem under systemd's apparent design would probably be to add the "noauto" label to the fstab, so that the device will not mount automatically on boot. If there's a way to configure a mount to be attempted at boot time, but not fail the boot if the device is not present, I don't know what it is. Use the well-documented fstab(5) option "nofail", which predates the creation of systemd. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54540e2b.7020...@zen.co.uk
Re: Perfect Jessie is something like this...
On 01/11/14 01:53, lee wrote: It doesn't need these code paths. The library doesn't do anything unless you do have the software actually running which the library makes useable --- at least that's what was said. Of course, not all cases are the same, yet in this case, the library shouldn't be installed unless the software it is for is installed. Gentoo and Funtoo are > over there, just like they were months ago when you first started complaining about systemd on debian-user. If you move over to using them instead of Debian, you'll probably be happier (because you'll have more control over what software runs on your systems and how it's configured) and the Debian maintainers will probably be happier (because there will be one fewer person haranguing them for refusing to embrace combinatorial explosion). Everyone wins. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5454b8a2.9070...@zen.co.uk
Re: /bin/perl vs. /usr/bin/perl
On 01/11/14 14:52, lee wrote: what's the proposed Debian way to deal with a different location of the 'perl' executable? #! /usr/bin/env perl Fedora has /bin/perl, Debian has /usr/bin/perl. Since I still have Fedora on the desktop and Debian on the VMs, I need compatibility. ... but I thought that on Fedora, /bin was turned into a symlink to /usr/bin in F17, so unless you've got some pre-F17 Fedora systems to care about, /usr/bin/perl should be fine on Fedora. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5454fc84.2040...@zen.co.uk
Re: How To Prove Systemd Can|Cannot Be Jessie Default
On 01/11/14 19:21, Martinx - ジェームズ wrote: After a week of tests, I realized that `systemd-journal` is not ready for prime time. A lot of times, it consumes 100% of CPU, making the system almost unusable. Debian Jessie should not activate `systemd-journal` by default (for logging), even when with systemd = PID1. Excellent. What's the reproducible method of causing this outcome, and which Debian (or upstream) bug number is associated with your findings? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545544a5.7030...@zen.co.uk
Re: Idea: Rename package `udev` to `systemd-udev`, plus new `udev` metapackage, to "preserve freedom of choice of init systems".
On 02/11/14 01:37, Martinx - ジェームズ wrote: Thoughts?! As I understand it, eudev is intended to provide all of udev's externally-visible functionality in an interface-compatible way, so it seems to me that whoever packages eudev should *probably* be able to declare it to be an adequate replacement for udev simply by adding "Provides: udev" to the control file. (udev is not designated 'essential', so you don't need to do the elaborate dance that was done with the new 'init' metapackage.) (ObDisclaimer: I am not a Debian packager, so my understanding of Debian policy may be incomplete, and this isn't the best place for discussing Debian packaging anyway.) As for mdev: you need to talk to the Debian maintainer of busybox about that, since mdev is part of the busybox upstream source package. I will note that mdev should probably *not* be marked "Provides: udev", since judging by this page on the gentoo wiki: http://wiki.gentoo.org/wiki/Mdev it *isn't* an interface-compatible drop-in replacement for udev. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54561377.60...@zen.co.uk
Re: Mount order after systemd update
On 03/11/14 09:13, Erwan David wrote: On Mon, Nov 03, 2014 at 09:33:30AM CET, Jonathan de Boyne Pollard said: That's what you get when your first recourse is Google rather than the manual that comes with your software on your computer. (-: The manual pages that you should be reading are: * man -S 5 crypttab # (http://freedesktop.org./software/systemd/man/crypttab.html) * man -S 8 systemd-cryptsetup-generator # (http://freedesktop.org./software/systemd/man/systemd-cryptsetup-generator.html) * man -S 8 systemd-cryptse...@.service.html # (http://freedesktop.org./software/systemd/man/systemd-cryptse...@.service.html) Sorry, but this doc should be available *before* migration, because it would render things unbootable to insall without configuring. It *is* available before migration - Jonathan has helpfully provided you with URLs for reading that documentation on the freedesktop.org website. There is also an assortment of other information on freedesktop.org about how to use systemd, above and beyond a complete set of systemd man pages: http://www.freedesktop.org/wiki/Software/systemd/ Same thing how to GUESS those names ? I seldom try to *guess* the names of programs I want to read documentation for, since very few programs of *any* kind have decently guessable names. I instead use tools like "apropos relevant-syllable" on my Linux systems (which often provides useful results), and adding things like "documentation" or "manual" or "man page" to my WWW searches. Here's what "apropos -s 1:4:5:7:8 crypt"[0][1] returns on my Debian jessie system: mormegil@cocytus:~$ apropos -s 1:4:5:7:8 crypt cisco-decrypt (1)- decrypts an obfuscated Cisco vpn client pre-shared key cryptoflex-tool (1) - utility for manipulating Schlumberger Cryptoflex data ... cryptsetup (8) - manage plain dm-crypt and LUKS encrypted volumes cryptsetup-reencrypt (8) - tool for offline LUKS device re-encryption des_modes (7ssl) - the variants of DES and other crypto algorithms of Ope... gpg (1) - OpenPGP encryption and signing tool gpg-zip (1) - encrypt or sign files into an archive gpg2 (1) - OpenPGP encryption and signing tool gpgsm (1)- CMS encryption and signing tool libgcrypt-config (1) - script to get information about the installed version ... luksformat (8) - Create and format an encrypted LUKS device mkpasswd (1) - Overfeatured front end to crypt(3) ntfsdecrypt (8) - decrypt or update NTFS files encrypted according to EFS pkcs15-crypt (1) - perform crypto operations using PKCS#15 smart cards smbpasswd (5)- The Samba encrypted password file symcryptrun (1) - Call a simple symmetric encryption tool systemd-cryptsetup (8) - Full disk decryption logic systemd-cryptsetup-generator (8) - Unit generator for /etc/crypttab systemd-cryptsetup@.service (8) - Full disk decryption logic zipcloak (1) - encrypt entries in a zipfile mormegil@cocytus:~$ [0] Searching for a distinctive *subset* of a relevant word is usually more helpful than searching for a complete word, hence "crypt" rather than "encrypted" or "encryption" or whatever. [1] I just discovered the '-s' command line flag to apropos. I am so happy; no more wading through reams of function man pages when I'm trying to find the man page for a program or a configuration file. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545764be.7000...@zen.co.uk
Re: "Lennart Poettering Linux" -- some real eye openers here ... don't be blindsided!
On 10/11/14 08:57, Andrew McGlashan wrote: And for those choosing to go with systemd they'll need 20 updates of Jessie just because the kernel is intrinsically linked to systemd and needs an update. Debian wheezy entered freeze with Linux kernel version 3.2.30. As of today, a system running wheezy and wheezy's security updates contains Linux kernel version 3.2.63. (People using wheezy-backports, or compiling their own kernels, may well have a later version of the kernel.) Debian jessie has entered freeze with systemd version 215 and Linux kernel version 3.16.5. When it becomes the new 'stable', it will contain systemd version 215 and a 3.16 Linux kernel. By the time it becomes 'oldstable', a system running a default installation of jessie and jessie's security updates will *still* contain systemd version 215 (possibly patched to resolve any security issues that have arisen over its lifespan) and a 3.16 kernel. This is how Debian works, and I have seen nothing to suggest that it will not be how Debian works during the lifespan of jessie. As such, if you wish people to believe your claim that a fully security-updated Debian jessie at the point it becomes oldstable will contain a 3.morethan16 Linux kernel and a version of systemd later than 215, it's incumbent on *you* to provide evidence for your claim. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54609997.7040...@zen.co.uk
Re: systemd - so much energy wasted in quarreling
On 10/11/14 19:26, Tanstaafl wrote: Exactly, it should remain in unstable unless/until it can be released *perfectly* stable, so if that means it stays in unstable for 5 years, so be it. If you want *perfectly* stable software, why are you using software that isn't formally proven? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54611723.1050...@zen.co.uk
Re: should I really be using the amd64 list?
On 11/11/14 15:23, Michael Fothergill wrote: Dear Debianists, Should I really be on the amd64 list not this one as an amd64 user? The description of the debian-amd64 list is "Debian port to AMD64 Porting Debian to AMD x86-64 architecture." so unless you're involved in Debian's amd64 porting effort I'd say you probably don't have any reason to post to that list. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54623312.5080...@zen.co.uk
Re: Perfect Jessie is something like this...
On 12/11/14 14:20, Klistvud wrote: As a side note: once systemd is put in place, such problem-less and swift migration between desktop environments is just one of the many "Good Things Linux" going down the drain... Eh? I'm running XFCE *just fine* on a jessie box with systemd as init, and if I wanted to switch to a different DE, all I'd need to do is install it and tell my display manager to launch that flavour of session. Using systemd as your init daemon does not force you to use GNOME; it doesn't even force you to use a "desktop environment" when you use X. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54637b18.4080...@zen.co.uk
Re: VPN routing on Sid
On 13/11/14 11:10, Luis Finotti wrote: Ah, that worked! Could you explain the "192.168.29.0/24" syntax though? I'm having a hard time finding what it means. (Is it a range 0 to 24?) The "/24" means that only the first 24 bits of the address are significant for matching purposes. So, 192.168.29.0/24 matches all addresses in the range 192.168.29.0 through 192.168.29.255. (Do say if that's not enough detail.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5464afe0.2010...@zen.co.uk
Re: Installing an Alternative Init?
On 15/11/14 23:04, Paul E Condon wrote: If one could absolutely rely on apt-get always getting it right, then "apt-get install -y sysvinit-core" could always be used to remove systemd even from a system that has been booted into systemd and running, and not just in the context of a pre-seed. Right? That command is unlikely to actually remove systemd on any Debian jessie system. What it will do is change what the symlink /sbin/init points to so that next time the system on which you do it is rebooted, it will use sysvinit as the init daemon. But if that that apt-get command doesn't work on an installation of systemd, *that* is a bug in apt-get that *should* be fixed in Jessie *before* it is released. Right? Probably wrong. It seems to me that if doing "apt-get install -y sysvinit-core" on a Debian jessie system fails, it's far more likely to involve a packaging bug in one or more of the packages being added/removed than a bug in apt-get. And the apt-get command, "apt-get install -y systemd" should switch a host that is running sysvinit or upstart, to running systemd. Nope. It should install the programs comprising the systemd suite... If not that is *another* bug in apt-get that must be fixed before release of Jessie. ... but if you meant "apt-get install -y systemd-sysv", I stand by my statement above: any problems arising in this process are unlikely to be bugs in apt-get. And while writing this, I noticed that "apt-get install -y systemd-sysv" on a system running upstart looks like it will have... *unhappy* consequences, since unlike systemd and sysvinit, upstart has not had its packaging restructured into a package full of programs and a package that changes the /sbin/init symlink. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5467ee7c.6090...@zen.co.uk
Re: Installing an Alternative Init?
On 16/11/14 00:21, Paul E Condon wrote: It should be possible to install systemd on a system that already has some other init system installed on it. This should be tested, but how? The obvious way is to upgrade a wheezy system, following the "upgrade to jessie while keeping sysvinit as the init system" procedure, reboot, and then install the package 'systemd-sysv' and make sure that the system (a) keeps running and (b) reboots cleanly. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5467f082.2080...@zen.co.uk
Re: If Not Systemd, then What?
On 16/11/14 11:40, Klistvud wrote: 1. Reviving the existing init systems. Modernizing them, making them into true, interchangeable drop-in replacements of each other, which do the task assigned, and do it well. Each of them accomplishing at least the common subset of tasks an init system is supposed to provide. Given the profundity of disagreement about what "init systems" are "supposed to provide", I believe that this would be a Sisyphean task. Positions people hold on the topic include, but: 1. The init daemon should fork exactly once; in the child it should exec another program, while the parent (PID 1) does nothing except reap zombies. 2. As (1), except that if the initially-forked child process exits, PID 1 should repeat the fork and exec-in-child procedure. 3. The init daemon should have a simple integrated service management mechanism akin to sysvinit's "/etc/inittab". 4. The init daemon should have a complex integrated service management mechanism, perhaps akin to those of upstart or systemd. 5. The init program should do some basic setup, then exec a service manager daemon *within PID 1*. Moving on from *there*, let's take a look at two of the things you suggest, each of which are quite reasonable in isolation. On the one hand, "making them into true, interchangeable drop-in replacements of each other" suggests to me that you think they should all have exactly the same set of interfaces and functionality. I don't agree with this position, but it's reasonable, though it's rather stifling (since now you can't add new functionality unless you can persuade all the other init maintainers to add it). On the other, "each of them accomplishing at least the common subset of tasks an init system is supposed to provide" suggests to me that you think it would be all right for some of them to have extra interfaces and functionality - but as soon as you allow extra interfaces and functionality, you no longer achieve the "true, interchangeable drop-in replacements" part. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5468c4a7.5000...@zen.co.uk
Re: If Not Systemd, then What?
On 16/11/14 17:33, Laurent Bigonville wrote: Are you aware that this is the approach that systemd and upstart have taken, right? 1) Both systemd (PID1) and upstart are drop-in replacement for the good old SysVinit as they both support the common "standard" that are LSB scripts (A really good share of the existing LSB initscripts in the debian archive are just working out of the box). Well. They're (mostly) a drop-in replacement for sysvrc and its supporting tools. They're certainly not a *drop-in* replacement for *sysvinit*, because they don't support all of sysvinit's interfaces; specifically, they don't support /etc/inittab. Luckily (for some values of lucky), /etc/inittab was such a terrible interface (it's unpleasantly reminiscent of Angband's monster, item, etc. databases) that it seems even most people who prefer sysvinit to systemd or upstart were using a factory-default /etc/inittab. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5468e830.30...@zen.co.uk
Re: Joey Hess is out?
On 17/11/14 12:25, Gian Uberto Lauri wrote: There were other poor design choices, it seems that Debian maintainers have fixed some of them (i.e. renaming network devices), other seems to be still there (binary logs...). A default Debian jessie configuration has persistent text logs in /var/log written by rsyslog, and *volatile* binary logs in /run/log/journal written by systemd-journald. Removing the binary logs completely disables functionality of the systemd suite which an administrator familiar with systemd would expect to be present by default. Administrators of systemd-based systems who wish to turn off the binary log can, of course, simply add the line Storage=none to the [Journal] section of /etc/systemd/journald.conf, at which point systemd-journald will simply forward all log entries directly to rsyslog without writing them to a binary file. If installing, or upgrading to, jessie resulted in a configuration with *only* binary logs, and this was not the obvious foreseeable result and intent of a deliberate administrator action taken during the installation/upgrade procedure, then that is probably what we call a *bug*, and is the sort of thing that is why Debian has a "testing" branch. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5469f671.8000...@zen.co.uk
Re: No Google bubble?
On 19/11/14 17:56, Curt wrote: As for country-specific results (language-oriented, certainly) how does ducky ducky a gogo handle the Tower of Babel problem? I don't know if they apply any geoip checks to inbound traffic, but they certainly support the "lang:ISO_language_code" search term (compare the results of "john wayne lang:en" with "john wayne lang:fr"), and there are some fairly obvious heuristics that I'd expect any competent search engine implementer to apply like "this query is written entirely in the Armenian alphabet, so we should probably prefer Armenian-language results even if the user has not specified 'lang:hy'." -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546cf55f.5090...@zen.co.uk
Re: udev memory problem when trying to plug a disk with corrupted partition table
On 20/11/14 01:03, Scott Ferguson wrote: On 20/11/14 04:06, "Morel Bérenger" wrote: I think it's msdos. AFAIK mdos partition tables don't support anywhere near that number of slices. :( MSDOS extended partitions contain a linked list of logical partitions. It looks, from the pattern of that table, like the linked list has been corrupted so as to form a cycle. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/546d47a2.2080...@zen.co.uk
Re: USB problem, hardware issue
On 21/11/14 11:50, Joel Roth wrote:
I upgraded sid, either to get new versions of software,
and to avoid too long a gap in time (which I was told could
lead to problem in upgrades having too cross too much
"distance".) I note that apt-get upgrade/dist-upgrade did
not advise installing new kernels.
In general, apt-get {dist-,}upgrade will never advise installing new
kernels. It will install new kernels automatically if you have the
linux-image-ARCHNAME metapackage for your architecture installed; if you
don't have that metapackage installed (e.g. because you compile your own
kernels), then new kernels (other than minor upgrades of the currently
installed kernel version, if you're using a packaged kernel) will only
be installed if you explicitly install them.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546f52fa.20...@zen.co.uk
Re: Why focus on systemd?
On 22/11/14 09:50, lee wrote: Nobody understands udev rules, Challenge accepted. *looks at /etc/udev/rules.d* *looks at /lib/udev/rules.d* I'm honestly baffled that someone who is capable of comfortably using emacs thinks these files are incomprehensible. They appear to be written in a domain-specific declarative language with a fairly straightforward syntax. *runs "man 7 udev"* Yup. Pretty straightforward. Some highly-commented example files would be *nice*, but I don't see anything particularly intimidating in there. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5470a6ce.9030...@zen.co.uk
Re: systemd-free alternatives are not off topic.
On 24/11/14 13:25, Jerry Stuckle wrote: And exactly what is the "Debian way" to add custom (NOT customized pre-packaged) software to the system? As far as I can tell, the obvious things that go into the "Debian way" for installing custom software are: 1) If your software isn't installed via Debian's packaging system, avoid conflicts with the packaging system by installing it in places that Debian's packaging system is not supposed to manipulate (e.g. /usr/local) 2) If your software needs an "init script", make sure that your script includes a correct LSB header and supports at least the "standard" verbs with their expected meanings. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54733990.1010...@zen.co.uk
Re: systemd-free alternatives are not off topic.
On 24/11/14 16:30, The Wanderer wrote: I do not have links to specific messages, since I don't habitually work with or enjoy browsing through Web archives of mailing lists, and since I've never understood (or even understood how to make practical use of) the "message links" - looking outwardly similar to complicated E-mail addresses - which people sometimes use to identify a particular E-mail message. Those "message links" use the Message-ID header, which is supposed to contain a globally unique identifier which can be used to unambiguously refer to the message in question, without worrying about different archives using different sequence numbers etc. Mail user agents should provide some means of viewing the Message-ID field of individual messages, and should also provide a means of searching locally archived mail for a specific Message-ID. The Debian mail archive also has a by-Message-ID search facility available at https://lists.debian.org/msgid-search/ I presume that you will be able to find the thread in your own local archive of recent messages from debian-devel. I wouldn't make that presumption myself, because I wouldn't expect others to keep a local archive of debian-devel given that I don't do so myself. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54736a21.2050...@zen.co.uk
Re: Systemd debugging
On 26/11/14 17:27, Haines Brown wrote: In pursuing this issue, the first thing I found out was that bootlogd is not used with systemd. So instead I did: # systemd --test Don't run test mode as root How else is it run? An excellent question, filed against systemd in Debian as bug #769370 thirteen days ago and not yet responded to. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769370 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547614e0.3000...@zen.co.uk
Re: bind9 needs sometimes a restart after resume from suspend
On 30/11/14 12:02, Andrew McGlashan wrote: On 30/11/2014 8:42 PM, Rainer Dorsch wrote: blackbox:/etc/bind# cat /etc/systemd/system/bind9-resume.service So ... buggy systemd bites yet again; This is *BIND* we're talking about; even if I was opposed to systemd, I probably wouldn't go jumping to the conclusion that this is necessarily a bug in systemd. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547b18d8.1080...@zen.co.uk
Re: Replacing systemd in Jessie
On 01/12/14 01:15, Patrick Bartek wrote: There are work-arounds for dist-upgrading to Jessie without installing systemd as the init, but you'll still have systemd dependencies (libraries usually) for software like GNOME3 or cups or udev to deal with. And you'll have to be on guard that some app doesn't pull in systemd in its entirety as the init. There is a simple mechanism, described in the draft Release Notes for Debian jessie, which can be used to guarantee that APT will not attempt to install the package "systemd-sysv" (which makes systemd be the system initialization and service supervision daemon) when upgrading from wheezy (or at any subsequent point unless and until you, by deliberate action, remove the pin): https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#systemd-upgrade-default-init-system Having taken this step, there is then no need for you to be personally "on guard" against having your init system changed to systemd, as your computer will be faithfully "on guard" on your behalf. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547bc9c8.9080...@zen.co.uk
Re: Debian fork: 'Devuan', Debian without Systemd
On 03/12/14 19:37, Martinx - ジェームズ wrote: Debian/Devuan WILL NEED an `udev` alternative to keep `sysinit-core` working. Perhaps. On the other hand, they might only need an alternative implementation of the user-space glue that makes kdbus work. Devuan will need something like `eudev` to succeed. Conveniently, eudev already exists, has active maintainers, and is readily obtainable in source code form. Anyone willing to embark on a project like Devuan should be perfectly capable of getting it packaged. Jessie isn't Debian. So you say. Others have a different opinion. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547f7bad.6090...@zen.co.uk
Re: Debian fork: 'Devuan', Debian without Systemd
On 03/12/14 21:52, Martinx - ジェームズ wrote: I'm using `GRSecurity` with Debian in prod and it doesn't work with `systemd`. I NEED `sysvinit-core` (or upstart) and there is no plans to deploy `systemd` at my company's public data center. Since it [systemd] doesn't work here. If `systemd` gets fixed (to work with `GRSecurity`), then, I'll give it a second try. Otherwise, I'll need to move to Devuan... Lennart do not care about that: https://bugs.freedesktop.org/show_bug.cgi?id=65575 - How bad is that? A cursory search using duckduckgo with the search terms: +grsecurity +systemd leads me, directly and indirectly, to information on various web sites associated with Arch Linux, Gentoo, and grsecurity which lead me to believe that it is possible to work around the problem described in that bug report without completely disabling CONFIG_GRKERNSEC_PROC. (Of course, I recognize that in any given situation, it may not be acceptable to make the necessary configuration changes.) That said, I don't see a problem with Lennart's position in that bug report anyway. "Well, this sounds useful, but I don't see how we can support this, we need access to the PID directory of the sender of messages, to collect metadata, there's really no way around it." seems like a perfectly reasonable explanation for things not working-as-intended on systems where that access is not available. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547f9a90.5080...@zen.co.uk
Re: Skipping fsck during boot with systemd?
On 08/12/14 01:29, The Wanderer wrote: If that results in you shooting yourself in the foot over the long term, then that's your problem, because you made the decision to prioritize the immediate benefit of cancelling the fsck over the long-term benefit of letting it run. My experience of running Linux on my personal local interactive (rather than server) systems over the past eighteen years leads me to believe that the long-term benefit of *prophylactic* fsck invocations triggered by mount-count or interval-since-check is approximately zero, since *those* invocations of fsck have never discovered FS corruption on my systems. I mean, sure, I've *had* filesystem corruption on my personal local interactive Linux systems - but it was always in a scenario of "hardware failure" or "unclean shutdown". Other people's experience may, of course, be different. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54858da7.4020...@zen.co.uk
Re: Skipping fsck during boot with systemd?
On 08/12/14 08:44, Curt wrote: On 2014-12-08, Stefan Monnier wrote: Actually, it's *always* a surprise. These fsck happen at long enough intervals, that I can never know if it was "4 months ago" or "7 months ago", and neither can I remember which laptop/desktop has the delay set to 172 days vs 194 days vs 98 days vs ... Can't you write a small script to obviate the limitations of your human memory, like this little hacker here did? There is *no legitimate basis* for arguing with the OP's complaint. The systemd transition has caused a user interface regression, which should be fixed. I like systemd, but I do wish certain of its non-coding proponents would stop indulging in incendiary defence of it against legitimate complaints. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54858e7f.2050...@zen.co.uk
Re: 9p/plumber to replace D-Bus?
On 10/12/14 13:26, Marty wrote: On 12/08/2014 09:12 AM, Lisi Reisz wrote: On Monday 08 December 2014 13:18:18 Marty wrote: I would even deign to give users a choice in the matter, [snip] Multi-seat PC and other anachronisms probably have to go away. Choice??? Lisi The industry and its plans for FOSS is strongly anti-choice: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html It appears to me that you have missed a point which seems to be implied by Lisi's choice of selective quotes. On the one hand, you say "I would even deign to give users a choice in the matter", and on the other you suggest making functionality that real people are using on real computers "go away". By all means, embark on your endeavour in creating alternatives to D-Bus. Just remember that to be a convincing alternative, it has to solve *at least* the same set of problems. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54888c00.3050...@zen.co.uk
Re: Dictionary changes
On 02/07/14 18:25, Steve Litt wrote: So then, the question becomes, where does there exist a list of common letters that are, for want of a better word, "ornamented ascii"? Umlauts, Carats, Circles, Grave accents, etc. Are the charts at http://www.unicode.org/charts/ what you're looking for, or do you want something more predigested? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b44a1c.4090...@zen.co.uk
Re: Chown Foibles
On 05/07/14 21:56, David Baron wrote: Continuing to set up my new 64-bit install. Any attempt to chown -R thisuser:thisuser /home/thisuser/.* For example,to reset permissions of hidden items, will change ALL users' home folders, everything. Actually, on the surface, this might seem correct behavior because of the '.' This is, of course, a catastrophe. Their kde, etc, is unusable. How can I do this? chown -R thisuser:thisuser /home/thisuser # note the absence of trailing /.* unless you have some clear reason why someone would need files under their homedir to be owned by a different user or have a non-default group. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b868fe.9040...@zen.co.uk
Re: I'm not a huge fan of systemd
On 06/07/14 00:10, The Wanderer wrote: > Can you run systemd without logind or journald? I can't quickly find an answer, so I'll leave answering that one to someone else. Can you run logind without systemd or journald? If you have something else that provides the systemd interfaces logind depends on, you can run logind (and timedated, localed, and hostnamed) without using systemd as PID 1. This is what the systemd-shim project is intended to allow (but see below). Can you run journald without systemd or logind? I don't know. The question seems somewhat moot to me, since I've seen people who like systemd in principle but think journald is a terrible idea, but I don't think I've seen someone who likes journald but thinks systemd is a terrible idea. If you can, then why is it that libpam package dependencies which appear (if I've understood the discussion correctly) to be about functionality now provided by logind are pulling in systemd *as the active init system* automatically? There appear to be two facets to this: First, the dependency on systemd's interfaces is expressed as a Depends entry of the form "systemd-sysv | systemd-shim", so as I understand it "install systemd-sysv" ends up being the default method of resolving the dependency because it's the first entry in the alternation. Second, logind >= 205 has a further interface dependency on systemd (logind <= 204 sets up cgroups by itself; logind >= 205 relies on systemd >= 205 to do it) which the current version of systemd-shim does not yet fulfill: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752939 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b954fe.9070...@zen.co.uk
Re: I'm not a huge fan of systemd
On 08/07/14 12:00, berenger.mo...@neutralite.org wrote: Le 08.07.2014 08:58, Kushal Kumaran a écrit : Neal Murphy writes: On Monday, July 07, 2014 03:49:52 PM Michael Biebl wrote: Am 07.07.2014 21:29, schrieb Andrei POPESCU: > To prove my point (on a laptop with LXDE and just a few services): > $ grep sleep /etc/init.d/* | wc -l > 27 > $ ls /etc/init.d/* | wc -l > 75 Well, you are clearly more expert than I, beer or not, since I did not known that init scripts had sleeps in them. Just for the info, your regex is not accurate, you do not include comments in it ;) but it won't change the fact that there is a problem: $ grep sleep /etc/init.d/* | wc -l 14 $ ls /etc/init.d/* | wc -l 45 Ratio: 31.1% That's my work computer, with probable unneeded "historical" stuff so I could probably reduce both numbers (since the start of this mail I have removed lot of them btw). Yup, the boot speed improvements come from doing things correctly and event based. Socket activation doesn't necessarily mean things are delayed but simply that explicit orderings are unnecessary. The numbers you have posted are depressing, but doing that over the complete archive is even more so. The last time I did an archive wide check on this was early 2014, at that time we had 1235 SysV init scripts and 1124 occurences of sleep. Whatever happened to semaphores (flags)? Seems to me that if a daemon is a dependency, the second-last startup thing it should do is connect to itself (since it may well be asynchronous); on success, it should run a flag up the pole (touch a file somewhere) to tell the world that it is up and ready to process requests. All of its dependents should wait for that flag to appear before they make their own services available. And later during operation, removal of the flag should cause dependent daemons to withdraw their services. How would dependent services notice the creation/deletion of the semaphore file? Presumably you would want that code (possibly using inotify) to be in a common program, rather than reimplemented everywhere. Since that common program is going to watch for the file and start/stop daemons, let's call that the init service. Both systemd and upstart can do exactly this. But, rather than introducing a file just for this purpose, it would be better to use something essential to the functioning of the service as the semaphore. If the service provides its functionality over a network, it should be considered ready when it listens on a socket. If the service provides its functionality over dbus, it should be considered ready when it acquires a name on the bus. Both systemd and upstart provide mechanisms for such events as well. Indeed, since starting programs is the exact goal of the first PID process. Plus, stuff from systemd is far easier to understand for a beginner (systemd beginner and sysvinit beginner, I insists on this). This dependency managing of dependencies is another advantage of systemd, but I'm not sure it means that other softwares should have hard dependencies on systemd, or that things like journaling, and others pieces of system should be related to the first process. Journaling for example should be, imho, managed in the usual way: we use stderr in programming, which is traditionally text. Since I'm not an expert at all, I can only guess that PID1 have to define the various std* streams, but if someone wants binary stuff, why not simply redirect those streams to an different application? What would be the problem with that? Why should desktops and end-user applications have to depend on systemd's parts? The systemd suite includes logind, which is a user session management system. For mpd, for example. Ok, it's started as daemon by default, but users can run instances of it for themselves if they want, and mpd is portable. Why should it have a hard dep on libsystemd-daemon0 Because systemd is the default Linux init system for Debian jessie, and libsystemd-daemon0 provides useful functionality for running a daemon on a computer that uses systemd as its init system, (it had no dep like this previously, and I doubt mpd will stop their support for windows or bsd... so it must be enabled by some sort of flag?). I would expect that it is enabled by a build-time flag. Depending on libsystemd-daemon0 does not make a program depend on having systemd as the init system. It just means that the program can now support the most efficient of systemd's startup mechanisms without duplication the programmer having to duplicate The alternative to depending on libsystemd-daemon0 is duplicating the functionality of libsystemd-daemon0 in every daemon that wants to have optimal behaviour on systemd systems. So, when building daemons for a Linux distribution whose *default* , it makes sense to have libsystemd-daemon0 as a hard dependency. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact lis
Re: I'm not a huge fan of systemd
On 09/07/14 05:07, Steve Litt wrote: [regarding double fork] In other words, it's going to bust my program, right? Maybe. Do the programs you launch need to outlive your session? If so, your launcher program's design will run into problems in a systemd world. If not, you should be fine. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53bd1c61.9080...@zen.co.uk
Re: I'm not a huge fan of systemd
On 09/07/14 14:40, Mark Carroll wrote: Hang on, that sounds scary. I'll still be able to launch something from the shell (maybe in an xterm) with a trailing & to put it in the background, and then log out and it will keep on going, right? Running a program in the background from a shell in an xterm (and even closing the xterm afterwards) works fine; indeed, that's how I launched the instance of Icedove I'm typing this e-mail in. What (per Tom H's mail) requires additional configuration (so, the problem appears to have a solution) is getting that program to keep running past the end of the login session. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53bd5003.6050...@zen.co.uk
Re: I'm not a huge fan of systemd
On 09/07/14 22:00, Steve Litt wrote: On Wed, 09 Jul 2014 15:21:55 +0100 Martin Read wrote: Running a program in the background from a shell in an xterm (and even closing the xterm afterwards) works fine; indeed, that's how I launched the instance of Icedove I'm typing this e-mail in. Yeah, but what happens to the background program when you exit the xterm, assuming you didn't precede the command with nohup, which carries all sorts of security and file size baggage? Well, my instances of icedove, kvirc, iceweasel, the steam client, sgt-loopy (launched from shells in now-closed lxterminal instances) are all running just fine (I habitually close terminals I've launched GUI applications from, because I'm seldom interested in reading gerbil spew from the windowing toolkit) - and all appear to have been reparented to PID 1 as you'd expect for a process whose original parent has exited. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53bdb838.1070...@zen.co.uk
Re: Sid Systemd upgrade
On 22/07/14 15:03, Joe wrote: I've got it now. Apparently /usr has needed to be available at boot time for a long time, but this seems to have completely passed me by, and hasn't yet bitten me. I have always thought that 'usr' was short for 'user', and that /usr contains only applications and not system software. We learn something every day: whether we want to or not. I can see that I'm not going to be upgrading my server next time, but rebuilding from scratch, as it has a /usr partition and isn't on LVM. At the very least, it's a partition rebuild onto another drive. Oh, joy. As I understand it: For many setups, separate /usr will work because those setups don't tickle the things that cause problems. For *any* setup, you can make separate /usr work by using an initrd and ensuring that all tools which will be needed before /usr is mounted are included in the initrd image. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ce7505.2000...@zen.co.uk
Re: Gnome for jessie
On 16/08/14 17:49, Steve Litt wrote: On Sat, 16 Aug 2014 11:00:10 -0400 (EDT) Stephen Powell wrote: My main objection to GNOME as the default desktop environment is that it *requires* 3D graphics acceleration from the X driver, something which is not available from all drivers. (For example, the mach64 driver which I am using right now as I compose this e-mail does not have 3D graphics acceleration.) Eeeeu, get it offa me! I thought the purpose of a wm/de was to let the user run, arrange, view and interact with his programs. Why someone would require the complexity of 3d graphics to accomplish this is beyond me. The task "draw this set of possibly-overlapping rectangles full of pixels, some of which may be partially or wholly transparent, in front of one big background rectangle" looks an awful lot like the task "draw this set of textured rectangles at different z-depths in an orthographic viewport". Modern graphics cards are *very good* at drawing textured rectangles at different z-depths in an orthographic viewport (in fact, they're better at it than the CPU is at drawing possibly-overlapping rectangles full of pixels, some of which may be partially or wholly transparent, in front of one big background rectangle), making it actually a perfectly viable strategy for a window manager to use. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ef9293.5050...@zen.co.uk
Re: Anyone got Dragon Naturally Speaking working under Debian Wheezy?
On 22/08/14 00:49, Ric Moore wrote: That's why I go off on a rant once in awhile, that pavucontrol needs to be a pulse depend, or users won't have the tool to setup and adjust pulse with. It's currently a Suggests; I suggest you file a bug report suggesting that this should be bumped to Recommends. (I wouldn't go as far as Depends, because IMO pulseaudio should not require X11.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f69e34.9030...@zen.co.uk
Re: Choose your side on the Linux divide
On 27/08/14 06:36, B wrote: What I don't understand is Debian leaving the alternative behind, this _doesn't_ sounds the Debian's way. But if it should be the new way, it'll be without me. There are certainly sincere efforts to enable Debian to continue to support other arrangements for system initialization and service launch. For example: https://packages.debian.org/sid/systemd-shim https://packages.debian.org/sid/cgmanager Neither of those packages are in any way part of systemd. Together, they allow systemd-logind to operate without requiring the use of systemd for system initialization and service launch. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53fddf90.7030...@zen.co.uk
Re: Choose your side on the Linux divide
On 27/08/14 19:07, Brian wrote: Please join him on the site where his article is published; there is a comments section. Perhaps other like-minded people would like to accompany you. Encouraging the balkanization of the Internet into a collection of echo chambers seems ill-advised. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53fe26d7.1050...@zen.co.uk
Re: Choose your side on the Linux divide
On 31/08/14 14:21, lee wrote: It doesn't even have decent documentation Opinions appear to vary on this matter; ISTR that when the TC were called upon to decide on the default init system for jessie, Russ Allbery experimented with all three of the proposed replacements and found systemd to be the best-documented out of sysvinit, upstart, systemd, and openrc. and makes things that are easily done with sysvinit a very difficult and cumbersome task which requires a lot of trial and error because you can't figure out what it actually does how. Could you provide a specific example, so that we can see the severity and extent of the problem? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54033691.40...@zen.co.uk
Re: Errors at login : in which log can I get the message ?
On 31/08/14 16:10, Erwan David wrote: EIther the explanation is incomplete or the badly redacted or the examples in the man are false I cannot see how journalctl /usr/bin/dbus-daemon or journalctl /dev/sda fit in that explanation There is a third possibility: you didn't finish reading the text provided. "As shortcuts for a few types of field/value matches, file paths may be specified. If a file path refers to an executable file, this is equivalent to an "_EXE=" match for the canonicalized binary path." /usr/bin/dbus-daemon is an executable file. "Similarly, if a path refers to a device node, this is equivalent to a "_KERNEL_DEVICE=" match for the device." /dev/sda is a device node. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54033bb2.7020...@zen.co.uk
Re: embrace, extend, extinguish
On 02/09/14 19:55, Jimmy Johnson wrote: Erwan David wrote: aptitude remove systemd -> downgrade almost everything to stable... Ok no program present in stable should depend on systemd... that's a lot of bugs to open... Erwan, the whole of my Wheezy desktop system as I know it seems to be locked into 'libsystemd-login0' and imposable to remove, somebody correct me if I'm wrong..please! The libsystemd-login0 package is required because some major components are built with support for systemd functionality, which they obtain by linking against the libsystemd-login shared library. Programs which are linked against a given shared library require that shared library to be present in order to run. *Supporting* systemd functionality is, of course, not the same thing as *requiring* that functionality to be present. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5406334c.5000...@zen.co.uk
Re: embrace, extend, extinguish
On 03/09/14 06:54, Erwan David wrote: lauching systemd-logind (which they do) is actually requiring it, no ? Point. (I find myself instinctively reading "requiring systemd" as "requiring systemd as PID 1", so I tend to say "requiring a component of the systemd suite" when talking about things that depend on, say, systemd-logind or systemd-udevd.) (samething that all those softs which start gconf daemon) Did someone try to *remove* pam-systemd from their configuration ? (after all if I do not use the feature, I should be able to configure the system for not using it). I haven't tried it. However, I've now had a look at the situation in Debian jessie as it currently stands, using the interactive mode of the aptitude package management tool. To remove the package libpam-systemd from a current Debian jessie system, you have to remove the packages gdm3, gnome-bluetooth, lightdm, policykit-1, udisks2, and network-manager. (I dare say many of the people who are opposed to depending on systemd components would say "no loss there, then" about some of those.) Various desktop-environment metapackages all result in installing at least one package that has a Depends: entry for at least one of the packages listed above: * Metapackage gnome-core Depends on gdm3, gnome-bluetooth, and policykit-1-gnome, the last of which Depends on policykit-1. * Metapackage kde-standard Depends on polkit-kde-1, which Depends on policykit-1. * Metapackage task-lxde-desktop Depends on lightdm, and metapackage lxde Recommends it. Metapackage lxde-core does not even Suggest lightdm. * Metapackage mate-desktop-environment-core Depends on mate-polkit, which Depends on policykit-1. * Metapackage razorqt depends on razorqt-policykit-agent, which depends on policykit-1. The following x-display-manager providers do not have a Depends reference that would automatically drag in one of the packages that Depend on libpam-systemd: * kdm * slim * wdm * xdm And of course, various standalone providers of x-window-manager do not Depend on libpam-systemd. So as far as I can see, yes, you *can* install a Debian jessie system with a GUI and an X display manager that does not require libpam-systemd. (Unless you want to use the full functionality of an HP printer, since at least as built in Debian jessie the package hplip Depends on the package policykit-1.) Something you can't do, though, is install a *fully-featured* GNOME, MATE, KDE, LXDE, or RazorQt desktop environment. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/540708a7.6050...@zen.co.uk
Re: brasero requires systemd-sysv
On 03/09/14 17:14, The Wanderer wrote: IMO, any functionality which anything not part of the init system might legitimately want to depend on - such as the functionality needed by libpam-systemd - should be implemented first, primarily, and indeed probably *only* as something that is *not* part of the init system. A reasonable position. There's some awkwardness in this particular case, though... Indeed, my understanding is that the cgroups-management functionality needed by libpam-systemd was initially implemented separately in logind and in the 'PID 1' systemd (and possibly elsewhere), and then refactored so as to have only one implementation - the one in PID 1. ... because this change (from systemd-logind manipulating cgroups itself, to systemd-logind sending cgroups manipulation requests to the dbus interface that is provided on systemd-as-PID-1 systems by systemd's PID 1) was done in response to the decision of the kernel's cgroup subsystem maintainer, Tejun Heo, that the way cgroups hierarchies worked was terrible and a single hierarchy single-writer model would be far more sensible. (AIUI, opinions differ *quite* widely on the correctness and/or sanity of this decision by Tejun Heo. I have no particular opinion on it myself.) It was only after that that someone else, not related (AFAIK) to the systemd project, implemented a standalone version via systemd-shim and the separate cgmanager project. This is indeed the case. One of the problems is that the systemd project seems to default to implementing potentially-independent things internally, instead of implementing them standalone and then making systemd (or whatever it is they wanted the new things for) depend on the standalone implementation. This leads to there being only the systemd-internal implementation, in at least some cases, and thus to the systemd lockin which is one of the things people complain about. It seems to me that it's likely to be hard to maintain that kind of discipline in respect of components you're only implementing at all because you want to use their functionality in something else you maintain. That's not to say it isn't worthwhile, but it may not always be worthwhile *enough* from the perspective of the people doing the work. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54075559.5060...@zen.co.uk
Re: brasero requires gvfs
On 03/09/14 15:40, Rob Owens wrote: xfburn is apparently aware that my cd drive is currently empty. Does anybody know what it uses to detect this? It is not using gvfs. Looking up xfburn in aptitude's interactive interface, I see that xfburn Depends: libgudev-1.0-0, which is a GObject-based wrapper library for libudev, which is a library for accessing udev device information, so I'd guess it's probably using that to get information about the state of the CD drive. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54078031.6030...@zen.co.uk
Re: brasero requires systemd-sysv
On 04/09/14 12:43, The Wanderer wrote: On 09/03/2014 at 01:52 PM, Martin Read wrote: was done in response to the decision of the kernel's cgroup subsystem maintainer, Tejun Heo, that the way cgroups hierarchies worked was terrible and a single hierarchy single-writer model would be far more sensible. I'm *way* behind on my LKML backlog (as in sometime in 2009, I think), but I may have to jump forward long enough to read this discussion. Any idea when, or under what thread title, it took place? Or if it wasn't on the LKML per se but on one of the subsystem lists, got a link? The original kernel discussion was in 2012; I read about it on LWN. Here are some relevant LWN.net links about the kernel change: https://lwn.net/Articles/484251/ "Fixing control groups" https://lwn.net/Articles/486401/ "A proposed plan for control groups" And here's a piece about the systemd changes to accommodate it: https://lwn.net/Articles/555920/ "Changes coming for systemd and control groups" Here's a pertinent GMANE link from the cgroups subsystem list: http://thread.gmane.org/gmane.linux.kernel.cgroups/857 "[RFD] cgroup: about multiple hierarchies" -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54085b0f.9040...@zen.co.uk
Re: brasero requires gvfs
On 07/09/14 18:31, lee wrote: As to console-kit, it was awful in that it might create a ridiculous number of processes, and I used to disable it because I never needed it. Can you disable logind? If you don't need anything that depends on gnome-settings-daemon, libpam-systemd, lighttpd, live-config-systemd, sogo, systemd-cron, systemd-dbg, systemd-sysv, or systemd-ui, you don't have to have the executable file /lib/systemd/systemd-logind on your hard disk *at all* (the items I listed are the things which Depends: systemd, and I'll note that systemd-cron and systemd-ui are optional even on systems which are using systemd as PID 1). If you aren't using a GUI, or your choice of GUI on Debian uses a traditional window manager (and doesn't use gdm3 or lightdm as its X display manager if it even has one) rather than being one of the "desktop environments", then it looks like it's still pretty easy to build a useful, working Debian jessie system that doesn't contain anything which Depends: libpam-systemd. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/540c9d67.9090...@zen.co.uk
Re: brasero requires gvfs
On 08/09/14 00:21, lee wrote: I don't have gnome-settings-daemon installed on Fedora, which uses systemd. Indeed; on Fedora, systemd is IIRC the *only* init system. On the Debian VM, it says that dbus depends on libsystemd-login0, so how could I remove that without having to remove xfce? You can't. And thus, you see the central tradeoff of binary vs. source distributions. In a binary distribution, the pain entailed in coping with combinatorial explosion means that even if a program *does* have a build system which allows extensive changes to which features get built into it, the distribution will probably only provide one configuration (typically, the most featureful, since "why does this depend on $LIBRARY_I_HATE?" is a rarer complaint than "why does this exclude 75% of the featureset?") out of the myriad possible configurations. In a source distribution, the end user has the freedom to configure their builds how they please. On the other hand, they need a much more extensive understanding of their system, and they have to devote more labour and computational resources to building their system. Perhaps you should consider this option. (This is where I mention that Debian's binary packages of the Xorg X server Depends: udev, and that the udev in Debian is the udev maintained by the systemd maintainers in the systemd git repository.) A "desktop system" is merely a "desktop system", and an init system is merely an init system. It is a bug when a "desktop system" like xfce depends on a particular init system, or parts thereof, no matter if directly or indirectly, especially for a distribution that intends to support a choice of init systems so that users can choose what they want to use and what not. Some components of XFCE have a hard dependency on dbus (and this is conceptually legitimate). dbus has a build-time-optional dependency on libsystemd-login, and a quick experimental check on my system confirms that the most recent version of the dbus suite, downloaded in source form directly from the dbus website, can be built on Linux without a dependency on libsystemd-login: $ ./configure --disable-systemd && make all [gerbil spew from the build process elided] $ ldd bus/dbus-daemon linux-vdso.so.1 (0x7fffb59fe000) libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x7fb354c2c000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fb354a0f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb354665000) /lib64/ld-linux-x86-64.so.2 (0x7fb354e8a000) However, standard practice in Debian is "enable ALL the things", so the dbus package in Debian jessie GNU/Linux systems is not built with --disable-systemd, and so it Depends: libsystemd-login0. Again: if you don't want the constraints attendant on accepting someone else's decisions about how the software on your computer is configured at build time, the alternative is to accept the burden of installing things from source instead. This bug just shows again how systemd is taking everything over, which is a bad thing. Systemd has become a single piece of software for a very limited purpose without which more and more totally unrelated software for totally different purposes isn't going to work anymore. That's like you're required to have, let's say, MS Windows installed on your hardware to be able to use it. Others have said this before. I finally realise what they mean. Why aren't all distributions standing up against this but instead embrace it? Last time I looked, systemd was not the default init system in Gentoo. I believe that they even facilitate the use of alternative /dev managers in place of systemd-udevd. Perhaps you should investigate this approach in more detail; you seem to have a legitimate and praiseworthy requirement for a higher level of control over what runs on your system than a binary distribution can realistically provide. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/540d9d89.8070...@zen.co.uk
Re: brasero requires gvfs
On 08/09/14 15:51, lee wrote: If the problem is so easy to solve as you describe, i. e. by compiling software appropriately, it boils down to that Debian would have to have different versions of packages, compiled with appropriate options, which are picked from depending on which init system the user decides to use. It's obvious that the rewards to you of Debian doing this outweigh the costs to you of Debian doing this, since it's obvious that you place a high value on the thing you're asking for, and it's not externally obvious that you'd incur any of the costs associated with making it happen. It's not entirely clear that the rewards to Debian of the action you request outweigh the costs of that action to the people whose labour and funding make Debian happen. It's a tricky question, with no easy answers. In any case, simply trying to avoid systemd wouldn't do anything to fix the problem. It is the developers of systemd and the makers of distributions who need to wake up and to do something about it, and they are the ones who appear to steadfastly remain ignorant. Real people think systemd provides real solutions to real problems that they have on their real systems. This means that "Here's how to solve the problems that systemd solved for you *more easily and more effectively* without using any systemd components" is a more compelling argument against systemd than suggesting that everyone who supports systemd is stuevilpid. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/540df2ed.1020...@zen.co.uk
Re: brasero requires gvfs
On 08/09/14 22:46, lee wrote: It would seem kinda logical to file the bug against the cd-burning software because it depends on an init system. Sort of. It's perfectly reasonable for brasero to Depends: gvfs (brasero's part of GNOME and gvfs is the "standard" way for GNOME applications to access the sort of things that brasero needs to access). It's perfectly reasonable for gvfs to Depends: gvfs-daemons (it's not immediately obvious from the package descriptions why there's a split in the first place). It looks reasonable for gvfs-daemon to depend on udisks2. It even looks kind of reasonable for udisks2 to depend on logind functionality (which is why it links against libpam-systemd). Part of the underlying problem is that systemd-logind >= 205, delivered in Debian as part of the systemd binary package, relies on calls to a dbus interface of systemd in order to perform operations that systemd-logind < 204 performed on its own. This change was not done on a whim of the systemd developers, but (as I mentioned elsethread) in response to a decision of the kernel cgroups subsystem maintainer (who is not, to my knowledge, a member of the systemd development team) regarding the future structure of the cgroups interface. However, this is probably a more general issue in that a yet unknown amount of packages suddenly somehow depends on a particular init system. So it would seem better to file a general meta-bug, like John suggests. In any case, I very much doubt that any package maintainers will see this as a bug. Even letting aside the element of convenience, they can always argue that there is no bug but correctly specified dependencies: Strictly speaking, that's a valid argument. They don't write the software; they just package it, and generally speaking they package it with something as close to upstream's default configuration as is consistent with it being part of Debian. [proposed social-contract bug against general] That's the bug report we need to file, accompanied by a detailed list of the reasons. The most likely outcome would be that we are being banned. There is at least one member of the technical committee, and several prominent Debian Developers, who I believe would *strongly* object to such a bug report being dismissed out of hand. I therefore think that filing such a bug report is a good idea, even though I am not remotely hostile to systemd being the default Linux init system in Debian jessie. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/540e2e3d.40...@zen.co.uk
Re: terminal doesn't come up in Jessie Beta-1?
On 09/09/14 15:31, Steve Litt wrote: It's kind of funny. All email clients suck, and yet there are tens of excellent window manager/desktop environments. All software sucks (except defective device drivers for vacuum pump systems). The only question is whether the nature of the suckage is a problem for a particular user. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/540f13c5.50...@zen.co.uk
Re: Query about existence of way to free up unnecessary RAM usage
On 09/09/14 19:42, B wrote: Normally, if you _really_ reach the system RAM limit, init begins killing the least used programs/daemons (well, this WAS true with a good init, such as the sysV one…) First, the OOM Killer is part of the kernel, not part of the init system. Second, it doesn't start killing processes until you run out of RAM *and swap*. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/540f4b34.10...@zen.co.uk
Re: Query about existence of way to free up unnecessary RAM usage
On 10/09/14 18:07, Curt wrote: Then why do the (net)installer(s) apply an obsolete principle when you accept a/the default partioning scheme(s) (well, at least the Squeeze netinstaller I used way back when did so). My first guess would be "because it's not so bad an idea that anyone in a position to change it cares about changing it". -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54109bb1.6080...@zen.co.uk
Re: vlc
On 11/09/14 21:05, Frank McCormick wrote: On my Sid installation VLC is broken. It does not display mpegs or mkvs. I have tried all the output modules and none make any difference. All I get is a black screen. Audio does work however. How can I track down the problem? The first step is to launch vlc from a terminal instead of a desktop menu/shortcut/whatever, so that you can see what error messages (if any) it is printing. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54120948.8050...@zen.co.uk
Re: brasero requires gvfs
On 13/09/14 20:54, lee wrote: Can you have, say, KDE on Gentoo without systemd? "Without systemd" means *all* of systemd, like systemd-login0 etc.. Many components of the KDE Software Collection have no identifiable dependency on systemd's support libraries. (Indeed, a significant fraction of them can be built for Windows.) I don't know whether you can get a fully functional KDE Plasma Desktop without policykit, and I don't know whether you can get a fully functional recent version of policykit without depending on the interfaces of logind. The best place to ask would be the user community discussion spaces (mailing lists / web forums / IRC channels) for KDE and/or for Gentoo Linux. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54156e07.3090...@zen.co.uk
Re: how to reinstall bash
On 14/09/14 10:44, songbird wrote: Marko Randjelovic wrote: I don't know what Debian release do you use, but since Squeeze, /bin/sh should point to dash. i'm not sure about that... I suspect it to be the case that if you've been continuously upgrading since before the change was made, your existing symlink will not have been changed. My current jessie system was originally installed as a wheezy system, and has /bin/sh as a link to /bin/dash. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54156e6e.20...@zen.co.uk
Re: preseeding: disable systemd
On 15/09/14 01:46, Marty wrote: (not OP but) I require the exclusion all packages by their dev teams from my computer. Is that clear enough? Linus doesn't trust them. Why should I? Just to be sure you're aware of what you're asking for: that includes udev, which: (a) in Debian is a hard dependency of initramfs-tools (a hard dependency of Debian's kernel packages), fuse, and xserver-xorg-core. (b) has been housed since version 184 (circa May 2012) in the systemd repository (although the program(s) comprising the udev package in Debian do not depend on systemd, systemd-logind, systemd-journald, or the published interfaces thereof) (c) is in large part maintained by Kay Sievers. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5416e1a5.1070...@zen.co.uk
