Re: The future of the boot system in Debian
Quoting mli...@stacktrace.us (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? I see absolutely zero point in throwing out partly aggressive remarks in this thread. Scott, who initiated upstart development, did a tremendous work in Debian before moving to something else, and deserves respect for this (and he *has* respect from most contributors in this project). So do all people who work partly funded by Canonical and do not put mental barriers where there are none. signature.asc Description: Digital signature
Bug#545264: RFP: quickly -- Program that helps you create software programs quickly
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
--- Please fill out the fields below. ---
Package name: quickly
Version: 0.2.2
Upstream Author: Rick Spencer and others
URL: https://launchpad.net/quickly
License: GNU GPL 3
Description: Program that helps you create software programs quickly
More about package:
Quickly helps you create software programs (and other things) quickly.
You can select from a set of application templates and use some simple
quickly commands to create, edit code and GUI, and publish your software
for others to use. Quickly's templates are easy to write. So if you are
a fan of language foo, you can create a foo-project template. Or if you
want to help people making plugins for your killer app, you can make a
killer-app-plugin template. You can even create a template for managing
corporate documents, creating your awesome LaTeX helpers The sky is the
limit!
Note: Version 0.2.2 is released without debian/ directory inside - so,
packager can package it properly.
--
Cheers,
Kartik Mistry | 0xD1028C8D | IRC: kart_
Debian GNU/Linux Developer
Blogs: {ftbfs, kartikm}.wordpress.com
--
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
On Sep 06, Steve Langasek wrote: > If you're unable to persuade upstream to change their implementation, and > you're unwilling to diverge from upstream to ensure the package complies > with Debian policy, your other option is to orphan the package and let I am willing to diverge from upstream and I have been doing it in varying degrees for the whole like of the package, what I am unwilling to do is to adopt crazy solutions which are broken, unmaintenable and/or useless anyway in the long end. > It's normal that in the process of drafting a standard, people will take > into account the prevailing real-world practices, to ensure that the > standard will be useful. Once something *is a standard*, you don't > arbitrarily change what you're doing and claim that it still complies with > the standard because "the standard follows what Red Hat does". I am not claiming that this complies with the standard, just that it does not matter because if there is a wide consensus (which does not need to be unanimous) about this then eventually the standard will be updated to reflect it. Anyway, FHS also has examples of things changed long after they were adopted by everybody, like /var/spool/mail/ vs. /var/mail/. > The FHS as part of Debian Policy is a promise to our users that they can > rely on the system working a certain way. It's not ok for *any* upstream to > force us to break that promise, no matter how important they think they are. While it is not OK, it is also hard to avoid. > The last time you made this claim, I asked Scott about it and he denied > that this was his position. Given that there has quite specifically been And I am pretty much sure that he told me otherwise, but I do not think this is very important now: if Ubuntu really has a policy of supporting a standalone /usr then it's about time that the Ubuntu developers join the relevant discussions on IRC and/or the linux-hotplug mailing list and show that Debian is not alone. -- ciao, Marco signature.asc Description: Digital signature
Re: The future of the boot system in Debian
Great news. I really look forward to converting my init scripts to native upstart jobs, but I believe that some clarifications are needed about the long-term impact of switching to upstart. Can you clarify what normal packages will have to do to support the non-Linux ports which are unable to run upstart? Do the maintainers of these ports plan to port upstart? Will packages have to ship both an upstart job and a legacy init script? When should maintainers start adding upstart jobs to their packages? -- ciao, Marco signature.asc Description: Digital signature
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: Policy of capitalisation of in /usr/share/?
Hi Danai, On Sat, Sep 05, 2009 at 03:08:10PM +0200, Danai SAE-HAN (韓達耐) wrote: > I recently posted bug #545127 (see [1]) as I noticed that the package > `publican' stores some shared files in /usr/share/Publican/ but stores > its documentation in /usr/share/doc/publican/. > As an end user, I expected /usr/share/publican/, given that the > package name is `publican'. > However, the upstream package uses /usr/share/Publican/. The Debian > Maintainer (Mikahil Gusarov, in CC) does not wish to change the > upstream source without a good reason, and that is perfectly > understandable. > The Debian Policy [2] has two places in which it says something about > /usr/share/: sections 8.2 (Shared library support files) and 10.7.3 > (Configuration Files > Behavior). However, according to Mikhail both > sections are not applicable, either because there are currently no > shared packages or because `publican' has no ./configure. [Correct me > if I'm wrong, Mikhail.] Mikhail suggests to change some of the > wording in the policy under 10.7.3 (see [1]). > I see a few options here: > - the policy does not cover this issue, and it is up to the the Debian > Maintainer to decide how the directory in /usr/share/ is called; > - the policy requires that directories in /usr/share/ be exactly > /usr/share//. Given that must use > lowercase letters (Debian Policy 5.6.1). Most packages already do > this, but this would affect some packages like X11 or PolicyKit, as > Mikhail Gusarov noted; > - the policy recommends /usr/share//, unless it is too > difficult to implement. > I would be most grateful if anyone could clarify this situation. Policy does indeed not require that directory names under /usr/share follow a particular pattern. Namespace conflicts are resolved ad-hoc, generally the same way that package namespace conflicts are; and in the case of a directory that's a capitalized form of the package name, there should be no namespace collision because package names must all be lowercase, so nothing else could claim precedence for this directory name. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: udev and /usr
On Sun, Sep 06, 2009 at 12:56:03AM +0200, Marco d'Itri wrote: > > > They are currently providing most of the manpower for developing udev > > > and the related infrastructure so this is pretty much the practical > > > effect, yes. > > So what, you think this means we don't have any right to object when they > > design things wrong? > No, I mean that after objecting and failing to have my objections > accepted, I have no other means of steering development in a different > direction. If you're unable to persuade upstream to change their implementation, and you're unwilling to diverge from upstream to ensure the package complies with Debian policy, your other option is to orphan the package and let someone maintain it who is willing to ensure it complies with Debian Policy. I don't mean to imply that this last is what you should do; I'm merely pointing out the set of options at your disposal. And pointing out that shipping a package that violates Debian Policy in such a blatant manner isn't one of those options. > I objected, multiple times, alone, and then started a discussion here. > What did *you* do other than accusing me? I appreciate that you took the time to bring this issue to the project's attention. What I don't appreciate is your statement that you don't intend to do anything about it (there's a policy violation, one of your packages is involved; it's your responsibility as a maintainer to help find a solution), or your claims that we shouldn't care about FHS compliance if Red Hat and SuSE don't. As for me, what I am doing is making sure I have all the facts so that I can take this issue upstream as you suggested. > > Violating the FHS is incompetent by definition and any resulting design is > > unreliable. > Maybe you were not involved with FSSTND and FHS development at the time, > but in multiple occasions it was modified to reflect what distributions > actually wanted to implement of previous versions of the specification, > like when /usr/libexec and /var/state were added and then removed again > (it was about 1997). > I was following FHS development at the time and I remember it. I am familiar with the history of the FHS. It's normal that in the process of drafting a standard, people will take into account the prevailing real-world practices, to ensure that the standard will be useful. Once something *is a standard*, you don't arbitrarily change what you're doing and claim that it still complies with the standard because "the standard follows what Red Hat does". The FHS as part of Debian Policy is a promise to our users that they can rely on the system working a certain way. It's not ok for *any* upstream to force us to break that promise, no matter how important they think they are. > > That bug was reopened as a result of a conversation I had with Martin and > > Scott in response to this precise thread. I was hoping Scott would be able > > to shed some light on the motivation for this goofy design, but he was just > > as much in the dark regarding the reason this was added and wasn't aware of > > the FHS problem that had been introduced. > But he was aware of other /usr-related issues in udev, and his answer > was that Ubuntu does not support standalone /usr filesystems. Do you have a pointer to where he said this, or was this another unlogged IRC discussion? The last time you made this claim, I asked Scott about it and he denied that this was his position. Given that there has quite specifically been work put into making /usr-on-a-separate-filesystem work in Ubuntu in the last release cycle (work that unfortunately has been undone to some degree by devicekit without anyone noticing until now), I would like to make sure we do have a shared understanding of how this is supposed to work, but it's hard to do this when all I have is hearsay. > > Do you have a reference to a thread where someone upstream has acknowledged > > the existence of this FHS bug and proceeded to implement this anyway? > There was at least > http://article.gmane.org/gmane.linux.hotplug.devel/14384 , but most > discussions happened on IRC where everybody else involved explained in > no uncertain terms that they do not want to support a standalone /usr > filesystem. Ok, thanks for the reference. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: The future of the boot system in Debian
Could someone please point me to a discussion on the pros and cons of upstart that was not funded by that spacecowboy shuttleworth? Michael Biebl wrote: Petter Reinholdtsen wrote: The future of the boot system in Debian === [..] The planned time frame for this is to replace /sbin/init with upstart for Squeeze, and see if we manage to change the very early boot to [..] Petter Reinholdtsen, Kel Modderman, Armin Berres Due to an oversight from my side, I missed to sign this announcement. As maintainer of upstart I obviously was involved in the discussion and planning and I support this plan. Regards, Michael -- 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
On Sep 05, Steve Langasek wrote: > > They are currently providing most of the manpower for developing udev > > and the related infrastructure so this is pretty much the practical > > effect, yes. > So what, you think this means we don't have any right to object when they > design things wrong? No, I mean that after objecting and failing to have my objections accepted, I have no other means of steering development in a different direction. I objected, multiple times, alone, and then started a discussion here. What did *you* do other than accusing me? > Violating the FHS is incompetent by definition and any resulting design is > unreliable. Maybe you were not involved with FSSTND and FHS development at the time, but in multiple occasions it was modified to reflect what distributions actually wanted to implement of previous versions of the specification, like when /usr/libexec and /var/state were added and then removed again (it was about 1997). I was following FHS development at the time and I remember it. > That bug was reopened as a result of a conversation I had with Martin and > Scott in response to this precise thread. I was hoping Scott would be able > to shed some light on the motivation for this goofy design, but he was just > as much in the dark regarding the reason this was added and wasn't aware of > the FHS problem that had been introduced. But he was aware of other /usr-related issues in udev, and his answer was that Ubuntu does not support standalone /usr filesystems. > Do you have a reference to a thread where someone upstream has acknowledged > the existence of this FHS bug and proceeded to implement this anyway? There was at least http://article.gmane.org/gmane.linux.hotplug.devel/14384 , but most discussions happened on IRC where everybody else involved explained in no uncertain terms that they do not want to support a standalone /usr filesystem. > You most certainly are arguing for a side, and it's not for the side that > you have an obligation to as a Debian developer. I love when people know what I think better than I do... -- ciao, Marco signature.asc Description: Digital signature
Re: DeviceKit and /usr
On Sep 05, Goswin von Brederlow wrote: > It is my understanding that the events get triggered in/before the > initramfs and need to be replayed after switching to / already. > How is replaying them when entering runlevel 2 any different from > that? The main issue is that the rules which run in the initramfs have almost no side effects (almost no RUN rules, etc). -- ciao, Marco signature.asc Description: Digital signature
Re: DeviceKit and /usr
On Sat, Sep 05, 2009 at 11:02:51AM +0200, Hendrik Sattler wrote: > Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek: > > On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote: > > > And it is also very unclear to me why this has to be in /lib/udev at > > > all. > > Because it provides a single point where the desktop hooks into the kernel > > hotplug event system, instead of having hal redo all the work already done > > by udev. /That/ much has a sound rationale, even if reading text databases > > in does not. > It's still no rationale at all to use libglib. Which is not the question I was answering. But if you were just having a rhetorical rant instead of trying to understand, then ok - noted. The rationale for this /using glib/ is that devicekit-disks is not an integral part of udev, it's an add-on component that will be installed only on desktop systems. So the size impact to /lib for servers for this component would be negligible; the total size impact of pulling in libglib on the desktop is zero; and the size impact to /lib for desktops is almost certainly also negligible. The upshot is that we almost certainly will have to move glib to /lib, because there's no way we're going to persuade the devicekit authors that they should avoid using libglib when it's already in /lib on all the systems they care about (so it's not an FHS violation anyway), and I don't think you're going to find anyone willing to maintain a devicekit fork either. (I'll do you one better, though -- system-config-printer upstream wants to install /lib/udev/udev-configure-printer, which pulls in the entire libcups stack. Sigh...) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: For the grub maintainers II
On Saturday 05 September 2009, Frans Pop wrote: > It has never been intended to be used as part of an update-grub script > and to be run every time the bootloader configuration is updated > because a new/updated kernel was installed or one of the packages that > affect an initrd (udev, mdcfg, lvm, ...) are updated. Basically: you do not want to have some script load every available file system kernel module available on the system at random moments, nor do you want to have that script regularly scan all partitions on your system, including any removable storage medium. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: For the grub maintainers II
Philipp Kern wrote: > Do you have os-prober installed? I would not recommend having os-prober installed for this. os-prober has always been intended to be run only _once_, mostly when a new system is installed. It exists as a .deb to be used for example after a debootstrap installation of a system (i.e. an install that did not use D-I). It could also be used to update the boot loader configuration, but IMO that should only happen by having the user run it explicitly. It has never been intended to be used as part of an update-grub script and to be run every time the bootloader configuration is updated because a new/updated kernel was installed or one of the packages that affect an initrd (udev, mdcfg, lvm, ...) are updated. Relying on os-prober to migrate from grub1 to grub2 is bad anyway as it will in no way preserve any existing manually added/changed boot menu entries. Migrating existing "other os" entries really needs to be solved in a different way. Cheers, FJP -- 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
On 2009-09-05, Goswin von Brederlow wrote: >>> Mounting NFS volumes from >>> the initramfs is probably not worth the effort. >> How do you make root on NFS work without this? > By building a kernel with nfsroot support and mounting without > locking and specific nfs version. > > I'm not sure if initramfs also supports it but I would rather doubt it > can build an initramfs with nfs support on its own. See /usr/share/initramfs-tools/scripts/nfs. (If I understood your concerns correctly; I'm doing NFS root with an initrd created by initramfs just fine.) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: apt-get not working anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Am Sa den 5. Sep 2009 um 20:06 schrieb Goswin von Brederlow: > % rmadison apt >apt | 0.6.46.4-0.1 | etch-m68k | source, m68k >apt | 0.6.46.4-0.1 | oldstable | source, alpha, amd64, arm, hppa, > i386, ia64, mips, mipsel, powerpc, s390, sparc >apt | 0.6.46.4-0.1+etch1 | oldstable-proposed-updates | source, alpha, > amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc >apt | 0.7.20.2+lenny1 |stable | source, alpha, amd64, arm, > armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc >apt | 0.7.20.2+squeeze1 | testing-proposed-updates | source, alpha, > amd64, armel, hppa, i386, ia64, mips, powerpc, s390, sparc >apt | 0.7.22.2 | testing | source, alpha, amd64, hppa, i386, > kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc >apt | 0.7.22.2+b2 | testing | armel, ia64 >apt | 0.7.23.1 | unstable | source, alpha, amd64, armel, hppa, > hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, > s390, sparc > > > Reduce your sources.list, possibly to just unstable main, apt-get update, > apt-get install apt, revert sources.list, enjoy. Uh, sorry to not making that clear enough. _I_ know how to (temporarily) fix that. But the problem is that the stable version has a hard limit which is not that far away from real setups. And I want not to hear the crying if every user add a bug report cause he is not able to fix it themself. And a simple upgrade to the unstable version is no solution as there is several dependencies which are incompatible between stable and unstable. (On my system this was only libapt-pkg-perl which makes several packages to get purged when installing the unstable version.) Am Sa den 5. Sep 2009 um 20:18 schrieb Hans-J. Ullrich: > APT::Cache-Limit "1"; Doesn't help as the limit is hard coded in apt. Just look at the source. The problem was fixed in versions after stable. Regards Klaus - -- Klaus Ethgenhttp://www.ethgen.de/ pub 2048R/D1A4EDE5 2000-02-26 Klaus Ethgen Fingerprint: D7 67 71 C4 99 A6 D4 FE EA 40 30 57 3C 88 26 2B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEVAwUBSqLNlp+OKpjRpO3lAQr25wf9G+SQXr3Nh2BUkuaaxfwrsjeiHwgUZJmJ OFCyfIF1wAeT7ZdM25OSOGyHACTRMvDgAFD9A/d8cdDmntGBV2Z5vpVBsbQr1pBt yCuNXdOdrLU84CwvCrCOl7Qbh9N8UkQ1+uPQVDw6lysq2dA2y1ZLroWKahATVB4g S0HJm0U/G3Gc7olv0U4854KtoC39ZsP3vqx7x/3T1BOk8lG94XTTmAEOocgyn7bJ Sf7/+fGx40RhIxQ8BzWjZtNwOKaogvfgg4BpBMnh+ac8zNgRhIpOwny/G8ClN1tZ fGndybfwPD4f1I15qsNnNlQIvUpuwqISI90x3o9PbsrheHedntiHpg== =fQXZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Joey Hess writes: > Charles Plessy: >> At least one of the consequences of being native is that the package gets all >> its gettext and manpages translations for free from Debian. In the case of >> programs like ikiwiki [..] > > AFAIK, any translator from Debian who has translated ikiwiki's gettext > or underlays (no man page translations ever contributed) has done so in > the knowledge that it is not specific to Debian. > > Gunnar Wolf: >> Do you want to throw stones in the way of Debian derivatives by being unable >> to do packaging-specific changes while keeping track of your upstream >> releases? > > I see our most modification-happy derivative, Ubuntu, frequently modify > native packages, with apparent success. > > I've never seen them or anyone reach for debhelper's --ignore flag, but > it is there in case there is some file in debian/ that the derivative does > not want used. I also would rather have a native package in Debian and then have Debian derivatives convert the package using Debians tar.gz as orig.tar.gz and put their derivate specific changes into diff.gz. Shipping a source with 0 byte diff.gz in Debian seems stupid and shipping a all of debian/ as diff.gz in Debian means the changes derivatives do get lost in a huge diff. Seems to me like a native package in Debian and non-native in a derivative is the best way. Now that all changes with the 3.0 formats. Then the could have: upstream.tar.gz debian.tar.gz derivative.diff.gz or upstream.tar.gz derivative.diff.gz That makes native or non-native in Debian equaly usefull to get changes back from derivatives. It is just a matter of making their build scripts build the right source packages. Something Debian could help teach dpkg-source. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: apt-get not working anymore
Am Samstag 05 September 2009 schrieb Goswin von Brederlow: > Klaus Ethgen writes: > > Hi, > > > > maybe that is an issue for debian-user, so I put it in the To too > > although I am not subscribed there. > > > > If you look to Bug #497617 there is a long time bug in apt first only > > targeting the German translations but now it is independent of the > > locales. > > > > When I run any apt-get command I get the error: > > E: Wow, you exceeded the number of versions this APT is capable of. > > E: Problem with MergeList > > /var/lib/apt/lists/debian.ethz.ch_mirror_debian_dists_experimental_main_b > >inary-i386_Packages E: The package lists or status file could not be > > parsed or opened. > > > > (The second line is just the one which is the drop too much.) > > > > This also happen with all locales set to "C". > > > > The problem is that it is not possible anymore to update the system at > > all. I think that is a very critical bug. > > > > Is it really necessary to break all installations until this bug is > > fixed? It is known long enough for now. > > > > I have the version 0.7.20.2+lenny1 installed, so it seems to be the most > > recent version. (apt-cache doesn't work too so I can only view the web > > site) > > > > Regards > >Klaus > Maybe this helps, as apt.conf is no more existent: add the following line in /etc/apt/apt.conf.d/20archive APT::Cache-Limit "1"; Hope this helps, as it increases memory. I know, this is only a workaround. Good luck! Hans-J. Ullrich -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: apt-get not working anymore
Klaus Ethgen writes: > Hi, > > maybe that is an issue for debian-user, so I put it in the To too > although I am not subscribed there. > > If you look to Bug #497617 there is a long time bug in apt first only > targeting the German translations but now it is independent of the > locales. > > When I run any apt-get command I get the error: > E: Wow, you exceeded the number of versions this APT is capable of. > E: Problem with MergeList > /var/lib/apt/lists/debian.ethz.ch_mirror_debian_dists_experimental_main_binary-i386_Packages > E: The package lists or status file could not be parsed or opened. > > (The second line is just the one which is the drop too much.) > > This also happen with all locales set to "C". > > The problem is that it is not possible anymore to update the system at > all. I think that is a very critical bug. > > Is it really necessary to break all installations until this bug is > fixed? It is known long enough for now. > > I have the version 0.7.20.2+lenny1 installed, so it seems to be the most > recent version. (apt-cache doesn't work too so I can only view the web > site) > > Regards >Klaus % rmadison apt apt | 0.6.46.4-0.1 | etch-m68k | source, m68k apt | 0.6.46.4-0.1 | oldstable | source, alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc apt | 0.6.46.4-0.1+etch1 | oldstable-proposed-updates | source, alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc apt | 0.7.20.2+lenny1 |stable | source, alpha, amd64, arm, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc apt | 0.7.20.2+squeeze1 | testing-proposed-updates | source, alpha, amd64, armel, hppa, i386, ia64, mips, powerpc, s390, sparc apt | 0.7.22.2 | testing | source, alpha, amd64, hppa, i386, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc apt | 0.7.22.2+b2 | testing | armel, ia64 apt | 0.7.23.1 | unstable | source, alpha, amd64, armel, hppa, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc Reduce your sources.list, possibly to just unstable main, apt-get update, apt-get install apt, revert sources.list, enjoy. MfG Goswin -- 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
Petter Reinholdtsen writes: > [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) Migth never happen. And since you can't rely on it ever happening you can just as well assume it never happens. Just ignore if / becomes read-write. > - 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) /usr might also never be read-write. But it might be missing at first. I don't realy see that there is an explicit stage where we have /var but not /usr. There is a stage where local filesystems are mounted and one where networking filesystems get mounted. But both /var and /usr could be local or networked. > 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 Just splitting into initramfs, only / read-only and everything seems sufficient. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Michael Biebl writes: > Gabor Gombas wrote: >> On Fri, Sep 04, 2009 at 06:43:35PM +0200, Michael Biebl wrote: >> >>> For your proposal to work, you'd need some kind of replay mechanism, which >>> allows udev to replay the add/remove events when /usr is available the >>> extended >>> ruleset is activated. >> >> You mean "udevadm trigger"? > > "udevadm trigger" afaik only works for coldplug events. It's also a very > costly > operation. So imho it would require a more elaborate mechanism to only replay > a > certain set of events, e.g. for rules files which failed (with e.g. a given > return code). > > Michael > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? It is my understanding that the events get triggered in/before the initramfs and need to be replayed after switching to / already. How is replaying them when entering runlevel 2 any different from that? Or am I wrong there? MfG Goswin -- 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 writes: > Le mardi 01 septembre 2009 à 10:32 +0200, Petter Reinholdtsen a écrit : >> In Debian, /usr/ is allowed to be on NFS. > > So is /. > >> Mounting NFS volumes from >> the initramfs is probably not worth the effort. > > How do you make root on NFS work without this? By building a kernel with nfsroot support and mounting without locking and specific nfs version. I'm not sure if initramfs also supports it but I would rather doubt it can build an initramfs with nfs support on its own. MfG Goswin -- 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
sean finney writes: > On Tue, Sep 01, 2009 at 03:01:35PM +0200, Giacomo A. Catenazzi wrote: >> Jonas Meurer wrote: >> >do we really consider to stop support for seperate /usr? after all fhs >> >supports seperate /usr by design. [1] >> >i hope that we keep fhs compability within debian. >> >> I agree, but the problem is "how?". > > i make no claims about the on-crackiness of the following suggestion, but: > what about smuggling such precious and required files into the initrd, > and either copying them at boot time or having a temporary bind-mount > to make them available until the real /usr can take over? > > > sean Bind mount / to // and install them to //usr/... as well as /usr/... That at least would be doable without breaking existing systems or forcing an imho bad partitioning on people. Like many people I have a small / partition (as raid1) and everything else in lvm. The size of / is relatively constant and I have plenty of breathing space there (still 40% free). The size of /usr on the other hand greatly varries depending on installed software and grows a lot over time, needs resizes. / must be outside LVM for so many reasons and /usr must be on lvm. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: For the grub maintainers II
On Sat, Sep 05, 2009 at 03:03:40PM +0200, Felix Zielcke wrote: > Robert filed already after the upload of grub-legacy a RC bug so it > doestn't migrate after the usual 10 days to testing. > > Note that we only Suggests: os-prober and not Recommend: it like Ubuntu > does because of 491872 > So if anyone want to help that we Recommend it again, then help the > os-prober maintainers to fix that bug. I don't know the specifics, but wouldn't it be possible for os-prober to create its own private mount name space (see clone(2), CLONE_NEWNS), and do the probing inside that name space? That way the desktop environments would not be able to intercept it. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Of the use of native packages for programs not specific to Debian.
Charles Plessy: > At least one of the consequences of being native is that the package gets all > its gettext and manpages translations for free from Debian. In the case of > programs like ikiwiki [..] AFAIK, any translator from Debian who has translated ikiwiki's gettext or underlays (no man page translations ever contributed) has done so in the knowledge that it is not specific to Debian. Gunnar Wolf: > Do you want to throw stones in the way of Debian derivatives by being unable > to do packaging-specific changes while keeping track of your upstream > releases? I see our most modification-happy derivative, Ubuntu, frequently modify native packages, with apparent success. I've never seen them or anyone reach for debhelper's --ignore flag, but it is there in case there is some file in debian/ that the derivative does not want used. -- see shy jo, who maintains non-debian-specific native packages including alien, etckeeper, filters, ikiwiki, jetring, moreutils, mpdtoys, mr, pdmenu, pristine-tar, sleepd, wmbattery; and prefers not to deal with source format 1.0 non-native packages. signature.asc Description: Digital signature
Re: The future of the boot system in Debian
Petter Reinholdtsen wrote: > The future of the boot system in Debian > === [..] > > The planned time frame for this is to replace /sbin/init with upstart > for Squeeze, and see if we manage to change the very early boot to [..] > Petter Reinholdtsen, Kel Modderman, Armin Berres Due to an oversight from my side, I missed to sign this announcement. As maintainer of upstart I obviously was involved in the discussion and planning and I support this plan. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: For the grub maintainers II
Am Samstag, den 05.09.2009, 15:04 +0200 schrieb Hans-J. Ullrich: > Additionally to that, my very own grub configuration with special > settings > (including a self created starting image) was not overtaken. > > So it would be nice, if the maintainers might include an option or > script, > which is importing the settings of grub-legacy. I also have to > friends, which > are also using debian, but who are not as experienced as me. Would be > nice, if > this importing would be as easy as possible. Anyone is free to provide such a script. But note that a `very own grub configuration with special settings' isn't easy to adapt to the GRUB 2 way. You can't just edit grub.cfg directly, you have to edit in /etc/grub.d/ Well you could just make a new file with them but then it wouldn't change anything with our defaults. -- Felix Zielcke Proud Debian Maintainer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: update-inetd migration to dpkp-triggers
On Fri, Sep 04, 2009 at 10:02:21PM -0700, Steve Langasek wrote [edited]: > On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote: > Invocations of update-inetd that lead to local policy overrides are bugs in > the caller, not in update-inetd. There is an explicitly reserved comment > string (##) for the only case relevant for package use. Indeed, many maintainer scripts are buggy, largely because documentation is unhpelful on how update-inetd should be used by postinst and postrm scripts. Some scripts override the default comment string (or equally worse, add entries with service names like "## ftp"), some use --disable instead of --remove in postrm ... you get the idea :) > > and doesn't support xinetd (#8927) > > This is a bug, yes. > > > The Rosy Future > > > * update-inetd will drop its current switches to > > add/remove/enable/disable services; > > This doesn't sound like a good idea; it sounds like a transition that's > going to break a lot of packages (either silently or noisily, depending on > the implementation). How do you intend to transition away from this without > either a) dropping existing package-provided entries on the floor, or b) > leaving packages with no way to clean up those same entries? This is meant to be in squeeze+1, at which point all update-inetd using deamon packages must be modified to install a fragment in /etc/inetd.conf.d/ instead of using --add. In that mode of operation --remove will not be applicable (fragments will be left behind, as is the case with xinetd). As for enable/disable, they shouldn't be used by maintainer scripts in the first place. > > * abolish /etc/inetd.conf and /etc/xinetd.d/ and instead auto-generate > > /var/lib/update-inetd/inetd.conf and auto-populate fragments in > > /var/lib/update-inetd/xinetd.d/ using xinetd fragments installed by deamon > > packages in /etc/inetd.conf.d/ > > Likewise, then, what happens to existing entries in /etc/xinetd.d? Just to clarify, this whole section refers to squeeze+1. As long as /etc/inetd.conf and /etc/xinetd.d/ exist, update-inetd will use them as input, along with /etc/inetd.conf.d/, to update /var/lib/update-inetd. update-inetd will print a warning asking the user to migrate all settings to /etc/inetd.conf.d and rename /etc/inetd.conf and /etc/xinetd.d (or have a --migrate switch to do so, but only to be invoked by the user) > > * document that local policy will live in /etc/inetd.conf.d/ and any manual > > changes will be made effective by running update-inetd > > I think this violates the principle of least surprise (restarting the daemon > after making your changes has been enough to make those changes take effect > since the inception of these daemons), and will be displeasing to many > admins as a result. This is a justified concern but I think it's a price we need to pay to be able to support both inetd and xinetd with a single source of policy. The need to run update-inetd will be remarked wherever we document that the new local policy has moved to /etc/inetd.conf.d. The number of steps remains the same though (instead of reloading inetd, one will have to run update-inetd) > > * all (4) superservers will lookup their config under /var/lib/update-inetd/ > > > * after deamon package installations, update-inetd will be invoked via a > > file > > trigger on /etc/inetd.conf.d/ to update the (x)inetd's actual > > configuration > > under /var/lib/ and reload (x)inetd > > This part seems reasonable. > > > How to Get There > > > The migration could(?) be done within one stable release, but I assume a > > more > > conservative approach over two releases. > > > * squeeze > > * all deamon packages that use update-inetd [1]: > > * should version-depend in the update-inetd version that is shipped > > in > > squeeze (so that /etc/inetd.conf.d/ is in place) > > * should install xinetd fragments in /etc/inetd.conf.d/ (and in > > /etc/xinetd.d/ if they did so already) > > * must continue calling update-inetd in postinst/prerm scripts as > > before > > * update-inetd will: > > * install /etc/inetd.conf.d/ and declare file-trigger interest in it > > * keep the old functionality, but additionally to updating > > /etc/inetd.conf, also update /var/lib/update-inetd/* using as > > input > > both /etc/inetd.conf and /etc/inetd.conf.d (and /etc/xinetd.d if > > installed) > > So with these packages that are calling update-inetd *and* installing a > snippet, what ends up being copied to /var/lib? The logic that combines /etc/inetd.conf and /etc/inetd.conf.d/ will have to filter out duplicates. On a second thought though, there's not much point in populating /var/lib in squeeze as it won't be used until inetds are patched (in squeeze+1). > > * update-inetd must: > > * sync effective inetd configurations based on /etc/inetd.conf.d/ > > and > > r
Re: For the grub maintainers II
Am Samstag 05 September 2009 schrieb Norbert Preining: > Already reported as a bug, but I think that should be discussed here, too. > > Upgrading to grub-pc does not carry over static stanza for Windows, nor > does the os-detecting code find my Windows on sda2. > > Since that is one of the most common szenaria (dual booting) I consider > the sole idea of generally switching to grup-pc a bit to early. > > That should be fixed first before even thinking about replacing > or using it as default boot loader. > > Best wishes > > Norbert I can confirm this. It was the main reason, why i still stay with grub-legacy. Additionally to that, my very own grub configuration with special settings (including a self created starting image) was not overtaken. So it would be nice, if the maintainers might include an option or script, which is importing the settings of grub-legacy. I also have to friends, which are also using debian, but who are not as experienced as me. Would be nice, if this importing would be as easy as possible. Best regards Hans -- 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
Hi,
One of the features missing in upstart that is present in
sysvinit is that the latter loads SELinux security policy early in the
boot sequence, and the former does not (please correct me if this is not
the case). I would be happy to help integrate selinux into upstart,
if that is the future of booting in Debian.
Having /sbin/init load the security policy is good because:
a) Doing it in an init script makes it easier to by pass security by
running another script earlier (so a malicious superuser may
trivially bypass security on reboot). This is even harder to prevent
using an event based system.
b) Using an init script makes it impossible to enforce security
policies and access control over which files /sbin/init may read,
c) Since it is compiled in, there is no dependency on things in
/usr/bin -- like load_policy, which also needs libsepol1 from /usr,
which is not small,
d) Putting policy loading in initramfs is bad for two reasons:
i) It means we would not longer suport SELinux use without having to
use initramfs -- my machines do not use either an initramfs, nor
modules -- which is easy when using custome kernels, and I think
is a use case Debian should continue to support
ii) We would need to either patch something in the initramfs to link
with libselinux1, to load policy directly, or we will have to
load into the initramfs load_policy and libsepol1 from /usr,
Adding a couple f small hunks to whatever provides /sbin/init
seems easier.
e) At this point, we only have two candidates for /sbin/init, sysvinit
and upstart, so the burden of writing patches is no onerous, and in
any case, I am volunteering to help create the patches.
manoj
ps: The sysvinit patches are rather small, and just two chunks (apart
from header includes. This is in init.c:
--8<---cut here---start->8---
#ifdef WITH_SELINUX
if (getenv("SELINUX_INIT") == NULL && !is_selinux_enabled()) {
putenv("SELINUX_INIT=YES");
if (selinux_init_load_policy(&enforce) == 0 ) {
execv(myname, argv);
} else {
if (enforce > 0) {
/* SELinux in enforcing mode but load_policy failed */
/* At this point, we probably can't open /dev/console, so log()
won't work */
fprintf(stderr,"Unable to load SELinux Policy. Machine is
in enforcing mode. Halting now.\n");
exit(1);
}
}
}
#endif
/* Start booting. */
--8<---cut here---end--->8---
This is in src/sulogin.c
--8<---cut here---start->8---
#ifdef WITH_SELINUX
if (is_selinux_enabled > 0) {
security_context_t scon=NULL;
char *seuser=NULL;
char *level=NULL;
if (getseuserbyname("root", &seuser, &level) == 0)
if (get_default_context_with_level(seuser, level, 0, &scon) >
0) {
if (setexeccon(scon) != 0)
fprintf(stderr, "setexeccon faile\n");
freecon(scon);
}
free(seuser);
free(level);
}
#endif
execl(sushell, shell, NULL);
perror(sushell);
--8<---cut here---end--->8---
--
It is easier to resist at the beginning than at the end. Leonardo da
Vinci
Manoj Srivastava
Re: RFC round 5: DEP-3: Patch Tagging Guidelines
On Tue, Sep 01, 2009 at 07:32:55PM +0200, Julien Cristau wrote: > On Wed, Aug 26, 2009 at 01:56:35 +0200, Raphael Hertzog wrote: > > > Hello, > > > > I made some last changes to the DEP following round 4. You'll find them > > below. > > I plan to switch the DEP's status to CANDIDATE since it's about time to > > start > > using this new format to try it out. Once I've done this, I'll announce it > > on > > d-d-a to encourage people to start using it. > > > > Current version: http://dep.debian.net/deps/dep3/ > > > FWIW, I'm not going to use something that I can't produce with git > format-patch and feed to git send-email / git am since that feels like > busy work; in particular the Author and Description fields are not > needed given there's From and Subject with the same information. I tried to point that out in June: http://lists.debian.org/debian-devel/2009/06/msg00551.html but failed. It'd be really helpful if DEP-3 would be compatible with the git format-patch output. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Policy of capitalisation of in /usr/share/?
Dear all I recently posted bug #545127 (see [1]) as I noticed that the package `publican' stores some shared files in /usr/share/Publican/ but stores its documentation in /usr/share/doc/publican/. As an end user, I expected /usr/share/publican/, given that the package name is `publican'. However, the upstream package uses /usr/share/Publican/. The Debian Maintainer (Mikahil Gusarov, in CC) does not wish to change the upstream source without a good reason, and that is perfectly understandable. The Debian Policy [2] has two places in which it says something about /usr/share/: sections 8.2 (Shared library support files) and 10.7.3 (Configuration Files > Behavior). However, according to Mikhail both sections are not applicable, either because there are currently no shared packages or because `publican' has no ./configure. [Correct me if I'm wrong, Mikhail.] Mikhail suggests to change some of the wording in the policy under 10.7.3 (see [1]). I see a few options here: - the policy does not cover this issue, and it is up to the the Debian Maintainer to decide how the directory in /usr/share/ is called; - the policy requires that directories in /usr/share/ be exactly /usr/share//. Given that must use lowercase letters (Debian Policy 5.6.1). Most packages already do this, but this would affect some packages like X11 or PolicyKit, as Mikhail Gusarov noted; - the policy recommends /usr/share//, unless it is too difficult to implement. I would be most grateful if anyone could clarify this situation. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545127 [2] http://www.debian.org/doc/debian-policy/ Best regards -- Danai SAE-HAN (韓達耐) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#545127: Policy of capitalisation of in /usr/share/?
Twas brillig at 15:08:10 05.09.2009 UTC+02 when da...@debian.org did gyre and gimble: DS> The Debian Policy [2] has two places in which it says something DS> about /usr/share/: sections 8.2 (Shared library support files) and DS> 10.7.3 (Configuration Files > Behavior). However, according to DS> Mikhail both sections are not applicable, either because there are DS> currently no shared packages or because `publican' has no DS> ./configure. [Correct me if I'm wrong, Mikhail.] Let me elaborate a bit. Publican is pure-Perl application with arch-indep data stored under /usr/share/Publican. 8.2 talks about shared library support files, and recommends using /usr/share/ in order to avoid conflicts between libfooN and libfooM. 10.7.3 talks about `package-configure' auxiliary files for maintainer scripts, Publican does not use such thing. 10.7.3 refers to /usr/share/ and /usr/lib/, though there is no requirement to use such directories, so I'd change it to say `arch-indep or arch-dep directories used by package'. -- http://fossarchy.blogspot.com/ pgpxQl3GD93I5.pgp Description: PGP signature
Re: For the grub maintainers II
Am Samstag, den 05.09.2009, 14:37 +0200 schrieb Norbert Preining: > Already reported as a bug, but I think that should be discussed here, too. > > Upgrading to grub-pc does not carry over static stanza for Windows, nor > does the os-detecting code find my Windows on sda2. > > Since that is one of the most common szenaria (dual booting) I consider > the sole idea of generally switching to grup-pc a bit to early. > > That should be fixed first before even thinking about replacing > or using it as default boot loader. > Robert filed already after the upload of grub-legacy a RC bug so it doestn't migrate after the usual 10 days to testing. Note that we only Suggests: os-prober and not Recommend: it like Ubuntu does because of 491872 So if anyone want to help that we Recommend it again, then help the os-prober maintainers to fix that bug. -- Felix Zielcke Proud Debian Maintainer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: For the grub maintainers II
On 2009-09-05, Norbert Preining wrote: > Already reported as a bug, but I think that should be discussed here, too. > > Upgrading to grub-pc does not carry over static stanza for Windows, nor > does the os-detecting code find my Windows on sda2. Do you have os-prober installed? Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
For the grub maintainers II
Already reported as a bug, but I think that should be discussed here, too. Upgrading to grub-pc does not carry over static stanza for Windows, nor does the os-detecting code find my Windows on sda2. Since that is one of the most common szenaria (dual booting) I consider the sole idea of generally switching to grup-pc a bit to early. That should be fixed first before even thinking about replacing or using it as default boot loader. Best wishes Norbert --- Dr. Norbert Preining Vienna University of Technology Debian Developer Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- SCRAMOGE (vb.) To cut oneself whilst licking envelopes. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#545151: ITP: libnatspec -- a library for national and language-specific issues
Package: wnpp Severity: wishlist Owner: "Andrew O. Shadoura" * Package name: libnatspec Version : 0.2.4 Upstream Authors: Vitaly Lipatov , Pavel Vainerman * URL : http://natspec.sourceforge.net/ * License : LGPL2.1 Programming Lang: C Description : a library for national and language-specific issues This library provides userful functions for dealing with locales and charsets. Natspec helps to solve most problems related to text reencoding. It enhances portability and allows projects not to try to deal with lanuage-specific issues themselves. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Am Samstag 05 September 2009 11:20:06 schrieb Michael Biebl:
> Hendrik Sattler wrote:
> > Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek:
> >> On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote:
> >>> And it is also very unclear to me why this has to be in /lib/udev at
> >>> all.
> >>
> >> Because it provides a single point where the desktop hooks into the
> >> kernel hotplug event system, instead of having hal redo all the work
> >> already done by udev. /That/ much has a sound rationale, even if
> >> reading text databases in does not.
> >
> > It's still no rationale at all to use libglib. Even d-bus is not a
> > reason, it is possible to use it without using gobject. If it isn't, fix
> > libdbus first or don't use it.
>
> I'm not sure why you bring up libdbus/dbus, but a quick look at dbus'
> dependencies will show you that it doesn't require libglib.
This refers to the previously mentioned URL
http://article.gmane.org/gmane.linux.gentoo.devel/62973:
"These extras are:
[...]
* gudev: glib/gobject support for libudev"
Additionally, further down the thread:
"This is the interface almost everything is going to turn to with GNOME
2.28 (via DeviceKit-power and DeviceKit-disks in most cases). By the
time GNOME 2.30 and 3.0 are released, (theoretically) nothing will use
HAL."
and
"all current DeviceKit-{power,disks} versions *need* gudev."
And that is usually about the usage of dbus.
HS
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Hendrik Sattler wrote:
> "This is the interface almost everything is going to turn to with GNOME
> 2.28 (via DeviceKit-power and DeviceKit-disks in most cases). By the
> time GNOME 2.30 and 3.0 are released, (theoretically) nothing will use
> HAL."
> and
> "all current DeviceKit-{power,disks} versions *need* gudev."
>
> And that is usually about the usage of dbus.
DeviceKit-{power,disks} talk to udev directly via lib(g)udev, there is no dbus
involved there.
So I'm still not quite sure yet, what point you are trying to make.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Re: DeviceKit and /usr
Hendrik Sattler wrote: > Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek: >> On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote: >>> And it is also very unclear to me why this has to be in /lib/udev at >>> all. >> Because it provides a single point where the desktop hooks into the kernel >> hotplug event system, instead of having hal redo all the work already done >> by udev. /That/ much has a sound rationale, even if reading text databases >> in does not. > > It's still no rationale at all to use libglib. Even d-bus is not a reason, it > is possible to use it without using gobject. If it isn't, fix libdbus first > or > don't use it. I'm not sure why you bring up libdbus/dbus, but a quick look at dbus' dependencies will show you that it doesn't require libglib. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: DeviceKit and /usr
Gabor Gombas wrote: > On Fri, Sep 04, 2009 at 06:43:35PM +0200, Michael Biebl wrote: > >> For your proposal to work, you'd need some kind of replay mechanism, which >> allows udev to replay the add/remove events when /usr is available the >> extended >> ruleset is activated. > > You mean "udevadm trigger"? "udevadm trigger" afaik only works for coldplug events. It's also a very costly operation. So imho it would require a more elaborate mechanism to only replay a certain set of events, e.g. for rules files which failed (with e.g. a given return code). Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: DeviceKit and /usr
Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek: > On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote: > > And it is also very unclear to me why this has to be in /lib/udev at > > all. > > Because it provides a single point where the desktop hooks into the kernel > hotplug event system, instead of having hal redo all the work already done > by udev. /That/ much has a sound rationale, even if reading text databases > in does not. It's still no rationale at all to use libglib. Even d-bus is not a reason, it is possible to use it without using gobject. If it isn't, fix libdbus first or don't use it. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
On Fri, Sep 04, 2009 at 06:43:35PM +0200, Michael Biebl wrote: > For your proposal to work, you'd need some kind of replay mechanism, which > allows udev to replay the add/remove events when /usr is available the > extended > ruleset is activated. You mean "udevadm trigger"? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: For the grub maintainers
Am Samstag, den 05.09.2009, 10:43 +0200 schrieb Norbert Preining: > On Sa, 05 Sep 2009, Felix Zielcke wrote: > > > How should the upgrade in sid work? At least aptitude does not find > > > a working upgrade path from -57 to -58 ... > > > > The problem was that grub-pc had an unversioned Conflicts: grub > > That has been fixed in the tonight uploaded 1.97~beta2-2. > > Thanks. > > Other question, why does the upgrade to grup-pc (and removing normal grub) > create a config file with a warning: > > Generating grub.cfg ... > Found Debian background: moreblue-orbit-grub.png > Found linux image: /boot/vmlinuz-2.6.31-rc8 > Found initrd image: /boot/initrd.img-2.6.31-rc8 > Found linux image: /boot/vmlinuz-2.6.31-rc7 > Found initrd image: /boot/initrd.img-2.6.31-rc7 > Found linux image: /boot/vmlinuz-2.6.30 > Found initrd image: /boot/initrd.img-2.6.30 > Warning: update-grub_lib is deprecated, use grub-mkconfig_lib instead > Found memtest86+ image: /boot/memtest86+.bin > done The memtest86+ entry is generated by /etc/grub.d/20_memtest86+ which the memtest86+ package provides, not by us. Already reported as #543213 -- Felix Zielcke Proud Debian Maintainer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: For the grub maintainers
On Sa, 05 Sep 2009, Felix Zielcke wrote: > > How should the upgrade in sid work? At least aptitude does not find > > a working upgrade path from -57 to -58 ... > > The problem was that grub-pc had an unversioned Conflicts: grub > That has been fixed in the tonight uploaded 1.97~beta2-2. Thanks. Other question, why does the upgrade to grup-pc (and removing normal grub) create a config file with a warning: Generating grub.cfg ... Found Debian background: moreblue-orbit-grub.png Found linux image: /boot/vmlinuz-2.6.31-rc8 Found initrd image: /boot/initrd.img-2.6.31-rc8 Found linux image: /boot/vmlinuz-2.6.31-rc7 Found initrd image: /boot/initrd.img-2.6.31-rc7 Found linux image: /boot/vmlinuz-2.6.30 Found initrd image: /boot/initrd.img-2.6.30 Warning: update-grub_lib is deprecated, use grub-mkconfig_lib instead Found memtest86+ image: /boot/memtest86+.bin done ?? Best wishes Norbert --- Dr. Norbert Preining Vienna University of Technology Debian Developer Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- LYDIARD TREGOZE (n.) The opposite of a mavis enderby (q.v.) An unrequited early love of your life who still causes terrible pangs though she inexplicably married a telephone engineer. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: For the grub maintainers
Am Samstag, den 05.09.2009, 10:33 +0200 schrieb Norbert Preining: > Cannot reply so sorry for breaking the thread. > > How should the upgrade in sid work? At least aptitude does not find > a working upgrade path from -57 to -58 ... The problem was that grub-pc had an unversioned Conflicts: grub That has been fixed in the tonight uploaded 1.97~beta2-2. -- Felix Zielcke Proud Debian Maintainer -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
For the grub maintainers
Cannot reply so sorry for breaking the thread. How should the upgrade in sid work? At least aptitude does not find a working upgrade path from -57 to -58 ... Best wishes Norbert --- Dr. Norbert Preining Vienna University of Technology Debian Developer Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- LOUTH (n.) The sort of man who wears loud check jackets, has a personalised tankard behind the bar and always gets served before you do. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the GRUB maintainers
Hi! On Fri, Sep 4, 2009 at 9:21 PM, Robert Millan wrote: > > Hi, > > As you may have noticed, upgrades of the GRUB Legacy package (`grub') > in unstable have begun using GRUB 2 (`grub-pc' package) as upgrade > path. This means that tentatively, GRUB 2 is to be considered the > option for Lenny to Squeeze upgrades. It should also become the option > for new Squeeze installs. > > This decision is not final yet! We're looking for feedback on this > transition. First and foremost, we need people to test GRUB 2 on their > machines and report any issues that they may find. > > GRUB 2 features a cleaner design, and is much more robust than its > predecessor. Also, unlike GRUB Legacy it's under active development. > > Nervertheless, we're aware that for a minority of users, upgrading is > not currently an option, because they rely on specific features of > GRUB Legacy that GRUB 2 doesn't provide. For those users, GRUB Legacy > will continue being supported, at least up untill the Squeeze release. > Works for me, on ~20 Servers running kvm / openvz / xen / vserver works for me on ~5 desktops (dell optiplex) works for me on 3 laptops (ibm x40-x61) Keep up your great work! /me loves grub2 regs, klaus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
