Re: System snapshots
[Otavio Salvador] > No because some applications doesn't depends only of configuration > files but data-files. When you purge then, all data files will be > removed together (in major of times). Another problem is how you can > revert upgrade processes in database files and like? RPM have a feature allowing it to do upgrade transactions and rollback of failed installs, where it will include the data files in the transaction log. I read about this in the Linux Journal article "Transactions and Rollback with RPM" by James Oden, http://www.linuxjournal.com/article/7034>. Such feature would be nice to have in Debian as well. If you have a very short upgrade window, where one will have to abort and roll back if the upgrade fail, it would be helpful if dpkg would allow you to roll back the upgrade. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: System snapshots
[Andrew Suffield] > Seems like a poor reimplementation of a backup system to me. It's > independently useful, and gains nothing from being embedded into the > package manager, so why stuff it into the package manager? I recommend reading the article, to gain some insight into the problem it is trying to solve. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
[Steve Greenland] > Guess what? This is not a paid support forum, or a commercial > organization. This is a *community*. Communities have cultures, > traditions, in-jokes, etc. You can either choose to be part of that > community, and learn to be part of the culture, or you can go join a > different community. Being part of a community or not being paid is not a valid excuse for being rude to others. I happen to be part of this community too, and I do not treasure being rude as a positive side of the debian community. > One of the *long* traditions of the hacking community is a low > tolerance for the *willfully* helpless. The only requirement for > joining our community is competence. This doesn't mean you have to > know everything, only that you show the ability to learn and not > waste other people's time repeating information that is widely > available elsewhere. This is sometimes interpeted as rudeness; > alternatively, I think it's rude to expect someone else to read > manpages to you. I agree that sometimes messages are mis-interpreted as rude because of the low communication skills of the message writer, but do not believe this should stop us from trying to avoid being rude to each other. > One of the responses to this has been to set up alternative > communities where friendliness and patience are valued > more. Debian-devel is not one of those alternatives. I can't claim to speak for debian-devel as a whole (as I get the impression you are doing above), but I can speak for myself, and I do value friendliness and patience on debian-devel as well as all the other debian forums. So in my view, we should have it as a goal to be friendly and not hostile when writing on the list. This goes for both readers and writers. There are seveal people where english isn't their native language, and we tend to choose strange expressions or say things that can be misunderstood. There is a difference between not trying to be rude and failing, and trying to be rude and succeeding, and this community would be better off if we avoid the second class of comments. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
[Tollef Fog Heen] > The question is what's considered rude. What's not rude on > debian-devel might be considered rude in other fora and vice versa. That might be your question, but it isn't mine. :) Calling someone a dickhead is rude in most fora. I suspect most of us know when we are trying to be rude, and when we are trying to ridicule others. And if we don't, we should learn it by being told that our behavoiur isn't appreaciated by others. I do not believe a discussion on the exact position of the line between rude and non-rude statement is very interesting. A more interesting discussion for me is how this community should behave when people are way over that line. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DebConf4 Final Report
[Pablo Lorenzzoni] > If you spot any mistake, please, let me know and I'll fix it in the > next revision. Thank you for a good report. I noticed the list of people from Debian Edu was a bit short. In addition to me, it should list Andreas Schouldei, Joey Hess and Konstantinos Margaritis, all of which are part of the debian-edu CDD. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reboot in postinst
[Diogo Kollross] > Is there a problem in using something like > > shutdown -r now > > inside a postinst script of a package? It will probably not do what you want, as the package installation process might be interrupted, and packages might be left half-way installed. Besides, it is a very bad idea. Why do you want to reboot, and when do you want to do it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reboot in postinst
[David Sawyer] > Moral of the story: NEVER SHUTDOWN OR REBOOT WITHOUT ASKING. Another moral might be to always test the stuff you plan to do on a production server on a test-server first. I fail to see how it is sensible to browse the net on a production server. And I fail to see how it is smart to run as a privileged user when it isn't required to do so. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Emphasize teams, not packages
[Jerome Warnier] > BTW, how could I apply for becoming DD with only doing sysadmin > tasks? I'd do it immediately. That's my job, I'm pretty good at it, > and I prefer that to packaging, while I'm able to package too (I > already have a package of mine in Debian). I have not confirmed that this procedure will work, but here is my suggestions anyway. - The Alioth system administrators have asked for help several times. Get in touch with them and check what exactly they need help with. Do a good job helping them, and prove that way your abilities as a system administrator. Next, contact the new maintainer frontdesk and ask how the NM process fit your skill set and interest, and go through the process to become a official Debian Developer. - There are several custom debian distributions focusing on making it easier to maintain a installation of Debian machines. For example Debian-Edu and Debian-NP comes to mind. Become active in these sub-projects, and do a god job improving the tools and maintain the system used by these projects, and then as earlier described, make contact with the new maintainer frontdesk to discuss your case. There is no need to wait until your official Debian Developer membership card is available for you to become involved in sysadmin work in Debian. And already being involved will make it a lot easier for you to become a official Debian Developer. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#364422: libopenobex1-dev: pkg-config should provide correct include-path
[Hendrik Sattler]
> Should kdebluetooth fix the include statements or should the
> openobex.pc file say that "includedir=${prefix}/include/openobex"?
If the API documentation say , then kdebluetooth
should use that when including the header.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
APT key maintainence (Was: bits from the release team)
[Martijn van Oosterhout] > Generate the key for 2007 on 1st of December 2006. This gives everyone > a month to get the new key before it's used. One month is not enough. CD distributions, offline and stable machines do not get updated every month. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Buffer Image
[Indraveni] > ahy this image is displyed. Can any one tell me from where this Image is > coming and how can I resolve it. As far as I know this image is stored in the video memory of your video card, and is displayed after the video mode is switched and before the X server manage to replace the content of the video memory with the new content. > Anybody there who is working on it. I have no idea. I'm not sure if anyone in the X consider it a problem. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making init scripts use dash
[Margarita Manterola] > During some tests I've performed, I've found that making the init > scripts run with dash as default shell instead of bash makes the boot > time a 10% faster (6 seconds in a 60 second boot). I saw (parts of) your talk at debconf on this topic, and was happy to see the results you were getting. Are your slides on the web somewhere? I was a bit surprised that parallel execution only shaved 2 seconds of the boot, but suspect it might be because of inefficient implementation in /etc/init.d/rc. > To make this speed up available to everyone, we have 2 main choices: > > 1. Make /bin/sh point to /bin/dash Debian-edu has been doing this since woody, to avoid bash blocking the umount of /usr/ when nss_ldap is being used (bug #120340). We have not experienced any serious problems with it, and all the minor problems we have seen have been fixed quickly. I believe this is a fairly safe thing to do, but believe it should be done shortly after etch releases, and not just a few months before we freeze for etch. There are other things we can manage before etch releases (avoid external programs, use dynamic readahead, parallel booting, etc), and I suggest we focus on them this summer, and switch to dash next spring. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making init scripts use dash
[Loïc Minier] > Right now, if a script is named ".sh", it is sourced, perhaps it's > enough to change /etc/init.d/rc to use dash, depend on dash there > (sysv-rc), and progressively convert init scripts to use a symlink > ending in .sh when they are POSIX? Actually, if we want to run the scripts in parallel, we want as few of them to be sourced. Because of this, I suspect it is better to reduce the number of scripts named .sh, not increase it. But of course, we need to do real measurements to figure out if sourcing is faster than running them in parallel to know which of these approaches actually improve the boot time. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
[Gregor Herrmann] > If you look at by_vote [0] the situation is different: > http://popcon.debian.org/main/editors/by_vote > > [0] which seems more relevant to me: > # is the number of people who installed this package; > # is the number of people who use this package regularly; Note, the popcon vote is not always accurate. It only use files in some directories (like */bin/, but not */lib/*), so most library packages will never get a vote, and most user packages will get votes. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Better portability for package maintainers
[Erast Benson] > And thanks to upstream folks, 90% of OSS software is platform > independent and just works. Just to get the facts straight here. I compile and port free software regularly to Linux, Solaris, Irix, HP-UX, Tru64 Unix, AIX and MacOSX, and do not share your view that 90% of "OSS software" (what is that? Lets call it free software for now), is platform independent. I regularly run into build problems on all of these, because most free software is never before compiled with an ANSI C compiler (only GCC, which have a number of "extentions" not supported by ANSI C), and need rewrites to compile on Irix, HP-UX and AIX, which happen to have good and strict ANSI C compilers. And there are heaps of endian problems (triggering on big-endian and alignment problems (triggering on hppa and sometimes sparc) too. Luckily, GCC is getting closer and closer to ANSI C these days, so perhaps some time in the near future, the code developed by free software developers will be platform independent. :) So I would say less than 20% of the free software is platform independent, based on personal problems. On the positive side, most of the upstream developers believe platform independence and standard compliance is a good thing, so patches are almost always accepted when submitted. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
[Wouter Verhelst] > Which, I'm sure, is important for popcon maintainers; however, I > don't think it is very relevant in this discussion (unless you can > point me towards an editor that is implemented as a library ;-) The problem do not only affect libraries. There are other packages (with user applications) which show up with no votes, or with a very low number of votes. I have not investigated this in detail, but want everyone looking at the vote numbers to be aware of the problems with it. Heck, even the installation number have problems. Just check out http://qa.debian.org/developer.php?popcon=popularity-contest>, showing that 99.72% of the machines reporting to popcon have popcon installed. I believe that when I figure out how the rest are reporting to popcon. (I suspect the last issue is a problem with corrupt dpkg data.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Changing the default syslogd (again...)
[Nathanael Nerode] > Conclusion > -- > We should change the default syslogd. There is only one feature I miss in the current sysklogd package, and that is the ability to store the facility and severity in the log file. If we are to switch, please select one where this is possible to enable. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: alternatives and priorities
[George Danchev] > or some hosts have popularity-contest installed from pure upstream sources > instead from a popularity-contest debian package, thus don't have it > registered with the dpkg db. That would seriously surprise me, as popularity-contest only is distributed as a Debian package, and the Debian maintainers are also upstream. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
[Michael Meskes] > So why is Java su much more important than all other packages in NEW? One metric could be the popularity-contest score. Looking at http://popcon.debian.org/unknown/by_vote> to see what packages are in common use by our packages while being missing in the debian archive show java in the lead together with mplayer and other media-related stuff. Based on those numbers I conclude that Java is important to our users. Based on my involvement in Debian Edu, I know Java is important to the schools we try to move over to free software, and together with a Flash player are one of the important pieces free software are missing to provide a complete solution for schools. But getting non-free Java is only easing the situation (less maintenance as more people will work on the packages), it isn't solving it. And I work with Debian Java to solve it, and will provide SUN Java to the schools until the point where a free alternative exist that will fulfill the needs of the schools. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't we have more ftp masters ?
[Benjamin Seidenberg] > FYI: > 12:33 < Ganneff> and for all those impatient waiting for NEW: i will > clear that in my jetlag time, in those nights i > cant sleep (ie 1st -> 2nd june, 2-> 3) :) Sounds good, but do not really addresses the fundamental problem here, which is that NEW processing at the moment is fragile and stops completely when the single person handling NEW is busy elsewhere. There are a lot of work in Debian depending on regular processing of NEW packages (transitions, fixing dependencies, fixing build issues, preparations for the stable release, etc), and we should thus strive to make the processing as robust as possible to avoid slowing down these processes. Unfortunately I have no practical suggestion on how to improve it. Adding more ftpmaster and -assistants might be one approach. Improving the tools to handle new source packages differently from old source packages with new package names (typically library renames etc) might be another. I do not know the procedures well enough to make educated guesses. :) The NEW processing have made progress the last few years, so I am confident that we are moving in the right direction. For examle the transparency added not too long ago with the creation of http://ftp-master.debian.org/new.html> helps me a lot when I decide when to upload and when to expect my uploaded packages to make it into the archive. I really appreciate that, though I wish the dates of individual uploads was shown and the sorting order was different. This are though minor issues, compared to the situation earlier, when almost no-one knew the current NEW status. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package Selection for Debian Live
[Daniel Baumann] > I'm open for your suggestions... It would be great if the packages used by Debian Edu would be included on the live CD. Our latest package lists are available from http://svn.debian.org/wsvn/debian-edu/trunk/src/debian-edu/tasks/?rev=0&sc=0> I guess the standalone and desktop-kde tasks are the most relevant for your live CD, thought I know we have discussed having live CDs for thin client servers to allow them to be completely without local state. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New LTSP uploaded!
[Otavio Salvador] > Of course we're interested in your help. If you have a partial > package of it, provide it somewhere so anyone can check it and try > to improve it while you're busy. Yes, absolutely. Please package ltsp-utils for debian. It is interesting and useful for all the existing installations using the official LTSP packages from the LTSP project (as opposed to the muekow approach we are working on in Debian. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rcpar, parallel boot written in C
[Maximiliano Curia] > After Marga's talk in Debconf6, I've been working in a program that > starts the initscripts in parallel [1]. It's similar in some aspects > to startpar (part of sysvinit package) but with two main goals: it > must work, it must be as little intrusive as possible (in respect to > the scripts behavior). What is the speed impact compared to the non-parallel boot and a boot with startpar and shell parallelization? > The idea is to have a working parallel boot system, which could be > accompanied by something similar to insserv[2], to have the smallest > possible boot time. > > The current version is almost a proof of concept, but works quite > well with non-interactive initscripts. It still does not handle the > input for scripts like checkroot.sh, scripts that prompt for a > passphrase, or similar. Anyway, I'll be working in the support of > interactive scripts for the next few days. > > It's not ready to be released, nor to be included in Debian, but I > would really like to have some eyes over it, some comments and > suggestions. > > I might make a package for this soon, but I still have to figure out how to > modify /etc/init.d/rc from outside the sysvinit package. > > [1] The darcs repository is available in http://maxy.com.ar/~maxy/darcs/rcpar > [2] insserv uses the new lsb initscripts tags to reorder them, but it's too > SUSE based As Martin comments, the initscripts-ng project is a better place for this topic. CC to it, and lets continue the discussion there. A similar system to yours was proposed by Olivier Sessink. Check out The thread starting at http://lists.alioth.debian.org/pipermail/initscripts-ng-devel/2005-November/000225.html> Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mass bug filing: lesstif1->lesstif2 transition
[Kai Hendry] > Affected packages are: [...] > Petter Reinholdtsen <[EMAIL PROTECTED]> >plan How did you conclude that it depend on lesstif1? Its build depend is 'lesstif2-dev | lesstif-dev', to make sure it build with any version of debian, but I believe it is built by lesstif2 by default. Patches to fix the problem you have detected are most welcome in the BTS. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
[Lars Wirzenius] > As far as I can see, using make's -j option is only useful if you > have multiple processors. Packages should not make such assumptions > of the build environment. Actually, I've seem speedup with -j2 on a single CPU machine. I suspect one process is compiling while the other fetches the source from disk. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why is procps procps.sh in init.d?
[Craig Small] > Isn't the whole point of the /etc/init.d/.sh files to setup > environment variables for subsequent init scripts. Nope. The point of .sh init.d scripts is to speed up the boot. The sourcing is not guaranteed when scripts are executed in parallel, so all scripts should work when executed in a separate process as well. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using the SSL snakeoil certificate
[Jaldhar H. Vyas] > Is this is a good idea for Debian? I think it is but it doesn't make > sense to switch dovecot over unless all the other ssl-cert using > packages also do it. Is this possible in the etch timeframe? Yes, it is a good idea to make the SSL certificate handling in Debian packages more consistent. In Debian-Edu, we install and automatically configure several services with SSL certiciates, like imap, ldap and webmin, and it is a pain to handle all the ways SSL-certificates are generated. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Poor quality of multipath-tools
[John Goerzen] > I'm quite concerned about the poor quality of multipath-tools. This > is an absolutely vital application for many, required to even get a > machine to *boot*. Well, I do not even know what multipath _is_, nor why it is important. If that is representative, I suspect the people interested in multipath have some work to do to raise the awareness of the problem. This email is a very good start, but it seem to assume that everyone know what multipart is and why it is important. Is multipath machines as common as the ppc64 machines, or is the problem affecting a lot of users? > I am gravely concerned, though, about the lack of attention this > package is receiving. Does anyone intend to give it some TLC > anytime soon? Perhaps you could give it some tender loving care, and talk to the people maintaining the affected packages using IRC and email, and hopefully get them to realize why they should fix it in time for etch. :) I suspect you might wait in wane if you expect someone else to do it. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian architectures, according to popularity-contest
It has been a while since I reported the architecture distribution in Debian, as reported by popularity-contest. The raising star is 'arm', now used by 1.3% of the population. 'alpha' and 'sparc' continue to drop. Here are the numbers. You can find the details on http://popcon.debian.org/>. 11678 86.35% i386 1106 8.18% amd64 223 1.65% powerpc 181 1.34% arm 117 0.87% sparc 50 0.37% alpha 42 0.31% hppa 32 0.24% ia64 27 0.20% mipsel 20 0.15% armeb 12 0.09% mips 12 0.09% kfreebsd-i386 9 0.07% hurd-i386 6 0.04% s390 5 0.04% m68k 2 0.01% i486 1 0.01% ppc64 1 0.01% kfreebsd-amd64 13524 100.00% total (ignored 325 without arch info) The 325 machines without arch info are most likely running Debian/Woody or earlier versions of debian. If you want to help the Debian project to get a more accurate view on the architectures used, make sure your machines have the popularity-contest package installed and enabled. The reported data is also used to decide which packages go into which installation CD, so you will increase the chance that the packages important to you are available on the first CD as well. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian architectures, according to popularity-contest
[Török Edvin] > Afaik popularity-contest uses access-time to report statistics. That is not entirely true. The installation count is collected using dpkg -l. The votes on the other hand are collected using atime, and that is less accurate and should be taken with a grain of salt. Because of this, the package ordering on the CDs are using the install count and not the votes. > Will it report correct statistics if I have all of my partitions > mounted with -o noatime? It will correctly report that the package is installed, but most probably not report any votes from your machine. > Does it also consider for example how often I upgrade a package? Not directly, but it can be seen from the file update times. See for example http://people.debian.org/~igloo/popcon-graphs/index.php?packages=ext2resize>, and notice how 'old' and 'recent' jump up and down when people are upgrading to a new version of the package. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian architectures, according to popularity-contest
[Stephen Gran] > While I have to agree that the presence or absence of ads in LJ may make > or break some consumers decisions about what hardware to go with, I just > feel I have to note that arm has been a long supported platform within > Debian, and there are hundreds if not thousands of machines running > arm/Debian, even if they are not reporting to popcon. In fact, if I was > running Debian on arm, I would hope my machine wasn't wasting precious > CPU cycles reporting to popcon. Claim like this come up again and again, for various architectures. I doubt that it is relevant for the accuracy of the statistics. I believe there are a large percentage of machines without popularity-contest installed for all the architectures, and that this do not skew the result significantly for any of the architecture. If it wasn't, I would expect the more powerful architectures to become more and more popular as the number of submissions increase. This has not happened. The relative population count for various architectures have not changed much while the amount of submissions have more than doubled. For example, m68k have had around 0.04% of the population all the time. :) I suspect the frequency of people treasuring their CPU time too much to spend it on popularity-contest is about the same on all architectures. :) I believe the availability of hardware have a lot more impact on the popcon statistics than the amount of people not running popularity-contest. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: udev vs ldap at startup
[Brian May] > I found my debian/testing computer was hanging on startup. udev was > trying to contact LDAP (via NSS), but LDAP wasn't configured yet. I recently discovered the same problem with debian-edu. We install an ldap server on the same machine using libnss-ldap, and the boot just hang. I found bug #375077 on this. Thank you for bringing it to my attention. I had to boot using the 'emergency' boot parameter to be able to edit nsswitch.conf to get the machine running enough for me to debug this. I guess programs started very early in the boot process must only look up users and groups present in /etc/passwd and /etc/group, and libnss-ldap should be configured to not try so long before it give up. I'm not sure what changed, but libnss-ldap with openldap on the same machine work just fine both in woody and sarge. Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stuff the installer does which isn't done on upgrade....
[Mike Hommey] > I don't know about the installer, but all filesystems I created with > mke2fs recently also have resize_inode, which isn't even in the > tune2fs manpage. The default was recently changed in /etc/mke2fs.conf. It make life with LVM a lot easier. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Status of inetd for etch
[Roger Leigh] > Any thoughts or comments? For the LTSP thin client environment, I switched to openbsd-inetd because I could not avoid an inetd, and the openbsd version didn't start when no service was enabled in /etc/inetd.conf. We do the same in Debian-edu. A minor problem is that we are unable to remove netkit-inetd from the CD, because debootstrap claim it is a required part of base and refuses to accept openbsd-inetd in its place. The latter might be because we use debootstrap from sarge. I am all for replacing netkit-inetd with something less broken, and preferably make it possible to install a minimal installation like the diskless LTSP clients without such package. We want these clients booting on 32 MiB of ram, including the ramdisk, so every KiB of memory saved counts. :) Friendly, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: upstart: please update to latest upstream version
[Thomas Goirand] > We are wasting a lot of time writing complex init.d scripts when all > these should be automated to begin with. This is error prone, and > gets even more complex if you want to support all what's needed: the > VERBOSE variable, [ -x $DAEMON ] || exit 0, default files holding > DAEMON_START=1 and other options, dependency to lsb-base, and so > much more... I agree. And I believe it would be perfectly possible to cut down the init.d scripts to only list the special settings for a given package and fetch the boilerplate code from a common location. See metainit and bug report #651004 for some ideas on how this could be done for init.d scripts. -- Happy hacking Petter Reinholdtsen -- 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/2fl8vjvp5au@login1.uio.no
Re: upstart: please update to latest upstream version
[Bernhard R. Link] > Currently we have a system where every user has a chance to debug > and fix those problems and make their system work again. I just wanted to give a small comment on this, as one of the sysvinit package maintainers in Debian. The quoted text give the impression that the current init.d based boot system is working fine, and that is not quite how I see it. The current sysvinit boot system is not working properly on Linux. And it has broken in new and interesting ways the last few years, thanks to the fact that the linux kernel developers have removed the big kernel lock, causing the kernel to become more event based and less sequential during boot. These problems lead to boot failures when some kind of hardware is used (think disks and network cards, but it can happen with any hardware), because it is not possible for the current dependency based boot system to know when some hardware device is available during boot. A well known case is having the user home directory on an external USB disk, only to discover that the disk device node isn't available when file systems are mounted during boot. There are other examples. To solve this problem the early boot (note only the early boot _need_ this) need to become event based, and once the file systems, network interfaces etc are set up, the later boot can work using simple init.d script dependencies. I do not know the proper solution to this for Debian, but both upstart and systemd seem to provide a working solution with different costs and advantages. Personally I hope kFreeBSD and Hurd will get the required features used by upstart and systemd, to at least make it possible to use these systems on all the architectures handled by Debian. Or perhaps we should just teach sysvinit to handle kernel events and thus make it capable of solving the problem of the event based kernel internally. No-one so far have volunteered to look at this approach, and I have no plans to do so myself, but I am sure it would be possible to integrate the nice features of upstart and systemd into sysvinit. :) -- Happy hacking Petter Reinholdtsen -- 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/2flvcmwo0pt@login1.uio.no
Re: upstart: please update to latest upstream version
[Goswin von Brederlow] > Not what I ment. The traditional init doesn't have this either. But sysvinit/startpar have it at the moment. The display managers have priority, and startpar try very hard to get them running early during the boot. :) If I remember correctly, the xdm, kdm and gdm scripts have priority. There is a list in the source, but I do not remember the details. -- Happy hacking Petter Reinholdtsen -- 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/2flfwe0yujh@login1.uio.no
Re: Network Security Toolkit
[Dmitrii Kashin] > Utilities I am interested in: > 1) nsttraceroute (GPLv2) > 2) nstgeolocate (GPLv2) > > I have not seen more, but we can make sure that all of 'nst*'-utils > provide some geolocation stuff in many different formats; all of them > distribute under free GPL license, and all of them are very useful for > imagination results. xtraceroute is a similar tool which was in Debian/Lenny. Check out http://packages.qa.debian.org/x/xt.html >. I do not know why it was removed, but suspect it was unmaintained and dead upstream. I miss it a lot. :) -- Happy hacking Petter Reinholdtsen -- 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/2flehtd1e3m@login2.uio.no
Re: On init in Debian
[Thomas Goirand] > By the way, does anyone know a way to count the numbers of init > script with have archive wide? It'd be nice to know how much work it > would be to rewrite absolutely all init.d scripts, and how many > source package this involves. I did a count of binary packages with init.d scripts at the start of the dependency based boot sequence work. Back then, it was around 1000 binary packages. I used apt-file search /etc/init.d/ to count. :) -- Happy hacking Petter Reinholdtsen -- 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/2flpqbs3epa@login1.uio.no
Re: The future of non-dependency-based boot
[Moray Allan] > With similar intention, I wondered about the possibility of running > scripts without the LSB headers after everything else. (= implied > dependency on those with LSB headers) The intention of the current implementation is to assume such scripts depend on $syslog and $remote_fs, and at one point in time I believe this worked just fine. But I have seen bug reports indicating that this no longer is true. As Debian should support init.d scripts as long as the Linux Software Base require it, I believe it is worth spending some time making sure init.d scripts work properly in Debian. Of the around 1000 packages with init.d scripts in Debian, I suspect at most 100 of them would need to provide upstart/systemd configuration to make the boot robust and correct, and the rest of the packages can keep using their existing init.d scripts. -- Happy hacking Petter Reinholdtsen -- 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/2fl62d7pya0@login2.uio.no
Re: The future of non-dependency-based boot
[Adam Borowski]
> Am I supposed to fetch a copy of initscripts and manually compare
> scripts it ships with those on 'dpkg -L initscripts'? Or is there
> some other obscure way?
Try this one instead:
dpkg-query -W -f='${Conffiles}\n' initscripts | grep obsolete
--
Happy hacking
Petter Reinholdtsen
--
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/2flzkajobvv@login2.uio.no
Re: The future of non-dependency-based boot
[Sven Joachim] > I beg to disagree, it is already unsupportable because the only way > to test it is to set up a lenny system, create some local init > script without LSB headers to prevent migration to dependency based > boot, and then upgrade all the way to squeeze and wheezy. You can also install file-rc. It only handle the static script ordering, and when switching the static ordering is activated. :) -- Happy hacking Petter Reinholdtsen -- 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/2flbomyqlr6@login1.uio.no
Re: The future of non-dependency-based boot
[James Cloos] > Manually choosing the order remains a reasonable choice for many > servers. The upstream dependencies are not always sufficiently detailed > and edits to the init files can be lost when upgrading. Your assumptions are wrong. You do not have to edit the init.d files themselves to override their dependencies, and risk them going away during upgrades. I created the possibility for the system administrator to insert overrides in /etc/insserv/overrides/ for just this use case. -- Happy hacking Petter Reinholdtsen -- 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/2flbomtibjh@login2.uio.no
Re: The future of non-dependency-based boot
[Roger Leigh] > I can't see why not at first glance--it's done its job, so should no > longer be needed. It is still needed in two use cases. 1) Machine upgraded from Lenny where the migration was not done. Either because it could not be done, or because the user choose not to do it. 2) Machines switching to/from file-rc. -- Happy hacking Petter Reinholdtsen -- 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/2flsjg06w7w@login2.uio.no
Re: RFC: OpenRC as Init System for Debian
[Svante Signell] > Init is about the boot of the computer, right? Who is stupid enough > to put in a usb stick _during_ the boot? We need to separate boot > from adding/removing peripheral devices! You seem to misunderstand the problem. I will try to give a short explanation. The problem at hand is that adding entries to fstab do not work reliably for USB disks. If you have the users home directories (or any other disk that should be mounted during boot) on a USB disk, the device might not be working when the boot get to the point in time where it try to mount partitions. This also happen for SCSI and network disks. Say you want to mount a network disk during boot. This depend on the network being configured. This in turn might depend on a DHCP reply from a DHCP server, and to send the DHCP request the network card need to be detected. To detect the network card, the network driver need to be loaded, and the network card need to be found on the PCI or some other internal bus. And with the Linux kernel today, there is no way to know when during boot the network card will be found on the bus. To make this work reliably, the boot system need to be event based, not sequence based. There are other scenarios where the boot often fail too, but I guess you get the idea. :) -- Happy hacking Petter Reinholdtsen -- 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/2flipgmb5zc@login1.uio.no
Re: RFC: OpenRC as Init System for Debian
[Svante Signell] > This is the whole cause of the problem: You don't know the names of your > devices ay longer. Blame Linus! > What's the point of changing names of peripheral devices "dynamically"? > I've been struggling with eth0 and eth1 for some rime now, never knowing > how it will be named for every new kernel :-( This is not a question of knowing the device names. It is a question of the kernel device not being initialized and ready when it is needed during boot. Having static entries in /dev/ would not help in any of the scenarios I described. The removal of the big kernel lock made the kernel less predictable, and is the source of these issues. :) -- Happy hacking Petter Reinholdtsen -- 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/2flaa1yb2t7@login1.uio.no
Re: MIA check: Jan Christoph Nordholz
[Dmitry Smirnov] > Petter, you sponsored last maintainer's upload back in 2009 - do you > happen to hear from Jan lately? Nope. Been busy elsewhere. :) -- Happy hacking Petter Reinholdtsen -- 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/2flmx5v4mk4@diskless.uio.no
Re: Moving /tmp to tmpfs is fine
[Ben Hutchings] > We should be thinking about implementing per-user temporary directories > and making sure that programs respect $TMPDIR. Yes, per-user temp directories is a good idea. Installing the libpam-tmpdir package enable this by default, and beside some problems with the root user (bad TMPDIR is inherited when I restart services using /etc/init.d/ scripts), it work well. Perhaps it should be extended to allow the directory to be below ~/ instead of below /tmp/. :) It make it very easy to spot the programs not respecting $TMPDIR. :) > (On Linux it's also possible to give each user a different /tmp > through mount namespaces. I'm not sure whether that's compatible > with historical use of /tmp by the X window system.) This sound a bit more scary, yes. -- Happy hacking Petter Reinholdtsen -- 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/2fltxz0p18t@login2.uio.no
Re: Maintainer responsible for or only doing maintenance?
[Jonas Smedegaard] > Is my point clear now (even if is may disagree with my reasoning)? I find your point quite clear, but suspect you misunderstood those claiming the sponsor have responsibilities regarding package maintenance. To me it is obvious that the sponsor is also responsible for a package, when the maintainer become unresponsive or missing. When the maintainer is active and available, the sponsor do not have to step in and the responsibility is "sleeping". :) The maintainer is responsible in the day to day maintenance, but when I sponsor packages I also keep in mind that I might end up having to care about the package some time in the future if the listed maintainer looses interest or disappears for other reasons. You seem to argue that this should not be the case. Is this because of your current sponsor practice, or is there some other experience behind your view on the responsibilities of a package sponsor in Debian? -- Happy hacking Petter Reinholdtsen -- 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/2fl62bbmloo@login2.uio.no
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
[Serge] > Well, nobody named the benefits yet. [Wouter Verhelst] > - You could mount your mail spool there, and make things go blazingly > fast [1] [...] > - There's no danger of a symlink attack or similar with things like > tmpreaper -- or indeed any need for tmpreaper anymore. You reboot the > system, and /tmp is clean again, no matter what was there before. This > is more than just a convenience. I've happily been using tmpfs on /tmp/ for probably ten years now, and can list some more benefits: - It allow diskless setups like LTSP to work the same way the default installation in Debian work. They use read-only NFS-mounted file systems and a writable tmpfs mounted on /tmp/. - It reduces the number of disk writes on a laptop, allowing it to spin down the disk a bit longer. -- Happy hacking, Petter Reinholdtsen -- 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/2fltxymku23@login2.uio.no
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
[Bjørn Mork] > I'd like to add another one: > > - a tmpfs is always easy to grow without requiring any special > preparations. Just add more swap. The swap could be on different > disks, and could even be files hosted on other file systems. This sound very similar to what I am doing already with LVM and online file system growing. A simple 'lvresize' and 'ext2resize' (or just debian-edu-fsautoresize for those of us with that tool available) later the full file systems have more free space again. :) Did I misunderstand you? > Any file system will run out of space given the broken applications > mentioned in this thread. tmpfs is the only one which will allow > all systems to dynamically add more space, only limited by the > available disks. That's why tmpfs should be the default for both new > and old systems, unless the administrator has explicitly made a more > limited choice. While I agree that tmpfs should be the default, I suspect this argument isn't solid enough to make it worth it. There are luckily other arguments too. :) -- Happy hacking Petter Reinholdtsen -- 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/2flobouko0q@login2.uio.no
Re: Dependency-based boot ordering and sysvinit in unstable
[Thorsten Glaser] > Roger Leigh dixit: > >>However, if you have any lingering scripts without any LSB headers, >>you'll need to fix them up or remove them to allow dynamic boot >>ordering to be enabled. This is obviously not too desirable, since > > sudo apt-get --purge install file-rc insserv- Good reply, and good short term solution! :) Now if only everyone else in Debian would follow your example, perhaps the old and obsolete static init.d script ordering will become maintained again. http://qa.debian.org/popcon.php?package=file-rc > show 0.18% of the population do so already, and there is an upward trend, so it might even lead to success. -- Happy hacking Petter Reinholdtsen One of the people who brought you dependency based boot sequencing -- 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/2flfwa388cf@login2.uio.no
Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1
[Roger Leigh] > Could [file-rc] use insserv to do the dependency graph and then just > consume the makefile-style dependency list? Yes. See http://bugs.debian.org/539591 >, http://bugs.debian.org/573004 > and the source of insserv, where a patch to do this was created and included by Kel. The patch has been available for more than two years. -- Happy hacking Petter Reinholdtsen -- 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/20120627092719.gb20...@login2.uio.no
Re: Audit of Debian/Ubuntu for unfixed vulnerabilities because of embedded code copies
[Michael Gilbert] >> Are you aware of my proposal to do this, mentioned on debian-security >> and also drafted on http://wiki.debian.org/CPEtagPackagesDep >? > > Does this actually cover embedded code copies? The spec probably > needs to get something like an "XBS-Embeds-Source-From-CPE" tag for > that. I did not have embedded code copies in mind when I wrote the draft, but it would be handled by just listing both the upstream CPE and the embedded CPE separated with commas. > Even so, do you think maintainers are really going to go through the > trouble to keep these tags accurately populated? I suppose its worth > it to try, but I have my doubts. Inaccurate information can be worse > than no information. At least with embedded-code-copies, we have a > centralized record that's kept up to date by security-involved people. I suspect it will be done if we can provide mechanism that make it useful for the maintainers to include the CPE codes and keep them updated. One idea would be to automatically show all CVEs that might affect the package on the packages.qa.debian.org page, to make it easier to track security issues. I hope to come up with other and perhaps better ideas to motivate people to provide CPE codes with the packages. -- Happy hacking Petter Reinholdtsen -- 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/20120702215911.gd32...@ulrik.uio.no
Re: Switching the default /bin/sh to dash
[Giacomo A. Catenazzi] > Hmm, so a switch to dash it is not because of POSIX, but because > of "better code" and lighter shell for our scripts? > > Which is also a good reason for the change. Yes, it is a good change. I would love to switch every installation to dash as /bin/sh, but believe the path of least surprises to the sysadmin is to only change new installations and not existing systems. > But could you tell us more about the "subtle problems for shutdown > sequences". http://bugs.debian.org/159771 > is an example, solved by switching from bash to dash. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Conflicting assignment of privileged ports on boot, once again
[Julien BLACHE] > That's it. The most common offenders are already in the list; if > you're seeing the problem routinely with a popular service that's > not on the list already, that'd be a wishlist bug against libc6. https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/306007> and http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=7002186&sliceId=1&docTypeID=DT_TID_1_1&dialogID=67050089&stateId=0%200%2067048399> report of a bug in the parsing of that file, failing with the current content. Is this issue fixed in Debian? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Conflicting assignment of privileged ports on boot, once again
[Mike Hommey]
> Interestingly, none of the tcp ports between 600 and 1024 that are
> listed in /etc/services appear in this file. Even more interesting,
> none of the ports in the /etc/bindresvport.blacklist are in
> /etc/services.
Really? This is from my sid chroot:
% for n in $(awk '{print $1}' /etc/bindresvport.blacklist | \
grep -v '#'); do grep $n /etc/services ; done
ipp 631/tcp # Internet Printing Protocol
ipp 631/udp
ldaps 636/tcp # LDAP over SSL
ldaps 636/udp
imaps 993/tcp # IMAP over SSL
imaps 993/udp
pop3s 995/tcp # POP-3 over SSL
pop3s 995/udp
%
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: udev, init.d and a daemon
[Giacomo A. Catenazzi] > Problems: > - How to force the deamon to be loaded BEFORE xorg in insserv? > I don't find a "before of" dependency in LSB headers The header is X-Start-Before. In this case, I would use an entry like this: # X-Start-Before: xdm kdm gdm ldm sdm to make sure your script is started before the display managers. See http://wiki.debian.org/LSBInitScripts> or insserv(8) for more info on the available headers. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Taking care of exising packages
[Patrick Matthäi] >> thing is the system of new packages (debian-mentors, >> mentors.debian.net) .. I think that there could be a team dedicated to >> addressing this important task, same as the team dedicated to the >> kernel, the core packages, translation, among other important packages. > > I think you do not know how much work it is to sponsor a packages, > especially if it is NEW or the maintainer does not have enough > experience yet and the whole sponsoring requests ends up in a 30 > mails conversation.. To avoid too much overhead and a large backlog with sponsoring, I only collect sponsoring requests over IRC, and have written a small document giving some guidelines on how I want to handle sponsoring[1]. Matthew Palmer have a similar list[2] I found when looking for clues and tips. 1 http://www.hungry.com/~pere/debian-sponsoring.html 2 http://people.debian.org/~mpalmer/sponsorship.html Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
[Giacomo A. Catenazzi] > I still think /usr standalone should be supported, but I agree with > you that it could be difficult to support it in actual way. > > Thus: Are there any technical difficulties to mount usr in the > standard initramfs? > I don't think there are more "special" /usr environments as compared > of / In Debian, /usr/ is allowed to be on NFS. Mounting NFS volumes from the initramfs is probably not worth the effort. I recommend moving the needed files from /usr/ to /, to get this working properly. udev need to start before /var/ and /usr/ is mounted when they are on separate partitions, and thus should only need files on /. If udev need /, /var/ and /usr/ to be on the same partition, I believe udev have a release critical bug that need to be fixed before Squeeze is released. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
[Josselin Mouette] > Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a écrit : >> In Debian, /usr/ is allowed to be on NFS. > > So is /. Perhaps, but it is not a supported solution which need to be handled by all packages. /usr/ on NFS on the other hand is a supported solution that need to be handled by all packages. I am aware that LTSP allow for such setup, but only after reorganizing the entire boot. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
[Martin Grimm] > We've currently running 240+ Linux guests on 2 IBM System z10 EC, > that's the newest hardware of this kind for those not so familiar > with this architecture. 236 of these are running Debian, mostly > etch, some still sarge and some lenny. Amongst these are > zelenka.debian.org and a build system for security updates. One simple way to help a bit which will make it more visible to the Debian community at large that the s390 port is used, is to install and activate popularity-contest on these machines and thus make sure 236 machines show up on http://popcon.debian.org/ > as running the s390 port. :) At the moment, only 8 machines are reporting to popularity-contest, which put s390 in line with hurd-i386, kfreebsd-amd64 and m68k as ports with very small user groups. That number made me and probably others believe that very few are using the s390 port - at least until your email came along. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
[Russ Allbery] > Is there an easy way (read: the software already exists and I can > just install it) for all of the systems to report to an internal > proxy that then resubmits the data so that no one else can know > where it's coming from exactly other than from our servers > somewhere? I expect you will get this if you use HTTP to submit and any HTTP proxy specified using the HTTP_PROXY variable in /etc/popularity-contest.conf. The only identity submitted would be the random ID generated by popcon to make sure the weekly resubmission of information replaces the last one. Or one could use a SMTP remailer stripping headers, I guess. But that seem to be more work than just using a HTTP proxy. The information submitted is generated and available in /var/log/popularity-contest for those that want to have a look. There is no information recorded about the source, except for the unique ID of the host which is generated using dd if=/dev/urandom bs=1k count=1 2>/dev/null | md5sum when the package is installed. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
[Bastian Blank] > Why do you not extend the current setup to do another step? > Currently we have two > - in the initramfs with only minimal information and > - during the rcS run with / available. Eh, currently we have 5 sections during the boot: - initramfs with minimal set of files available. - rcS with only / available read-only (before checkroot.sh) - rcS with / read-write, /var/ and /usr/ might be missing (after checkroot.sh) - rcS with / and /var/ read-write (after mountall.sh) - rcS with /, /var/ and /usr/ read-write (after mountnfs.sh) Everything running during boot need to know which section it is running it, and avoid using tools and files only guaranteed to be available in later sections. In addition, there is an optional section split when udev is installed after / is read-only and before it is read-write, which is before and after devices in /dev/ are available. In runlevels 2-5 local and NFS file systems are available, so scripts running from there can be a less carefyl Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The future of the boot system in Debian
[mli...@stacktrace.us] > Could someone please point me to a discussion on the pros and cons > of upstart that was not funded by that spacecowboy shuttleworth? No idea who funded the work, but some Fedora notes can be found via http://fedoraproject.org/wiki/FCNewInit>. Fedora have already switched to upstart. Switching /sbin/init to upstart in Debian today is a seamless operations, which keep the boot system working exactly as before (just another process calling /etc/init.d/rc :). This of course only give us theoretical advantages. To get actual advantages, we need to use the available features in individual packages. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: The future of the boot system in Debian
[Rene Mayrhofer] > Please don't. As you correctly pointed out, the current Debian init > architecture is one of the most painful and outdated (not to say > broken) parts in the whole system. It's really time to move away > from old cruft (and I consider inittab to be cruft of little use at > this time) and start using something that will not cause more pain > in the future. I guess we were a bit unclear. The point is to use it for upgrades (ie when it exist), while not installing /etc/inittab for new installs, thus slowly getting rid of the file while ensuring the switch do not affect upgrades negatively. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: who should cleanup /var/lib/update-rd.d ? should it be cleaned up at all?
[Holger Levsen] > today I noticed that quite many packages fail the piuparts test, > because of a file left after purge in /var/lib/update-rd.d - who's > responsibility is it to clean this up? Each package? Or? Or > shouldn't those be cleaned on purge and piuparts should ignore those > files? (I don't think the latter is the correct approach.) The directory belong to the sysv-rc package, and will be cleaned up when that package is removed. :) We discussed on IRC to remove files from there when update-rc.d is asked to remove symlinks to a script, and if we decide to implement it that would solve the piuparts issue. Thanks for bringing it to our attention. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Faster boot by running init.d scripts in parallel
One "hidden" feature of the current Debian boot sustem, is the ability to run the init.d scripts in parallel. This require dependency based boot sequencing to be enabled, and the init.d script dependencies to be complete and correct to work reliably. The feature is hidden and undocumented, because we plan to drop the CONCURRENCY variable in the future and make concurrent booting the default when dependency based boot sequencing is enabled. If you want to test this feature in testing or unstable, use this command: echo CONCURRENCY=makefile >> /etc/default/rcS It will enable makefile style concurrency, and run N scripts in parallel during boot, where N is the number of CPUs or cores on the machine. This only work when dependency based boot sequencing. This can be enabled using dpkg-reconfigure insserv sysv-rc If some services fail to work properly, the problem is most likely because of bugs in the init.d script headers. See http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot > for clues on how to fix it. Most scripts have correct enough dependency information, but help is needed to find and fix the remaning few with bugs. Please make sure to usertag reported bugs to make them show up on http://bugs.debian.org/cgi-bin/pkgreport.cgi?usertag=initscripts-ng-de...@lists.alioth.debian.org > If you want to improve boot speed even more, I recommend installing the readahead-fedora packages, and boot once with the 'profile' kernel option to adjust its readahead list to the list of files needed during boot. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Faster boot by running init.d scripts in parallel
[Wouter Verhelst] > That seems suboptimal. Could be. See the startpar program to see how the scripts are run in parallel. Note that the boot is mostly CPU bound when readahead is used, which you should use if you care about boot speed. :) > If it actually is configurable, but you just didn't tell us so, then > please feel free to disregard this mail ;-) The startpar program can take arguments to adjust this, but we do not provide support for this in sysv-rc. Not sure if we want to do so or not. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Faster boot by running init.d scripts in parallel
[Michael Biebl] > Would be interesting to have a before and after bootchart so this > regression can be investigated. Yes, definitely. Would also be interesting to know what kind of hardware you got (CPU, harddrive), and if you enabled readahead or not. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Talk: Reflections of a bigtime Debian bug reporter
[Dan Jacobson] > Gentlemen, I shall be delivering my talk, > "Reflections of a bigtime Debian bug reporter" > http://jidanni.org/comp/bug_reporter.html Interesting topic. I had a look at your outline, and one particular thing I found missing was good instructions on what to include in a bug report. From http://wiki.debian.org/DebianEdu/HowTo/BugReports >, I find this list very useful for people wanting to report bugs: - What did you do just before things went wrong? As detailed as possible, please, so that the developers and other testers are able to recreate the error. - What happened, including accurate notes of any error messages and so on. - What did you expect would happen? Why do you think what actually happened was wrong? - Include a copy of any relevant logfiles. Especially the 'what did you expect' is important, as it often make it possible to differentiate between software bugs, documentation bugs and plan simple user expectation issues. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Please help with checking the boot and shutdown script ordering
As was announced earlier, Squeeze will be using dependency based boot sequencing to order the init.d scripts. The current dependencies are fairly good, but work is still needed to weed out the last bugs in the ordering. Automatic systems are in place to detect the most grave problems and inconsistencies, but to detect missing or incorrect dependencies, someone that know each script and package need to be involved. This is where you come in. :) The current effort is coordinated on IRC (#pkg-sysvinit on irc.debian.org) and the mailing list initscripts-ng-de...@lists.alioth.debian.org. The wiki page http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot > link to related resources. One new resource is an archive wide check of the consistency of dependencies available from http://lintian.debian.org/~pere/>. In the log file available from there, one can currently see how all scripts in the archive will be ordered in each rc?.d/ directory, and also see bugs and inconsistencies detected. Examples of such are scripts depending on non-existing services, scripts starting in rcS.d/ depending on $syslog which is started in rc2.d/, etc. Another new resource is piuparts, which will detect packages with inconsistency between the package dependency and the init.d script dependency - like a script requiring $portmap while the package do not depend on portmap. Please help find and fix errors in the init.d script ordering. The majority of packages are fairly correct, and I have tested the packages installed by tasksel to verify that the common setup is correct, but some lesser used packages might have incorrect order and only manual review can discover this. For sequential booting, the dependencies only need to be fairly correct to get a useful order, but for concurrent booting the dependencies need to be complete to avoid surprises. If you want to help out and wonder what to look for in the headers or in the log files generated by the automatic checking systems, please ask on IRC. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please help with checking the boot and shutdown script ordering
[Alexander Reichle-Schmehl] > Couldn't that be added as a check to lintian? Sure, for this particular problem, which at most affect 14 scripts. For the general case, it is not possible for lintian to know which package a given init.d script dependency belong to. Quite a lot of lintian checks are already written, thanks to Raphael, and we should create more as we come up with tests that can be done per package. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Faster boot by running init.d scripts in parallel
[Manoj Srivastava] > So, on deeper inspection, I have to recant: setting concurrency to > makefile in /etc/default/rcS does not in fact change the > timing. Which made me wonder why I thought it did, and it might be > that I removed but not purged a package, and that might have made > inserv throw a hissy fit. After purging that packages, reboots with > and without the concurrency bit show absolutely no change. Right. That sound more sensible. I would expect no change if the boot is IO bound and not CPU bound, but slower boot with concurrent booting was a mystery to me. :) Was this with or without dependency based boot script ordering? The concurrent booting only work with dependency based boot sequencing. > I can still put up the bootchartd data, but it is pretty boring. Please do, I find it interesting to learn more how different Debian systems boot to see if there are new improvements to be found. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Faster boot by running init.d scripts in parallel
[Manoj Srivastava] > ok. Late, but better than never: > http://people.debian.org/~srivasta/ Thank you. Very interesting to see. :) > bootchart-unopt.png = Data from before I started working > on optimizing boot times Duration 2 minutes 13 seconds, and as far as I can see using the legacy boot ordering and sequencial boot. > bootchart_concurrency.* = With CONCURRENCY=Makefile Duration 1 minute 7 seconds, and using concurrent booting and the new dependency based boot ordering. Unable to see the start of the slowest component from the original boot, the opennms, and that is rather strange. Was opennms started as it should, or is there some dependency bug in its init.d script? > bootchart.* = Normal, serial boot. Duration also 1 minute 7 seconds, and as far as I can see this is using concurrent booting (init.d/rc is starting startpar) too. Seem to be identical to the other boot. Why did you believe this was using serial boot? The content of /etc/default/rcS must have had some CONCURRENCY setting, or there must be a but in sysv-rc. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Faster boot by running init.d scripts in parallel
[Manoj Srivastava] > I rebooted, and I still get init.d/rc is starting startpar. I do > not have any line with CONCURRENCY= in /etc/default/rcS, commented > or otherwise. There is definitely a bug somewhere. Very strange. This do not happen when I test without the CONCURRENCY value set. Is the message "Using startpar-style concurrent boot in runlevel 2" or "Using makefile-style concurrent boot in runlevel 2" printed during boot, to indicate that concurrent booting is enabled? It is not printed when I test. Anyway, probably best to move this discussion to BTS, as a bug against sysv-rc? No idea how to reproduce, and no clue what the problem is. Will probably need both to be able to change the behaviour. Of course if you are happy with concurrent booting, no need to fix it. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Is Mari Wang MIA?
[Ernesto Hernández-Novich] > Have you had a chance to review your package? > > It's the only one holding the latest webgui 7.7 package I have ready > for upload to close a couple of bugs. It was uploaded two days ago. See http://packages.qa.debian.org/libi/libimage-exiftool-perl.html > for the details. :) Great to hear that a new webgui package will be uploaded soon. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Faster boot by running init.d scripts in parallel
[Manoj Srivastava] >> Is CONCURRENCY set in /etc/init.d/rc ? I used to have it set there. > > /etc/init.d/rc:CONCURRENCY=none Could it be a bootchart problem instead, graphing the wrong file or something? The version in unstable was broken because some Java library changed its API. I uploaded a fixed version yesterday. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: piuparts-MBF: owned and unowned files after purge
[Manoj Srivastava] > I can't seem to run piuparts locally here, since it fails trying > to chroot with this cryptic error message while trying to install, for > some reason, debfoster: [...] > | WARNING: The following essential packages will be removed. > | This should NOT be done unless you know exactly what you are doing! > | install-info (due to util-linux) This seem like the old and fixed issue with util-linux depending on install-info. Are you working with old mirrors? > I am leaning towards thinking this is a false positive. The issue was real, and fixed in util-linux version 2.16.1-3 (#547430). Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Build logs from local builds
[Charles Plessy] > Why don’t we remove the key of the developers uploading “crap > packages” from the Debian keyring? I believe a better approach is to collect stats on who upload packages which fail to build on all architectures, and add a process to review/requalify a Debian Developer if this happen too often. This way DDs know that their upload quality have consequences, and hopefully it will lead to higher quality packages. Of course the end result for those that do not improving the quality of their upload should be to loose the right to upload packages. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Build logs from local builds
[Luca Niccoli] > I think Petter meant "upload packages which don't build successfully > even on a single architecture".[1] That is exactly what I meant, yes. :) If the source do not compile on any architecture, I believe it the maintainer must have failed to done the minimum checks that should be required before uploading the source. > I guess the kernel team doesn't do that. I sure hope the kernel source compile on at least one of the architectures in Debian. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Iceweasel and Firefox compatibility
[Adam Majer] > Opera does allows per-site configuration of the UA string. Opera lies > a lot in name of compatibility. I believe a complete list of the workarounds in Opera is available from http://www.opera.com/docs/browserjs/>. The version of browser.js used by my Opera is downloaded from http://help.opera.com/servicefiles/userjsfiles/all/browserjs-desktop-10.00-20091109.js >, redirected from http://xml.opera.com/userjs/ >. Firefox/Iceweasel do not have a similar feature? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Linux image packages going to depend on python
[Manoj Srivastava] > This is fine. /etc/fstab is used by mountall.sh, mount, and > swapon explicitly I believe fsck and dump tools also use it to decide when to check and back up the file systems. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#559761: ITP: release -- provides information about the current releases
[Benjamin Drung] > * distro-release-info This seem to me like the best name of the suggested names. > Should i rename the scripts, too? I believe it would be best if the program name and the package name was the same. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
[Kees Cook] > As an example, I have a debdiff against openssh to use it: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561887 > > With the new package, the arch-specific logic for hardening defaults > is in one place, and a maintainer can selectively disable anything they > don't want on by default. This might be a good compromise to get network services hardened without changing the default build system. Is there a plan for which packages to convert first? A patch for my netplan package would be most welcome. :) I guess starting with the most popular ones is a good idea, and realise netplan is not one of these. :) Personally I would prefer the build default to change instead, and a mechanism to disable in per package for those that can't use the hardening defaults, but realise it might be a risky path to take. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: where is /etc/hosts supposed to come from?
[Iustin Pop] > the FQDN should be available directly on the host, without external > dependencies. Which is why I personally think the machine name (the > one that the kernel knows) should hold the canonical name. I agree, and I always make sure /etc/hostname is the FQDN or something close to it on machines I run. We do the same at the university where I work, on all Unix versions that are capable of storing the long names (had some problems with older HP-UX, not sure we have any Unix versions left which refused hostnames >8 characters). Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian development and release: always releasable (essay)
[Russ Allbery] > I would need to do some research, since I'm not personally familiar > with everything that's in a blend or a task at the moment. Just off > the top of my head, though, to pick an area of personal expertise, I > don't think there's an existing blend or task for a Kerberos KDC or, > more generally, an authentication and identity management > infrastructure. Actually, I believe there is. The Debian Edu blend contain the education-main-server task and metapackage, which include a Kerberos KDC. It also contain the LDAP server as KDC backend storage and user/group/etc lookup. -- Happy hacking Petter Reinholdtsen -- 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/2flsj1ag54h@login1.uio.no
Re: [Popcon-developers] Encrypted popcon submissions
[Paul Wise] > I wonder if the release team would accept a backport of these > features to popcon in stable/oldstable. GPG and time truncation are > security enhancements and reporting the dpkg Vendor field is very > useful and has no risks. Once GPG is tested, would you consider > doing a stable/oldstable update before the next point release? I suspect the new encryption feature would break popcon.skolelinux.org, as we have not investigated the new feature and use popularity-contest directly from Debian. Our collector would start getting encrypted submissions and lack the key to decrypt them. For Jessie, I hope we have time to figure out a solution, but for Wheezy we are not going to rewrite that part of our system. -- Happy hacking Petter Reinholdtsen One of the Debian Edu developers -- 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/20130622040019.ge28...@ulrik.uio.no
Re: [Popcon-developers] Encrypted popcon submissions
[Paul Wise] > This could be solved by having a mapping between encryption keys and > URLs. A mechanism that would allow derivatives to just drop some > files/dirs into their base-files package would probably be the > easiest. I suspect the easiest way would be to allow more than one GPG key to be used when encrypting, and finding the keys in a .d directory. > Also you could just have popcon in DebianEdu submit only to the > Debian popcon site, IIRC DebianEdu sets the dpkg vendor field to > something other than Debian? Debian Edu do not set the dpkg vendor field in Wheezy and earlier. I created http://bugs.debian.org/712996 > to track its inclusion yesterday. -- Happy hacking Petter Reinholdtsen -- 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/20130622043814.gf28...@ulrik.uio.no
Is updating utmp when logging in a user a requirement in Debian?
Hi. Traditionally, on Unix like systems, it is possible to run the 'w' and 'who' command to see all logged in users and ttys currently in used on the system. These commands look in /var/run/utmp to figure out what users are logged in, and depend on login managers (like login, gdm, etc) and terminal emulators to update the utmp file at the start and end of a session. In addition, the /var/log/wtmp file is used to record a history of sessions, accessable using the 'last' command. I believe it is a requirement in Debian to keep the files utmp and wtmp up to date, and that any program should be able to depend on the content of these files. Example of packages depending on correct utmp information is sysvinit (the shutdown program broadcast a message to all logged in users), acpi-support-base (will lock the screen with the console user's password for hibernation) and killer (kill processes of users without active console sessions). But my view is not shared by everyone, as for example can be seen in http://bugs.debian.org/648604 >, where the maintainer of lightdm believe correctly updated utmp information is nice to have but not a requirement. It is not the first time I meet this view, so he is not the only one believing utmp and wtmp are not really no longer important pieces of a Unix like system. The debian policy manual have this to say about utmp and wtmp: 11.3 Using pseudo-ttys and modifying wtmp, utmp and lastlog Some programs need to create pseudo-ttys. This should be done using Unix98 ptys if the C library supports it. The resulting program must not be installed setuid root, unless that is required for other functionality. The files /var/run/utmp, /var/log/wtmp and /var/log/lastlog must be installed writable by group utmp. Programs which need to modify those files must be installed setgid utmp. But it do not state that programs should update it, nor when it should happen. Perhaps it should be extended to make that more clear? So my question to my fellow debian developers is simply this: Is correct updating of utmp and wtmp a requirement in debian, or just nice to have? Is it a wishlist bug to fix it, or a release critical problem? There are related mechanism like consolekit in place in Debian that can provide a list of currently logged in users, so the question is also if it is enough to only update consolekit, or if utmp must be updated too. -- Happy hacking Petter Reinholdtsen -- 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/2fl61wxqsgg@diskless.uio.no
Re: Audit of Debian/Ubuntu for unfixed vulnerabilities because of embedded code copies
[Henri Salo] > Has there been any progress with this project? I am glad to help if > there is something I can do? This is needed in my opinion. You could try to run the scripts I created in the debian-security svn repository, and see how they could be improved. I have not had time to work much on this issue for a long time, and this is unlikely to change any time soon. :( You can try to add CPE info to a few packages to test the proposal, and see if it make tracking easier. But first and foremost, you can try to figure out what need to be done to move the idea forward, as I lack the time to do so myself. :( If you want more direct feedback from me, we could meet on IRC to exchange knowledge. Otherwise, you can ask using email. -- Happy hacking Petter Reinholdtsen -- 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/20120929203142.gf20...@ulrik.uio.no
Re: Status of circular dependencies in Sid
[Ian Jackson] >There is still nothing per se wrong with circular dependencies [Thorsten Glaser] > Actually, I’m hitting an APT bug during dist-upgrades right now for > packages with circular dependencies, usually two (perl with > perl-modules, and g++-$version with its library), when they are > indirectly depended on by a package with Important: yes set, as was > recommended for metapackages which should not be considered by APT > for automatic removal. A similar issue with libqt4-dbus is blocking upgrades of a desktop installation from squeeze to wheezy the last two weeks (as detected by jenkins.debian.net). See http://bugs.debian.org/655382 > and related BTS reports for the details. I really hope we can get rid of the circular package dependencies. :) -- Happy hacking Petter Reinholdtsen -- 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/2fl62428rn7@login2.uio.no
Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
[Steve Langasek] > My knee-jerk reaction to the Fedora proposal had been that it was > sick and wrong and would cause unacceptable breakage for users on > upgrades if Debian adopted the same plan. However, I struggled to > formulate a concrete scenario where losing support for that last > configuration would actually make a difference. I can give you one example of what we loose if stuff in / depend on stuff in /usr/. I read the entire thread, and everyone is talking about the boot, while ignoring the shutdown. When using NSS modules linked to libraries in /usr/ and bash (or any other shell loading user information at startup) as /bin/sh, the shell scripts being run to shut down the machine will block /usr/ from being umounted. When /usr/ is a LVM partition, this block LVM from being shut down, and leave /usr/ in a dirty state and LVM not properly shut down before poweroff. Thus, having stuff in / depend on libraries in /usr/ can cause real problems during shutdown. See http://bugs.debian.org/120340 > and http://bugs.debian.org/159771 > for the old story about bash and LDAP NSS blocking umount. -- Happy hacking Petter Reinholdtsen -- 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/2fly5gy72w7@login2.uio.no
Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
[Philipp Kern] > What in LVM should need to be shutdown? No idea. I have just seen messages about the LVM subsystem being busy at shutdown. I have not investigated where they came from. -- Happy hacking Petter Reinholdtsen -- 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/20121216225730.gq23...@ulrik.uio.no
Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
[Thorsten Glaser] > That’s just another argument for using /bin/mksh-static as /bin/sh. > (It’s also faster than /bin/dash which is dynamically linked.) Does this mean that mksh-static isn't using NSS at all? Do you have benchmarks showing that it is faster than dash? How does it affect the boot times? -- Happy hacking Petter Reinholdtsen -- 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/2fl4njf5dd6@diskless.uio.no
Re: Ifupdown, loopback interface, /etc/network/interfaces.d
[Andrew Shadura] > Well, yes, I forgot about NM. Actually, as far as I know, it's the only > tool affected, everything else either doesn't care to read /e/n/i, or > is already fixed, or this difference is irrelevant and doesn't need to > be urgently patched. Correct me if I'm wrong. You are wrong. Debian Edu also expect /etc/network/interfaces to have the complete network setup. -- Happy hacking Petter Reinholdtsen -- 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/2fltxqtbm6y@login2.uio.no
Bug#699077: ITP: isenkram -- Suggest packages to install when inserting new hardware
Package: wnpp Owner: Petter Reinholdtsen Severity: wishlist * Package name: isenkram Version : 0.2 Upstream Author : Petter Reinholdtsen * URL : http://anonscm.debian.org/gitweb/?p=collab-maint/isenkram.git * License : GPL Programming Lang: Python, Perl, shell Description : Suggest packages to install when inserting new hardware Try to figure out what packages are need freshly inserted hardware dongle. See http://people.skolelinux.org/pere/blog/tags/isenkram/ > and the git source for information of the project. -- Happy hacking Petter Reinholdtsen -- 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/2fl622jf09t@diskless.uio.no
Re: Interactive package management via aptitude
[Andreas Beckmann] > Looks like we should start doing some automated upgrade tests with > aptitude ... jenkins.debian.net would be one solution, piuparts > another (anybody who wants to write a patch?). A few years ago I did chroot upgrade tests like the one done by jenkins.debian.net, using both apt-get and aptitude, to get a list of differences. The differences were huge, and to me it seemed that both of them failed and succeeded some times. I guess what we really want to is to both test upgrades with apt-get and aptitude chroots, and compare them to the result we get by asking tasksel to install the original task. After all, we want to make sure upgrades and installations end up with almost the same setup. If you want to create such chroot test with jenkins, I am sure Holger welcome a patch. The chroot scripts are simple to extend. :) -- Happy hacking Petter Reinholdtsen -- 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/2flli8k9q32@login2.uio.no
Re: Init dependency between nfs-kernel-server and name server
[Goswin von Brederlow] > That way nfs-kernel-server is started after the name resolvers but > none of them is required. Does that look right? Nope. Virtual facilities (like $named and $local_fs) provided by several scripts should not be listed in the Provides line of individual init.d scripts. So the idea might make sense, but the implementation would be to add a virtual facility starting with $, define it in /etc/insserv.conf.d/ for each package providing it and use it in Should-Start headers. :) Besides, I believe $named is a existing and fitting virtual facility for this use. Happy hacking, -- Petter Reinholdtsen -- 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/2fleibkkbo9@login1.uio.no
Re: Init dependency between nfs-kernel-server and name server
[Tollef Fog Heen] > It seems quite inappropriate to limit this information to just a > single init system when we have more than one in Debian. We should > strive to move that information into a init-agnostic place, and I > don't see why it would be wrong to just have the relevant init > scripts Provide the relevant facility. The simple issue is that this do not work with insserv, the first and as far as I have tested only system using the headers. I suspect that it would be better to list the provided virtual facilities in the scripts themselves, but believe it is a bad idea to do so until the LSB clearly state that this is the way that it should be done and insserv have been changed to handle it. I brought this topic up with the insserv upstream developers, but they believe it is a bad idea. Did not find time to work any more on the topic. A patch for insserv and a discussion within the LSB standardization framework would be a good way to bring this topic forward. :) Feel free to look into it if you got the spare time to spend on it. :) Happy hacking, -- Petter Reinholdtsen -- 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/2fl1v7gdlg0@login1.uio.no
