Dell Latitude Nvidia problems Re: Re: Re: Re: major linux problems summary 2012
I have the same card and I can tell you that the nouveau driver is broken with it. See the bug mentioned above: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640464 According to point 6 of http://nouveau.freedesktop.org/wiki/TroubleShooting do you tried building nouveau from the latest sources? Maybe this is a idea or secondly request bug report directly to freedesktop. Yesterday for example I tried and filled a bug report: https://bugs.freedesktop.org/show_bug.cgi?id=57081 Regards, KarolSzk. -- 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/50a34bfa.2020...@mikronika.com.pl
Re: Gentoo guys starting a fork of udev
On 11/14/2012 11:25 AM, Michael Biebl wrote: > So far this seems to be mostly talk and hot air. It's clearly going to take some time to materialize into a more definitive project, however, I don't think that's fair to say it's only "talk and hot air" as I saw some Gentoo patches to uncruft udev already. Though the thread I gave link to doesn't show that at all. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50a352f4.6010...@debian.org
Bug#693198: ITP: ec2debian-build-ami is a bunch of scripts which creates Debian images for use in clouds.
Package: wnpp Severity: wishlist Owner: "Marcin Kulisz (kuLa)" * Package name: ec2debian-build-ami Version : b72146d3git Upstream Author : Eric Hammond and Anders Ingemann * URL : https://github.com/andsens/ec2debian-build-ami * License : (AL-2.0) Programming Lang: (Shell) Description : ec2debian-build-ami is a bunch of scripts which creates Debian images for use in clouds. ec2debian-build-ami is a bunch of scripts which creates a vanilla debian squeeze machine images for use in clouds. no latent logfiles no bash history or even apt package cache. This software creates fully operational images for Amazons EC2. Those images suppose to work on OpenStack as well as on other cloud solutions which are sharing API with the previous 2. This tool is utilising euca2ools. -- 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/20121114082243.16286.15219.report...@bashton004.bashton.com
Re: Bug#693040: libav: Strange build failure on several archs
Am 13.11.2012 16:45, schrieb Reinhard Tartler: The problem is upstream and has been identified now. Reverting upstream commit 468ea9d5b14f92fe61f47f034e67066f65163f5f seems to fix the issue, albeit a better solution is currently being worked on. Good to know that you've succeeded to narrow down the problem. But how could it ever build on the other archs if the symbol in question isn't exported anymore, why does it only break on selected archs? - Fabian -- 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/50a35687.1020...@greffrath.com
Re: Bug#693040: libav: Strange build failure on several archs
On Wed, Nov 14, 2012 at 9:29 AM, Fabian Greffrath wrote: > Am 13.11.2012 16:45, schrieb Reinhard Tartler: > >> The problem is upstream and has been identified now. Reverting >> upstream commit 468ea9d5b14f92fe61f47f034e67066f65163f5f seems to fix >> the issue, albeit a better solution is currently being worked on. > > > Good to know that you've succeeded to narrow down the problem. But how could > it ever build on the other archs if the symbol in question isn't exported > anymore, why does it only break on selected archs? Because those are the archs that do not have special ASM variants of the log2 implementation but fall back to the C variant. The C variant tries to access the ff_log2_tab symbol, to which the access is hidden. The proper patch to solve this is: http://patches.libav.org/patch/30530/ -- regards, Reinhard -- 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/CAJ0cceaZn7-BYyrDaVf7mV0=BTgu=73aubjfnusdab_xxmx...@mail.gmail.com
Re: Gentoo guys starting a fork of udev
also sprach Thomas Goirand [2012.11.14.0412 +0100]: > As Gentoo guys and some major kernel people are protesting about the > insanity Kay and Lennart have done to udev, I cannot help but notice that Kay and Lennart were both Gentoo-freaks when they took on udev and at least I always attributed much of what was wrong with udev from the start (e.g. the configuration file format) to being born in an environment where people still compile from source. ;) -- .''`. martin f. krafft Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems "convictions are more dangerous enemies of truth than lies." - friedrich nietzsche digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#693215: ITP: bustle -- D-Bus activity visualiser
Package: wnpp Severity: wishlist Owner: Hector Oron * Package name: bustle Version : 0.4.1 Upstream Author : Will Thompson * URL : http://www.willthompson.co.uk/bustle/ * License : LGPL-2.1+ and GPL-2+ Programming Lang: Haskell/C Description : D-Bus activity visualiser Bustle is a tool to chart and provide timing information of D-Bus calls for profiling and debugging purposes. It is intended to replace reading the cryptic output of dbus-monitor. Calls are displayed using Message Sequence Charts, a succinct way of representing entities and interactions over time. It can also output data in Graphviz format. This package contains the graphical visualizer for traces generated with the bustle-pcap tool. -- 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/20121114105836.30368.39676.report...@polynomio.collabora.co.uk
Re: A common configuration format, anyone?
On 14/11/12 06:48, Chow Loong Jin wrote: On 14/11/2012 13:43, Philip Ashmore wrote: Hi there. As someone who develops software for Debian I encounter situations where I have to specify the same information multiple times, and when that information changes I have to remember to update it in each of these places. Just now I had to add a debian/*doc.postrm.in to one of my projects. Makefile.am - save the *in file in EXTRA_DIST configure.ac - convert the *.in to a *. Why are you generating debian/* files from within the upstream build system? That's just wrong. Packaging is packaging. Upstream matter is upstream matter. Also, you don't need to add the file into EXTRA_DIST if you've already added it using AC_CONFIG_FILES -- autotools does that automatically. Now that's the kind of thing that semantic validation/constraints that I'm talking about. If Debian had a wizard where you could go to "add pre-processing file" it would eliminate such typos. Git - add to version control. Ack. makefile - new version If you generate your upstream tarball with autogen/make dist, you should never have this issue. The build system I've developed has a top-level "makefile" that stores the version, short and long descriptions. It's easy to communicate using terms one is familiar with and forget about transposition and assumed knowledge. NEWS - what's changed ChangeLog - what's changed Autogenerate this from git log. Some upstreams don't bother with this, even. I must look into this sometime. Glad to know. Git - store the changes Ack. As you can see, you're uselessly repeating steps that can already be automatically done today, in addition to doing it just plain wrong (re: Makefile.am/configure.ac) [...] That aside, I have nfc how to interpret your proposed text file thing, but GNOME has something similar, called DOAP files[1], which albeit in XML format, are more readable than yours. It's a simple format which, like xml, is human-readable but that's just a plus - us humans prefer to interact with the content efficiently rather than be bogged down in the representation. I plan to use the format to allow more expressive graphical representations to be developed. Plus, the binary form can be transformed using the "sbd" tool/example packaged with v3c-storyboard, but these are all baby steps to being able to develop interfaces with it that can interact with the "real world" and transform content - including (different versions of) themselves. This format can be interpreted using libffi to define closures - interpreted functions, as the sb/tests/hello-world4-test program shows. Then those functions can be transformed into executable code using LLVM as the hello-world3-test program shows, so I hope it will be easier to do rapid prototyping with than html5/JavaScript, because you use one visual representation to modify something elses visual representation, which could be anything. (And finally, like Ben said, please don't ask anyone to package anything in this format.) [1] https://live.gnome.org/MaintainersCorner#maintainers I wasn't thinking of asking anyone to package software in this format - sorry if I gave that impression. The packaging tools used by Debian and others have a steep learning curve because their representation isn't human-friendly - it's all for the convenience of a build system dating back to UNIX. I'm talking about a graphical interface that generates these files so that developers never have to look at them. In my opinion anything written in (ba)sh or m4 is just asking for a typo to do the unexpected, which is a fundamental flaw of textual representation. My goal is to narrow the grand canyon of a gap between how graphical interfaces do such a great job of hiding the details, to the way we develop them, which is all about the details. Whether I achieve anything like that is another matter, but I don't see any huge obstacles in my way. The idea is to have a Debian/Fedora/AnOther "portal" where you're basically hand-held at every step in the process if doing whatever you want to, from system configuration to developing packages. The other approach, the one that was there since before GUIs, is the mailing list. Regards, Philip Ashmore -- 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/50a38000.5010...@philipashmore.com
Re: A common configuration format, anyone?
2012/11/14 Philip Ashmore > simple format which, like xml, is human-readable XML is not human-readable :-)
Re: cross-build-essential
+++ Wookey [2012-06-27 20:04 +0100]: > +++ Wookey [2012-01-19 14:32 +]: > > +++ Neil Williams [2012-01-19 13:02 +]: > > > On Thu, 19 Jan 2012 12:10:28 + > > > Wookey wrote: > > > > > > > I've thought for a long time that a package like build-essential for > > > > cross-building would be a really good idea. > > > > > > +1 > > > > > > It should probably depend on build-essential itself as a starting point. > > > > I suppose so. You won't get far without that. > > OK, there has been progress in this area. Thanks to Patrick McDermmot > (GSOC student) we have a patch to add support to build-essential for a > crossbuild-essential- packages. > > http://odin1.pehjota.net/~pj/debian-bootstrap/build-essential/ I've now munged this a fair amount to actually work, and tested it on the arm64 bootstrap as well as some armel and armhf builds. It all works rather nicely. I've filed a bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693220 to try and reach a conclusion on the matter of having one source pakcage that produce the build-essential and crossbuild-essential- packages. Or having this done as a separate source package. It was designed to be merged, but the version in the repo has the native bits commented out so is effectively a separate (but rather similar) source package: http://people.debian.org/~wookey/bootstrap/ubunturepo/pool/main/c/cross-build-essential/ (the testing has been done in Ubuntu as the toolchains are already in-archive, so it would need a few package-name changes for Debian, which I expect to get to soon - that makes no difference to the architectural question). Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20121114121510.gy24...@stoneboat.aleph1.co.uk
Re: Gentoo guys starting a fork of udev
On 11/14/12 18:37, martin f krafft wrote: > also sprach Thomas Goirand [2012.11.14.0412 +0100]: >> As Gentoo guys and some major kernel people are protesting about the >> insanity Kay and Lennart have done to udev, > > I cannot help but notice that Kay and Lennart were both > Gentoo-freaks when they took on udev You make my head hurt. These guys are throwing mud at Gentoo at any chance they get, how on earth did you get an impression that they'd consider Gentoo to be more than a kinky toy for bored kiddies? > and at least I always > attributed much of what was wrong with udev from the start (e.g. the > configuration file format) to being born in an environment where > people still compile from source. ;) > And you compile from what? ;) But anyway, we're getting tired of their ADHD-driven changes just to change things - maybe we can build up enough momentum so that things might just be less frustrating for us all. You're all welcome to join, ignore us or do what you want. Have a nice day, Patrick -- 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/50a3a153.2000...@gentoo.org
Re: Gentoo guys starting a fork of udev
On 11/14/12 19:53, Matthias Klumpp wrote: > What are the problems they try to address? Removal of features, broken build system, etc. Just the little things that make things exciting (and we prefer things to be boring so we can sleep at night) Plus an unpredictable upstream that can't be trusted anymore. (See recent rants by kernel people about udev breaking firmware loading completely because LOL FASTOR) > The strong binding to > systemd is good and makes much sense to me, If you wanted to use systemd maybe. But since we don't want it it's a strong negative point > and udev is still usable > without systemd (and will be in the future). It's slowly losing features or getting broken in funny ways because upstream wants you to migrate into the exciting future. It's becoming more and more troublesome, and we don't know what they'll change next just because they can > Also, both systemd and udev are Linux-only, so the situation here at > Debian hasn't changed. > The problems we had in the past with bad udev+kernel combinations and > changing config file format etc. can also be addressed in udev, > without the need of forking. Most of the issues we've had since the merge have been declared features by upstream. Discussing with them appears to be futile. > In general, I think a fork of udev would do much more harm than trying > to solve the problems in udev. Of course, they're free to fork, but > the separation will hurt both projects and everything relying on > udev/the fork. An API-compatible fork should not cause any problems. Since we cannot cooperate with upstream I don't see any other way forward. I do agree that it's "stupid" - would be nice if we could work together etc. etc. > Regards, >Matthias -- 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/50a3a387.4020...@gentoo.org
Re: Gentoo guys starting a fork of udev
On Wed, Nov 14, 2012 at 09:49:07PM +0800, Patrick Lauer wrote: > But anyway, we're getting tired of their ADHD-driven changes just to > change things TBH, I'm getting tired of people who are constantly shooting against them because these people are unwilling to accept changes. We're not bringing Linux forward if we stick to 30-year-old concepts. systemd is a good design and most people actually agree otherwise it wouldn't become standard on so many distributions (except Ubuntu, but that's rather a political decision IMHO). One of the Arch developers actually made a couple of good points why they switched to systemd as default [1]. Cheers, Adrian > [1] https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 -- 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/20121114140435.gb28...@physik.fu-berlin.de
Re: Gentoo guys starting a fork of udev
On 11/14/2012 09:04 AM, John Paul Adrian Glaubitz wrote: On Wed, Nov 14, 2012 at 09:49:07PM +0800, Patrick Lauer wrote: But anyway, we're getting tired of their ADHD-driven changes just to change things TBH, I'm getting tired of people who are constantly shooting against them because these people are unwilling to accept changes. We're not bringing Linux forward if we stick to 30-year-old concepts. While I think I recognize the idea behind this, and it's one I don't necessarily entirely disagree with, this sentiment just seems wrong to me. True, if people are unwilling to accept change for the simple reason that it *is* change, that's a bad thing. But why is a 30-year-old concept necessarily worse than a new one? Or to put it another way, why is it necessary to "bring Linux forward", in cases where what is already present is good and works well? (And, taken further: in cases where what is already there *isn't* good and/or *doesn't* work well, why is it necessary to accept change *in a particular direction*, if that direction has problems of its own?) I've run across a few software projects where it has seemed as if the developers were adding new features and removing old ones and changing UIs not because there was something wrong with the old, but apparently just because "we're the developers, we have to make changes or we're not developing it" - because they seemed to think that letting a program sit unchanged is automatically a bad thing, no matter how close to perfect-for-its-purpose the program may already have been. Change is not always bad; in fact, it's very often good. But change isn't always good either, and refusal of change isn't always simple obstinacy or stagnation. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- 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/50a3a895.6090...@fastmail.fm
Re: Gentoo guys starting a fork of udev
On 11/14/12 22:04, John Paul Adrian Glaubitz wrote: > On Wed, Nov 14, 2012 at 09:49:07PM +0800, Patrick Lauer wrote: >> But anyway, we're getting tired of their ADHD-driven changes just to >> change things > > TBH, I'm getting tired of people who are constantly shooting against > them because these people are unwilling to accept changes. We're not > bringing Linux forward if we stick to 30-year-old concepts. Y'know ... I like progress. There's some pretty nice new things that are an actual improvement, like GPT. At last more than 4 partitions (and no longer compatible to MS-DOS 3.3) ... But then there's for example UEFI (which I've never seen working as suggested by documentation), grub2 (should be called "blinky cursor app"), then the random changes to udev that make it unable to load firmware, moving things around (well, no script hardcodes /sbin/ip, right?) just for fun ... I'm tired of these changes that don't solve any problems. Half-baked stuff that is deployed before it is even feature-complete with the boring old stuff it is supposed to replace. How would you feel about a forced upgrade of apt to yum? After all newer is better ... > systemd is a good > design and most people actually agree otherwise it wouldn't become > standard on so many distributions (except Ubuntu, but that's rather a > political decision IMHO). It does have some good ideas, and it is better than the random bits of unmaintained shell it replaces - but it's mediocre at best. No real design, just things nailed together with screws and secured with tape. I'm waiting for the one that comes to replace it :) > One of the Arch developers actually made a couple of good points why > they switched to systemd as default [1]. > Their users really appreciate it, especially those that are now migrating to other distros because they preferred their OS when it was booting as intended. -- 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/50a3aa92.1060...@gentoo.org
Re: Gentoo guys starting a fork of udev
On Wed, Nov 14, 2012 at 09:20:05AM -0500, The Wanderer wrote: > But why is a 30-year-old concept necessarily worse than a new one? Or to put > it > another way, why is it necessary to "bring Linux forward", in cases where what > is already present is good and works well? (And, taken further: in cases where > what is already there *isn't* good and/or *doesn't* work well, why is it > necessary to accept change *in a particular direction*, if that direction has > problems of its own?) Because System V Init isn't a good concept. It fails in so many regards. There is no standardized way for init scripts, it cannot make sure processes actually run and restart them on demand. It also lacks mechanisms for ressource control and figuring out dependencies between service without hardcoding them. It's just a dirty hack. System V Init was good 20 years ago, but it isn't nowadays. Automatic dependencies, process watchdogs and ressource control are something which is incredibly useful to have nowadays, especially on big machines which are shared among many users (clusters, for example). > I've run across a few software projects where it has seemed as if the > developers > were adding new features and removing old ones and changing UIs not because > there was something wrong with the old, but apparently just because "we're the > developers, we have to make changes or we're not developing it" - because they > seemed to think that letting a program sit unchanged is automatically a bad > thing, no matter how close to perfect-for-its-purpose the program may already > have been. True, but as I said, System V Init is not a good concept anymore, that's why it's being dropped. Apple dropped the old init system with MacOS X 10.4, why should the Linux world still stick to it in 2012? Adrian -- 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/20121114143721.ge28...@physik.fu-berlin.de
Re: Gentoo guys starting a fork of udev
On Wed, Nov 14, 2012 at 10:28:34PM +0800, Patrick Lauer wrote: > I'm tired of these changes that don't solve any problems. Half-baked > stuff that is deployed before it is even feature-complete with the > boring old stuff it is supposed to replace. How would you feel about a > forced upgrade of apt to yum? After all newer is better ... Comparing apples and oranges here. You cannot "upgrade" apt to yum because yum is feature-wise very much comparable to apt. systemd, OTOH, brings many new useful features you simply can't have with any other init system. Period. > > > systemd is a good > > design and most people actually agree otherwise it wouldn't become > > standard on so many distributions (except Ubuntu, but that's rather a > > political decision IMHO). > It does have some good ideas, and it is better than the random bits of > unmaintained shell it replaces - but it's mediocre at best. No real > design, just things nailed together with screws and secured with tape. Which just shows that you probably never seriously dug into systemd. systemd has a very sensible and mature concept as opposed to the very hacky System V Init where every distribution has to provide their *own* init scripts (which clearly shows there is no concept) and lots of modern functionatity is simply missing. > > One of the Arch developers actually made a couple of good points why > > they switched to systemd as default [1]. > > > Their users really appreciate it, especially those that are now > migrating to other distros because they preferred their OS when it was > booting as intended. Stating from the thread in the Arch forums which I have posted, I would say that this is simply untrue. People aren't going away from Arch because of systemd. There are some who are unhappy with it, sure, but most Arch users support the systemd switch or simply don't care because they only want their init system to be fast and reliable which truly is what systemd provides. Adrian -- 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/20121114144509.gf28...@physik.fu-berlin.de
Re: A common configuration format, anyone?
Am Mittwoch, den 14.11.2012, 15:32 +0400 schrieb Игорь Пашев: > > > 2012/11/14 Philip Ashmore > simple format which, like xml, is human-readable > > > XML is not human-readable :-) XML is human-readable, but in most cases ugly to write. IMO XML is not human-writable. -- Benjamin Drung Debian & Ubuntu Developer -- 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/1352907081.2868.1.camel@deep-thought
Re: Gentoo guys starting a fork of udev
On 11/14/2012 07:53 PM, Matthias Klumpp wrote: > What are the problems they try to address? Haven't you read this? https://lkml.org/lkml/2012/10/2/505 Plus the unwanted move from / to /usr, insane configuration file things not using /etc, and more RedHat-ismes which have been discussed at large in this list (let's not restart such thread). > The strong binding to > systemd is good and makes much sense to me, and udev is still usable > without systemd (and will be in the future). As they merged, it becomes less and less the case. You're seeing fixes patching udev to rename it systemd-udev, which really, is more advertizing / marketing than anything, but it shows what kind of direction its taking. To me, it looks like udev authors are forcing this so you have no choice but to use systemd. > Also, both systemd and udev are Linux-only, so the situation here at > Debian hasn't changed. Let's say that we choose another implementation of init (let's say, upstart or OpenRC, or even keep our old sysv-rc), then having systemd bound to udev and udev bound to systemd will not make things easy for us. > The problems we had in the past with bad udev+kernel combinations and > changing config file format etc. can also be addressed in udev, > without the need of forking. > In general, I think a fork of udev would do much more harm than trying > to solve the problems in udev. In an ideal world, yes. But when the development goes wild, and upstream doesn't listen to others or refuses patches, what kind of alternative do you have? > Of course, they're free to fork, but > the separation will hurt both projects and everything relying on > udev/the fork. That is correct, but the pain is already there with the new versions of udev, and its likely it wont change back. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50a3c10d.3010...@debian.org
Re: Gentoo guys starting a fork of udev
On Wed, Nov 14, 2012 at 03:04:35PM +0100, John Paul Adrian Glaubitz wrote: > On Wed, Nov 14, 2012 at 09:49:07PM +0800, Patrick Lauer wrote: > > But anyway, we're getting tired of their ADHD-driven changes just to > > change things > > TBH, I'm getting tired of people who are constantly shooting against > them because these people are unwilling to accept changes. We're not > bringing Linux forward if we stick to 30-year-old concepts. systemd is a good > design and most people actually agree otherwise it wouldn't become > standard on so many distributions (except Ubuntu, but that's rather a > political decision IMHO). systemd does have some good design features. It also has some bad ones. It's not as black and white as some people have claimed. If you want a reliable system, you need a reliable PID 1. Putting additional complexity into PID1 increases the likelihood that a bug will bring down your *entire system*. PID 1 is a single point of failure. It *must* be absolutely dependable and reliable. Upstart is also AFAIK at fault here. sysvinit is fairly minimal, but even it could be simplified further. Other init systems (e.g. s6)[1] take that even further so that at any point in time, PID1 is running an image dedicated to the current system state, e.g. booting, running, shutting down, and it will exec() a new image to initiate a state change. When running normally, PID 1 should do nothing except to reap zombies, and switch to shutdown. Everything else can be done in a separate process started by PID 1. In the case of sysvinit, runlevel changes are delegated to /etc/init.d/rc. This could be sysv-rc, openrc, or some other program. If that program fails, init will carry on running. That's not to say that systemd doesn't do a better job of resolving dependencies and service management. It does. But. It's introduced a single point of failure by putting all that into a single process, running as PID 1. That complexity should not be in PID1, it should be a separate process. There's no intrinsic need for it to be there. We've contained the damage should there be a failure by keeping things separate. >From a technical POV of how it resolves dependencies and manages services, systemd should be better. But from the POV of the system stability and reliability as a whole... that's much harder to quantify and much less clear cut. After all, if sysvinit is working for you, and starts up all the services correctly, once the system is up, it's up. It will continue to run reliably. Regards, Roger [1] http://www.skarnet.org/software/s6/ -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20121114160512.gk...@codelibre.net
Re: A common configuration format, anyone?
On Wednesday 14 November 2012 12:26:56 Philip Ashmore wrote: > The packaging tools used by Debian and others have a steep learning > curve because their representation isn't human-friendly - it's all for > the convenience of a build system dating back to UNIX. > > I'm talking about a graphical interface that generates these files so > that developers never have to look at them. Hmm, that sounds like 'cme edit dpkg' (provided by libconfig-model-dpkg-perl). For more details, see [1]. HTH [1] https://github.com/dod38fr/config-model/wiki/Using-config-model#wiki-Debian_packaging -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- 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/201211141752.42276@debian.org
Re: Bug#656858: libimage-exiftool-perl: new upstream version available
On Tuesday 13 November 2012 12:12:14 random.numb...@gmx.com wrote: > libimage-exiftool-perl got its last update in July 2011. ... > Mari's last reaction to this bug was five months ago. This package could be also maintained by Debian-perl team. Mari, do you have any objection if Debian-perl team adopt libimage-exif-perl ? Note that you are more than welcome to join the team if you want to participate in maintaining this package when you have more free time. All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- 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/201211141744.43649@debian.org
Re: Gentoo guys starting a fork of udev
On Nov 14, 2012, at 5:05 PM, Roger Leigh wrote: > On Wed, Nov 14, 2012 at 03:04:35PM +0100, John Paul Adrian Glaubitz wrote: >> On Wed, Nov 14, 2012 at 09:49:07PM +0800, Patrick Lauer wrote: >>> But anyway, we're getting tired of their ADHD-driven changes just to >>> change things >> >> TBH, I'm getting tired of people who are constantly shooting against >> them because these people are unwilling to accept changes. We're not >> bringing Linux forward if we stick to 30-year-old concepts. systemd is a good >> design and most people actually agree otherwise it wouldn't become >> standard on so many distributions (except Ubuntu, but that's rather a >> political decision IMHO). > > systemd does have some good design features. It also has some bad > ones. It's not as black and white as some people have claimed. > > If you want a reliable system, you need a reliable PID 1. Putting > additional complexity into PID1 increases the likelihood that a > bug will bring down your *entire system*. PID 1 is a single point > of failure. It *must* be absolutely dependable and reliable. > Upstart is also AFAIK at fault here. Sticking to the same logic, we should pull out all functionality out of the Linux kernel and use a micro kernel. Modern computer systems are much more versatile and complex than they were at the time when System V Init was conceived. You need a certain complexity if you want a certain functionality. I don't want to reboot my computer when changing my network connection, add or remove new hardware like disks or input devices. And I don't want to mess around with configuration files when I want to redirect the audio output of VLC from the internal laptop speakers to an bluetooth or AirPlay. The reason why Linux has become so successful is because users don't have to mess with tools like isaconf and pnpdump anymore to configure their Soundblaster sound card or edit the interfaces or hosts file to change their IP address. I honestly think that people who are fighting modern software like systemd, pulse-audio or udev are simply fearing that their expertise in hacking configuration files in order to get things working are no longer needed anymore. They fear that the average joe can install and set up a Linux box without their help. When I started using Linux in 1998, I would have never thought that I'd be installing it onto my mother's laptop almost 15 years later as the sole operating system and she'd be happily using it with nearly zero support from my side. This would have never been possible without all these little modern helpers that we have nowadays. If some advanced users want to stick to the traditional Unix way, they're free to use distributions like Gentoo or use any of the BSDs. But I honestly ask them to stop spreading FUD about how software like systemd or Pulse-Audio is hurting Linux and free software, because Linux wouldn't be there where it is nowadays without these developments. Adrian -- 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/0277b04f-40fa-4ae1-b3d0-fe08b0e0e...@physik.fu-berlin.de
Re: Gentoo guys starting a fork of udev
On Wed, Nov 14, 2012 at 06:26:39PM +0100, John Paul Adrian Glaubitz wrote: > > If you want a reliable system, you need a reliable PID 1. Putting > > additional complexity into PID1 increases the likelihood that a > > bug will bring down your *entire system*. PID 1 is a single point > > of failure. It *must* be absolutely dependable and reliable. > > Upstart is also AFAIK at fault here. > > Sticking to the same logic, we should pull out all functionality out of the > Linux kernel and use a micro kernel. > > Modern computer systems are much more versatile and complex than they were at > the time when System V Init was conceived. Some things must be as simple as possible even today. > I honestly think that people who are fighting modern software like systemd, > pulse-audio or udev are simply fearing that their expertise in hacking > configuration files in order to get things working are no longer needed > anymore. They fear that the average joe can install and set up a Linux box > without their help. May be init today should has some new features, but systemd is not such new init. systemd is a wrong way. See plan9 for a good design examples. -- 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/20121114174237.GA31202@localhost
Re: Gentoo guys starting a fork of udev
On 11/14/2012 10:37 PM, John Paul Adrian Glaubitz wrote: > True, but as I said, System V Init is not a good concept anymore, > that's why it's being dropped. Apple dropped the old init system with > MacOS X 10.4, why should the Linux world still stick to it in 2012? Could we try not to mix the init system debate with the udev brokenness one? Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50a3ddb2.1000...@debian.org
Re: Gentoo guys starting a fork of udev
On Nov 14, 2012, at 7:06 PM, Thomas Goirand wrote: > On 11/14/2012 10:37 PM, John Paul Adrian Glaubitz wrote: >> True, but as I said, System V Init is not a good concept anymore, >> that's why it's being dropped. Apple dropped the old init system with >> MacOS X 10.4, why should the Linux world still stick to it in 2012? > Could we try not to mix the init system debate with > the udev brokenness one? udev isn't broken. The only reason why you think udev is broken is because you don't want to use the way it is intended to be used and now you're looking for people to jump the band wagon. I could start the same discussion regarding other software packages not being compatible with certain platforms: "I want to use $DAEMON on $KERNEL, so please do something, upstream!" Adrian -- 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/50ffb4fe-0a85-43f5-a933-a5bb091e0...@physik.fu-berlin.de
Re: Gentoo guys starting a fork of udev
On 11/15/2012 01:26 AM, John Paul Adrian Glaubitz wrote: > On Nov 14, 2012, at 5:05 PM, Roger Leigh wrote: > >> On Wed, Nov 14, 2012 at 03:04:35PM +0100, John Paul Adrian Glaubitz wrote: >>> On Wed, Nov 14, 2012 at 09:49:07PM +0800, Patrick Lauer wrote: But anyway, we're getting tired of their ADHD-driven changes just to change things >>> TBH, I'm getting tired of people who are constantly shooting against >>> them because these people are unwilling to accept changes. We're not >>> bringing Linux forward if we stick to 30-year-old concepts. systemd is a >>> good >>> design and most people actually agree otherwise it wouldn't become >>> standard on so many distributions (except Ubuntu, but that's rather a >>> political decision IMHO). >> systemd does have some good design features. It also has some bad >> ones. It's not as black and white as some people have claimed. >> >> If you want a reliable system, you need a reliable PID 1. Putting >> additional complexity into PID1 increases the likelihood that a >> bug will bring down your *entire system*. PID 1 is a single point >> of failure. It *must* be absolutely dependable and reliable. >> Upstart is also AFAIK at fault here. > Sticking to the same logic, we should pull out all functionality out of the > Linux kernel and use a micro kernel. > > Modern computer systems are much more versatile and complex than they were at > the time when System V Init was conceived. > > You need a certain complexity if you want a certain functionality. I don't > want to reboot my computer when changing my network connection, add or remove > new hardware like disks or input devices. And I don't want to mess around > with configuration files when I want to redirect the audio output of VLC from > the internal laptop speakers to an bluetooth or AirPlay. > > The reason why Linux has become so successful is because users don't have to > mess with tools like isaconf and pnpdump anymore to configure their > Soundblaster sound card or edit the interfaces or hosts file to change their > IP address. > > I honestly think that people who are fighting modern software like systemd, > pulse-audio or udev are simply fearing that their expertise in hacking > configuration files in order to get things working are no longer needed > anymore. They fear that the average joe can install and set up a Linux box > without their help. > > When I started using Linux in 1998, I would have never thought that I'd be > installing it onto my mother's laptop almost 15 years later as the sole > operating system and she'd be happily using it with nearly zero support from > my side. This would have never been possible without all these little modern > helpers that we have nowadays. > > If some advanced users want to stick to the traditional Unix way, they're > free to use distributions like Gentoo or use any of the BSDs. But I honestly > ask them to stop spreading FUD about how software like systemd or Pulse-Audio > is hurting Linux and free software, because Linux wouldn't be there where it > is nowadays without these developments. > > Adrian > Hi Adrian, Roger talks about technical design and upstream author choices, with some I believe very valid points, and you're talking about features! This can't go anywhere. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50a3e07c.1020...@debian.org
Re: Gentoo guys starting a fork of udev
On 2012-11-14 15:16, John Paul Adrian Glaubitz wrote: On Nov 14, 2012, at 7:06 PM, Thomas Goirand wrote: On 11/14/2012 10:37 PM, John Paul Adrian Glaubitz wrote: True, but as I said, System V Init is not a good concept anymore, that's why it's being dropped. Apple dropped the old init system with MacOS X 10.4, why should the Linux world still stick to it in 2012? Could we try not to mix the init system debate with the udev brokenness one? udev isn't broken. really? https://bbs.archlinux.org/viewtopic.php?id=134012&p=1 but don't trust me https://lkml.org/lkml/2012/10/2/505 -- 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/973bc827353d2f58c3856ceaa79a0...@zumbi.com.ar
Re: Bug#656858: libimage-exiftool-perl: new upstream version available
About 10 days ago I sent an email to m...@qu.debian.org requesting that this package be orphaned. They suggested that I email the sponsor/co-maintainer, Petter Reinholdtsen, which I did, but I have so far had no response from him either. - Phil -- 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/98576e6d-5420-42ec-94bb-8936d5ca5...@owl.phy.queensu.ca
Re: Gentoo guys starting a fork of udev
Hi! On Wed, 2012-11-14 at 21:49:07 +0800, Patrick Lauer wrote: > But anyway, we're getting tired of their ADHD-driven changes just to > change things - maybe we can build up enough momentum so that things > might just be less frustrating for us all. You're all welcome to join, > ignore us or do what you want. Nice! I've had on my TODO (but TBH as a very low priority item), to look into something like this too, but I was thinking about taking FreeBSD's devd and trying to port it to other systems instead. In any case I'll keep an eye on this fork, and I'll gladly switch to it whenever it's available. You might want to contact the Ubuntu folks too, as I don't think they are planning on switching to systemd any time soon. thanks, guillem -- 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/20121114193801.ga31...@gaara.hadrons.org
Re: Gentoo guys starting a fork of udev
On Wed, Nov 14, 2012 at 03:04:35PM +0100, John Paul Adrian Glaubitz wrote: > On Wed, Nov 14, 2012 at 09:49:07PM +0800, Patrick Lauer wrote: > > But anyway, we're getting tired of their ADHD-driven changes just to > > change things > TBH, I'm getting tired of people who are constantly shooting against > them because these people are unwilling to accept changes. We're not > bringing Linux forward if we stick to 30-year-old concepts. systemd is a > good design and most people actually agree otherwise it wouldn't become > standard on so many distributions (except Ubuntu, but that's rather a > political decision IMHO). Pretty sure you have this backwards. The decision to implement upstart and use it in Ubuntu was a political one. The decision to NIH a dependency-based init system and then try to strongarm everyone into using it by breaking compatibility was the political one. BTW, if systemd is a good design, why does it rely so heavily on socket-based activation, which has fundamentally unmaintainable security? > One of the Arch developers actually made a couple of good points why > they switched to systemd as default [1]. I have spent too much time arguing against the perceived deficiencies of systemd (such as [...] "it was started by Lennart Poettering" [...]). I strongly believe that 1) all of these perceived deficiencies are not deficiencies, but are actually benefits [...] So I guess the Arch developers also have nothing but nice things to say about pulseaudio and avahi. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Candidates for removal from testing (2012-11-14)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, We are considering removing the following packages from testing as they have unfixed RC bugs filed against them. The packages can be found in the attached dd-list. The bugs that put them on this list can be found in the removals file (also attached) just above the package name. We have BCC'ed this email to @packages.debian.org for the relevant packages. The packages have been selected based on the following criteria: * The package had at least one RC bug without activity for the past 14 days. * If a bug is assigned to multiple packages, both packages will be affected. * The RC bug affects both unstable and testing. * The affected package does not have any reverse dependencies in testing. If the relevant RC bugs in the affected packages are not dealt with /before/ Wednesday the 22nd of Nov.[1], the packages will be removed from testing. Note that "dealt with" may also include downgrading a severity-inflated bug or fixing affected versions in the BTS. Please remember to file unblock bugs for packages fixed via uploads to unstable (and tpu bugs for requests to fix the package via a tpu upload). Should you need a bit more time than given, please do not hesitate to contact us. It is also easier for us if we can avoid having to reintroduce a removed package. We will check the DELAYED queues before activing the removal hints, so NMUs in the DELAYED queues will be given a chance to reach unstable. Thanks, Niels (on behalf of the Release Team) The bugs were found using the tools from: svn://svn.debian.org/svn/collab-qa/rc-buggy-leaf-packages http://release.debian.org/wheezy/freeze_policy.html [1] We intend to do the removal with the 10:00 UTC run of Britney of that day. --8<-- dd-list --8<-- Alexander Wirt ferm Cameron Dale apt-p2p Debian Sympa team sympa Emmanuel Bouthenot sympa (U) Jonas Smedegaard sympa (U) Jonathan Wiltshire mediawiki-math (U) Mediawiki Maintenance Team mediawiki-math Stefan Hornburg (Racke) sympa (U) --8<-- end of dd-list --8<-- --8<-- removals.txt --8<-- # #635969/#641732 remove apt-p2p/0.1.6 # #688377 remove ferm/2.1-2 # #689249 remove mediawiki-math/2:1.0+git20120528-5 # #686846 remove sympa/6.1.11~dfsg-4 --8<-- end of removals.txt --8<-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQo/9WAAoJEAVLu599gGRCYEwQAKgzvM4ZMKTKtQ39cAyDPfi4 y+z/oDVCEL3ES8MqEh7IuEQ7p0ZPvf9XlIrshCodOtPGZxQT4yhbFDsAQYURW1Jg 1YsuK53iQYhl+Wj/TQX5NBcKfA0xIqiM3dSEDPBtdxen5ZO1YWE3jxCA75T5mrrt YuNEt1PlftWGdTzqqXt8b8L6Ol6/CGk1cUaZJTbDqiwuTlplYsfOL+3Nyj2PallB MHgF8JnO3lAxnNSIbYTjdn8zhshDBsRBO3sgRoUcjxS/RJw9IPaaaU+RxuTjGc9X ZYN8gwlXuC0AJYkhZ/qbczig9t8Tk+OzIPI2TOJtXr1tJITOOFSPPNdjm5Tg7PJC HvyiYWxLsBzYx7fLBzMJf3FNv6o9N9EHNYDIvgmm/XQVHGcyt8aaNfqgbojEEr0U mNQrzxk2yXxsi+R3jiOYwBlapq6PIv+V+APtvmusQ0bvL9is5CZ8LuF5tZrpAe1j XrurYCdXHKL1tvAZ+GRECEmmFLvdO/kgmJJ2IdoJsTyabXXxNDXxJYBhJw6tNCOr hXYNwD5XnQD9/h0stvhHm+/k9gFHBO+UHj+Iu44E27VLHofRqKtlM008rqDVkPjx TjHVZ+FjnHRuvH+4hSxM18tsNc7xyY3yH/IthnLJKbyy5m+b992P/AFq15fQV08n pu/RtgutvHSDPm1v1Zkg =X/gb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121114210210.c22f13e...@thykier.net
Re: Gentoo guys starting a fork of udev
On Wed, Nov 14, 2012 at 12:47:11PM -0800, Steve Langasek wrote: > On Wed, Nov 14, 2012 at 03:04:35PM +0100, John Paul Adrian Glaubitz wrote: > > On Wed, Nov 14, 2012 at 09:49:07PM +0800, Patrick Lauer wrote: > > > But anyway, we're getting tired of their ADHD-driven changes just to > > > change things > > TBH, I'm getting tired of people who are constantly shooting against > > them because these people are unwilling to accept changes. We're not > > bringing Linux forward if we stick to 30-year-old concepts. systemd is a > > good design and most people actually agree otherwise it wouldn't become > > standard on so many distributions (except Ubuntu, but that's rather a > > political decision IMHO). > Pretty sure you have this backwards. The decision to implement upstart and > use it in Ubuntu was a political one. Haha, I mean technical. ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: A common configuration format, anyone?
On 14/11/12 16:52, Dominique Dumont wrote: On Wednesday 14 November 2012 12:26:56 Philip Ashmore wrote: The packaging tools used by Debian and others have a steep learning curve because their representation isn't human-friendly - it's all for the convenience of a build system dating back to UNIX. I'm talking about a graphical interface that generates these files so that developers never have to look at them. Hmm, that sounds like 'cme edit dpkg' (provided by libconfig-model-dpkg-perl). For more details, see [1]. HTH [1] https://github.com/dod38fr/config-model/wiki/Using-config-model#wiki-Debian_packaging Except that the system I'm working on could also implement the GIT api, the APT package database, and be controlled by a text user interface (TUI) as well as the command line or a GUI. Come to think of it, Debian does have a portal to all things Debian - the world wide web. Regards, Philip -- 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/50a40d7c.5040...@philipashmore.com
Re: Gentoo guys starting a fork of udev
On Nov 14, 2012, at 10:11 PM, Steve Langasek wrote: > On Wed, Nov 14, 2012 at 12:47:11PM -0800, Steve Langasek wrote: >> On Wed, Nov 14, 2012 at 03:04:35PM +0100, John Paul Adrian Glaubitz wrote: >>> On Wed, Nov 14, 2012 at 09:49:07PM +0800, Patrick Lauer wrote: But anyway, we're getting tired of their ADHD-driven changes just to change things > >>> TBH, I'm getting tired of people who are constantly shooting against >>> them because these people are unwilling to accept changes. We're not >>> bringing Linux forward if we stick to 30-year-old concepts. systemd is a >>> good design and most people actually agree otherwise it wouldn't become >>> standard on so many distributions (except Ubuntu, but that's rather a >>> political decision IMHO). > >> Pretty sure you have this backwards. The decision to implement upstart and >> use it in Ubuntu was a political one. > > Haha, I mean technical. ;) Haha, gotcha! :) Adrian -- 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/39499ac6-5c31-4541-bec4-e58e28a13...@physik.fu-berlin.de
Re: Gentoo guys starting a fork of udev
Steve Langasek wrote: > Pretty sure you have this backwards. The decision to implement upstart and > use it in Ubuntu was a technical [corrected] one. The decision to NIH a > dependency-based init system and then try to strongarm everyone into using > it by breaking compatibility was the political one. The decision to create upstart was a technical decision. However, upstart had design flaws, and so systemd was created to do better. This was also a technical decision. Do you seriously claim that it would have been possible to work within the existing upstart project to bring it to the level of current systemd? I find that totally implausible. Ubuntu still sticking to upstart is a political decision as far as I can see; there is no technical reason why it would be a better alternative even for their own use than systemd. > BTW, if systemd is a good design, why does it rely so heavily on > socket-based activation, which has fundamentally unmaintainable security? What exactly do you mean by this "fundamentally unmaintainable security" claim? -- 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/1352929546.1952.10.camel@glyph.nonexistent.invalid
Re: Gentoo guys starting a fork of udev
Hi! All these concerns about systemd and systemd vs. upstart have been addressed in a very good way by the systemd authors. Also, I would like to point out that "systemd" is the name of a project with multiple binaries - all the features systemd provides don't mean that everything is running in one process, in fact, systemd spawns some helpers on-demand for many actions. (However, the systemd core does more things than SysVInit, but as long as this code is tested and works well (and isn't changed that often) I have no concern) Also, systemd provides systemd-logind, an excellent way to get rid of ConsoleKit, which also makes it possible to have real multiseat support. And managing services using systemd is fantastic! :) But well, back to udev: I am not personally involved with the udev packaging, but has someone already talked to the people making the criticised decisions to explain themselves? I don't think ReadHat developers want to do any damage to these integral components, so I hardly think that there were no reasons for a change. Also, if these issues cannot be solved, would maintaining a small patchset for udev be an option? Cheers, Matthias 2012/11/14 Uoti Urpala : > Steve Langasek wrote: >> Pretty sure you have this backwards. The decision to implement upstart and >> use it in Ubuntu was a technical [corrected] one. The decision to NIH a >> dependency-based init system and then try to strongarm everyone into using >> it by breaking compatibility was the political one. > > The decision to create upstart was a technical decision. However, > upstart had design flaws, and so systemd was created to do better. This > was also a technical decision. Do you seriously claim that it would have > been possible to work within the existing upstart project to bring it to > the level of current systemd? I find that totally implausible. > > Ubuntu still sticking to upstart is a political decision as far as I can > see; there is no technical reason why it would be a better alternative > even for their own use than systemd. > > >> BTW, if systemd is a good design, why does it rely so heavily on >> socket-based activation, which has fundamentally unmaintainable security? > > What exactly do you mean by this "fundamentally unmaintainable security" > claim? > > > > -- > 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/1352929546.1952.10.camel@glyph.nonexistent.invalid > -- 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/CAKNHny9eocGg7xjYxo_duhihox=r60b_uf7tpwzg_b+xopj...@mail.gmail.com
Re: Gentoo guys starting a fork of udev
On Wed, Nov 14, 2012 at 03:41:55PM -0300, gustavo panizzo wrote: > >udev isn't broken. > > really? > > https://bbs.archlinux.org/viewtopic.php?id=134012&p=1 I actually remember having seen this issue on Fedora Rawhide as well, but it vanished after an update a few weeks ago, so it rather seems like a "normal" bug to me. That's not really what "broken" means in this context. > but don't trust me > > https://lkml.org/lkml/2012/10/2/505 Well, yes, it's the same issue. Linus is well known for going on a rant very quickly, but that doesn't mean that udev is completely broken. Yes, they obviously made a recent change that broke module loading on some machines, but that doesn't mean the whole concept is broken. That's just an unfair statement. Also, Kay is admitting that there is/was a problem with udev that needs to be addressed and it seems that they did because I cannot reproduce it anymore with udev 195 anymore. Adrian -- 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/20121114223427.ga23...@physik.fu-berlin.de
Re: Gentoo guys starting a fork of udev
On Wed, Nov 14, 2012 at 11:34:27PM +0100, John Paul Adrian Glaubitz wrote: > On Wed, Nov 14, 2012 at 03:41:55PM -0300, gustavo panizzo wrote: > > >udev isn't broken. > > > > really? > > > > https://bbs.archlinux.org/viewtopic.php?id=134012&p=1 > > I actually remember having seen this issue on Fedora Rawhide as well, > but it vanished after an update a few weeks ago, so it rather seems > like a "normal" bug to me. That's not really what "broken" means in > this context. > > > but don't trust me > > > > https://lkml.org/lkml/2012/10/2/505 > > Well, yes, it's the same issue. Linus is well known for going on a > rant very quickly, but that doesn't mean that udev is completely > broken. > > Yes, they obviously made a recent change that broke module loading on > some machines, but that doesn't mean the whole concept is > broken. That's just an unfair statement. Also, Kay is admitting that > there is/was a problem with udev that needs to be addressed and it > seems that they did because I cannot reproduce it anymore with udev > 195 anymore. I believe the regression (removal of support for firmware loading during module loading) has been fixed. However, the udev developers *knew in advance* that this would be a problem, reported such uses of firmware loading as being driver bugs. They then went ahead and changed udev even though the drivers had not all been updated (and it was evidently not easy to do so in some cases). Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20121114224312.gu13...@decadent.org.uk
Re: Gentoo guys starting a fork of udev
On Wed, Nov 14, 2012 at 11:43 PM, Ben Hutchings wrote: > I believe the regression (removal of support for firmware loading > during module loading) has been fixed. However, the udev developers > *knew in advance* that this would be a problem, reported such uses > of firmware loading as being driver bugs. They then went ahead and > changed udev even though the drivers had not all been updated (and it > was evidently not easy to do so in some cases). If the systemd/udev people continue with that attitude, I'm expecting Linus Torvalds to come with his super-simple, super-fast, super-minimal and super-brilliant udev replacement any minute now. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- 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/CAKcBokuor9JEyhVh0-4bn=6xoh693vcvy4wf-6xc0v7s5ez...@mail.gmail.com
Re: Candidates for removal from testing (2012-11-14)
Hi,
On Wed, Nov 14, 2012 at 10:02:10PM +0100, Niels Thykier wrote:
[...]
> Should you need a bit more time than given, please do not hesitate to
> contact us. It is also easier for us if we can avoid having to
> reintroduce a removed package.
[...]
> Debian Sympa team
>sympa
>
> Emmanuel Bouthenot
>sympa (U)
As said in the bug report[1], I'm currently working on fixing this bug
but I might need more time to finish writing some tests to be sure that
the fix is correct.
Is it possible to relax the deadline?
[1] http://bugs.debian.org/686846
Regards,
--
Emmanuel Bouthenot
mail: kolter@{openics,debian}.orggpg: 4096R/0x929D42C3
xmpp: kol...@im.openics.org irc: kolter@{freenode,oftc}
--
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/20121114231515.gb6...@openics.org
Re: Gentoo guys starting a fork of udev
On Wed, Nov 14, 2012 at 04:05:12PM +, Roger Leigh wrote: > On Wed, Nov 14, 2012 at 03:04:35PM +0100, John Paul Adrian Glaubitz wrote: > > On Wed, Nov 14, 2012 at 09:49:07PM +0800, Patrick Lauer wrote: > > > But anyway, we're getting tired of their ADHD-driven changes just to > > > change things > > TBH, I'm getting tired of people who are constantly shooting against > > them because these people are unwilling to accept changes. We're not > > bringing Linux forward if we stick to 30-year-old concepts. systemd is a > > good > > design and most people actually agree otherwise it wouldn't become > > standard on so many distributions (except Ubuntu, but that's rather a > > political decision IMHO). > systemd does have some good design features. It also has some bad > ones. It's not as black and white as some people have claimed. > If you want a reliable system, you need a reliable PID 1. Putting > additional complexity into PID1 increases the likelihood that a > bug will bring down your *entire system*. PID 1 is a single point > of failure. It *must* be absolutely dependable and reliable. > Upstart is also AFAIK at fault here. [Citation needed] Upstart provides a PID 1 that is absolutely rock solid. It's true that it's more complex than sysvinit, because it's more featureful; but great care has been taken to only pull the features into PID 1 that absolutely have to be there, and the implementation of those features is very elegant and maintainable.[1] Aside from libc, upstart has only two external library dependencies (three in trunk), dbus and nih: $ objdump -p /sbin/init | grep NEEDED NEEDED libnih.so.1 NEEDED libnih-dbus.so.1 NEEDED libdbus-1.so.3 NEEDED librt.so.1 NEEDED libc.so.6 $ And upstart is rigorously unit-tested at build time. That's a far cry from systemd's 8 external dependencies: $ objdump -p /lib/systemd/systemd | grep NEEDED NEEDED libselinux.so.1 NEEDED libdbus-1.so.3 NEEDED libudev.so.0 NEEDED libwrap.so.0 NEEDED libpam.so.0 NEEDED libaudit.so.0 NEEDED libcap.so.2 NEEDED libkmod.so.2 NEEDED librt.so.1 NEEDED libc.so.6 NEEDED ld-linux.so.2 $ And of all the concerns raised when Ubuntu (and Fedora and OpenSuSE) switched to upstart, "PID 1 is buggy and crashes" was not one of them. > sysvinit is fairly minimal, but even it could be simplified > further. Other init systems (e.g. s6)[1] take that even further > so that at any point in time, PID1 is running an image dedicated > to the current system state, e.g. booting, running, shutting down, > and it will exec() a new image to initiate a state change. When > running normally, PID 1 should do nothing except to reap zombies, > and switch to shutdown. Everything else can be done in a > separate process started by PID 1. This is an arbitrary design constraint that's not grounded in anyone's actual experience of deploying upstart. This is not theoretical. upstart has been PID 1 in Ubuntu since 2006. It *is* absolutely dependable and reliable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] http://ifdeflinux.blogspot.co.uk/2012/11/upstart-cookbook-updated-for-developers.html signature.asc Description: Digital signature
Re: Gentoo guys starting a fork of udev
On Nov 15, 2012, at 12:23 AM, Steve Langasek wrote: > Upstart provides a PID 1 that is absolutely rock solid. It's true that it's > more complex than sysvinit, because it's more featureful; The same is valid for the comparision of upstart vs systemd. > And of all the concerns raised when Ubuntu (and Fedora and OpenSuSE) > switched to upstart, "PID 1 is buggy and crashes" was not one of them. With only Ubuntu being the remaining distribution sticking to upstart, while nearly everyone else has switched to systemd. > This is not theoretical. upstart has been PID 1 in Ubuntu since 2006. It > *is* absolutely dependable and reliable. Upstart has had its problems, too [1]. And, honestly, the way this bug was handled left me with little confidence in upstart. Adrian > [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177
Re: Gentoo guys starting a fork of udev
On Nov 14, 2012, at 6:43 PM, lego12...@yandex.ru wrote: >> Modern computer systems are much more versatile and complex than they were >> at the time when System V Init was conceived. > > Some things must be as simple as possible even today. Care to elaborate why? To save memory on an 8 GB workstation? Even the 25 US$ Raspberry Pi has enough power for systemd. Are you also choosing FAT32 over ext4 because it is simpler? Why are we having Fibre Channel support in the kernel? Why does the kernel include a virtual machine hypervisor? Why do we support IPv6? We could just go back and stick with our good old SunOS 4 boxes. > >> I honestly think that people who are fighting modern software like systemd, >> pulse-audio or udev are simply fearing that their expertise in hacking >> configuration files in order to get things working are no longer needed >> anymore. They fear that the average joe can install and set up a Linux box >> without their help. > > May be init today should has some new features, but systemd is not such new > init. systemd is a wrong way. See plan9 for a good design examples. What makes you think that systemd does it the wrong way? They are using a very similar concept that Apple uses very successfully on MacOS X since 10.4 while no one in this universe has ever touched Plan 9 again. People are constantly insisting that systemd is too bloated or unreliable, but yet no one has really come up with real examples to prove that. Yes, the core binary of System V Init is smaller than systemd's. However, System V Init needs a lot of bloat in form of hacky bash scripts using even more external tools like sed and awk to be actually useful in any regard. And I think it makes way more sense to have all the functionality of the init system integrated into it's core binary rather than depending on external scripts which will hopefully do what init expects from them. Adrian -- 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/290b451f-cc15-4793-a0aa-2516d1eff...@physik.fu-berlin.de
Re: A common configuration format, anyone?
On 14 November 2012 15:31, Benjamin Drung wrote: > Am Mittwoch, den 14.11.2012, 15:32 +0400 schrieb Игорь Пашев: >> >> >> 2012/11/14 Philip Ashmore >> simple format which, like xml, is human-readable >> >> >> XML is not human-readable :-) > > XML is human-readable, but in most cases ugly to write. IMO XML is not > human-writable. > Also XML is not "diff-able" easily, which is usual for tree-like structures. In XML defence, at least it's not "write once" / "write only" format the way perl is ;-) Regards, Dmitrijs. -- 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/CANBHLUgeT6sVVCo7CiyPvTg6BnzphhNKe7mSBFf7yVNP=vr...@mail.gmail.com
Re: Gentoo guys starting a fork of udev
On Thu, Nov 15, 2012 at 12:45:48AM +0100, John Paul Adrian Glaubitz wrote: > On Nov 15, 2012, at 12:23 AM, Steve Langasek wrote: [...] > > This is not theoretical. upstart has been PID 1 in Ubuntu since 2006. It > > *is* absolutely dependable and reliable. > > Upstart has had its problems, too [1]. And, honestly, the way this bug was > handled left me with little confidence in upstart. > > Adrian > > > [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177 I suppose you should comment on it too, just to add your indignation at a bug that never affected you and wasn't fixed for a whole 2 days. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20121115001759.gv13...@decadent.org.uk
Re: Gentoo guys starting a fork of udev
On Thu, Nov 15, 2012 at 12:45:48AM +0100, John Paul Adrian Glaubitz wrote: > > This is not theoretical. upstart has been PID 1 in Ubuntu since 2006. It > > *is* absolutely dependable and reliable. > Upstart has had its problems, too [1]. > [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177 A bug in an upstart job, and your dissatisfaction with how the upstart maintainer responded to the bug report, is entirely orthogonal to Roger's point about complexity in PID 1. > And, honestly, the way this bug was handled left me with little confidence > in upstart. I'm very sad for you. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Gentoo guys starting a fork of udev
On Nov 15, 2012, at 1:19 AM, Steve Langasek wrote: > On Thu, Nov 15, 2012 at 12:45:48AM +0100, John Paul Adrian Glaubitz wrote: >>> This is not theoretical. upstart has been PID 1 in Ubuntu since 2006. It >>> *is* absolutely dependable and reliable. > >> Upstart has had its problems, too [1]. > >> [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177 > > A bug in an upstart job, and your dissatisfaction with how the upstart > maintainer responded to the bug report, is entirely orthogonal to Roger's > point about complexity in PID 1. I don't think so. It shows what can happen if you delagate fundamental tasks out of the core init binary into external bash scripts. Upstart has to rely entirely rely on the external script to do the right thing instead of doing it itself. You are constantly argueing that this makes the whole system more reliable, yet it took one apparently harmless command to kill the entire filesystem. I don't want to imagine this situation on our backup or home directory server. This would not have happened with systemd's design. > >> And, honestly, the way this bug was handled left me with little confidence >> in upstart. > > I'm very sad for you. So, you think marking such a major flaw as a wishlist is an appropriate reaction? Adrian -- 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/1a08d899-27f3-474f-8619-2ca57032c...@physik.fu-berlin.de
Re: Gentoo guys starting a fork of udev
On Nov 15, 2012, at 1:17 AM, Ben Hutchings wrote: >>> [1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/557177 > > I suppose you should comment on it too, just to add your indignation > at a bug that never affected you and wasn't fixed for a whole 2 days. Yes, it was fixed, after a very heated discussion with the maintainer who was blaiming users first for using the script incorrectly. Again, that's what can happen if you rely on hacky bash scripts for core functionality. Adrian -- 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/77ee56aa-6c1c-4cda-875f-59340ffbc...@physik.fu-berlin.de
Re: Re: Gentoo guys starting a fork of udev
As a source for some of our concerns here is us trying to separate out the udev build system so we can build ONLY udev if we want to install ONLY udev (we have to build systemd if we want ONLY udev right now). This means we have to pull in build deps even if we don't actually need them. http://lists.freedesktop.org/archives/systemd-devel/2012-June/005464.html -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: Gentoo guys starting a fork of udev
On Thu, Nov 15, 2012 at 12:57:50AM +0100, John Paul Adrian Glaubitz wrote: > On Nov 14, 2012, at 6:43 PM, lego12...@yandex.ru wrote: > > >> Modern computer systems are much more versatile and complex than they were > >> at the time when System V Init was conceived. > > > > Some things must be as simple as possible even today. > > Care to elaborate why? To save memory on an 8 GB workstation? Even the 25 US$ > Raspberry Pi has enough power for systemd. It's very simple. What happens if the init process terminates? The answer is that you get an instant kernel panic. PID 1 must never die. Test it yourself: boot with 'init=/bin/bash' and then type 'exit' to terminate the shell. So if the init process receives a signal like a SIGSEGV due to tripping over a bad pointer, your system will die immediately. Therefore, keeping PID 1 as simple as reasonably possible is of critical importance. [OK, you can try to mitigate by re-execing yourself in a signal handler, but even that adds extra complexity and is itself not without danger. I hope you take the point.] So systems which put additional logic in PID 1 are going to increase the probability of bugs being present, and those bugs could kill your system. There is no need for systemd, upstart, or any init system to have anything more than the bare minimum in PID 1; you can just fork and exec the more complicated part and keep this separated. So it's nothing to do about how powerful the system is. Or even if we're running unit files, upstart jobs or shell scripts. It's to do with the fundamental reliability of PID 1, because this is a critical point of failure; if it dies, there's no recovery, the system is dead. If you had to run a system which was safety critical, you wouldn't run systemd on it, and you wouldn't run upstart. Even if they were tested extensively, it's just too great a risk. If you were really serious, you'd probably not run sysvinit either; it's better in this respect than the other two, but there are still tinier, more easily verifiable init systems out there where it's just a screenful of code, and it's provably correct. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20121115011132.gr...@codelibre.net
Re: A common configuration format, anyone?
On 15/11/12 00:15, Dmitrijs Ledkovs wrote: On 14 November 2012 15:31, Benjamin Drung wrote: Am Mittwoch, den 14.11.2012, 15:32 +0400 schrieb Игорь Пашев: 2012/11/14 Philip Ashmore simple format which, like xml, is human-readable XML is not human-readable :-) XML is human-readable, but in most cases ugly to write. IMO XML is not human-writable. Also XML is not "diff-able" easily, which is usual for tree-like structures. In XML defence, at least it's not "write once" / "write only" format the way perl is ;-) Regards, Dmitrijs. It's possible to paint a picture a pixel at a time too ;) Philip -- 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/50a44341.3030...@philipashmore.com
Re: Gentoo guys starting a fork of udev
On Thu, Nov 15, 2012 at 01:11:32AM +, Roger Leigh wrote: [...] > So systems which put additional logic in PID 1 are going to increase > the probability of bugs being present, and those bugs could kill > your system. [...] This is also true for the kernel, which is why we generally prefer to use Hurd... or not. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20121115020745.gw13...@decadent.org.uk
Re: History of Debian bootstrapping/porting efforts
I read your recent post to debian-devel with great interest, as I've done some bootstrapping efforts in the past, and I'm currently in the middle of a "port" for the x32 ABI. In the past, what I've done (mostly privately) was to develop a script I called "pbuildd" which essentially just runs through the list of currently unbuilt packages and tries running pbuilder on them all, then installs anything that succeeds into a local repository and starts up the loop again. Then, when things got stuck, I just did a manual inspection of the unsatisfied dependencies to find the cycles, and chose one to break. In fact, I've just started uploading my current iteration of this to http://87.98.215.228/debian/ -- you might want to especially look at scripts/pbuildd which is the central script to run this loop. (And over time, it's gathered various optimizations to speed up the "installation into local repository" step, try to avoid invoking pbuilder if it can easily determine that certain Build-Depends aren't present at all, etc.) Initially, when I needed to break a cycle, I would just build something by hand and stick it into the "partial" directory, but over time I started developing automated cycle-breaker scripts, which are currently under scripts/cb.inactive (the pbuildd script looks for them under scripts/cb). The scripts tend to become outdated over time, though, with a moving target, and I'm sure the current state is no exception. My personal heuristics for what I preferred were: first, prefer cycle-breaking which just removes Build-Depends which are there to build documentation. Then, prefer cycle-breaking which ignores Build-Depends on one or a few libraries which provide purely optional features. If I couldn't find anything of this sort, I'd just try to find the cycle-breaking point which would be (fuzzily) "least invasive" and "least likely to break the resulting packages, at least as far as packages that Build-Depend on them". In the past, pbuildd was mainly geared towards trying to build all of Debian (including the binary-indep packages) starting from a minimal chroot and with minimal extra package downloads, but on an established architecture. It was only recently that I started applying it to bootstrapping x32. The way I started that was actually: I started off mainly following the instructions from Linux From Scratch, though of course adjusting it to "cross-building" to x32 as necessary. I also inserted dpkg into the process as soon as possible after the first LFS stage creating the chroot with /tools, and from then on ran installs into temporary directories, and built dummy dpkg packages with no dependencies. Then, after the LFS builds were over, I started building real Debian packages from the actual .dsc source packages, and eventually had enough packages built in this way that I was able to do a debootstrap, and start the pbuildd process. (So yes, x32 might be a special case in that it runs on already widely available hardware, and I could develop from an existing Debian installation. But I'd imagine that was probably the case as well, though possibly to a smaller degree, for the amd64 and ia64 ports, and possibly other recent ports to new ABIs on existing hardware (armhf?).) As for specifics on the x32 port -- currently the most common issues I see (roughly from most common to least common) are: * Outdated libtool, which causes it to want to ld -r with the wrong -m target type. (And also ld -r more often than usual, because "getconf ARG_MAX" outputs "undefined" on x32 in certain circumstances, which the outdated libtool can't handle properly.) Of course this isn't an issue for packages that autoreconf at build time. * Issues which will hit every architecture once we switch to eglibc 2.16. Out of this, by far the most common is gnulib (other than very recent git versions) wanting to attach a warning to the "gets" prototype, which is no longer exported by default in eglibc 2.16. * Code still using sysctl(2), which is no longer supported in x32. * Code which unconditionally uses 64-bit asm snippets if __x86_64__ or __amd64__ is defined -- which causes assembler failures if one of the inputs or outputs is a long or a pointer type, and the asm snippet uses explicit "q" sizing suffixes (or there are other mismatches). -- Daniel Schepler -- 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/CADf0C45igv-SnQcEz8v_A0vH=VKRJ+eFc7cwt2j5U=8rcyf...@mail.gmail.com
Question: Packages.xz and Contents-.xz
Hi, Just a question, is there any reason not provide Packages.xz and Contents-.xz in package repository? I cannot find any information about it, so please tell me. > henrich@hp:/tmp$ du -k Packages.* > 6052 Packages.bz2 > 5812 Packages.xz > henrich@hp:/tmp$ time bzip2 -d Packages.bz2 > > real 0m0.999s > user 0m0.956s > sys 0m0.020s > > henrich@hp:/tmp$ rm Packages > henrich@hp:/tmp$ time xz -d Packages.xz > > real 0m0.565s > user 0m0.532s > sys 0m0.032s > henrich@hp:/tmp$ time gzip -d Packages.gz > gzip: Packages already exists; do you wish to overwrite (y or n)? y > > real 0m1.932s > user 0m0.272s > sys 0m0.012s decompression speed is best : xz second: bz2 third : gz compression is best : xz (-6e) second: bz2 third : gz For slow CPU, gzip is good. For fast CPU or narrow bandwidth, xz is good. I think provide Packages.xz rather than bzip2 is better choice (if we can). > henrich@hp:/tmp$ du -k Contents-amd64.* > 24988 Contents-amd64.gz > 15512 Contents-amd64.xz And Contents-.xz will save disk space and traffic size 10MB x arch (=14) x (stable + testing + unstable) = 420MB/sync -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- 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/20121115111013.373f743dd4fe50eab5b5a...@debian.or.jp
Re: Candidates for removal from testing (2012-11-14)
On Thu, Nov 15, 2012 at 5:02 AM, Niels Thykier wrote: > We are considering removing the following packages from testing as > they have unfixed RC bugs filed against them. The packages can be > found in the attached dd-list. ... > Alexander Wirt >ferm Um, DSA might not be happy about that since they use it on Debian machines, CCing them. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6FODnEbBekdpKtfkkwnPM5boC=1mhgwnpnah1vr5vt...@mail.gmail.com
Re: Gentoo guys starting a fork of udev
On 11/15/2012 06:43 AM, Ben Hutchings wrote: > I believe the regression (removal of support for firmware loading > during module loading) has been fixed. However, the udev developers > *knew in advance* that this would be a problem, reported such uses of > firmware loading as being driver bugs. They then went ahead and > changed udev even though the drivers had not all been updated (and it > was evidently not easy to do so in some cases). Ben. Which is the exact same attitude as for moving to /usr, refusing patches for supporting other arch, and so on. They just don't care about breaking other people's system. This *will* happen again. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50a460a6.3060...@debian.org
Re: Candidates for removal from testing (2012-11-14)
On 15/11/12 04:20, Paul Wise wrote: On Thu, Nov 15, 2012 at 5:02 AM, Niels Thykier wrote: We are considering removing the following packages from testing as they have unfixed RC bugs filed against them. The packages can be found in the attached dd-list. ... Alexander Wirt ferm Um, DSA might not be happy about that since they use it on Debian machines, CCing them. And apparently the concerned Serious bug #688377 was fixed in Sid. Jerome -- 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/50a46202.7090...@rezozer.net
Re: Gentoo guys starting a fork of udev
On 11/15/2012 10:07 AM, Ben Hutchings wrote: > On Thu, Nov 15, 2012 at 01:11:32AM +, Roger Leigh wrote: > [...] >> So systems which put additional logic in PID 1 are going to increase >> the probability of bugs being present, and those bugs could kill >> your system. > [...] > > This is also true for the kernel, which is why we generally prefer > to use Hurd... or not. > > Ben. The fact we aren't using Hurd has *nothing* to do with the fact it is a micro kernel, and you know it. If Hurd has the same level of hardware support as Linux, as many contributors, and as many features, then probably, it would also have as many users. Mixing the discussion around feature and engineer design does *not* work, even in the case of kernels. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50a46377.7040...@debian.org
Re: Gentoo guys starting a fork of udev
On 11/15/2012 07:57 AM, John Paul Adrian Glaubitz wrote: > On Nov 14, 2012, at 6:43 PM, lego12...@yandex.ru wrote: > >>> Modern computer systems are much more versatile and complex than they were >>> at the time when System V Init was conceived. >> Some things must be as simple as possible even today. > Care to elaborate why? To save memory on an 8 GB workstation? Even the 25 US$ > Raspberry Pi has enough power for systemd. > > Are you also choosing FAT32 over ext4 because it is simpler? > > Why are we having Fibre Channel support in the kernel? Why does the kernel > include a virtual machine hypervisor? Why do we support IPv6? > > We could just go back and stick with our good old SunOS 4 boxes. Would you care reading what's being written to you? Roger didn't write that the init system should be kept without features, using old age techniques. He wrote that he believes that *pid 1* should be kept simple, and that the complexity should go somewhere else (like, in a fork of PID 1, for example). That is very different from what you write above. >> People are constantly insisting that systemd is too bloated or unreliable, >> but yet no one has really come up with real examples to prove that. I'm sorry but the sentence above is just plain wrong. See Linus post, and all the things that udev broke. >> Yes, the core binary of System V Init is smaller than systemd's. However, >> System V Init needs a lot of bloat in form of hacky bash scripts using even >> more external tools like sed and awk to be actually useful in any regard. But these hacks / bloats will not ultimately result in a kernel crash. >> And I think it makes way more sense to have all the functionality of the >> init system Yes. >> integrated into it's core binary And no! :) It would have been possible to do the right thing (tm) and have both feature and reliability. Currently, we only have the former, which is due to the design. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50a4654d.8010...@debian.org
How to make port/bootstrapping work easier
Hi Daniel, thanks for your detailed report! You also commented a lot on your actual practice (thanks!) so I changed the subject to reflect the slight topic change of my reply. On Wed, Nov 14, 2012 at 05:54:06PM -0800, Daniel Schepler wrote: > I read your recent post to debian-devel with great interest, as I've > done some bootstrapping efforts in the past, and I'm currently in the > middle of a "port" for the x32 ABI. In the past, what I've done > (mostly privately) was to develop a script I called "pbuildd" which > essentially just runs through the list of currently unbuilt packages > and tries running pbuilder on them all, then installs anything that > succeeds into a local repository and starts up the loop again. This is what a small function does for me in the very early steps in a theoretical manner. Naturally it quickly fails due to dependency cycles ;) > Then, when things got stuck, I just did a manual inspection of the > unsatisfied dependencies to find the cycles, and chose one to break. > In fact, I've just started uploading my current iteration of this to > http://87.98.215.228/debian/ -- you might want to especially look at > scripts/pbuildd which is the central script to run this loop. (And > over time, it's gathered various optimizations to speed up the > "installation into local repository" step, try to avoid invoking > pbuilder if it can easily determine that certain Build-Depends aren't > present at all, etc.) What my tools try to do, is to figure out a build order for bootstrapping Debian from nothing. This order can then be given to a tool that does the actual compilation in that order. The "figuring out the order" part is purely theoretical. I only look at the Packages and Sources files and the dependency relationships stored within to generate a dependency graph which I then evaluate. My tool doesnt know or care about whether or not a package can actually be compiled on the new architecture. It does no compilation by itself and can therefor not figure this out by itself. Running into compilation problems is (as of now) still what the user would have to take care of (from the point of view of my tools). I call it "my tools" because there is no name for the project yet. The git repository [6] and mailing list [7] just run under the name "debian-bootstrap". At this point I should also mention that everything heavily depends on dose3 and Pietro Abate is a great help with this project and I certainly wouldnt be where I am without dose3 and his continuous help and additions to the project. > Initially, when I needed to break a cycle, I would just build > something by hand and stick it into the "partial" directory, but over > time I started developing automated cycle-breaker scripts, which are > currently under scripts/cb.inactive (the pbuildd script looks for them > under scripts/cb). I had a look at the files in scripts/cb.inactive and they seem to store lots of information about which build dependencies can be dropped for a huge number of source packages. This is, if I read lines like inst_pkgs "`get_control_re $PBUILDD_ROOT/build/a/antlr/*.dsc 'build-(depends|depends-indep)' | sed -e '/\/d' -e '/\/d' \ -e '/\/d' -e '/\/d' \ -e '/\/d'` correct in meaning that gcj-native-helper, nant, cli-common-dev etc can be dropped, right? Sadly, that information is stored in a turing complete format (bash scripts) which makes the information badly machine readable. But if the format '/\/d' is mostly used, then I guess a regex can extract lots of the information with some tolerable uncertainty. I will try to hack up a script that harvests the droppable build dependencies from the files you have in scripts/cb.inactive. This information might be immensely usable, thanks! As a porter has to come up with those droppable build dependencies for each new port, a new syntax has been proposed in [3] by Guillem Jover called "build profiles". Would this information be included in the build dependencies of some core packages, bootstrapping would already become much easier for a porter. An example of how the proposed format works: Build-Depends: huge (>= 1.0) [i386 arm] , tiny The < and > "brackets" are used in the same way [ and ] are used for architectures to denote the profile for which that dependency can be dropped (or is exclusively required). Besides bootstrapping, such profiles could also be used for embedded builds or for bootstrapping compilers that need themselves to be built. The latter topic also recently came up on debian-devel [8]. There exist trivial patches for dpkg [4] and dose3 [5] to implement this functionality. > The scripts tend to become outdated over time, though, with a moving > target, and I'm sure the current state is no exception. My personal > heuristics for what I preferred were: first, prefer cycle-breaking > which just removes Build-Depends which are there to build > documentation. Then, prefer cycle-breaking which ignores > Build-De
Re: Gentoo guys starting a fork of udev
On Thu, 2012-11-15 at 11:37 +0800, Thomas Goirand wrote: > On 11/15/2012 10:07 AM, Ben Hutchings wrote: > > On Thu, Nov 15, 2012 at 01:11:32AM +, Roger Leigh wrote: > > [...] > >> So systems which put additional logic in PID 1 are going to increase > >> the probability of bugs being present, and those bugs could kill > >> your system. > > [...] > > > > This is also true for the kernel, which is why we generally prefer > > to use Hurd... or not. > > > > Ben. > > The fact we aren't using Hurd has *nothing* to do with > the fact it is a micro kernel, and you know it. Aside from the fact that micro-kernels are grossly impractical. > If Hurd has the same level of hardware support as > Linux, as many contributors, and as many features, > then probably, it would also have as many users. It turns out that stupid architectures make it hard to attract and keep contributors. > Mixing the discussion around feature and engineer > design does *not* work, even in the case of kernels. Whether the kernel or init survives a crash is completely unimportant if the applications the computer is supposed to run become unavailable. What good is a smaller, less buggy init if it can't keep (say) apache and sshd running? Ben. -- Ben Hutchings friends: People who know you well, but like you anyway. signature.asc Description: This is a digitally signed message part
Re: Candidates for removal from testing (2012-11-14)
On Thu, 2012-11-15 at 11:20 +0800, Paul Wise wrote: > On Thu, Nov 15, 2012 at 5:02 AM, Niels Thykier wrote: > > > We are considering removing the following packages from testing as > > they have unfixed RC bugs filed against them. The packages can be > > found in the attached dd-list. > ... > > Alexander Wirt > >ferm > > Um, DSA might not be happy about that since they use it on Debian > machines, CCing them. There's already an updated package in unstable, as of last night. Regards, Adam -- 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/1352959764.27968.174.ca...@jacala.jungle.funky-badger.org
Re: Gentoo guys starting a fork of udev
On Thu, Nov 15, 2012 at 12:57:50AM +0100, John Paul Adrian Glaubitz wrote: > > Some things must be as simple as possible even today. > > Care to elaborate why? To save memory on an 8 GB workstation? Even the 25 US$ > Raspberry Pi has enough power for systemd. This is obvious. For security and stability reasons. This is KISS. > Are you also choosing FAT32 over ext4 because it is simpler? Yes, of course. In some embedded devices we use fat32 or ext2. It simpler and faster. > > May be init today should has some new features, but systemd is not such new > > init. systemd is a wrong way. See plan9 for a good design examples. > > What makes you think that systemd does it the wrong way? They are using a > very similar concept that Apple uses very successfully on MacOS X since 10.4 > while no one in this universe has ever touched Plan 9 again. Who said that Apple concepts are technically good? I don't think so. > People are constantly insisting that systemd is too bloated or unreliable, > but yet no one has really come up with real examples to prove that. I think this is the question of the near future. > Yes, the core binary of System V Init is smaller than systemd's. However, > System V Init needs a lot of bloat in form of hacky bash scripts using even > more external tools like sed and awk to be actually useful in any regard. And what? The easy and power extension mechanisms are bad? I don't understand, why do people that don't like and don't understand unix ideas still use it and complain about it? > And I think it makes way more sense to have all the functionality of the init > system integrated into it's core binary rather than depending on external > scripts which will hopefully do what init expects from them. Sorry, but this is not true. This is the bad design and a wrong way. -- 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/20121115061159.GA7358@localhost
Bug#637232: [patch] provide a libc6-dev-compat package
On Fri, Nov 02, 2012 at 11:43:21AM +0100, Matthias Klose wrote:
> this is a patch I'm proposing to apply to the Ubuntu eglibc builds
> for precise, quantal and raring.
>
> - it adds symlinks for .a, .so and .o files
> - adds a symlink for the asm header dir
> - depends on the libc-dev- packages, which provide
>more needed header files/symlinks in /usr/include.
I am not sure using the biarch package for providing compat symlinks is
the way to go. Especially on architectures without biarch packages where
it even doesn't work.
> diff -Nru eglibc-2.16/debian/changelog eglibc-2.16/debian/changelog
> --- eglibc-2.16/debian/changelog 2012-10-28 00:24:42.0 +0200
> +++ eglibc-2.16/debian/changelog 2012-11-02 10:57:32.0 +0100
> @@ -1,3 +1,9 @@
> +eglibc (2.16-0ubuntu4) raring; urgency=low
> +
> + * Build a libc-compat-dev package. Closes: #637232.
> +
> + -- Matthias Klose Thu, 01 Nov 2012 18:16:32 +0200
> +
> eglibc (2.16-0ubuntu3) raring; urgency=low
>
>* Regenerate the control file.
> diff -Nru eglibc-2.16/debian/control eglibc-2.16/debian/control
> --- eglibc-2.16/debian/control2012-10-28 00:23:38.0 +0200
> +++ eglibc-2.16/debian/control2012-11-02 10:40:56.0 +0100
> @@ -175,6 +175,17 @@
> Contains the symlinks, headers, and object files needed to compile
> and link programs which use the standard C library.
>
> +Package: libc6-dev-compat
> +Architecture: amd64 arm arm64 armel armhf hppa i386 m68k mips mipsel powerpc
> powerpcspe ppc64 sparc sparc64 s390 s390x sh4 x32
> +Section: libdevel
> +Priority: extra
> +Depends: libc6-dev (= ${binary:Version}), ${multilibdev}
> +Provides: libc-dev-compat
> +Conflicts: libc6-dev (<< 2.13-0ubuntu7)
> +Description: Embedded GNU C Library: Non-Multiarch compatibility symlinks
> + Contains the symlinks for headers, libraries and object files in
> + non-multiarch locations.
> +
> Package: libc6-dbg
> Architecture: amd64 arm arm64 armel armhf hppa i386 m68k mips mipsel powerpc
> powerpcspe ppc64 sparc sparc64 s390 s390x sh4 x32
> Section: debug
> @@ -265,6 +276,17 @@
> Contains the symlinks, headers, and object files needed to compile
> and link programs which use the standard C library.
>
> +Package: libc6.1-dev-compat
> +Architecture: alpha ia64
> +Section: libdevel
> +Priority: extra
> +Depends: libc6.1-dev (= ${binary:Version}), ${multilibdev}
> +Provides: libc-dev-compat
> +Conflicts: libc6.1-dev (<< 2.13-0ubuntu7)
> +Description: Embedded GNU C Library: Non-Multiarch compatibility symlinks
> + Contains the symlinks for headers, libraries and object files in
> + non-multiarch locations.
> +
> Package: libc6.1-dbg
> Architecture: alpha ia64
> Section: debug
> @@ -355,6 +377,17 @@
> Contains the symlinks, headers, and object files needed to compile
> and link programs which use the standard C library.
>
> +Package: libc0.3-dev-compat
> +Architecture: hurd-i386
> +Section: libdevel
> +Priority: extra
> +Depends: libc0.3-dev (= ${binary:Version}), ${multilibdev}
> +Provides: libc-dev-compat
> +Conflicts: libc0.3-dev (<< 2.13-0ubuntu7)
> +Description: Embedded GNU C Library: Non-Multiarch compatibility symlinks
> + Contains the symlinks for headers, libraries and object files in
> + non-multiarch locations.
> +
> Package: libc0.3-dbg
> Architecture: hurd-i386
> Section: debug
> @@ -445,6 +478,17 @@
> Contains the symlinks, headers, and object files needed to compile
> and link programs which use the standard C library.
>
> +Package: libc0.1-dev-compat
> +Architecture: kfreebsd-amd64 kfreebsd-i386
> +Section: libdevel
> +Priority: extra
> +Depends: libc0.1-dev (= ${binary:Version}), ${multilibdev}
> +Provides: libc-dev-compat
> +Conflicts: libc0.1-dev (<< 2.13-0ubuntu7)
> +Description: Embedded GNU C Library: Non-Multiarch compatibility symlinks
> + Contains the symlinks for headers, libraries and object files in
> + non-multiarch locations.
> +
> Package: libc0.1-dbg
> Architecture: kfreebsd-amd64 kfreebsd-i386
> Section: debug
> diff -Nru eglibc-2.16/debian/control.in/libc
> eglibc-2.16/debian/control.in/libc
> --- eglibc-2.16/debian/control.in/libc2012-10-26 17:50:39.0
> +0200
> +++ eglibc-2.16/debian/control.in/libc2012-11-02 10:16:38.0
> +0100
> @@ -39,6 +39,17 @@
> Contains the symlinks, headers, and object files needed to compile
> and link programs which use the standard C library.
>
> +Package: @libc@-dev-compat
> +Architecture: @archs@
> +Section: libdevel
> +Priority: extra
> +Depends: @libc@-dev (= ${binary:Version}), ${multilibdev}
> +Provides: libc-dev-compat
> +Conflicts: @libc@-dev (<< 2.13-0ubuntu7)
> +Description: Embedded GNU C Library: Non-Multiarch compatibility symlinks
> + Contains the symlinks for headers, libraries and object files in
> + non-multiarch locations.
> +
> Package: @libc@-dbg
> Architecture: @archs@
> Section: debug
> diff -Nru eglibc-2.16/debian/rules eglibc-2.16/debian/rules
> --- egl
