Re: Moving /tmp to tmpfs makes it useless
On Thu, May 24, 2012 at 9:30 PM, Jakub Wilk jw...@debian.org wrote: Q: I'm a smart man, I know what I'm doing, what apps I'm breaking and what consequences my decision might have, but I still need my /tmp in tmpfs. A: Then you should do that. In those rare cases when defaults need to be changed they should be changed. ACK. /tmp on tmpfs is a nice hack (I use it myself!), but it's a terrible default. Hasn't this been discussed at length already in previous threads? I'm all for discussion and even revisiting topics to some extent, but it doesn't seem healthy that we come back to a dead discussion, raising the same topics again, over and over, not taking into account what has already been said about it, not doing proper research beforehand, not taking into account constraints such as the looming freeze... Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna-kuh89xaxdyckluxk1qobsypxib1l2_cenjzka0dc...@mail.gmail.com
Re: RFC: OpenRC as Init System for Debian
On Tue, May 15, 2012 at 5:38 PM, Stefan Fritsch s...@sfritsch.de wrote: On Wednesday 09 May 2012, Gergely Nagy wrote: Apart from the fact that requirements will be different on different systems. Putting functionality for all possible corner cases into the daemon is not sensible for any upstream. That is what configuration files and similar things are for, I believe. I'd love to see an example where a complex init script is needed, and that can't be easily turned into systemd service files (for example). So far, I was told of two cases where the init script does more than a simple unit file does: one was nbd-client, which does funky stuff I dared not try to understand last night, the other is every package that supports starting multiple instances of the same service. For example, the apache2 init script starts htcacheclean if and only if mod_disk_cache is enabled. While this could arguably be considered as an upstrem deficiency, such cases won't simply disappear because systemd becomes more common. And fixing this in the daemon as part of a packager's work is not feasible. And with my upstream hat on, I would rather spend my time on fixing real bugs than things that can be easily worked around by the init script (or the apachectl script). Also, the apache2 init script creates various required directories on volatile file systems like /var/run or /var/lock Move this logic out of the init script and use ExecStartPre? That way the same logic can be used by all init systems. Please read systemd.service(5) if you haven't already. and supports multiple running instances, but these are more common problems. As far as I can tell, systemd supports multiple instances natively... Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna-oiacd2jvveuphlpvuqhsxzzv-jaosjnkqkxk7ldy...@mail.gmail.com
Re: RFC: OpenRC as Init System for Debian
Hi, On Wed, May 9, 2012 at 10:57 AM, Patrick Lauer patr...@gentoo.org wrote: On 05/09/12 21:37, Tollef Fog Heen wrote: ]] Philipp Kern You will not, however, get a conffile update prompt when the system file changes (e.g. to update your own local copy to incorporate the fix). This is something I'm pondering if we should handle in either a systemd trigger or a tool that packages shipping systemd files can call to tell the user about any changes. (Basically a wrapper around ucf, probably.) Why this arbitrary limit to only one application? http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=3chap=4 Something along those lines makes life a lot easier and avoids these schizophrenic hacks around package managers that don't respect files - but it needs support in the package manager to work reliably. Are you aware of how ucf works? I understand you love Gentoo, but we do have our own tools (that probably precede Gentoo's, actually). :-) Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa9DM7Vh27QAjb5o¤derbue1wk85xspb0xmnjo3kt...@mail.gmail.com
Re: RFC: OpenRC as Init System for Debian
Hi, On Wed, May 9, 2012 at 7:11 PM, Steve McIntyre st...@einval.com wrote: Uoti Urpala wrote: Who's the one choosing his preferred configuration format based on the limitations of his preferred packaging system here? Hint: it's not Red Hat. *yawn* When you've got something constructive to add to Debian development, let us know. Until that point, please go away and stop trolling. Please don't take me wrong, but I think (this time) Uoti wasn't missing the point (although the way he worded his concerns was certainly not accurate). I think he was referring to the specific way you described the situation, which seemed rather dogmatic. It's true that we the way we have always done things is configuration belongs in /etc, as you described. It's also true that we have tools to work with that assumption, such as ucf. Contrary to what Uoti implied, ucf is not even part of the packaging system (it's used in maintainer scripts), but yea, it's part of our basic packaging toolset. Also contrary to what Uoti said, I don't think the reason why people like Steve do not like this new way to handle config files is because of limitations in our tools. I don't think that statement makes any sense at all, actually (what limitations in our tools are we talking about, after all?). I've seen people mention that the way udev and systemd do config files is really motivated by limitations in RH's packaging tools. Maybe that's the case, maybe not. Does it really matter? I'd much rather see Steve explain why this way to handle config files is worse than the traditional way. It doesn't matter if it's great for RH or anyone else really. It's not relevant at all. It's just silly. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa-UZMfO7pGSKnH+W8T7+PMYotKHskyFEJxprEV=qnm...@mail.gmail.com
Re: Node.js and it's future in debian
Hi, On Thu, May 3, 2012 at 2:22 PM, Patrick Ouellette poue...@debian.org wrote: I can find numbers of potential node users by examining the number of active amateur radio licenses and make educated guesses as to how many may be using the ham radio node software as either a user of the system or a system provider/administrator. FWIW, the bug log from Node.js when they examined the Debian installations of each found them to be a similar number as reported by popcorn. (N.B. I don't put much stock in popcorn's numbers because it can be opted out of) I don't think anyone is trying to imply that popcon is a *reliable* source of information on how many people are using a certain package. But the difference is striking, the nodejs package is at least 7 or 8 times more popular according to popcon. It would be very hard to believe that nodejs is not more popular than node package. There are also other ways to measure nodejs's popularity. For instance, Google returns less than 20 million results for ham radio, and almost 60 million results for node.js. So while I don't think decisions shouldn't be taken based solely on popcon stats, I think it would be silly to think that ham radio would be more popular than node.js. I understand you're reluctant to undergo this transition and I empathize, but this argument is really a long shot. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa_q009fcs_DSphG9KÐre21nasqvaukoahug9nehu...@mail.gmail.com
Re: RFC: OpenRC as Init System for Debian
On Mon, Apr 30, 2012 at 11:57 AM, Thomas Goirand z...@debian.org wrote: On 04/30/2012 04:56 AM, Fernando Lemos wrote: I agree that OpenRC would be an improvement over the status quo, but migrating *away* from OpenRC later on would be a major pain as we would have to support both LSB/sysvinit scripts and OpenRC service descriptions for the foreseeable future. Ah? Is this any different with other alternatives like upstart or systemd? Yes. The kernel isn't getting any less event-based, so OpenRC would be an interim solution. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna-pad0n6bw-k2h4cbsmcwyqfjom3zq-jvmw33qq8dw...@mail.gmail.com
Re: RFC: OpenRC as Init System for Debian
On Mon, Apr 30, 2012 at 12:50 PM, Roger Leigh rle...@codelibre.net wrote: On Mon, Apr 30, 2012 at 12:04:32PM -0300, Fernando Lemos wrote: On Mon, Apr 30, 2012 at 11:57 AM, Thomas Goirand z...@debian.org wrote: On 04/30/2012 04:56 AM, Fernando Lemos wrote: I agree that OpenRC would be an improvement over the status quo, but migrating *away* from OpenRC later on would be a major pain as we would have to support both LSB/sysvinit scripts and OpenRC service descriptions for the foreseeable future. Ah? Is this any different with other alternatives like upstart or systemd? Yes. The kernel isn't getting any less event-based, so OpenRC would be an interim solution. Unless OpenRC itself could become more event-based. How realistic is that? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna-jrxkfeicsvhz2mzbe-4nldkfqmfmyex5bdb+uf8g...@mail.gmail.com
Re: RFC: OpenRC as Init System for Debian
On Sun, Apr 29, 2012 at 2:45 PM, Roger Leigh rle...@codelibre.net wrote: One of the definining characteristics of the Linux ecosystem, including Debian, has been that the system has been made up of a set of loosely- coupled compoments with well-defined interfaces. This is in stark contrast to, e.g. Windows, MacOS and other proprietary systems, which have extremely tight coupling between their components, and where being able to swap out one component for another is almost unheard of. Given that this loose coupling has enabled experimentation with a wide variety of different solutions to problems, and allowed the evolution of a diverse range of different packages to solve a very wide variety of needs, it could be considered one of the defining factors in the success of Linux. Quite why we would want to replace this with a one-size-fits-all solution beggars belief. Just to be clear, what you're describing is specific to systemd, not to event-based init systems in general. It's true that diversity fosters innovation. I think the question here is, should Debian make technical choices based on whether or not the resulting distribution is an ambient that fosters innovation on init system design? And when I think of it that way, the answer seems to be a resounding no. Given the ongoing debate regarding the different init systems we might want to adopt long-term, I think this is perhaps one of the less discussed factors, but perhaps one of the more important ones. Both systemd and upstart are technically superior to all the alternatives, systemd perhaps more so. But while the technical advantages are nice, these come at the cost of reducing the amount of diversity in the system, and our ability to replace pieces which don't fit our needs due to the tight coupling. Just to be clear again, this is also specific to the current event-based init implementations. It's not in any way a characteristic of event-based init systems in general. Integration versus flexibility is a tradeoff. At one end of the spectrum, we have a very tightly integrated distribution, where nothing is interchangeable. At the other end, we have the concept of distribution as a simple collection of binaries with pretty much no integration. Having a better integrated init system would push Debian a little bit towards the former, no doubt. While sysvinit is clearly inferior, it gives us (Debian) something the others do not: control over our own destiny, and the ability to modify every aspect of it and the init scripts to fit our needs. Both systemd and upstart are largely influenced by third parties. As a trivial example: systemd creates user session information in /run/user/$user . I brought up with lennart the fact that this would only permit one session per user. He rejected out of hand the fact that more than one session would ever be needed, because Gnome only allowed one session per user. So the limitations of Gnome in this respect have led to a fundamental limitation in systemd's session management. We could patch and work around this type of brokenness easily enough. But given the rapid speed at which systemd is growing and swallowing up more and more functionality previously served by different tools, would we have the ability and will to continue to patch every bit that didn't fit our needs, and keep that working over time? If we can't, we'll potentialy end up with a technically superior system... which meets the needs of Gnome/Fedora and other distributions, rather than our own. And when the primary maintainers have shown themselves to be less than willing to accommodate even this simplest of requests (as above; a single tempnam call would have been sufficient), would we be committing ourselves to a less than desirable fate? That's certainly something we need to take into account. There's an option you didn't mention: forking. I think it's better to fork than to try to come up with something from scratch. When people write stuff from scratch, 9 out of 10 times they just don't understand the problem they're trying to solve. And if it's a big project (such as an init system), it's very unlikely to ever get off the ground. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna838ycfnqc7g0todrcjkdbsmpdjh-9zrsz4x4aymrh...@mail.gmail.com
Re: RFC: OpenRC as Init System for Debian
On Sun, Apr 29, 2012 at 5:14 PM, Roger Leigh rle...@codelibre.net wrote: Keeping our options open, and evaluating what are options are available and usable is important, and this is the principal reason why I am interested in looking at OpenRC. It doesn't hurt to try it out and see if it meets our needs. Agreed on the keeping our options open part. But given that the kernel is increasingly event-based, OpenRC seems to be a step backwards. I agree that OpenRC would be an improvement over the status quo, but migrating *away* from OpenRC later on would be a major pain as we would have to support both LSB/sysvinit scripts and OpenRC service descriptions for the foreseeable future. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna8w36re26qaxeyxegna4e_tqpyrkp3+t1omhaqa4-_...@mail.gmail.com
Re: libbitcoin
Hi, On Fri, Apr 27, 2012 at 2:36 PM, Amir Taaki zgen...@yahoo.com wrote: Anyway, sorry if this sounds presumptious but if anyone can make a package then contact me and I'll collaborate and make whatever changes are needed to get it to work with Debian. I did make an effort before asking for help, but I'm mostly familiar with upstream processes. Please refrain from posting requests or announcements like this to debian-devel in the future. We have a process for requesting software to be packaged for Debian (RFPs), please read the following: http://www.debian.org/devel/wnpp/ Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna_4jonwq5ghiytak5d66-8yuuhj2-sojpdw86lwypr...@mail.gmail.com
Re: I want to become a Debian maintainer!
Hi, On Fri, Apr 20, 2012 at 7:31 PM, Svante Signell svante.sign...@telia.com wrote: In order to contribute more than being a porter (and patch submitter), I'm wondering how much effort/support is needed to become a DM, i.e. being able to upload packages myself, etc. A second alternative would be to build packages, and ask for a sponsor. Problem is that for GNU/Hurd there aren't that many interested ... The NM process is thoroughly documented: http://wiki.debian.org/DebianMaintainer We also have debian-mentors for questions like that. Please take debian-devel out of the loop. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna_lhona9qdj+wnkjz+82ejqr8lctcpzanrxsvf8ain...@mail.gmail.com
Re: Packaging of new upstream (pre-)releases until wheezy
On Sat, Apr 14, 2012 at 4:36 PM, Neil Williams codeh...@debian.org wrote: On Sat, 14 Apr 2012 20:36:13 +0200 Svante Signell s...@kth.se wrote: Doing that will make the release of wheezy much smoother than trying to fix things in the last minute (and risk that the packages gets excluded from wheezy??) Definitely. Whether the new version goes into experimental or into unstable, the sooner the uploads are made the better - with the requirement that if the changes involve a SONAME change or other disruptions, talk to the release team (and wait for a response) before uploading. Well, since now we have a roughly scheduled freeze, I can see why a maintainer might want to postpone the packaging of a new upstream release (or even skip it) in order to avoid unnecessary work and/or multiple transitions. Although I agree that package early should be a strong recommendation, it's entirely up to the maintainers to decide what's best. I believe the release team can help a maintainer to decide it too, not entirely sure if that's a common procedure. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna8+qo6rteej4nyvudax9krz+-w7q6mnsxxaqvr_tho...@mail.gmail.com
Re: bug reports with urls in them
Hi, On Sun, Apr 1, 2012 at 8:45 AM, Michael Welle mwe012...@gmx.net wrote: Hello, Michael Banck mba...@debian.org writes: On Sun, Apr 01, 2012 at 11:31:49AM +0200, Michael Welle wrote: Anyways, what if I want to report a bug that happens if I use foo.org? We can discuss this again once this is actually the case. chances that users without technical background come back and report that bug a second time (after figuring out what might be wrong) are slim I think. How do you suggest we fix this? We certainly can't disable spam filters or we'll be flooded with spam. If you follow debian-devel, you must also know that a web reporting frontend was discussed in length already, so hopefully this won't be brought up again. I'm not sure it's a problem even worth discussing. The trouble of coming up with a solution seems much bigger than the inconvenience of missing an odd report here and there (I'd be curious to know how often a report is wrongfully rejected). Also, let's be practical. If the reporter doesn't realize something went wrong with the report, he or she is most likely not very tech-savvy. Those reports are still mostly useful, but in a sea of bug reports, those are often the least useful. And if the reporter does notice that the report has been wrongfully rejected but can't be bothered to report it again, perhaps the issue wasn't such a big deal. I'm not saying it's good that we miss reports like this, but we must put things into perspective. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna98mkuj82x+snu+9pezocygrgn9kyvd73soox3xek9...@mail.gmail.com
Re: please update to latest upstart version (again)
Hi, On Fri, Mar 23, 2012 at 7:08 PM, Thomas Bechtold thomasbecht...@jpberlin.de wrote: Hi, i just want to ask if it's possible to update to the latest upstart version. i followed the latest discussion but i just want to have the latest version available in debian. i don't care about the upstart support in debian because: - i have my own upstart packages for my own software and want to control my own daemons with upstart. - i don't care about any upstart support in debian please update the upstart version to 1.5 for wheezy. Regardless of why you want it updated, note that this is not the appropriate way to ask for an update. Please file a bug report with wishlist priority against the package that needs to be updated in our BTS and don't mail debian-devel. I believe it's considered more polite to wait a few days after an upstream release before filing this bug report, though. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna_fpcvsuxb4fkqtxxxhcuu9xfx3fqn-vexm8c1wpkw...@mail.gmail.com
Re: please update to latest upstart version (again)
On Fri, Mar 23, 2012 at 7:54 PM, Thomas Bechtold thomasbecht...@jpberlin.de wrote: On Fri, 2012-03-23 at 19:25 -0300, Fernando Lemos wrote: Hi, On Fri, Mar 23, 2012 at 7:08 PM, Thomas Bechtold thomasbecht...@jpberlin.de wrote: Hi, i just want to ask if it's possible to update to the latest upstart version. i followed the latest discussion but i just want to have the latest version available in debian. i don't care about the upstart support in debian because: - i have my own upstart packages for my own software and want to control my own daemons with upstart. - i don't care about any upstart support in debian please update the upstart version to 1.5 for wheezy. Regardless of why you want it updated, note that this is not the appropriate way to ask for an update. Please file a bug report with wishlist priority against the package that needs to be updated in our BTS and don't mail debian-devel. I believe it's considered more polite to wait a few days after an upstream release before filing this bug report, though. i did this already 10 month ago [1]. i also wrote some mails to the maintainer, he answered, i build some test packages for debian sid, wrote mails again but at the end nothing happened and the maintainer didn't answer to my last question what i should do to get a new version into debian. so i though debian-devel is another way to ask for an update (or NMU). As Steve said in the bug report, he's waiting for the policy bits to be finished before looking into updating upstart. So either help out with that or wait. Asking for an update in debian-devel has zero impact on the possibility of the package getting updated, so please, refrain from doing that again in the future. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna8hkgcwhn87rooznmgd1-pxztsoqcrryl3b85ghgn4...@mail.gmail.com
Re: On init in Debian
On Thu, Mar 22, 2012 at 8:07 PM, Svante Signell svante.sign...@telia.com wrote: Please, don't make things unbearably complicated in case something breaks!!! Network *should* work also in console mode... Looking forward to the which nasty bugs in the future are caused by systemd/upstart! Wow. You *clearly* don't know how NM, upstart, or systemd work, and you don't want to put any effort into learning. And that's ok. But it doesn't mean NM, upstart or systemd are any more complicated than the technology they aim to replace. This progress more and more looks like what happened to the abilities of repairing your own car: How many is able to do that today compared to some years ago? Now you have to call the emergency service to transfer it to the experts in the garage for computer check and repair. Progress is not always for the benefit of the users, but for the developers!? This is non-sense. If you want to continue to drive an old, slow and unsafe car, you can just stop updating your install, or benefit only security updates (while they last). If you want *any* sort of progress, you've got to deal with the possibility of breakage. That's why we have processes in place to avoid this breakage. You can always keep using squeeze forever. Nobody is preventing you from doing that. Expecting everyone else to do the same, though, is ridiculous. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna8p-ycqvmmnt8beynrc+_7ujrv+90omanqxomw5r4t...@mail.gmail.com
Re: On init in *Debian*
On Wed, Mar 21, 2012 at 4:48 PM, Thomas Goirand z...@debian.org wrote: I really think that what's missing here is: - Improve sysvinit and make it better to fit our needs without breaking anything (eg: less scripts redundancy, parallel booting, ...). You're missing the point. We already have parallel booting. Less script redundancy, while being something it seems most of us (if not all of us) are interested in, is just a nice side effect of switching to a modern init system. An improved init system would need to be event based, as many people with actual knowledge on the issue have already stated (as the Linux kernel itself is becoming increasingly event-based). Turning sysvinit into an event-based init system is basically rewriting it. So what you're proposing to boils down to let's start a new event-based init system from scratch. So you're saying we could create this brand new init system instead of using stuff that is being used in the real world. And you're also saying that this would be done in a way that will cause less breakage than using alternatives that have been used for quite some time now. I don't mean to sound disrespectful, but this makes no sense at all. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna_7obfvfghknxxf0oczgxtj0z7yq8tqkz9yrwsvudk...@mail.gmail.com
Re: On init in Debian
On Fri, Mar 16, 2012 at 4:05 PM, Andreas Metzler ametz...@downhill.at.eu.org wrote: Philip Hands p...@hands.com wrote: On Fri, 16 Mar 2012 14:37:39 +0100, Vincent Danjean vdanjean...@free.fr wrote: [...] * We could try to define a file format that allow a conversion (by a separate specific tool or at runtime) to various init systems. This would avoid to be blocked by the syntax/features of one source init system. This was mentioned in the thread (I forget by whom) and strikes me as the only viable strategy, in that this is the only way that the various factions can all collaborate on making a workable solution, rather than fighting for theirs to be The One True Init. [...] I am not sure this actually is a big improvement, we might end up with * either being limited to the common featureset * or doing something like #ifdef systemd elseif upstart ... which is almost as bad as having to ship both init-scripts and systemd configuration file. Having a sysvinit script generator today would be a great improvement over the status quo. It's almost orthogonal to discussing a replacement for sysvinit, as it would follow the current trend of replacing lots of manually crafted, error-prone code by something simpler (e.g. debhelper, then dh). Right now, creating a init script means copying an ugly 159-line skeleton and carefully editing it, hoping not to break anything while at it. Even if we can't have a single generator for multiple init systems, having something declarative to build most init scripts we need would be a big step forward and it would make a lot of sense as well in a future where we may need to support multiple init systems. The real solution would be, of course, deciding on an alternative init system with sane service description files. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa9Z8qdYqAYQEiyUuhYtvozMc=wv7wtvd4bmm-xkuc0...@mail.gmail.com
Proposing the creation of a virtual package for icon themes
Hello, After a brief discussion in debian-mentors[1], Paul Wise suggested that we might need a virtual package for icon themes that adhere to the FreeDesktop.org icon naming spec[2]. Following his suggestions, I posted a message requesting feedback from debian-desktop[3] (I suggest that interested parties read that thread for more insight). Now I'm following the instructions in the authoritative list of virtual packages[4], and step 1 is proposing the changes to debian-devel and filing a bug report against debian-policy (the report will be filed after this e-mail is sent). [1]: http://lists.debian.org/debian-mentors/2012/03/msg00055.html [2]: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html [3]: http://lists.debian.org/debian-desktop/2012/03/msg00020.html [4]: http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt The problem I'm trying to solve is that packages currently need to express dependency relations on any of a number of icon themes that provide the necessary icons. As an example, the package arista depends on: gnome-icon-theme | gnome-icon-theme-gartoon | gnome-icon-theme-nuovo | gnome-icon-theme-yasis | lxde-icon-theme | moblin-icon-theme | tango-icon-theme | gnome-themes-more | gnome-accessibility-themes This obviously doesn't scale well. By introducing a virtual package (say, fdo-icon-theme), several packages could be changed to depend on (or suggest, recommend) something as simple as gnome-icon-theme | fdo-icon-theme. Some virtual package names have been proposed: * fd-icon-theme (by Paul Wise) * freedesktop-icon-theme (by Paul Wise) * fdo-icon-theme (by Sune Vuorela) They're all fine to me. If I had to pick one, I'd go with fdo-icon-theme. I hope we can stay away from lengthy discussions about naming. This is how I imagine this change would impact maintainers: * A lintian warning could be created to make sure that packages that adhere to the spec provide the virtual package. I plan to take a look at this if the idea goes through, but I know very little Perl, so I'd be glad if someone beat me to it. * Wishlist bugs could be filed against packages that adhere to the spec but don't provide the virtual package. * Likewise, wishlist bugs could be filed against packages that provide the necessary icons but don't adhere to the spec. It would be up to maintainers of individual packages to choose whether to depend on (or suggest, recommend) the virtual package or on some specific icon theme(s) instead, of course. But in most cases there would be no reason not to simply depend on the virtual package. The changes won't happen overnight. As soon as enough icon theme packages provide the virtual package, the maintainers should be able to depend on it. Given that the changes simplify package maintenance and don't seem very disruptive, though, I believe the they will be well received. So in order for the process to continue, it would be great if we could iron out any remaining issues. Does anybody object to this proposal (and why)? Is there anything I'm missing, i.e., when it comes to how this would impact packaging? Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa-xEhhrHCHT9+SyWpyTkMvbdvRMFNZ=dpjpfor3as7...@mail.gmail.com
Re: upstart: please update to latest upstream version
On Sun, Mar 11, 2012 at 7:25 AM, Vincent Bernat ber...@debian.org wrote: OoO En cette nuit nuageuse du mercredi 07 mars 2012, vers 00:21, Fernando Lemos fernando...@gmail.com disait : To give one particular example: systemd uses Linux-specific features to accurately track all the processes started by a service, which allows accurate monitoring and shutdown of processes which could otherwise disassociate themselves from their parent processes via the usual daemonizing trick. POSIX doesn't provide features that allow this in general, but Linux does. (Quite possibly other OSes provide those features too, but not in a standardized way.) By the way, upstart uses ptrace for this: http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/ It's an interesting trick, and probably more portable too. Maybe we could have an intermediate goal to patch any daemon to add an option to not fork on start. If any daemon can be started without forking, it seems easy to start/stop them without cgroups. This would allow to generate a sysvinit script from systemd service description. I don't know any daemon that does not have a flag to not fork on start. The number of daemons to patch may be low. This will not be as clean as using cgroups, but it won't be worst than the actual situation. I don't quite understand the problem you're trying to solve. Both upstart and systemd already handle cases where the daemon doesn't have the option of not forking. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna_yssbdaj7drllntltob5w3sh46k0t1yuk88kepxqn...@mail.gmail.com
Re: Python bindings - where to ask for help?
On Wed, Mar 7, 2012 at 1:28 PM, Jens Stimpfle deb...@jstimpfle.de wrote: python-poppler bindings are incomplete, I am missing one for ps_file_new. I feel that I have to patch it myself, but am at a loss for understanding how it works. The build system has a poppler.defs file which gets compiled to C code using a badly documented format. (The documentation I could find does not apply to the format in poppler.defs. The function is listed in poppler.defs, but no binding is generated and no error output). Does anyone have experience with generating the bindings, or can point me to a location where I'm likely to get help? debian-devel is for discussion about the development *of* Debian, not for discussion about development *on* Debian. For your specific problem, try to contact the authors of the bindings. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa_EEv+Bfw6RFX2tx-T4d8UM+c=t_+cywukllu-g6tt...@mail.gmail.com
Re: upstart: please update to latest upstream version
Hi, On Tue, Mar 6, 2012 at 7:46 PM, Josh Triplett j...@joshtriplett.org wrote: To give one particular example: systemd uses Linux-specific features to accurately track all the processes started by a service, which allows accurate monitoring and shutdown of processes which could otherwise disassociate themselves from their parent processes via the usual daemonizing trick. POSIX doesn't provide features that allow this in general, but Linux does. (Quite possibly other OSes provide those features too, but not in a standardized way.) By the way, upstart uses ptrace for this: http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/ It's an interesting trick, and probably more portable too. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna-nyq9y1ayxdpbsnwwwa15o3y1rcov++_zh6wct9gf...@mail.gmail.com
Re: Unofficial repositories on 'debian' domains
On Mon, Mar 5, 2012 at 4:40 AM, Stefano Zacchiroli lea...@debian.org wrote: What we need, though, is probably to make it more clear to our users what is the difference among *.debian.net and *.debian.org services. It is something that developers know by folklore, but that I seriously doubt most of our users know. For me, the most appropriate way to do is to put a splash page at www.debian.net explaining that. If DSA agrees with that approach, I'm sure we can easily come up with a suitable splash text. How about one of those banners at the top of the screen? Like when you visit Google and it asks you if you want to make your home page point to Google. Something like This is an unofficial Debian resource. Read more Clicking Read more would take the user to a page that explains what debian.net is and things like that. The banner could be dismissed (perhaps with cookies to remember the setting). This should be simple to implement with Javascript and CSS, and it should be trivial to use in the *.debian.net pages. I believe people don't go to http://www.debian.net/ often, as it redirects to http://www.debian.org/. If we come up with a splash for debian.net, people that visit mentors.debian.net, for example, will not see it. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa_nbFV+fyrriua7iM8Dbwn7x=msw3x_tuhbxzbx+nz...@mail.gmail.com
Re: Unofficial repositories on 'debian' domains
On Mon, Mar 5, 2012 at 11:09 AM, Arno Töll deb...@toell.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 05.03.2012 14:31, Fernando Lemos wrote: I believe people don't go to http://www.debian.net/ often, as it redirects to http://www.debian.org/. If we come up with a splash for debian.net, people that visit mentors.debian.net, for example, will not see it. with all due to respect, but I'd prefer if mentors.debian.net weren't repeatedly compared with completely unrelated external archives like Dotdeb or Debian Multimedia. If we feel like debian.net domains should emphasize their non-affiliation with the Debian project as a whole, be it. But I'd ask you not to mix-up and confuse debian.net projects with other stuff discussed in here. Thanks. I didn't mean to compare m.d.n to any other debian.net subdomain, it was just the first subdomain I could think of. That said, I don't see why mentors.debian.net should be treated differently from any other *.debian.net domain. It is very useful and very important to Debian, but it's still an unofficial subdomain. Please note nobody is comparing m.d.n to d.m.o. There are two discussions going on in this thread. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna9utygha8b-cqh_fei3udp8oxpa4fjosj5vsmwmpsv...@mail.gmail.com
Re: A DM/DD should know how to watch his mouth (code of conduct).
Hi, On Sun, Mar 4, 2012 at 6:28 PM, Sergio Cipolla secipo...@gmail.com wrote: Hello. I'm just a Debian user for some years and I'm writing to this list because I found that at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660814 the Debian Multimedia maintainer Fabian Greffrath was very wrong, by being not only wrong in what he said but also very impolite. Why is he wrong in what he said? Don't take me wrong, I'm a d-m.o user myself, but Fabian is entitled to his opinion. I wrote to a follow-up of that bug report ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660924 ) about what I thought of it: Fabian, who do you think you are to call d-m-o's packages as 'crappy'? d-m-o is a traditional and very respected 3rd party repository for Debian and has been for years. That's way off-topic in the context of that bug report. I can't tell the same of you. Yes, let's make this personal. Classy. You know very well why it uses an epoch in their versioning: exactly so as people that want/need to use the extra features/packages it provides don't mix what shouldn't be mixed with the official Debian packages. And how does that have anything to do with the fact that installing packages from outside the Debian repositories can introduce incompatibilities with software installed from the Debian repositories? I'm not sure if you're a Debian Maintainer or not (or worse, Debian Developer) but this kind of big mouthing shouldn't be accepted from a DM/DD. If I find out the proper channel for this I'll raise this subject so as the Debian contributors know that they should measure their words otherwise they should step down (even a 'do-ocracy' has its limits). So I'm writing to this list to raise this subject that a DM/DD should stand to a minimum level of respect, specially when talking about fellow contributors (even unofficial). Maybe this is already in some sort of code-of-conduct for someone applying for DM but if it's not, I leave here my suggestion. While I personally would try to avoid the language Fabian used, asking a maintainer to step down solely because of this incident is ridiculous. Fabian's language in those bug reports isn't uncommon in the free software community, deal with it. Someone call the whambulance, quick. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa-wqOL8Q=-kdms87tllfu22qx1s6-ylytbmn7jdyvl...@mail.gmail.com
Re: Network Security Toolkit
Hi, On Wed, Feb 29, 2012 at 3:41 PM, Dmitrii Kashin free...@gmail.com wrote: A list of the actual utilities that you are interested in would help people to answer your question. Okay. Here are listed all packages LiveCD contain: http://networksecuritytoolkit.org/nst/log/manifest.html Here are also described all licenses of any utilities. Utilities I am interested in: 1) nsttraceroute (GPLv2) 2) nstgeolocate (GPLv2) I have not seen more, but we can make sure that all of 'nst*'-utils provide some geolocation stuff in many different formats; all of them distribute under free GPL license, and all of them are very useful for imagination results. Cool, but debian-devel is the wrong place for what you're trying to accomplish. We have a process for this, please consider filing RFP bugs: http://wiki.debian.org/RFP Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa9wP4KnHqkVEZponHGg7q=064hojgvpt2p6pp86kjy...@mail.gmail.com
Re: Enabling hardened build flags for Wheezy
Hi, On Wed, Feb 29, 2012 at 9:23 PM, Paul Wise p...@debian.org wrote: Personally I think this is completely the wrong approach to take for compiler hardening flags. The flags should be enabled by default in upstream GCC and disabled by upstream software where they result in problems. The compiler hardening flags have been tested over N years by RHEL, Fedora, Ubuntu, Gentoo and probably others. The approach Debian is taking (as opposed to Red Hat, Fedora, Ubuntu etc) means that software compiled outside of the packaging system will not benefit from the compiler's hardening flags. Doing it in this way also violates our social contract. Not sure it's a good idea to reignite this, specially this late into the Wheezy development cycle (and specially in debian-devel). This has already been discussed in detail: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=552688 Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa8Lr-FniudT6htrWMGArUfhO9V5f_tc4LST8S8=eai...@mail.gmail.com
Re: upstart: please update to latest upstream version
On Fri, Feb 24, 2012 at 9:10 AM, Josselin Mouette j...@debian.org wrote: Of course the hard part is to make the initial decision to switch to a given init system; this is the kind of things Debian is very bad at. That's something I've always wondered. It seems to me that we'll *never* reach any form of consensus in debian-devel about switching to a different sysvinit. So who could make this decision? There's the technical committee, but with due respect, I'm not sure they'd be able to vote on this in a reasonable timeframe. It seems that everyone has a strong opinion when it comes to upstart and systemd, even people who don't work on lower level stuff. Whole proposals get stalled because basically anyone can become a blocker. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna8wvborjgncuuc7yxushlp+blaosnytej7adjsz13v...@mail.gmail.com
Re: upstart: please update to latest upstream version
On Sat, Feb 25, 2012 at 1:00 AM, Russ Allbery r...@debian.org wrote: Steve Langasek vor...@debian.org writes: There are two main challenges here that I'm aware of with trying to generate init scripts from upstart jobs: - Process supervision. A lot of the win of moving to an init system like upstart or systemd is that init *knows* which process corresponds to which job and doesn't have to use PID files. If we lose the process supervision, we have to manage how to generate PID files for our processes again, for all the different ways that daemons start, and we have to track that information somewhere - even if we put it in the upstart job or systemd ini, it's information not being used except under sysvinit, so have we actually saved ourselves from code rot? - Dependency tracking. Upstart start conditions are not easily convertible into the kind of dependency information that's useful to insserv+startpar; with socket-based activation in systemd, much of the inter-service dependency information is missing altogether. Again, this is probably going to somehow require tracking information for the benefit of sysvinit that's not used by the native consumer of the job format. Granted, though, it's at least potentially possible to keep track of both of these things in a declarative fashion, and there'd certainly be some benefit to that even if we're not entirely free of the risk of bit rot. If someone is interested in trying to implement such an upstart job - init script autoconverter, I'd be willing to help. The nice thing about the converter is that, as people have pointed out before, you don't have to solve the whole problem like you would if you were writing a full init system. An 80% solution would be fine; the other 20% of the software will require manually-written init scripts, and will bear some maintenance burden, but they're probably also likely to be more core software that's worth the additional work. The goal for the converter, I think, should be to get the typical daemon that people are packaging without a huge amount of expertise to just work, not to get, say, the complex system startup scripts to convert automatically. How about a converter from a different, init-agnostic format into the specific formats? That way we could specify stuff that's specific to each format, things such as: * Socket activation information for systemd (and possibly upstart with upstart-socket-bridge) * Events emitted by upstart * Dependencies declared in the LSB header of the sysvinit script * Path to the pidfile for the sysvinit script * Invocation for the sysvinit script so that the process stores the pidfile at the specific location This file could be easier to parse than a upstart/systemd unit too. I think even more than scripts could be converted into this basic format. The only drawback I can see is that it's another init description syntax to learn (if it's simple enough, maybe it's not a big deal). Lots of packages use /etc/default. I wonder if we could map a big chunk of those cases into this basic format, stuff like *_EXTRA_OPTS/*_OPTS. There's also *_DISABLED/*_ENABLED, which are redundant (since all init systems already provide a way to disable services), but which we might want to support too for backwards compatibility. Supporting this alone would mean even more packages can start using this basic format with no changes for end users at all. I guesstimate 90-95%. Then there's always oddball init scripts. I bet some of those can be fixed, some may be split into a wrapper script (which could also be invoked by upstart and systemd for even more reuse). I can envision this converter being plugged into dh so that the init files are automatically generated. The maintainer could supply init-specific scripts for weird stuff that isn't covered by the basic format supported by the generator. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna_csn3ebasnb43j6tz4nwmebgntgyborl6mwxp4-72...@mail.gmail.com
Re: upstart: please update to latest upstream version
On Sat, Feb 25, 2012 at 1:35 AM, Fernando Lemos fernando...@gmail.com wrote: * Socket activation information for systemd (and possibly upstart with upstart-socket-bridge) By the way, I wonder if we could also come up with a wrapper that allowed upstart to work with the systemd socket activation protocol. If I'm not mistaken, the upstart-socket-bridge protocol is a superset of the systemd socket activation protocol (I think SJR himself mentioned that, not sure), so this seems doable. This would mean the socket activation information could perhaps be shared by both upstart and systemd, thus making it easier to convert between upstart job descriptions and systemd units (assuming the daemon supports socket activation). Another option would be creating a upstart-systemd-bridge that used the systemd socket activation protocol. Even if one of these approaches is possible, I'm not sure how much work this would entail. It might as well not be worth pursuing. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa-1fWoNy6Z9PO-RkcFaM8qeaT11C=6qc9h4zmwy2v3...@mail.gmail.com
Re: upstart: please update to latest upstream version
On Sat, Feb 25, 2012 at 1:44 AM, Russ Allbery r...@debian.org wrote: This file could be easier to parse than a upstart/systemd unit too. I think even more than scripts could be converted into this basic format. The only drawback I can see is that it's another init description syntax to learn (if it's simple enough, maybe it's not a big deal). Both systemd and upstart have extensible formats, so this would probably be most easily done via extending one or the other of them rather than inventing a completely separate format, I think. In that case, either way seems fine to me. Lots of packages use /etc/default. One of the big features of upstart (and I believe systemd as well) is that this mostly goes away. There are better ways provided for most of the things one currently has to use /etc/default for. For example, the upstart scripts are small and simple enough that, unlike with init.d scripts, it's meaningful and natural to expect the local administrator to just edit it and change the flags passed to the program, rather than using *_EXTRA_OPTS all the time, because the init file just doesn't change very often. Unlike the current init scripts, which are complex messes and change all the time. (I'm still a *bit* dubious that this will work well in practice, but at least the theory sounds great.) Indeed. What I meant is that we probably could support the most common usage of /etc/default so that more sysvinit scripts could be converted to be automatically generated from a declarative description. So yes, those files in /etc/default would not be used by the services launched by upstart/systemd. They would only exist so that everything would transition smoothly to people stuck with sysvinit, even if the maintainer chooses to get rid of manually created sysvinit scripts. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa9=mmzbdNbQ5Wr9M+Gr8Cu3D3OQ5f=+lirbzvyfw9d...@mail.gmail.com
Re: Default display manager should not be gdm3
Em 23/02/2012 14:58, Steve Langasek vor...@debian.org escreveu: On Thu, Feb 23, 2012 at 08:56:22AM +0100, Vincent Bernat wrote: Moreover, other display manager may not work correctly because gdm3 is the only display manager supporting all modern stuff. For example, we could switch to something like slim but slim does not play nice with ConsoleKit which means that a user logged with slim won't be considered as a local user and therefore won't have rights for power management, network configuration and things like that. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601003 Shouldn't that be trivial to address with the use of the pam_ck_connector module? Unfortunately, no. Since CK 0.4.3, if i'm not mistaken, you only get an active and local CK session if you specify the X display and the tty for the session creation (through libck-connector). LightDM works well with CK. XDM can be patched, there are patches available in the mailing list, but I think they never got merged. There's more info about CK vs. DMs in a bug I filed against XDM some time ago, I can't look it up right now. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna9+elrg2gq52ud3axr91qbrgfeeuhbdzdcdesypxay...@mail.gmail.com
Bug#660449: general: The pc freeze suddenly
Hello Vittore, On Sun, Feb 19, 2012 at 12:01 PM, Vittore Luccio vluc...@gmail.com wrote: Thanks to you. Here's some other information: [...] What you're reporting is waaay too general. Please contact the debian-user mailing list [1] or some other localized mailing list for Debian users, and ask for advice on how to narrow it down and troubleshoot it. It might be anything, hardware problems, driver problems, or actual bugs on other higher level components. Reporting a bug without narrowing it down first is pretty much useless. Also, please take care not to mail cont...@bugs.debian.org unless you know what you're doing, as it can have unintended consequences. [1] http://lists.debian.org/debian-user/ Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa9Sr37d4TuvdtvVi7vSijkyXtzwfUHh1N=7m90xcot...@mail.gmail.com
Re: Patch Tagging Guidelines: DEP-3 moved to ACCEPTED status
On Wed, Jan 18, 2012 at 4:37 PM, Dominique Dumont domi.dum...@free.fr wrote: Le Wednesday 18 January 2012 18:41:44, Jakub Wilk a écrit : And how do I use this parser? I want something as simple as: for a given patch, check if the header complies to DEP-3 and if it does, dump it in some machine-readable format. Currently, it cannot be used outside of the more general debian package files editor. You can use dpkg-copyright instead of dpkg, though: http://search.cpan.org/~ddumont/Config-Model-1.265/lib/Config/Model/models/Debian/Dpkg/Copyright.pod Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa-ivQQYdbEcno5di=+yv8f_iu6chnef4ddqwxvb0fw...@mail.gmail.com
Re: from / to /usr/: a summary
On Sat, Dec 31, 2011 at 12:59 AM, Enrico Weigelt weig...@metux.de wrote: * Adam Borowski kilob...@angband.pl schrieb: On Fri, Dec 30, 2011 at 02:47:38PM +0100, Marco d'Itri wrote: On Dec 30, Carlos Alberto Lopez Perez clo...@igalia.com wrote: I think that stephan is right here. Every package using files in /etc It DOES NOT MATTER who is right, some upstreams have decided otherwise. At least udev, systemd and next month module-init-tools do override the configuration files in /usr/lib/ with the configuration files in /etc/. Deal with it. Then udev and systemd are broken. You're introducing a dangerous inconsistency that's going to bite people. ACK. Sometimes upstreams doing really stange things (maybe because they dont have any package management in mind), that should be fixed. If upstream doesnt do those fixes, distros have to catch in. Look, the purpose of distros is to provide an consistent, robust and mainainable environment. Sometimes the distro maintainers have to bite in the bitter apple and cleanup upstreams's dirt. Are you guys applying for maintainership for this huge delta you want to introduce between upstream and us? Are you becoming new, reputable upstreams for that forked software? If not, please refrain from telling people what to do. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa92t4N5zrWm=UX=PO1f19X=ykqvyb9szdo1cq7bhrk...@mail.gmail.com
Re: A few observations about systemd
On Mon, Jul 25, 2011 at 8:57 AM, Marc Haber mh+debian-de...@zugschlus.de wrote: On Sat, 23 Jul 2011 13:09:02 -0300, Fernando Lemos fernando...@gmail.com wrote: The thing you don't seem to get is that systemd uses init files No need to be rude and to assume stupidity on the other side when one is just asking innocent questions about what to expect in the next years. That was not the intention, please don't overreact. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa9FiA=6m5M-+Q21-x+CF1_5hG=agygfcrhwglpj+p1...@mail.gmail.com
Re: A few observations about systemd
On Sat, Jul 23, 2011 at 12:47 PM, Marc Haber mh+debian-de...@zugschlus.de wrote: On Thu, 21 Jul 2011 18:12:13 -0300, Fernando Lemos fernando...@gmail.com wrote: A more realistic option would be launching a program (or script) which would read a configuration file (containing whatever /etc/default/exim4 contains nowadays) and launch the exim instance(s). So one would have some thing like an init script, which would probably have to stay around and monitor the daemon? That doesn't look like an easier way to do things. The thing you don't seem to get is that systemd uses init files which are not really scripts. If your daemon is so unorthodox (to put it politely) that it needs to be started up from a script, you can simple continue using an init script to start it up, just move it out of /etc/init.d, which really was never a great place for it. Unfortunately, there are other big unorthodox daemons out there. Fortunately, systemd can live with them just fine. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa863Vo2ZkJZEC_THXRE05Rh_6UJ_wDjaPcULYkWc_vY=g...@mail.gmail.com
Re: A few observations about systemd
On Sat, Jul 23, 2011 at 4:47 PM, Stephan Seitz stse+deb...@fsing.rootsland.net wrote: On Fri, Jul 22, 2011 at 05:09:11PM +0200, Michael Biebl wrote: Configuration file for the daemon is /etc/default/rsyslog: The canonical configuration file for the rsyslog daemon is /etc/rsyslog.conf. Yes, but it doesn’t allow you to change start options of the daemon itself. Those should be configurable through the configuration file. include that via EnvironmentFile=/etc/foo/bar [1]. If it is avoidable, you shouldn't do that though, as /etc/default files are Debian specific and one aim of systemd is, that unit files are usable cross-distro. I don’t know if files in /etc/default are Debian specific ones, but sometimes you need to change start parameters of the daemon. One example is sasldauth. If you have postfix in a chroot environemnt (standard Debian), you need to change the parameter for the named socket. Those should be configurable through the configuration file. If that's not possible for some random daemon, write a wrapper. So you need a configuration file at least for certain daemons to change options for the daemon start. A lot of those /etc/default files have a ENABLED=YES flags, which are not particularly useful with systemd, as systemd provides proper mechanisms to enable/disable services in a convenient way. Well, that is fine. I often disable a service by putting a „exit 0” in its init script, if I don’t want to always run this service. But why are the unit files not configuration files to begin with like init scripts? In my eyes they all belong in /etc. If you want to configure the init files, feel free to copy them to etc and edit them there (as has been mentioned in this thread already). Adding exit 0 to a init script is not really a good idea (as has been mentioned in this thread already too). Let's put it this way. Systemd splits the metadata required to initialize a service (such as what the daemon provides, what needs to be done to start it up, what should activate it, i.e., all the stuff that's stored in declarative init files) from the configuration of the service (stored in the daemon configuration files). The former is data and clearly doesn't belong in etc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa9iE7MhkbhjJJkfWM8Nd+6t=arpzzvniwzynrr9yvj...@mail.gmail.com
Re: A few observations about systemd
On Fri, Jul 22, 2011 at 6:12 AM, Guus Sliepen g...@debian.org wrote: By the way, we already have the SysV init scripts, so we don't need to do anything to keep supporting that, while it will take some time before every package with a daemon has the required systemd scripts in place, I think we should wait with any switch until there is at least enough coverage. If you think your comparison is suitable, then are you suggesting we do something as difficult as moving from .deb format to .rpm? [...] I'm sure systemd won't be free of problems either. So lets first work on getting daemon packages to support systemd, and then see if the result is good enough to switch to systemd by default. That makes no sense, please do some research. systemd supports SysV init scripts, there's absolutely no need to wait until packages support systemd. What *is* needed is specified here: http://wiki.debian.org/systemd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna8wyoxwbkowuwwi4gchnzojsyxsixqd8rnfokkpxtm...@mail.gmail.com
Re: A few observations about systemd
On Fri, Jul 22, 2011 at 9:20 AM, Fernando Lemos fernando...@gmail.com wrote: On Fri, Jul 22, 2011 at 6:12 AM, Guus Sliepen g...@debian.org wrote: By the way, we already have the SysV init scripts, so we don't need to do anything to keep supporting that, while it will take some time before every package with a daemon has the required systemd scripts in place, I think we should wait with any switch until there is at least enough coverage. If you think your comparison is suitable, then are you suggesting we do something as difficult as moving from .deb format to .rpm? [...] I'm sure systemd won't be free of problems either. So lets first work on getting daemon packages to support systemd, and then see if the result is good enough to switch to systemd by default. That makes no sense, please do some research. systemd supports SysV init scripts, there's absolutely no need to wait until packages support systemd. Sorry, reading my own post again, I realized you might have meant let's wait until more packages support systemd so we can be sure it's the right option. That does make sense. I guess we would still need, though, to amend the policy? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa_9T=0DE_t93YfV=jcc2daqfbgwjxtda_y7aeuvp8f...@mail.gmail.com
Re: Minimal init
On Fri, Jul 22, 2011 at 11:57 AM, Juliusz Chroboczek j...@pps.jussieu.fr wrote: No, I don't think so. If these external tools double fork then they are just wrong. Double Forking has been the right way to do it for decades. It has been the default way for most daemons, granted. (Getty is a notable exception.) Demanding from upstreams that they change their software this fundamentally to cater for a new init system is [...] unrealistic Runit has been around for a decade or so. Most daemons known to me have a command-line flag that prevents forking. Remember, preventing forking is about *removing* code from daemons, not adding new code. Adding a flag to avoid forking is a trivial exercice, and it's a rare upstream that will refuse the usually trivial patch. Well, to be fair, preventing forking is *adding* code to parse the right option and skip the calls that do the double forking. It should be, though, a fairly simple change. From what I've seen in Lennart's posts, adding systemd support doesn't seem to be too complicated. Some bigger changes may be required for more complex daemons. It's understandable that upstream might not accept them at first. In an hyphotetical scenario where systemd becomes the default init system in Debian, not having a systemd init file could be an overridable lintian warning or something like that. I'd like to stress that systemd apparently handles LSB scripts pretty well, even running them in parallel whenever possible. I find it perfectly natural that it'll take time for some upstreams to get confortable merging those patches. Package maintainers that prefer not to ship those patches could opt to ship a SysV init script instead. This backwards compatibility isn't going away in the foreseeable future. I also think it wouldn't be wise for an upstream to ignore systemd compatibility patches unless those require massive changes to the code (which could be a symptom of more serious upstream problems or perhaps bad design decisions). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna83qdvm3x-6txuqbos0k_eqtec3-f_8dhx9a37pcqy...@mail.gmail.com
Re: Making daemons compatible with systemd [was: Minimal init]
On Fri, Jul 22, 2011 at 3:31 PM, Juliusz Chroboczek j...@pps.jussieu.fr wrote: From what I've seen in Lennart's posts, adding systemd support doesn't seem to be too complicated. No. No changes at all are necessary to be compatible with systemd. This is a very impressive feature of systemd; at the same time, this is what complicates systemd, and creates a dependency on cgroups. I was referring to socket activation. Is that cool? Is that bloat? I say yes to both. I'd rather avoid the word bloat in this discussion, as it's very often misused. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna_xwfhvt90p0myk5c-6p4on0oo_vuzjul30n4hkeek...@mail.gmail.com
Re: A few observations about systemd
On Thu, Jul 21, 2011 at 5:44 PM, Marc Haber mh+debian-de...@zugschlus.de wrote: On Wed, 20 Jul 2011 10:36:34 +0200, Tollef Fog Heen tfh...@err.no wrote: Something like: ExecStartPre=/usr/sbin/update-exim4.conf ExecStart=/usr/sbin/exim4 -bd -q30m should do what you want. exim4 is one example, and it adds some extra complexity. An exim4 daemon does two jobs: Running the queue and listening for SMTP. Currently, you can configure in /etc/default/exim4 whether you want both jobs to be done by the same daemon, two dedicated daemons or only one doing one of the jobs. Additionally, there is a special mode for ppp-connected systems. How would I do this with systemd? Please don't get me wrong: I like the ideas behind systemd, but I need some more input to decide whether it's actually as flexible as an init script. I believe the systemd way to handle this would be moving the logic that automatically configures the daemon with flags or additional instances out of the init script. In the specific case you mention, perhaps this functionality should have been built into exim. A more realistic option would be launching a program (or script) which would read a configuration file (containing whatever /etc/default/exim4 contains nowadays) and launch the exim instance(s). Thus the original init script could also be then greatly simplified (to the point where it could be defined in a init-system-agnostic declarative format). I'm not a maintainer of any package that ships init scripts, so please take my words with a grain of salt. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna9wxmalmxhcspfwdqpwnpfciap65ovkxjstpuyga4k...@mail.gmail.com
Re: [Lennart Poettering] Re: A few observations about systemd
On Tue, Jul 19, 2011 at 3:41 PM, Peter Samuelson pe...@p12n.org wrote: [Uoti Urpala] IMO letting kFreeBSD block a technology like systemd (or even letting it have a significant impact on the discussion about whether it's desirable to introduce the technology for the main Linux case) would only be justifiable if there were very solid arguments why kFreeBSD is a big net win for the project, or after a vote showing significant support for the port. IMO letting systemd block a technology like kFreeBSD (or even letting it have a significant impact on the discussion about whether it's desirable to introduce the port for Debian releases) would only be justifiable if there were very solid arguments why systemd is a big net win for the project, or after a vote showing significant support for the package. What I don't understand is, why do so many people think they're mutually exclusive? I guess this thread is past the point where nothing useful can come out of it anymore. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canvyna-myrysmfrzf1hoz9ue_phcbbtfursp_ccbfecbiil...@mail.gmail.com
Re: A few observations about systemd
On Mon, Jul 18, 2011 at 9:02 AM, Gergely Nagy alger...@balabit.hu wrote: [...] (Personally, I like the patch systemd path best, and time and skill permitting, I'd be happy to help, if so need be.) While that may sound attractive at first, I don't think it's technically possible at all at the moment. It's not a simple portability problem, systemd relies on very complex Linux-specific stuff. I think implementing all the required stuff would be an effort comparable to implementing something like KMS or GEM or Gallium3D on FreeBSD. It's simply not something a distribution could be concerned with, so I don't think it would be realistic to consider this an option. That said, I'd love to be proven wrong. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANVYNa_hzFgUd6jmRY-e19=cqhor_8s779lj0wpk3np-qsf...@mail.gmail.com
Re: Getting good bug reports
On Thu, May 26, 2011 at 9:21 AM, Patrick Strasser patrick.stras...@tugraz.at wrote: [...] Why not use some simple non-HTTP-protocol on port 80? That tends to break transparent proxying. If port 80 is the only one you have open, chances are you're behind a transparent proxy as well. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTikhWKmYAwCYZRtng86f=o1aje8...@mail.gmail.com
Re: packaging-dev meta package
On Thu, May 26, 2011 at 5:05 PM, Benjamin Drung bdr...@debian.org wrote: Hi, A few days ago, we had a discussion in Ubuntu about a packaging-dev meta package. The problem is that users have to install a bunch of packages if they want to dive into packaging. Even some packagers get annoyed when they need to turn a newly installed system into a packaging environment. The solution would be a meta package that depends on the commonly used packages for packaging. Isn't apt-get build-dep enough? Users can always use equivs for something more specific. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=k=2t56u2njso39k8vwasonf3...@mail.gmail.com
Re: bug reporting workflow is outdated
On Sun, May 22, 2011 at 6:25 PM, Didier Raboud o...@debian.org wrote: I think expecting having a working smtp on laptops, workstations, etc, is unreasonable these days. I suggest that we can make an HTTP based bug reporting method. While I disagree with your appreciation, I am sure that it would be technically feasible to code and deploy an HTTP-to-Debian-BTS gateway (some things have to be DoneRight™, but it's doable). This has been discussed over and over. I suggest that anyone interested Google for the last thread on the matter and don't bring it up again unless something changed since then. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=n7=J=F_Pb6MvVmAe=md+cmsp...@mail.gmail.com
Re: A concrete proposal for rolling implementation
On Wed, May 4, 2011 at 6:40 PM, sean finney sean...@debian.org wrote: [...] On Wed, May 04, 2011 at 10:25:35PM +0200, Stefano Zacchiroli wrote: On Wed, May 04, 2011 at 02:24:12PM +0200, Josselin Mouette wrote: What to do during freezes - If we want to do something different though, there is a simple recipe: allow packages to be picked up from unstable, but also from experimental. [...] One issue that would need to be addressed with experimental is that opening a migration route anywhere out of experimental might come as an unpleasant surprise to some, since there's a standing expectation that it's a pseudo-suite where we can put stuff that we don't necessarily want to try out in unstable. Not an insurmountable problem (either we change that or introduce yet another psuedo-suite for this purpose), but worth note anyway. Indeed. I guess we could specify a flag in this overrides file that says whether or not it's fine to fetch from experimental (defaulting to off). That way it would be up to the maintainer to specify that experimental is good and stable enough for rolling. I really like this new proposal, nice job. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktin4vnums0qbqe1ruvubkezyrhu...@mail.gmail.com
Re: network-manager as default? No!
2011/5/1 Miroslav Suchý miros...@suchy.cz: Dne 3.4.2011 18:08, Fernando Lemos napsal(a): * It doesn't have a good command-line interface It does have CLI interface. Those commands are bundled directly in NetworkManager: nm-cli nm-tool nm-online I'm not sure if this qualify as good command-line interface :) Those tools can't create or delete connections, which is kind of important, so no. ;-) Of course you can always create the system connections with a text editor, it's nothing too complex but the format isn't documented AFAICT, probably because you are not supposed to create them manually. That said, nothing prevents the creation of a decent command-line interface. There's cnetworkmanager, which wasn't working the last time I checked (API incompatibility with the Debian packages, might have been fixed by now). The DBus API is pretty straightforward, I use a bunch of scripts to create and delete wireless connections. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktimbymnwhtge1ko3xy0m86thgg_...@mail.gmail.com
Re: network-manager as default? No!
On Fri, Apr 15, 2011 at 10:04 AM, Patrick Schoenfeld schoenf...@debian.org wrote: I've always believed that peoply chose NM for simplicity. And I can understand that. It's simple because it doesn't support anything complex, including common VPN setups. ifupdown does not support any VPN setup at all. how does that fit in your argumentation? Btw, not sure this hasn't been mentioned before but: http://packages.debian.org/squeeze/network-manager-openvpn http://packages.debian.org/squeeze/network-manager-vpnc But nevermind, this thread is not about considering technical merits or sane defaults, it's all about letting the world know about your preferences, right? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTikdSmTCwS9yFQmG36CC5khMAK=q...@mail.gmail.com
Re: network-manager as default? No!
On Fri, Apr 15, 2011 at 6:50 PM, Felipe Sateler fsate...@debian.org wrote: Could those thread participants who have gripes from their last NM experience many years ago please confirm that their gripes still apply before continuing with the discussion? felipe@pcfelipe:supercollider% apt-cache policy network-manager network-manager: Installed: 0.8.3.999-1 Candidate: 0.8.3.999-1 Version table: 0.8.998-1 0 1 http://ftp.br.debian.org/debian/ experimental/main amd64 Packages *** 0.8.3.999-1 0 500 http://ftp.br.debian.org/debian/ sid/main amd64 Packages 500 http://ftp.br.debian.org/debian/ testing/main amd64 Packages 100 /var/lib/dpkg/status felipe@pcfelipe:supercollider% sudo aptitude reinstall network-manager The following packages will be REINSTALLED: network-manager 0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 216 not upgraded. Need to get 0 B/1,102 kB of archives. After unpacking 0 B will be used. Reading package fields... Done Reading package status... Done Retrieving bug reports... Done Parsing Found/Fixed information... Done (Reading database ... 219815 files and directories currently installed.) Preparing to replace network-manager 0.8.3.999-1 (using .../network- manager_0.8.3.999-1_amd64.deb) ... Unpacking replacement network-manager ... Setting up network-manager (0.8.3.999-1) ... Reloading system message bus config...done. Stopping network connection manager: NetworkManager. ps, wifi connection gone Starting network connection manager: NetworkManager. Processing triggers for man-db ... As it was said before (*multiple* times, unfortunately), that's expected. Your *wired* connection won't go down... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=ASmGeu+jL0LmULrnrLmpi=cr...@mail.gmail.com
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 4, 2011 at 2:38 PM, Tzafrir Cohen tzaf...@cohens.org.il wrote: [...] It does have system-global config file. But the settings are not expected to be there. By default the settings are expected to be in the user directory (has this changed since 0.8?). So I won't easily find it when I want to e.g. change configuration as root. This is unlike wicd that keeps everything under /etc/wicd . NM, prior to 0.9, had system-wide and user-specific connections. Those user-specific configurations were replaced in 0.9 by system-wide configurations with permissions. The system-wide connections are always (even prior to 0.9) in /etc as you'd expect. I use NM with system-wide WiFi connections only. I create the system wide configurations through a collection of scripts I've assembled (since the other NM command line clients were either broken at the time I tried them or not powerful enough) and NM automagically picks the right connections for me when I'm on the road. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTinZdpKsf-5Ks4qWayFCQwJXX=8...@mail.gmail.com
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 4, 2011 at 6:23 PM, Mathieu Trudel-Lapierre mathieu...@gmail.com wrote: [...] This said, I don't think NM can be the magic bullet to fix everything. Even RedHat while shipping NetworkManager on servers last I checked, still relies on their simpler command-line setup for interfaces. So should we. Defaulting to using NM probably takes care of the widest audience who would use DHCP and such, and others can fall back to ifupdown or a successor to do the more complicated things like bridging. Also note that there are NM plugins that enable NM to understand /etc/network/interfaces and the Fedora/RHEL counterparts. This means that if a server has NM enabled and an administrator wants to configure networking manually, he can do it just fine even if NM is installed. NM will gracefully understand that and won't try to do anything stupid (see /etc/NetworkManager/NetworkManager.conf). For servers using DHCP, you don't even have to create a connection. Wired interfaces are already automatically configured to use DHCP in NM. For the other cases, just use the legacy tools or configure /etc/network/interfaces and set managed=true in /etc/NetworkManager/NetworkManager.conf (not sure if the latter works, never tested it). Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=91F41twWq=henpcw0r5uvykt...@mail.gmail.com
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Mon, Apr 4, 2011 at 9:20 PM, Stanislav Maslovski stanislav.maslov...@gmail.com wrote: [...] Also note that there are NM plugins that enable NM to understand /etc/network/interfaces and the Fedora/RHEL counterparts. This means that if a server has NM enabled and an administrator wants to configure networking manually, he can do it just fine even if NM is installed. NM will gracefully understand that and won't try to do anything stupid (see /etc/NetworkManager/NetworkManager.conf). The mentioned plugin is nothing more than just a rather primitive parser intended to read a limited set of common interface settings such as ip addresses, netmasks, dns servers, etc., from the existing /e/n/interfaces file for the ease of transition. The plugin simply translates these settings into the internal representation of NM. It is not intended to interoperate with the ifupdown infrastructure in any other way. Therefore, it is generally useless for an administrator that wants to configure network interfaces manually. Yes, it's just a parser. It can still be used to configure NM via /etc/network/interfaces, at least according to README.Debian (never tried that): Managed mode will make NetworkManager manage all devices and will make NetworkManager honour all dhcp and static configurations for wired and wireless devices. Which means you should be able to keep using /etc/network/interfaces for simple setup. ifupdown and friends will not work in that scenario, or the other way around, obviously. For servers using DHCP, you don't even have to create a connection. Wired interfaces are already automatically configured to use DHCP in NM. For the other cases, just use the legacy tools or configure /etc/network/interfaces and set managed=true Accordingly to docs here http://live.gnome.org/NetworkManager/SystemSettings that should be actually managed=false if you want an interface to be completely ignored by NM. Yes, it's managed=false, sorry. That's the default in Debian AFAICT, which means that /etc/network/interfaces takes precedence. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktinwjizcqy0spdt-wbjndvhm2_h...@mail.gmail.com
Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)
On Sun, Apr 3, 2011 at 5:11 AM, martin f krafft madd...@debian.org wrote: [...] last I checked, for instance, it was not possible to hook up two network cards with DHCP. [...] Hmmm I do have two network cards and they both get IP addresses with DHCP as I would expect (when they both are enabled). Anyways, I don't think NM is the right solution for all proposed use cases right now for a number of reasons: * It doesn't have a good command-line interface * It probably can't do some of the more complex yet common setups possible with ifupdown, guessnet and friends * NM was built by the Gnome community and their goals are a lot different from ours Nevertheless, I do believe something like NM is probably the way to go, as it is a cleaner and more controlled event-oriented design compared to a collection of all sort of scripts. It's seems to be the right way to do it, even if you don't agree with the particular implementation. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktikbfxomezyby7gfsox1zuq58f3...@mail.gmail.com
Re: linker related changes for wheezy
Hi, On Sun, Feb 27, 2011 at 3:45 PM, Fernando Lemos fernando...@gmail.com wrote: In situations like this, what can package maintainers do? Would adding -Wl,--copy-dt-needed-entries to the build script be acceptable and would gold support that flag too? Should the bugs be assigned to the libraries instead (Boost and others)? There's no way this can be considered a bug in the packages that use such libraries, it makes no sense. As it turns out, -Wl,--copy-dt-needed-entries isn't supported by gold (yay). The patch Roger Leigh posted to the Boost bugtracker seems to have been ignored[1], but I'm glad that there's been some discussion between Roger and the Boost maintainers[2]. Hopefully this will be sorted out in the future. I'm not sure what other Boost-based package maintainers are doing. I suspect they're just working around the problem by linking to the missing libraries. I do not plan to do this with btag (unless it's required in the near future for whatever reason), though I've patched upstream for convenience. If we get pkg-config support, I'll adapt btag's build system upstream and the Debian package as well. Regards, [1]: https://svn.boost.org/trac/boost/ticket/1094 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248674 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=jwszkh0bkhapguzbydhgu5rmfxczxyg042...@mail.gmail.com
Re: linker related changes for wheezy
Hi, On Sun, Feb 27, 2011 at 1:00 PM, Matthias Klose d...@debian.org wrote: [...] The latter change is described in [1] (section [2]). To summarize: If a library symbol is directly used by an object without explicitly linking this library, the link step now fails. The fix is to pass the library explictly to the linker. Rationale for this change: - Correctness. Symbols should not be resolved unintentionally. - Robustness. If a library drops a dependency on another library with the involved symbol, then the application still using this symbol will fail to build. - Buildability with the gold linker. Gold defaults to --no-copy-dt-needed-entries. Using gold as the default linker is not a goal for wheezy, but buildability of the archive with gold is required as a prerequisite. [...] Those are valid points, of course, but many Boost projects will fail to build now and I see no good solution[1][2][3]. Some libraries like libboost-filesystem and libboost-asio implicitly depend on libboost-system or libboost-thread or some other Boost library because they refer to their symbols in inlined functions and methods. This is a technical requirement mostly related to C++ templates (though C libraries could be affected too if they use inlined code). The problem with simply adding the missing libraries to each project's build system is that those dependencies aren't documented anywhere. The mantainers would have to add them manually in each project's build scripts. The dependencies might change in the future, too, and in that case the package will fail to build again. Roger Leigh proposed pkg-config integration in Boost[4] but got no feedback. That would be a way out of this problem, but I suspect upstream is not really interested. It could be argued that --no-copy-dt-needed-entries is C-centric since it ignores the problems faced by libraries that expose C++ templates. In situations like this, what can package maintainers do? Would adding -Wl,--copy-dt-needed-entries to the build script be acceptable and would gold support that flag too? Should the bugs be assigned to the libraries instead (Boost and others)? There's no way this can be considered a bug in the packages that use such libraries, it makes no sense. Thanks, [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248674 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602959 [3]: http://lists.debian.org/debian-devel/2010/12/msg00055.html [4]: https://svn.boost.org/trac/boost/ticket/1094 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikxekrxx5td9fctfp64r_gye-vhqyoz4vo...@mail.gmail.com
Re: linker related changes for wheezy
Olaf, On Sun, Feb 27, 2011 at 3:54 PM, Olaf van der Spek olafvds...@gmail.com wrote: On Sun, Feb 27, 2011 at 7:45 PM, Fernando Lemos fernando...@gmail.com wrote: Those are valid points, of course, but many Boost projects will fail to build now and I see no good solution[1][2][3]. Some libraries like I do: http://en.wikipedia.org/wiki/Auto-linking First has to be implemented in GCC though. This has been discussed before. Good luck a) writing the code, b) convincing the GCC developers it's a good idea and getting it upstream and then c) getting all the pieces in Debian. Ah, all that in time for wheezy, okay? I'd suggest we concentrate on viable alternatives. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTi=lbcicr_al_wkwxou7c97wv9ys2agbhhkt4...@mail.gmail.com
Re: does aptitude really need to lock the status database when downloading?
On Fri, Feb 4, 2011 at 6:57 AM, Stanislav Maslovski stanislav.maslov...@gmail.com wrote: [...] If you want to have that level of control, why don't you just check it manually? Use --download-only with apt-get (no dpkg locking this way) and when it's done, use apt-get without it to install the packages after making sure that there is no dpkg active anymore. This is possible, however, it is an extra busy work for a user. In any case, I think that holding a lock only for downloading is an overkill and this can be relaxed. As far as I can tell (and please correct me if I'm wrong), when you do, say, an apt-get upgrade, apt prepares an upgrade plan that uses a given set of packages. If apt wouldn't lock and parallel to that you do an apt-get install, for example, the original plan might not be valid anymore (e.g., new Breaks or Conflicts were introduced). So a new plan would have to be created, the user would have to be asked for confirmation again. Doesn't sound that great. As Julian Taylor mentioned, there is also another side of the same problem: aptitude itself can be improved so that it is able to download and unpack in parallel. If it were doing this then the lock would be justified. As far as I know, apt-get already downloads in parallel. Not sure about aptitude. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTim31Hson4sEw-zVtkowQmyhkFAu=a+ummoem...@mail.gmail.com
Re: does aptitude really need to lock the status database when downloading?
On Fri, Feb 4, 2011 at 5:10 PM, Simon Chopin chopin.si...@googlemail.com wrote: [...] As Julian Taylor mentioned, there is also another side of the same problem: aptitude itself can be improved so that it is able to download and unpack in parallel. If it were doing this then the lock would be justified. As far as I know, apt-get already downloads in parallel. Not sure about aptitude. I think it does, when on different servers IIRC. But I believe what Stanislas mean is to unpack while downloading the rest of the packages. Ah yeah, indeed, I realized that when I read the sentence again... I often wondered why it wasn't the case, but I've assumed so far that there was probably a reason I just could not think of :) I can think one: autoremove and packages marked as automatically installed. When you install package B as a dependency of A, you install B as an automatically installed package, so that apt-get autoremove can get rid of it when A is no longer installed. If you lock to install package B, then unlock and lock again when you're about to install A, apt-get autoremove might have been invoked in the mean time and package B might not be present anymore. Sure, you can handle that too, but I really don't think it's worth the hassle. There might be a lot many more cases like this, and the benefit seems very insignificant. Anyways, the proper way to request this feature is through the bugtracker. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikd2nhvct43nqfywtf0nmwqkbmcgcjbrk-gr...@mail.gmail.com
Re: List of FTBFS in Ubuntu
Hi Olaf, Roger On Thu, Dec 9, 2010 at 11:00 AM, Olaf van der Spek olafvds...@gmail.com wrote: [...] Now, pkg-config isn't standardised /either/, but it's useful because it will work with any standards-conforming compiler. It's just a generalisation of existing practice (in the form of foo-config scripts generated during a package build). Pkg-config probably isn't bad, but it does increase the complexity of build script. Especially compared to auto linking. Correct me if I'm wrong, but I don't think implementing auto linking support in GCC is a realistic goal. I can imagine there are lots of technical and non-technical issues involved, it's certainly not something that can be accomplished in the short term. But this is all moot. I've written the pkg-config support into the auto-link header, and we just need to integrate it into the build system to get the job done. How does pkg-config handle the selection of the threading variant? Toolset-variant? Seems it's hard-coded to a single variant. Yeah, take a look at the comments in the report Roger linked to. It looks like we can't handle multiple variants with pkg-config. I don't think this is a major problem for the time being, though, as there's a single variant in Debian and I imagine that's also the case for most other distributions. I think proper pkg-config support would be fantastic. I'm wondering if this support could be patched downstream in case upstream rejects or ignores the patches Roger submitted. I'll adapt btag's build system to use pkg-config for Boost as soon as this enters unstable. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=pwhkthrmama9scwsql-yy7wca6rz6p7bhv...@mail.gmail.com
Re: List of FTBFS in Ubuntu
Hi Lucas, Thanks for generating this list. 2010/12/3 Lucas Nussbaum lu...@lucas-nussbaum.net: Fernando Tarlá Cardoso Lemos fernando...@gmail.com btag This is not a bug in btag. The problem is that binutils-gold (used by Ubuntu) breaks every program that uses Boost (among other C++ libraries): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602959 binutils-gold needs to support --add-needed and preferably make that the default behavior, otherwise there will be lots of false positives like this. I personally don't intend to work around it unless binutils-gold support becomes mandatory for Debian (which hopefully won't happen until binutils-gold is fixed). Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinojopye7qx9xo=z0lcsvb2nd-_z7nhzxrds...@mail.gmail.com
Re: List of FTBFS in Ubuntu
Hi Roger, On Fri, Dec 3, 2010 at 12:08 PM, Roger Leigh rle...@codelibre.net wrote: This is a bug in your package, unfortunately. While it might appear that you only use boost_system /indirectly/, your code is in fact using it /directly/ via inline functions in the boost_filesystem headers. You can see this for yourself if you take a close look at the boost_filesystem headers. We do end up with boost::system symbols, I know that (please read the aforementioned BTS discussion). I disagree on it being a bug on btag, though. Please read on. While I do find this a rather annoying violation of encapsulation, you will find (e.g. with nm -C -D) your binary will have boost::system symbols in it which are only satisfied indirectly via libboost_filesystem and which would result in breakage if libboost_filesystem drops that dependency and you don't explicitly link against it. Ideally, the headers should be fixed. The thing is, libboost_filesystem is not supposed to drop their dependency on libboost_system unless its headers no longer refer to boost::system. The requirement of linking to boost::system is an implementation detail of boost::filesystem that package maintainers should *not* have to worry about. Boost works on the assumption that the linker will consider the dependencies of the DSOs. You can say it's a Boost bug, you can say it's a binutils-gold bug (for changing a behavior that people relied on for the sake of performance), or you can say it's a CMake/pkg-config bug (for not listing the right dependencies for boost::filesystem), but it's in no way a bug in btag or any other package that links against libboost::filesystem, libboost::asio and countless other C++ libraries in the same situation. So I think it would be *really* nasty if ever developer had to work around a bug somewhere because something else is broken. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimnzthvv71bwds7v7lcntc13fmt_bqkoszxw...@mail.gmail.com
Re: List of FTBFS in Ubuntu
Hi Roger, On Fri, Dec 3, 2010 at 3:41 PM, Roger Leigh rle...@codelibre.net wrote: [...] btag *does* use boost::system, even though you don't want to use it. Right now, with the g++4.5 and/or the gold linker, you aren't linking with a library you need. And I'm afraid that right at this point in time, it does need solving in btag. From the compiler perspective, it does use boost::System. From the developer perspective, it doesn't. Sure, I can patch the build system to include -lboost_system, but what if Boost 1.4.3 depends on another library? It's madness, this doesn't scale at all. Now arguably, boost should provide that information for use, but right now it *doesn't*, and it is the user's responsibility to do the donkey work. This information isn't specified in the library dependencies, so they can't be used as a substitute. Their reasoning I think is that the dependency is already encoded in the DSOs, no need to make that information redundant. If they did provide this info, I'd agree on following it to the letter and adding that dependency information to the build system. Why? If you link indirectly today, and later on boost_filesystem drops its boost_system dependency, your code will break because those inlined functions are in *your* code, not the filesystem library. You'll get a link failure. By linking explictly, you're protected against future failure. I don't disagree, though as I said previously, if boost::filesystem dropped the libboost_system dependency, it's because it's no longer present in the headers too, so that wouldn't be an issue. If they drop it and still use in the headers, then it's likely going to be considered a bug. Just for the record, C++ templates don't require inlining; you can specifically instantiate and export particular instances to avoid this. Full support for exported templates in g++ would also be useful, but we've been waiting over a decade for that and it's due to be removed from the standard. I think it would require some refactoring in Boost. So I think it would be *really* nasty if ever developer had to work around a bug somewhere because something else is broken. It's arguable whether it's a bug or not. Maybe this is what was specifically intended? We do need a scalable approach to dealing with this, and I'd suggest pkg-config should be the route to take. But until such time we have a solution like that in place, the onus is on the library users to link correctly, and it is going to be a major problem. How about this compromise. If --add-needed worked with binutils-gold, Boost projects could specify it and keep depending only on the libs they actually use (from a developer's perspective). I'd be happy to add that flag upstream in btag. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikgxyxfmr+7o45_mrt0qogxpy6sxefz4pzbh...@mail.gmail.com
Re: List of FTBFS in Ubuntu
Hi, Olaf On Fri, Dec 3, 2010 at 3:49 PM, Olaf van der Spek olafvds...@gmail.com wrote: On Fri, Dec 3, 2010 at 6:41 PM, Roger Leigh rle...@codelibre.net wrote: Why? If you link indirectly today, and later on boost_filesystem drops its boost_system dependency, your code will break because those inlined functions are in *your* code, not the filesystem library. You'll get a link failure. By linking explictly, you're protected against future failure. If the boost_system code is removed from the boost_filesystem headers and the dependency is dropped, why would you get a link failure? What Roger is referring to is the situation where boost::filesystem's DSO no longer depends boost_system, but the header files still use boost::system in inlined methods. That, however, is very unlikely (and probably would be treated as a Boost bug), as it would cause a lot of FTBFS issues, even with --add-needed. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinbmvj1y6yv2d6dv-glurduioffxuuxgz_-d...@mail.gmail.com
Re: Atomic operations
Hi, On Fri, Nov 19, 2010 at 10:56 PM, T. Alex Chen alex_c...@yahoo.com wrote: I want to do atomic operation and find there is already such implementation in Linux, e.g. atomic_add, atomic_set, atomic_cmpset, etc, after I google on the Web. I find a libatomic-ops-dev package and install it. But there is still no man page after the installation. Did I install the right package? Where can I get the man page of these atomic operations? Please don't post support questions to debian-devel. debian-devel is about the development *of* Debian, *not* the development *on* Debian. This is the wrong list for this question and your other recent questions. Please look for the support channels instead. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=lr9qdt2xhrdncbthevpjubmiuof9t6uc5z...@mail.gmail.com
Bug#602473: general: cannot change dhcp address to static
Hi, On Fri, Nov 5, 2010 at 4:39 AM, ivan okol...@gmail.com wrote: I cannot chage manually IP address in /etc/network/interfaces, after bring interface down with ifconfig eth0 down I manually edit above maentioned file with: allow-hotplug eth0 iface eth0 inet static address xxx.xxx.xx.xx and so on and after bringing up command on eth0 host wont connent any more or still hanging on dhcp. Ifconfig eth0 still showing DHCP address, it will change only after restarting host. You must first ifdown then interface, then change the configuration file, and then ifup the interface. If you don't, you won't get the expected results. This bug is invalid (and shouldn't be reported as general either). Please use real support resources before posting bug reports with support questions. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimwd0meky64l-xsk=d-fetdzh_b6he00uwjf...@mail.gmail.com
Re: Summary of CUT discussions
Hi Roland, On Mon, Sep 27, 2010 at 5:14 PM, Roland Mas lola...@debian.org wrote: Well, we know that fully 27% of popcon-reporting users already use unstable or testing. So in general, developers already have an incentive to keep unstable and testing usable for those users, not just stable. I'm fine with an incentive. An official promise by the project that unstable and testing (or rolling) *will* be usable, on the other hand, makes me really nervous. I recommend that you watch the BoF video, if you haven't already. Joey explicitly states there that CUT will not be as stable as stable. You can't obviously get the same stability as stable without all the quality assurance and the freezes, not now at least. I wouldn't be at all surprised if CUT ended up being mostly used for desktop systems, and not for servers, since the desktop is exactly the area where rolling releases with constant shiny stuff and new hardware support is most needed. Certainly. And CUT is very probably going to be useful for them, just as testing can also be useful. However, from what I understand, CUT/rolling is going to be basically testing plus chromium (oversimplified). I'm completely fine with that, as it's just another suite that flows from unstable. The problem arises from what we, as a project, tell the world CUT is. If we want to call it “safe for many users” or “supported”, which is as far as I know its most important selling point, then we need to take out some packages. I don't know how many, but at least some; fusionforge is admittedly pathological, but I wouldn't be surprised about other applications that use a database and need to care about data migration. Wikis, webapps, ERPs, collection management stuff, that sort of thing. Do we need those in CUT? I don't know. But CUT suddenly becomes testing plus chromium minus a number of packages. If that still fits the goals of CUT, then by all means go ahead; I was just reacting to the stance that it's only a communication issue, because it clearly isn't. CUT is not about providing the same level of stability of stable (not in the short term, at the very least), so I don't really think this is a problem. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikbsqiwtovtpon3y=nb=5mahbhme+9pbybg0...@mail.gmail.com
Re: Summary of CUT discussions (Was: unstable/testing/[pending/frozen/]stable)
Hey, On Sun, Sep 26, 2010 at 10:55 AM, Luk Claes l...@debian.org wrote: IMHO, what is missing from rolling should be added to testing, not worked around by introducing another suite: I believe it's the other way around, actually. To me, adding stuff to testing is the workaround. Testing is not meant to be used like a rolling release distribution, as it is based on a set of constraints which do not have anything to do with rolling releases and constantly reasonably up-to-date distributions. And that's why it rears its ugly head (generally by freeze time) for users which were expecting it to be a rolling-like distribution. How can we ensure that testing always contains a stable version of chromium ? The current decision of keeping it out of testing was right given our actual constraints on what's ok for a stable release. I would argue that we need to redefine our criteria for a stable release and I plan to have this discussion at some point but I think in the mean time having rolling is good way to fix this. I'd rather fix this so chromium can be added to testing and stable. And how can that be done? Chromium can't go into stable, so it must be removed from testing as the product of testing is stable. People have suggested backports and volatile, but I see those solutions as an afterthought. How can we ensure that testing continues to be updated during freeze time ? This one is really not fixable without a second distribution. I know it's also the most problematic aspect for the release team because you fear that it will make people care less about getting a stable release out of the door. I think this fear is not completely justified, people that do not care do not need an excuse to not care, they already do it (unfortunately). I think this is completely the wrong question, we'd better ask the question: Why do freezes have to take that long? I do think it's completely wrong to have the people causing the long freezes benefit from another suite which fits better with not really caring about stable, I'd rather have some peer pressure to have a constantly usable testing which can be released fast (aka without a long freeze being necessary). I do think having snapshots could help with that goal. I agree that having much shorter freezes would make the situation a lot better and I do believe that snapshots could provide some sort of quality assurance that would help shorten freezes. This does not solve the other issues with using testing the way many people use it nowadays. Why would non-frequent snapshots help more than frequent snapshots? Because in that case they could really be used and supported for installing, better user testing, security... I think it kind of depends on how the CUT team plans to assure some level of quality to the snapshots. If it's just about automated testing and minimal user intervention (as hinted in the BoF video), I don't see why non-frequent snapshots would be a requirement. Right, though I don't see the need for rolling in this situation unless we want to keep long freezes and half baked solutions for difficult to support packages. I'd rather have these issues fixed than worked around... and I hope many people support that? Testing or unstable only exist to support stable. Stable is the final product, testing and unstable are byproducts which people aren't supposed to use unless they're trying to improve the next stable in some way. I think what the CUT team is trying to achieve is to make testing or the rolling suite a first-class citizen and I really like that idea. I'm under the impression that some (most?) developers care at least as much about testing and unstable as they care about stable, as they use testing or unstable on a daily basis in their machines. Some may be afraid that a rolling release model would mean some maintainers aren't going to care about stable anymore. I think this is a valid point, but preventing maintainers from working on what they care about doesn't seem right and might actually stray maintainers away from the project. Who knows, maybe having a rolling suite would even allow us to unfork some Debian derivatives. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik81b7l5l8bbivub=5sopzw8-fcm3zhxlygw...@mail.gmail.com
Re: Bug#595820: ITP: woof -- A small, simple, stupid webserver to share files
On Tue, Sep 7, 2010 at 7:35 AM, Mike Hommey m...@glandium.org wrote: On Tue, Sep 07, 2010 at 12:27:14PM +0200, Salvo 'LtWorf' Tomaselli wrote: On Tuesday 07 September 2010 12:02:38 Jean-Christophe Dubacq wrote: What about using nc ? nc -l /etc/passwd http://localhost:/ = bingo. We will probably not convince you, but there are way too many alternatives to make the packaging effort worth the time. you convinced me, and i was well aware of that. But how can i convince someone with an apple that he has to download gcc and compile nc or even worst convince someone with windows? Someone with an apple or windows doesn't need a debian package of woof. And someone with debian has nc. That, and you don't really need nc on the client side. I believe most browsers would download the file even though nc won't send any HTTP headers. If that's not the case, try something like: printf 'HTTP/1.0 200 OK\nContent-Type: application/octet-stream\n\n' | cat - /etc/passwd | nc -l -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim2acfaog+cxc28j8ezi8oqhbp4xwk6obc2d...@mail.gmail.com
Re: More advanced home directory creation in Debian?
On Sun, Aug 22, 2010 at 3:29 PM, Lars Wirzenius l...@liw.fi wrote: (My own preference would be to create all home directories as completely empty, not even using /etc/skel, and fix all applications that need a file to create one on demand.) There's no need for any of the files in /etc/skel, so there's nothing that needs fixing. /etc/skel these days is mostly distro-specific defaults that users expect to see (a better PS1, for example, or aliases like ls --color). For that same reason, there's no need to update files in user directories. Important stuff goes to login.defs or /etc/profile or maybe elsewhere, you can have a very functional setup with zero files in ~. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik-abqlf4egqcgwdbxv3qhajhm-ybsqtoat+...@mail.gmail.com
Re: More advanced home directory creation in Debian?
On Sun, Aug 22, 2010 at 6:40 PM, Christoph Anton Mitterer cales...@scientia.net wrote: You're aware that not only .bash_* and .profile can be distributed by /etc/skel,... but any other config file (e.g. .vimrc) a specific site or organisation may found useful for their users? Or a predefined directory structure,... ssh config perhaps specific for each user? /etc/skel is used to populate user home directories on user creation, nothing more. For system-wide settings , use /etc (e.g. /etc/vim/vimrc.local). Use site-specific scripts for any more convoluted needs you might have. There's nothing to be discussed about this, really. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=sdtfz9w_2rkq7ngx-ic6b0ne6n74pks1tu...@mail.gmail.com
Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling
2010/7/26 Jesús M. Navarro jesus.nava...@undominio.net: Hi, Ian: On Monday 26 July 2010 13:49:00 Ian Jackson wrote: Brian May writes (Re: How to make Debian more attractive for users, was: Re: The number of popcon.debian.org-submissions is falling): I would really like to see a HTML/HTTP browser based interface for the BTS. I would have several advantages: I would strongly resist any such suggestion, for the reasons I have already explained. In summary: We don't have a lack of bug reports, we have a lack of developer time. Increasing the number of bug reports will take away developer time for triage, for no benefit. Simply, we do not need to, and should not, make reporting bugs easier. I would say bug reports should be always welcome. The easier to fill bug reports, the better. How many BTS reports have you closed? I don't mean to sound offensive here, but this thread is fruitless. All I see is people talking and talking over something they have no say in. This is free software. If you want to get your idea implemented, either file a bug report and patiently wait (and leave debian-devel alone) or implement it yourself. Talk is cheap. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=qbc20s5o26ue+rjjt9ow-dwwsrybbrk=sq...@mail.gmail.com
Re: A Look In the Mirror: Attacks on Package Managers
On Sun, Jun 6, 2010 at 5:31 AM, Florian Weimer f...@deneb.enyo.de wrote: * Fernando Lemos: 1. Man-in-the-middle attacks between clients and security update servers 2. Denial-of-service attacks to the security updates infrastructure 3. No trusted servers for security updates for testing and unstable Using HTTPS for the security update infrastructure could solve #1, Not really, because the mirrors are already middlemen, so encrypting the transport to them doesn't change much. Sorry, I think I wasn't clear enough. I mean using HTTPS for security.debian.org, i.e., the security update servers. Regular updates would still come from whatever mirror the user chooses, HTTPS wouldn't help there. Now if we had a timestamp in the root metadata updated on a daily basis, that would solve #1 and #3 Actually, it wouldn't because we do not provide a secure time source. pool.ntp.org faces the same theoretical issues as our mirror network. Indeed. But if you play with the system clock, the admin is probably going to notice it. make, tar and possibly others are going to complain about timestamps in the future. An attacker would have to create an evil mirror and an evil NTP server, hope that some admin uses both his evil mirror and his evil NTP server (not that unlikely if the evil mirror and NTP server are geographically closer to the target) and hope that the admin doesn't notice a lot of clues that something is going on. It's one more problem an attacker would have to deal with. You'd have to fetch the root metadata from a trusted server over something like HTTPS (that is, something with authentication and a challange-response component built in). That's a good solution, but, as mentioned before, that would generate a lot of false positives. Mirrors only synchronize every X hours. If you happened to download the root metadata from the trusted server before the mirror catched up, you'd be told the mirror is stale when in fact it's perfectly healthy. Perhaps the trusted server could serve the root metadata mentioning packages available from time() - X hours before through time(), where X is the maximum delay between a mirror and the master servers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin-ubsfoitistapvqgnwgumo74vjuqby2psp...@mail.gmail.com
Re: A Look In the Mirror: Attacks on Package Managers
On Sun, Jun 6, 2010 at 1:34 PM, David Kalnischkies kalnischkies+deb...@gmail.com wrote: In regards to APT i will have a look later how to implement it, hints regarding a good error message are welcomed as i can currently only thing about stuff like: W: http://debian.example.org squeeze Release: The Validation date for the archive has expired. (This can indicate an outdated mirror.) I'd suggest that the warning message informed how many days behind the server is. Some sort of tolerance setting should also be implemented for the corner cases. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim59hnphxfwmrrs7phxhcdly9ewfjws7q1ti...@mail.gmail.com
Re: pid file security
On Sat, Jun 5, 2010 at 7:59 AM, Luke Kenneth Casson Leighton luke.leigh...@gmail.com wrote: okaaay, riight. so. ah ha. it makes things quicker... by avoiding starting the services _entirely_ :) It goes beyond that. Instead of program A depending on B being done initializing so that it can connect to B's socket, for example, A can be initialized right away and it'll block when it needs to use B's socket until B is done initializing. This is faster because A and B can be started at the same time even though A depends on something provided by B. second: assuming that systemd is _only_ capable of starting up services [as an inetd replacement] via redirecting stdin/stdout to TCP/UDP/other sockets, that still places depinit as being more capable than systemd because you have the option, in depinit, of: * running a service unmonitored i.e. a la sysv init * running a services foreground-connected i.e. auto-restarted etc. Well, systemd does have sysv-like compatibility (in fact it even parses LSB headers and starts sysv scripts in parallel, unlike upstart). I believe that in that mode it does not monitor the processes, but I'm not sure. Now regarding auto-restarting services as they fail, I believe that's at least planned. Since systemd can monitor services with ease, my guess is that auto-restarting shouldn't be a big deal. I'm quite excited about systemd, I think the potential is there. Most mainstream distros have already commited to upstart though, so I can see why it could fail despite looking like a great alternative. Another major issue is lack of cross-platform support, as it depends on Linux specifics such as cgroups, and this is a big drawback for Debian as we have Hurd and kFreeBSD... More info on systemd in this lengthy blog post: http://0pointer.de/blog/projects/systemd.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim-lsngdcjqj8tqulxz7rd4dlu66dvq6kcyg...@mail.gmail.com
Re: A Look In the Mirror: Attacks on Package Managers
On Sun, Jun 6, 2010 at 1:37 AM, Michael Gilbert michael.s.gilb...@gmail.com wrote: All of the issues raised in this paper can be mitigated by a proactive user. Malicious mirror activity can be detected by paying attention to debsecan and the security tracker [0]. debsecan displays all known vulnerable packages on a particular system, and the security tracker displays all known vulnerable packages. Differences between the two for a period longer than about a week would be a sign that the mirror is intentionally holding back vulnerable packages. Of course the major flaw with this statement is that there aren't a whole these proactive users. However, if there are enough, some will spot the activity, and raise concern, which will ultimately protect others when the evil mirror is shut down. Agreed. I'd like to point out that since we sign root metadata, it's impossible to keep some packages outdated (say, daemons facing the internet) while others are up-to-date. What this means is that a replay or freeze attack is very unlikely to go unnoticed. Lots of packages being downgraded, no updates for too long, things like that stand out. If an admin doesn't notice that, I find it unlikely that he or she will notice a stale mirror warning either. Moreover, as people have said already, stable is safe because security updates come directly from security.debian.org, not from mirrors. The remaining issues I see are: 1. Man-in-the-middle attacks between clients and security update servers 2. Denial-of-service attacks to the security updates infrastructure 3. No trusted servers for security updates for testing and unstable Using HTTPS for the security update infrastructure could solve #1, but not much can be done about #2 (though such an attack would be Hollywood-esque in scale). Now if we had a timestamp in the root metadata updated on a daily basis, that would solve #1 and #3 (or anything else related to replay attacks), and it doesn't sound too hard to implement (of course, talk is cheap). #2 is not quite under our control. Another idea would be actively comparing mirrors to make sure evil or dead mirrors are removed from our list of mirrors (if that isn't the case already). Not much can be done if the end user isn't being notified, though. Coupled to that, maybe some sort of PKI could make it possible to revoke the hability of the mirror to advertise itself as a trusted, up-to-date mirror. The bottomline seems to be that stable is safe enough, whereas if you use something else you're on your own as usual, but I believe we can improve this situation. I'm neither a security guy nor a Debian infrastructure guy, so please take my words with a grain of salt. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin08k1oam2-qbnqqmununf6_fvmx6-_7mjyg...@mail.gmail.com
Re: Archive area for clamz (Amazon MP3 downloader)
On Mon, May 31, 2010 at 5:24 AM, Philipp Kern tr...@philkern.de wrote: On 2010-05-30, brian m. carlson sand...@crustytoothpaste.ath.cx wrote: The difference is that those tools provide a reasonable level of functionality with free data. Weather information is in the public domain because there's no originality to it. Most programs that display lyrics or album covers are music players, and there is free music (available in our archive, no less) that they can usefully play. Console emulators like zsnes are in main, I think because there used to be at least one free ROM it can be used with (be it useful or not). xmame-sdl is in contrib, though. I find it hard to draw the line between main and contrib unless there's non-free depends, it's all very subjective. Regards, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimraphv1jxbh4zkycsdx5wxjopohcv-oy7cp...@mail.gmail.com
