Bug#278442: RFH: athcool -- Enable powersaving mode for Athlon/Duron processors
Package: wnpp Severity: normal I request assistance with maintaining the athcool package. The package description is: athcool is a small utility for enabling/disabling Powersaving mode for AMD Athlon/Duron processors. . By enabling Powersaving mode you can lower power consumption and CPU temperature when the CPU is idle. . Powersaving works only if your kernel supports ACPI (APM does not work), because athcool does only (un)set the "Disconnect enable when STPGNT detected" bits in the Chipset's Northbridge. To really save power, the STPGNT signal has to be sent when the CPU is idling. This is done by the ACPI subsystem when C2 state entered. . !!!WARNING!!! Depending on your motherboard and/or hardware components, enabling Athlon powersaving mode sometimes causes: . * noisy or distorted sound playback, * a slowdown in harddisk performance, * system locks or instability, * massive corruption of the filesystem (observed at least once). . If you met those problems, you should not use athcool. Please use athcool AT YOUR OWN RISK. . If athcool works fine for you, and you want it to run automatically on startup, please read the /usr/share/doc/athcool/README.Debian file. Unfortunately, I only own one athlon-based system, which means I'm unable to test athcool on most supported systems. Hence, I'd like some volunteers to test athcool on as many different systems as possible, and to try to reproduce the bugs that are reported. If you own an athlon-based computer and want to help me with athcool, please send me an e-mail and tell me what kind of motherboard/CPU you own. FYI, I currently need someone with a VIA KT600 or KT400 chipset to try to reproduce bug #276757 on both kind of systems. Thanks in advance, Nicolas Boullis
Bug#281759: general: Cannot 'eject' a CDROM as normal user
Hi, On Wed, Nov 17, 2004 at 06:05:47PM +0100, Leszek Koltunski wrote: > > So, the question is: why is /dev/hdc owned by 'disk' in Sarge? Does it > have to be so for some reason? If not, I'd suggest to change that to > 'cdrom' as it seems to help with ejecting... I guess it is simply not owned by cdrom because /dev/hdc might as well be a hard drive (in which case giving read/write permission to users would be stupid ans unsecure). On the other hand, if you were using a 2.6 kernel with udev, /dev/hdc would be owned by group cdrom (assuming it is a CD/DVD drive). Regards, Nicolas
removing in postrm rc*.d symlinks that I did not create
Hi folks, A package of mine installs an init script. But as the corresponding programs plays with the motherboard's chipset configuration, it is quite prone to break the system. So I chose not to install rc*.d symlinks by default. To make life easier for users, i explain in a README file how to set up those links and how to remove them with apdate-rc.d. Hence, when a user is convinced this program does not break his system, he can easily set up the links for automatic startup. But a user felt concerned that, in the future, he may remove the package and forget to delete the links. Then I thought I could remove the links in postrm on purge, considering they are part of the package's configuration (their absence being the default configuration). I built the package, but lintian complains: E: athcool: postrm-contains-additional-updaterc.d-calls /etc/init.d/athcool N: N: The postrm de-registers an /etc/init.d script which has not been N: registered in the postinst script before. I lintian right here? Should I ignore this error? Any other suggestion to answer my user's concerns? Thanks in advance for any feedback, Nicolas
Re: removing in postrm rc*.d symlinks that I did not create
Hi, On Wed, Dec 15, 2004 at 04:33:49PM -0800, Russ Allbery wrote: > > A technique that I've used in packages with this issue is to install the > rc*.d symlinks by default, but also have the init script check a file in > /etc/default to see whether or not to actually start at boot. If you > install a default /etc/default file that says not to start, you accomplish > the same thing, don't have this problem, and make it just as easy for > users to enable the package. Thanks for your suggestion. I already thought about it, but I fnind it quite confusing when I cannot run /etc/init.d/foobar by hand as soon as it is not enabled on startup. Cheers, Nicolas
Re: removing in postrm rc*.d symlinks that I did not create
Hi, On Wed, Dec 15, 2004 at 08:47:43PM -0600, John Hasler wrote: > Your script should check $PRERUNLEVEL. It will be N if you are booting. That's a nice idea, but do you know how fine it would behave with things like file-rc? Nicolas
Re: removing in postrm rc*.d symlinks that I did not create
Hi, On Thu, Dec 16, 2004 at 09:32:08AM +0100, Javier Fernández-Sanguino Peña wrote: > > Well, you could have a message saying that you need to enable foo and a > 'force-start' action that started it regardless of what's in /etc/default. That might be a solution. Users would certainly be less confused, but some scripts they would have written would still be... > Moreover, the script could check if it's being called on startup (it's name > is 'S') and heed the default value and start anyway if called from the > command line. I think such a solution was suggested in an ancient thread, and it was concluded that it would not work with file-rc... > There are plenty of ways to avoid that confusion. There certainly are some workarounds, but my initial question is still unanswered: is it ok to remove the links if I did not create them but told the user how to create them? Nicolas
Re: removing in postrm rc*.d symlinks that I did not create
On Thu, Dec 16, 2004 at 12:53:27AM -0500, sean finney wrote: > On Thu, Dec 16, 2004 at 12:34:21AM +0100, Nicolas Boullis wrote: > > But a user felt concerned that, in the future, he may remove the package > > and forget to delete the links. Then I thought I could remove the links > > in postrm on purge, considering they are part of the package's > > configuration (their absence being the default configuration). > > if the package is removed, the init script should just exit with 0 > status. removing the links during purge would also be appropriate. So you think lintian is wrong to complain? > you could also install the links by default, but have some other > variable in /etc/default/$package control whether or not it actually > starts (i think somebody else has mentioned this too). Yes, I know such solutions but don't like them much. But if "my" solution is proved to be wrong, I'll implement such a workaround... Nicolas
Re: removing in postrm rc*.d symlinks that I did not create
Hi, On Thu, Dec 16, 2004 at 09:13:43AM +0100, Adrian von Bidder wrote: > On Thursday 16 December 2004 00.34, Nicolas Boullis wrote: > [de-installing run-level links that weren't installed] > > How about installing links as /etc/rc?.d/K??foo - so the links are there and > are properly manageable, but the init script will only be called as 'K??foo > stop' Unfortunately, athcool is not a deamon but a program that modifies some low-level configuration. Hence, running "/etc/init.d/athcool stop" actually does something (and might break the system) as badly as "/etc/init.d/athcool start"... I like the idea, but I'm afraid it's not appropriate for athcool, at least without reworking the init script... Cheers, Nicolas
DD needing a sponsor to upload
Hi, As I moved recently, I currently have no decent Internet connectivity. Hence, I'm quite unable to keep an unstable system up-to-date, si I can't build packages to upload. Several packages of mine are in need of an upload, especially libcdio and vcdimager. I have uploaded the source packages to my debian homepage on http://people.debian.org/~nboullis. Could someone please build the binary packages and upload for me? (As far as I know source-only uploads are not allowed, and anyway, I can't be sure it'll work fine with an up-to-date sid; I only tested with a one month old sarge.) Thanks in advance, Nicolas Boullis PS: please CC your replies to me (MFT set accordingly) as I currently can't track d-d. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DD needing a sponsor to upload
Hi, On Sun, Feb 06, 2005 at 08:53:52PM +1100, Anibal Monsalve Salazar wrote: > Changes: > vcdimager (0.7.21-1) unstable; urgency=low > . >* New upstream release. >* Rebuild against libcdio3 and libiso9600-3. >* Hack ltmain.sh to build programs with rpath as .libs/lt/foobar rather > than .libs/lt-foobar. >* Regenerate the manpages accordingly. > > Does the new vcdimager version fix the RC bug #290685? You're quite right, I somehow forgot the Closes: parts in the changelog... I just reuploaded the source package. Would you build and upload for me? Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
self-depending packages
Hi, Trying to upgrade a woody system to sarge, I experienced problems upgrading libgtk2.0-0, and discovered that this packages was self-depending. Afetr forcing the upgrade with "dpkg -i --force-depends", everything went smoothly. So I filed a bug against libgtk2.0-0. Then I discovered that I could upgrade this package from woody to sarge with no trouble in a clean pbuilder chroot. So the problem might me more complex. However, from this bug report began a discussion with Loic Minier about self-dependencies and circular dependencies. Readibg policy 7.2, I see: " Depends This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured. " My understanding is that a self-depending package must be configured before it can be configured, which makes it unconfigurable, and hence uninstallable. And I think the same reasoning can be applied to circular dependencies. But Loic disagrees. What is the opinion of others? Shouldn't policy be more explicit about circular (and self) dependencies? Moreover, I just wrote a small python script that looks for self-dependencies in sarge, and found those packages: libtabe2 libtextwrap1 gnustep-back libbonoboui2-0 libgail-common libbonobo2 libgtk2.0-0 Should a bug be filed against those packages? Cheers, Nicolas PS: please CC your replies to me, as I am currently quite unable to track debian-devel. (MFT set accordingly) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Spliting packages between pkg and pkg-data
On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote: > Hello Debian developers, > > When doing research about circular-deps, I looked at a lot of packages > that are split between a binary package and a data package. This is a > good thing since this reduce the total siez of the archive, however > there are simple rules that should be followed: > > 3) Keep the files that 'signal' executables in the same package than the >executable (e.g. menu file, program manpage). Why? I agree that it menu files and manpages are generally not that large, but what would it break to have them in pkg-data? (I would consider it strange to have such files out of the main pkg package, but it looks policy-compliant as far as I can see...) Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Spliting packages between pkg and pkg-data
Hi, On Sun, Nov 20, 2005 at 12:39:24PM -0800, Russ Allbery wrote: > Nicolas Boullis <[EMAIL PROTECTED]> writes: > > On Sun, Nov 20, 2005 at 12:13:48PM +0100, Bill Allombert wrote: > > >> 3) Keep the files that 'signal' executables in the same package than the > >>executable (e.g. menu file, program manpage). > > > Why? I agree that it menu files and manpages are generally not that > > large, but what would it break to have them in pkg-data? > > (I would consider it strange to have such files out of the main pkg > > package, but it looks policy-compliant as far as I can see...) > > Well, one practical concern is that it makes it harder for other utilities > like lintian to analyze the package properly. Well, that's an argument I don't like. Those are tools that help us check our packages are correct, but I don't think it is reasonable to modify otherwise correct package only to make such tools happy. For the same reason, I'm not happy with setting lintian overrides, as I consider it bloats the packages for no good reason (although the "bloat" is very limited"). Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: db.debian.org (and related infrastructure) updates
Hi, On Sat, Dec 30, 2006 at 04:31:12PM +0100, Joerg Jaspert wrote: > - the birthDate field isn't currently available via the mail daemon, >this will be fixed soon. What about gender? How is it specified? with a ldapsearch, I can find 1, 2 and 9... Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#375412: ITP: vdr-plugin-dxr3 -- Plugin to vdr to use a DXR3/Hollywood+ MPEG decoder as primary interface
Package: wnpp Severity: wishlist Owner: Nicolas Boullis <[EMAIL PROTECTED]> * Package name: vdr-plugin-dxr3 Version : 0.2.6 Upstream Author : Kai Moeller <[EMAIL PROTECTED]>, Stefan Schluenss <[EMAIL PROTECTED]>, Christian Gmeiner , ...and numerous others, see CONTRIBUTORS. * URL : http://sourceforge.net/projects/dxr3plugin/ * License : GPL Programming Lang: C++ Description : Plugin to vdr to use a DXR3/Hollywood+ MPEG decoder as primary interface This plugin for vdr allows using a DXR3/Hollywood+ MPEG decoder card as primary interface. This package will be maintained within the "Debian VDR Team <[EMAIL PROTECTED]>". -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental'), (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.1-irma Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building kernel modules for stock kernels is a hell of a job!
Hi, On Mon, Sep 29, 2003 at 01:43:05PM -0400, David Z Maze wrote: > I don't consider it a bug. I do think the kdist and kdist_image > targets should reinvoke make under $(ROOT_CMD), though, just to be > sure. The i2c-source debian/rules file has: > > kdist_image: > $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules binary-modules > $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean > > kdist: > $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules binary-modules > dpkg-genchanges -b -e"$(KMAINT) <$(KEMAIL)>" -u"$(KSRC)/.." > > $(CHFILE) > debsign -e"$(KMAINT) <$(KEMAIL)>" $(CHFILE) > $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean > > kdist_clean: > $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean Are those $(MFLAGS) really useful? I thought they were not because $(MAKE) also had the flags, but I'm not sure anymore... Regards, Nicolas
Re: Building kernel modules for stock kernels is a hell of a job!
Hi, On Tue, Sep 30, 2003 at 12:27:29AM +0200, Eduard Bloch wrote: > > > kdist_clean: > > > $(ROOT_CMD) $(MAKE) $(MFLAGS) -f debian/rules clean > > > > Are those $(MFLAGS) really useful? > > I thought they were not because $(MAKE) also had the flags, but I'm not > > sure anymore... > > MFLAGS are the flags that make got on the commandline. The calls above > copy the make call with options. Well, I just checked the gnu make manual (section 5.6.3) and, if I understand it correctly, it says that using $(MFLAGS) is now useless thanks to the $(MAKEFLAGS) variable... Is there something wrong with my inderstanding of this manual? Or is this a gnu-only feature, that we should not depend on? Regards, Nicolas
A new way to specify versionned dependencies may be needed
Hi, One package of mine needs to conflict with a few consecutive versions of a package. Let's say that the package foo introduced a feature that conflicts with my package in version A and removed it in version B. So I'd like my package to conflict with versions A to B of foo. I tried to specify it with "Conflicts: foo (>> A), foo (<< B)" but, as I feared, it does not work since it now conflicts both with all versions >> A and with all versions << B (as A << B, that means all versions). Is there a way to specify such a conflict? Listing all the versions would work, but that's not really convenient... Any suggestion is welcome. Hence, I think a new way to specify versionned relationship between packages might be useful. For example, the conflict I need might be written as "Conflicts: foo (>> A, << B)". Is such a feature planned for the future? It's certainly too late to have something for sarge, so it certainly won't be implemented before sarge+1, and we won't be able to use it before sarge+2. Currently, there's no need for such a feature for positive dependencies (Depends, Recommends and Suggests), because there is a workaround: "Depends: foo (>> A), foo (<< B)" works for "Depends: foo (>> A, << B)", but it only works because only one version of foo can be installed at a time. If versionned provides are ever implemented, it may become possible to have several versions of a package at a time, thus breaking this workaround. Any comment? Nicolas
Re: A new way to specify versionned dependencies may be needed
Hi, On Fri, Oct 03, 2003 at 09:19:39AM +0200, Dagfinn Ilmari Mannsåker wrote: > > So I'd like my package to conflict with versions A to B of foo. I tried > > to specify it with "Conflicts: foo (>> A), foo (<< B)" but, as I feared, > > it does not work since it now conflicts both with all versions >> A and > > with all versions << B (as A << B, that means all versions). > > How about "Depends: foo (<< A) | foo (>> B)"? No, my package does not depend in any way on foo. Depending on foo only to prevent a few specific versions of foo to be installed would be evil, AFAICS... > > Currently, there's no need for such a feature for positive dependencies > > (Depends, Recommends and Suggests), because there is a workaround: > > "Depends: foo (>> A), foo (<< B)" works for "Depends: foo (>> A, << B)", > > but it only works because only one version of foo can be installed at a > > time. If versionned provides are ever implemented, it may become > > possible to have several versions of a package at a time, thus breaking > > this workaround. > > The above will also break if versioned provides are implemented. Which "The abobe"? Your "Depends: foo (<< A) | foo (>> B)"? Or my "Depends: foo (>> A, << B)"? I can't see why mine would be broken. Did I miss something? Regards, Nicolas
Re: A new way to specify versionned dependencies may be needed
(Sorry Daniel for first sending this e-mail to you only by mistake.) Hi, On Fri, Oct 03, 2003 at 04:06:42PM -0400, Daniel Jacobowitz wrote: > On Fri, Oct 03, 2003 at 09:55:09PM +0200, Nicolas Boullis wrote: > > Hi, > > > > On Fri, Oct 03, 2003 at 09:19:39AM +0200, Dagfinn Ilmari Mannsåker wrote: > > > > > > So I'd like my package to conflict with versions A to B of foo. I tried > > > > to specify it with "Conflicts: foo (>> A), foo (<< B)" but, as I > > > > feared, > > > > it does not work since it now conflicts both with all versions >> A and > > > > with all versions << B (as A << B, that means all versions). > > > > > > How about "Depends: foo (<< A) | foo (>> B)"? > > > > No, my package does not depend in any way on foo. Depending on foo only > > to prevent a few specific versions of foo to be installed would be evil, > > AFAICS... > > The best extant solution to this is just to Conflicts: foo (<= B). > Forcing an upgrade isn't such a bad thing... Well, that depends. For example, if testing as a version << A of foo, and we are getting close to a release, conflicting with that version for no good reason would be somewhat broken. (That's roughly the current situation with foo=dvb-dev, A=1.0.0, B=1.0.1 and my package=em8300-headers.) Moreover, that does not answer to my real question: is there a good reason not to implement such an extended syntax for versionned relationships. If there is no good reason, I might try to implement such a thing and provide it to the maintainers of dpkg... Regards, Nicolas
lintian: postinst-does-not-load-confmodule
Hi, I was about to upload a new release of one of my packages, but lintian complains that "postinst-does-not-load-confmodule". Running lintian with -i, I can get more information: N: Even if your postinst does not involve debconf, you currently need to N: make sure it loads one of the debconf libraries. This will be changed N: in the future. I can't understand why I should load anything related to debconf, if I don't use debconf in postinst. (I use debconf in preinst and config, where I load it with ". /usr/share/debconf/confmodule".) What am I missing? Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Please help me make athcool compatible with dependency-based init systems (was: Release Update: freeze, architecture requalification)
Hi, Disclaimer: I've been pretty busy recently, not giving my Debian packages the care and love they deserve. That's why I'm now asking for help, somewhat late... On Sat, Jul 19, 2008 at 03:35:35PM +0200, Luk Claes wrote: > > * Prepare init.d-Scripts for dependency-based init systems > > Wider testing of dependency-based init systems has lead to some new bugs > for this goal, but the current state looks quite well. We are confident > that we will have full support for dep-based init system in lenny. One of my packages, namely athcool installs an init script that is not yet compatible with dependency-based init systems. For some reason, it was not detected by automatic systems such as lintian, and no bug was filed against it, and no-one cared about it yet. Athcool installs an init script but does not install links to run it on boot, and that might be the reason why lintian did not notice about it. (No startup link is installed because athcool causes bad stability issues on some systems. If one tests it and experiences such problems, the system is back to a normal state after a reboot.) Someone who is satisfied with athcool can run update-rc.d (as documented in /usr/share/doc/athcool/README.Debian) to enable startup links. I'd like to reproduce a similar behaviour with the headers for dependency-based init systems, but I know close to nothing about such systems. I read the corresponding section of the LSB, but it did not help me much. I guess I could set Default-Start and Default-Stop empty. But then I have no idea how I would document the enablement of startup links by the user. Since those keywords are called "Default", I guess there is a way to override them, but how? Or I think one might change the Default-Start and Default-Stop keyworks, but then who would they ask the system to take the change into account? Any help is welcome, especially as a patch or a NMU, but please don't forget the documentation issue. Thanks in advance, Nicolas PS: I have no time to read d-devel; please CC replies to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please help me make athcool compatible with dependency-based init systems (was: Release Update: freeze, architecture requalification)
Hi, As a follow-up to myself, and as suggested by Kel Modderman, please also CC replies to the developer list for initscripts-ng. (Full message kept for those people.) On Mon, Jul 21, 2008 at 11:33:10PM +0200, Nicolas Boullis wrote: > Hi, > > Disclaimer: I've been pretty busy recently, not giving my Debian > packages the care and love they deserve. That's why I'm now asking for > help, somewhat late... > > On Sat, Jul 19, 2008 at 03:35:35PM +0200, Luk Claes wrote: > > > > * Prepare init.d-Scripts for dependency-based init systems > > > > Wider testing of dependency-based init systems has lead to some new bugs > > for this goal, but the current state looks quite well. We are confident > > that we will have full support for dep-based init system in lenny. > > One of my packages, namely athcool installs an init script that is not > yet compatible with dependency-based init systems. For some reason, it > was not detected by automatic systems such as lintian, and no bug was > filed against it, and no-one cared about it yet. > > Athcool installs an init script but does not install links to run it on > boot, and that might be the reason why lintian did not notice about it. > (No startup link is installed because athcool causes bad stability > issues on some systems. If one tests it and experiences such problems, > the system is back to a normal state after a reboot.) Someone who is > satisfied with athcool can run update-rc.d (as documented in > /usr/share/doc/athcool/README.Debian) to enable startup links. > > I'd like to reproduce a similar behaviour with the headers for > dependency-based init systems, but I know close to nothing about such > systems. I read the corresponding section of the LSB, but it did not > help me much. I guess I could set Default-Start and Default-Stop empty. > But then I have no idea how I would document the enablement of startup > links by the user. Since those keywords are called "Default", I guess > there is a way to override them, but how? Or I think one might change > the Default-Start and Default-Stop keyworks, but then who would they ask > the system to take the change into account? > > Any help is welcome, especially as a patch or a NMU, but please don't > forget the documentation issue. > > > Thanks in advance, > > Nicolas > > > PS: I have no time to read d-devel; please CC replies to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please help me make athcool compatible with dependency-based init systems
Hi Kel, On Wed, Jul 23, 2008 at 11:55:04PM +1000, Kel Modderman wrote: > Hi Nicolas, > > Just add the LSB header with correct information like: > > ### BEGIN INIT INFO > # Provides: athcool > # Required-Start:$remote_fs > # Required-Stop: $remote_fs > # Default-Start: 2 3 4 5 > # Default-Stop: > # Description: enable powersaving mode for Athlon/Duron processors > ### END INIT INFO > > Your package does not call update-rc.d in postinst, courtesy of > "dh_installinit -n", therefore no links get created even on insserv system. > > There is no need to modify README.Debian instructions, as insserv package > provides an update-rc.d wrapper. When the admin follows the existing > instructions of "update-rc.d athcool start 20 2 3 4 5 ." you will get runlevel > links, just that the sequence number 20 is ignored and a more precise sequence > number is calculated by insserv. Thanks for your answer. Sorry for asking a potentially stupid question, but how does the "Default-Start" keyword affect the bahvior of the system? Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please help me make athcool compatible with dependency-based init systems
Hi, On Wed, Jul 23, 2008 at 11:36:01PM +0300, Teodor wrote: > On Wed, Jul 23, 2008 at 10:52 PM, Nicolas Boullis <[EMAIL PROTECTED]> wrote: > > Sorry for asking a potentially stupid question, but how does the > > "Default-Start" keyword affect the bahvior of the system? > > Refer to http://wiki.debian.org/LSBInitScripts for details. Maybe this > page should be updated for LSB 3.2? Well... I already read LSB, but there's nothing about how it really interacts with the system. What does "default" mean here? Does it affect update-rc.d? Is it used when insserv is enabled? I'd rather be sure that no-one will get startup links unwillingly, so I'd like to understand how it really affects things... (For example: one installs athcool, does not create startup links and then installs and enables insserv...) Cheers, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A new way to specify versionned dependencies may be needed
Hi, On Tue, Oct 07, 2003 at 05:03:19AM +1000, Anthony Towns wrote: > On Sat, Oct 04, 2003 at 01:46:08AM +0200, Nicolas Boullis wrote: > > Moreover, that does not answer to my real question: is there a good > > reason not to implement such an extended syntax for versionned > > relationships. > > Probably not; but there needs to be a good reason to do it. It has to > be implemented in dpkg, apt, testing, and everything else that worries > about conflicts, and to ensure upgrades work okay, can't be used for > a release after it's rolled out (so, assuming a release once a year, > not until early 2006). Do you care enough? I perfectly know that such a thing can't be available before sarge+1 at best. But AFAICS, such a thing would also be useful for "positive relationship" (depends, recommends, suggest). People currently specify things as "Depends: foo (>= 1.0.0-1), foo (< 1.0.1)". But that will break if more than one version of foo can coexist at a time. That's currently impossible, but that may become possible when versionned provides are available (if they ever become available). That is if foo-bar 0.9.9-1 "Provides: foo (= 0.9.9-1)" and foo-baz 1.0.1-1 "Provides: foo (= 1.0.1-1)", then having both would (wrongly) satisfy the "Depends: foo (>= 1.0.0-1), foo (< 1.0.1)" condition. Did I miss something obvious? Regards, Nicolas
Re: [ANNOUNCE] Debian Developer Packages Overview
Hi! This tool is great and very useful. However, there is a little bug with some kind of mangling of the version numbers: on "http://qa.debian.org/developer/index.php?package=loadwatch";, loadwatch appears to have 2 different versions in testing and unstable (1.0_1.1alpha1-1 and 1.0+1.1alpha1-1), while this is in fact the same version. Anyway, this tool is great. Thanks for your work. Nicolas
Re: Do not touch l10n files (was Re: DDTP issue)
Hi, On Tue, May 13, 2003 at 05:56:08PM +0200, Bill Allombert wrote: > Bonjour, > > I am french and I don't regard the 'Imprimerie Nationale' rules as binding. > We are still a free country. > > Do we have such standard document for the original english description ? > No, and there is no dedicated team to review them. > > I think we should focus on provided accurate description not > typographically correct one. Keeping things simple so that > Debian maintainers can understand what is coming along with the > translation is important, because they have the final responsibility > of the package. > > Telling them 'you do not speak french, so don't try to understand' is > not acceptable. I do speak french and I have often trouble to understand > myself. > > If you have a problem with the original translation, please ask the > maintainer before doing the translation. We should work with him and > not against him. You're probably right, those useless l10n teams are annoying. Anyway, translating is easy: let's ask google to translate our texts for us. It does not always very high quality results, but who cares if the typography and the grammar are not perfect? Anyone is able to understand, isn't it? > Amicalement, For those who don't understand french, that means "Friendly," and I think you're not very friendly with Denis... Regards, Nicolas
Re: Bug#140183: aspell does install or depend on any languages
Hi! When I read both your mail, I have the feeling that aspell should be split in 2 packages: aspell (which provides the spell-checking functionality, and depends on any dictionary) and aspell-dev (which provides the word-list generation functionality). And if you can't split both functionality, you may still have everything in aspell-dev and aspell depends on aspell-dev. Hence, packages would depend on aspell-dev instead of aspell, and no dictionary will be required. And users will still use aspell, which depends on a dictionnary, which seems more policy-compiant since most users consider aspell as a spell-checker... What about this suggestion? Regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
