Re: kbirthday - reminds you of birthdays it reads from KDE addressbook
Hallo! * Eike Sauer <[EMAIL PROTECTED]> wrote: > As I forgot two birthdays last year, I looked for some > program to remember me. Until now, I used kalarm, but > I had to tell it all birthdays I had already entered > in the KDE addressbook. [kbirthday] How about taking kickpim? It has this feature and also a basic access to the kadressbook (small editor, popup over a kontakt, "write a mail") and a pop and imap mailchecker. Access to mbox files and korganiser is on the TODO. I have it as a basic debian package, but I'm not fluent in c++ and native packages so I wouldn't want to package it... http://kickpim.sourceforge.net Jan
Re: kbirthday - reminds you of birthdays it reads from KDE addressbook
Hallo! * Eike Sauer <[EMAIL PROTECTED]> wrote: > As I forgot two birthdays last year, I looked for some > program to remember me. Until now, I used kalarm, but > I had to tell it all birthdays I had already entered > in the KDE addressbook. [kbirthday] How about taking kickpim? It has this feature and also a basic access to the kadressbook (small editor, popup over a kontakt, "write a mail") and a pop and imap mailchecker. Access to mbox files and korganiser is on the TODO. I have it as a basic debian package, but I'm not fluent in c++ and native packages so I wouldn't want to package it... http://kickpim.sourceforge.net Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[FIXED] Re: symlinks between two packages
Ainsi parla Nicolas Rueff le 315ème jour de l'an 2003: > Ainsi parla Andreas Metzler le 315ème jour de l'an 2003: > > > On Tue, Nov 11, 2003 at 01:23:32PM +0100, Nicolas Rueff wrote: > > > I'm attempting to become DD, so I'm currently packaging some > > > software. One of this software must be packaged in two parts: one > > > for the client part (tty/console), one for the X frontend, so the > > > X frontend package depends on the client package. > > > > > My problem is that the README and changelog files are the same for > > > both, so instead of install 2 times the same files. I attempt to > > > make symlinks from README and changelog from the X frontend > > > package to those from the client package, which seems correct > > > since the X frontend package depends on the client package, so > > > they will never be dead links. But lintian tells me that the > > > README and changelog files from the X frontend package are > > > zero-sized, which is quite normal since the links are broken while > > > they are not installed. > > > > > So should I install the same version for the two packages, or rely > > > on symlinks, ignoring lintians's errors ? > > > > The easy way around that is to make the complete directory > > /usr/share/doc/xfrontend a symlink to /usr/share/doc/client-part > > (policy 12.3). > > That seems to be what I'm looking for: > (from policy 12.3): /usr/share/doc/package may be a symbolic link to > another directory in /usr/share/doc only if the two packages both come > from the same source and the first package Depends on the second. All right, this was what I was looking for. Thank you Andreas. -- .,p**"*=b_ Nicolas Rueff ?P" .__ `*b Montbéliard - France |P .d?'`&, 9| http://rueff.tuxfamily.org M: |} |- H' [EMAIL PROTECTED] &| `#?_._oH' +33 6 77 64 44 80 `H. "`"`' GPG 0xDD44DAB4 `#?. ICQ 97700474 `^~. We are Penguin. Resistance is futile. You will be assimilated. -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/E/IT d- s:- a24>? C++ UL+++$ P++ L !E W+++ N++ o? K- w-- !O M- V-- !PS !PE !Y PGP+++ t+ 5 X+ R* tv++ b DI++ D++ G++ e+++ h r- y++ --END GEEK CODE BLOCK-- pgp0.pgp Description: PGP signature
kbirthday - reminds you of birthdays it reads from KDE addressbook
Hello! As I forgot two birthdays last year, I looked for some program to remember me. Until now, I used kalarm, but I had to tell it all birthdays I had already entered in the KDE addressbook. Kbirthday is a little kicker applet that reminds you of birthdays (and anniversaries). Unlike kalarm, it reads them from your KDE addressbook on it's own. This package realises the ITP (187563) of Ralph Nolden (as he has granted in private email). Package name: kbirthday Version : 0.7.1 URL : http://www.gfai.de/~jaham/projects/kbirthday/kbirthday.html License : GPL Description : reminds you of birthdays it reads from KDE addressbook Kbirthday is a kicker applet that reminds you of birthdays and anniversaries from your KDE addressbook. It uses the KDE addressbook API to access the addressbook data. So you can use your favourite addressbook frontend to manage your friends addresses, birthdays and anniversaries. The package has been built with pbuilder and is lintian and linda clean (thanks to the hint of Matt Zimmerman). The package itself and the files to build it can be found at: http://user.cs.tu-berlin.de/~eikes/debian/kbirthday/ I'm looking for someone to sponsor the upload. Ciao, Eike
[FIXED] Re: symlinks between two packages
Ainsi parla Nicolas Rueff le 315ème jour de l'an 2003: > Ainsi parla Andreas Metzler le 315ème jour de l'an 2003: > > > On Tue, Nov 11, 2003 at 01:23:32PM +0100, Nicolas Rueff wrote: > > > I'm attempting to become DD, so I'm currently packaging some > > > software. One of this software must be packaged in two parts: one > > > for the client part (tty/console), one for the X frontend, so the > > > X frontend package depends on the client package. > > > > > My problem is that the README and changelog files are the same for > > > both, so instead of install 2 times the same files. I attempt to > > > make symlinks from README and changelog from the X frontend > > > package to those from the client package, which seems correct > > > since the X frontend package depends on the client package, so > > > they will never be dead links. But lintian tells me that the > > > README and changelog files from the X frontend package are > > > zero-sized, which is quite normal since the links are broken while > > > they are not installed. > > > > > So should I install the same version for the two packages, or rely > > > on symlinks, ignoring lintians's errors ? > > > > The easy way around that is to make the complete directory > > /usr/share/doc/xfrontend a symlink to /usr/share/doc/client-part > > (policy 12.3). > > That seems to be what I'm looking for: > (from policy 12.3): /usr/share/doc/package may be a symbolic link to > another directory in /usr/share/doc only if the two packages both come > from the same source and the first package Depends on the second. All right, this was what I was looking for. Thank you Andreas. -- .,p**"*=b_ Nicolas Rueff ?P" .__ `*b Montbéliard - France |P .d?'`&, 9| http://rueff.tuxfamily.org M: |} |- H' [EMAIL PROTECTED] &| `#?_._oH' +33 6 77 64 44 80 `H. "`"`' GPG 0xDD44DAB4 `#?. ICQ 97700474 `^~. We are Penguin. Resistance is futile. You will be assimilated. -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/E/IT d- s:- a24>? C++ UL+++$ P++ L !E W+++ N++ o? K- w-- !O M- V-- !PS !PE !Y PGP+++ t+ 5 X+ R* tv++ b DI++ D++ G++ e+++ h r- y++ --END GEEK CODE BLOCK-- pgp1OXNfuIrl3.pgp Description: PGP signature
RFC: zorp and zorplibll packages
Hi! As my sponsor is very busy nowadays, would someone take a look at the new zorp and zorplibll packages? They are available at http://sourceforge.net/project/showfiles.php?group_id=93515 at the download area of the Official Unofficial Zorp project. I am not requesting an upload, just a check. Thank you for your help. -- GNU GPL: csak tiszta forrásból -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: zorp and zorplibll packages
Hi! As my sponsor is very busy nowadays, would someone take a look at the new zorp and zorplibll packages? They are available at http://sourceforge.net/project/showfiles.php?group_id=93515 at the download area of the Official Unofficial Zorp project. I am not requesting an upload, just a check. Thank you for your help. -- GNU GPL: csak tiszta forrásból
kbirthday - reminds you of birthdays it reads from KDE addressbook
Hello! As I forgot two birthdays last year, I looked for some program to remember me. Until now, I used kalarm, but I had to tell it all birthdays I had already entered in the KDE addressbook. Kbirthday is a little kicker applet that reminds you of birthdays (and anniversaries). Unlike kalarm, it reads them from your KDE addressbook on it's own. This package realises the ITP (187563) of Ralph Nolden (as he has granted in private email). Package name: kbirthday Version : 0.7.1 URL : http://www.gfai.de/~jaham/projects/kbirthday/kbirthday.html License : GPL Description : reminds you of birthdays it reads from KDE addressbook Kbirthday is a kicker applet that reminds you of birthdays and anniversaries from your KDE addressbook. It uses the KDE addressbook API to access the addressbook data. So you can use your favourite addressbook frontend to manage your friends addresses, birthdays and anniversaries. The package has been built with pbuilder and is lintian and linda clean (thanks to the hint of Matt Zimmerman). The package itself and the files to build it can be found at: http://user.cs.tu-berlin.de/~eikes/debian/kbirthday/ I'm looking for someone to sponsor the upload. Ciao, Eike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Init.d script, preventing start of one service
Hello, On Tue, Nov 11, 2003 at 06:04:31PM +0100, Andreas Metzler wrote: > I am redirecting to debian-mentors, imho the more appropriate list. > Thanks, i will continue go and look for it. > On Tue, Nov 11, 2003 at 04:27:03PM +0100, Sylvain LE GALL wrote: > > In one of the package i maitain i have a config script which begin by > > asking if the service attached to this package need to be run. I use a > > variable ( stored in /etc/default/mldonkey -- LAUNCH_AT_STARTUP="yes" ) > > to determine if i need to run the service or not. > > > If the variable is set to yes, the init script launch the service, > > otherwise it does nothing. > > I think that is the best solution currently possible. > > > The user ask me if i can use update-rc.d to create/remove symlink > > depending on the former LAUNCH_AT_STARTUP value. > > IMHO it is dubious whether you are allowed to do that, it would work > *basically*[1] like this in postinst: > -- > db_get mldonkey/runservice > runme="$RET" > if [ "$RET" = "true" ] > update-rc.d -f remove mldonkey > update-rc.d mldonkey defaults > else > update-rc.d -f remove mldonkey > update-rc.d mldonkey stop 20 > fi > ... > invoke-rc.d mldonkey start > -- > And invoke-rc.d will only start the service if it has a start-entry in > the sysvinit system for the current runlevel. > > The big problem is that you loose user configuration, i.e. if $user > has set up his system to run mldonkey only in runlevel5 you will nuke > it. > I totally agree on that... I think update-rc.d is admin stuff. ( i just want to use it for registering / unregistering init script ). > And there is no way around it, as it is impossible to query what links > currently exist. (You cannot do ls in the symlink-directories, see > file-rc), you may only interface with the init-stuff with invoke- and > update-rc.d. > > > What is the standard solution for doing this in debian? > > Afaict the standard solutions are: > - ship daemon and clients in separate packages (ftp, ssh, nfs, ...) to > circumvent the problem (no option for mldonkey afaict) > - Choose a default and let the user change it by hand instead of via > dpkg-reconfigure. > That is what is actually done ( mldonkey-server / mldonkey-client and LAUNCH_AT_STARTUP configure via dpkg-reconfigure ). Thanks for your repsonse Kind regard Sylvain LE GALL
Re: Init.d script, preventing start of one service
Hello, On Tue, Nov 11, 2003 at 06:04:31PM +0100, Andreas Metzler wrote: > I am redirecting to debian-mentors, imho the more appropriate list. > Thanks, i will continue go and look for it. > On Tue, Nov 11, 2003 at 04:27:03PM +0100, Sylvain LE GALL wrote: > > In one of the package i maitain i have a config script which begin by > > asking if the service attached to this package need to be run. I use a > > variable ( stored in /etc/default/mldonkey -- LAUNCH_AT_STARTUP="yes" ) > > to determine if i need to run the service or not. > > > If the variable is set to yes, the init script launch the service, > > otherwise it does nothing. > > I think that is the best solution currently possible. > > > The user ask me if i can use update-rc.d to create/remove symlink > > depending on the former LAUNCH_AT_STARTUP value. > > IMHO it is dubious whether you are allowed to do that, it would work > *basically*[1] like this in postinst: > -- > db_get mldonkey/runservice > runme="$RET" > if [ "$RET" = "true" ] > update-rc.d -f remove mldonkey > update-rc.d mldonkey defaults > else > update-rc.d -f remove mldonkey > update-rc.d mldonkey stop 20 > fi > ... > invoke-rc.d mldonkey start > -- > And invoke-rc.d will only start the service if it has a start-entry in > the sysvinit system for the current runlevel. > > The big problem is that you loose user configuration, i.e. if $user > has set up his system to run mldonkey only in runlevel5 you will nuke > it. > I totally agree on that... I think update-rc.d is admin stuff. ( i just want to use it for registering / unregistering init script ). > And there is no way around it, as it is impossible to query what links > currently exist. (You cannot do ls in the symlink-directories, see > file-rc), you may only interface with the init-stuff with invoke- and > update-rc.d. > > > What is the standard solution for doing this in debian? > > Afaict the standard solutions are: > - ship daemon and clients in separate packages (ftp, ssh, nfs, ...) to > circumvent the problem (no option for mldonkey afaict) > - Choose a default and let the user change it by hand instead of via > dpkg-reconfigure. > That is what is actually done ( mldonkey-server / mldonkey-client and LAUNCH_AT_STARTUP configure via dpkg-reconfigure ). Thanks for your repsonse Kind regard Sylvain LE GALL -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: symlinks between two packages
Ainsi parla Andreas Metzler le 315ème jour de l'an 2003: > On Tue, Nov 11, 2003 at 01:23:32PM +0100, Nicolas Rueff wrote: > > I'm attempting to become DD, so I'm currently packaging some > > software. One of this software must be packaged in two parts: one > > for the client part (tty/console), one for the X frontend, so the X > > frontend package depends on the client package. > > > My problem is that the README and changelog files are the same for > > both, so instead of install 2 times the same files. I attempt to > > make symlinks from README and changelog from the X frontend package > > to those from the client package, which seems correct since the X > > frontend package depends on the client package, so they will never > > be dead links. But lintian tells me that the README and changelog > > files from the X frontend package are zero-sized, which is quite > > normal since the links are broken while they are not installed. > > > So should I install the same version for the two packages, or rely > > on symlinks, ignoring lintians's errors ? > > The easy way around that is to make the complete directory > /usr/share/doc/xfrontend a symlink to /usr/share/doc/client-part > (policy 12.3). That seems to be what I'm looking for: (from policy 12.3): /usr/share/doc/package may be a symbolic link to another directory in /usr/share/doc only if the two packages both come from the same source and the first package Depends on the second. > If you don't want to do that a bugreport against lintian (and linda > too, if the bug applies) might be called for. I did this myself some > months ago (#181899 and #181900), the bugs where supposed to be fixed > but I did not do my home-work and doublecheck that. - Sorry. Well, if I found some time to spend on it, I'll try to fix it. Tks. -- .,p**"*=b_ Nicolas Rueff ?P" .__ `*b Montbéliard - France |P .d?'`&, 9| http://rueff.tuxfamily.org M: |} |- H' [EMAIL PROTECTED] &| `#?_._oH' +33 6 77 64 44 80 `H. "`"`' GPG 0xDD44DAB4 `#?. ICQ 97700474 `^~. We are Penguin. Resistance is futile. You will be assimilated. -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/E/IT d- s:- a24>? C++ UL+++$ P++ L !E W+++ N++ o? K- w-- !O M- V-- !PS !PE !Y PGP+++ t+ 5 X+ R* tv++ b DI++ D++ G++ e+++ h r- y++ --END GEEK CODE BLOCK-- pgpzvg2KCXaxm.pgp Description: PGP signature
Re: symlinks between two packages
Ainsi parla Andreas Metzler le 315ème jour de l'an 2003: > On Tue, Nov 11, 2003 at 01:23:32PM +0100, Nicolas Rueff wrote: > > I'm attempting to become DD, so I'm currently packaging some > > software. One of this software must be packaged in two parts: one > > for the client part (tty/console), one for the X frontend, so the X > > frontend package depends on the client package. > > > My problem is that the README and changelog files are the same for > > both, so instead of install 2 times the same files. I attempt to > > make symlinks from README and changelog from the X frontend package > > to those from the client package, which seems correct since the X > > frontend package depends on the client package, so they will never > > be dead links. But lintian tells me that the README and changelog > > files from the X frontend package are zero-sized, which is quite > > normal since the links are broken while they are not installed. > > > So should I install the same version for the two packages, or rely > > on symlinks, ignoring lintians's errors ? > > The easy way around that is to make the complete directory > /usr/share/doc/xfrontend a symlink to /usr/share/doc/client-part > (policy 12.3). That seems to be what I'm looking for: (from policy 12.3): /usr/share/doc/package may be a symbolic link to another directory in /usr/share/doc only if the two packages both come from the same source and the first package Depends on the second. > If you don't want to do that a bugreport against lintian (and linda > too, if the bug applies) might be called for. I did this myself some > months ago (#181899 and #181900), the bugs where supposed to be fixed > but I did not do my home-work and doublecheck that. - Sorry. Well, if I found some time to spend on it, I'll try to fix it. Tks. -- .,p**"*=b_ Nicolas Rueff ?P" .__ `*b Montbéliard - France |P .d?'`&, 9| http://rueff.tuxfamily.org M: |} |- H' [EMAIL PROTECTED] &| `#?_._oH' +33 6 77 64 44 80 `H. "`"`' GPG 0xDD44DAB4 `#?. ICQ 97700474 `^~. We are Penguin. Resistance is futile. You will be assimilated. -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/E/IT d- s:- a24>? C++ UL+++$ P++ L !E W+++ N++ o? K- w-- !O M- V-- !PS !PE !Y PGP+++ t+ 5 X+ R* tv++ b DI++ D++ G++ e+++ h r- y++ --END GEEK CODE BLOCK-- pgp0.pgp Description: PGP signature
Re: Init.d script, preventing start of one service
I am redirecting to debian-mentors, imho the more appropriate list. On Tue, Nov 11, 2003 at 04:27:03PM +0100, Sylvain LE GALL wrote: > In one of the package i maitain i have a config script which begin by > asking if the service attached to this package need to be run. I use a > variable ( stored in /etc/default/mldonkey -- LAUNCH_AT_STARTUP="yes" ) > to determine if i need to run the service or not. > If the variable is set to yes, the init script launch the service, > otherwise it does nothing. I think that is the best solution currently possible. > The user ask me if i can use update-rc.d to create/remove symlink > depending on the former LAUNCH_AT_STARTUP value. IMHO it is dubious whether you are allowed to do that, it would work *basically*[1] like this in postinst: -- db_get mldonkey/runservice runme="$RET" if [ "$RET" = "true" ] update-rc.d -f remove mldonkey update-rc.d mldonkey defaults else update-rc.d -f remove mldonkey update-rc.d mldonkey stop 20 fi ... invoke-rc.d mldonkey start -- And invoke-rc.d will only start the service if it has a start-entry in the sysvinit system for the current runlevel. The big problem is that you loose user configuration, i.e. if $user has set up his system to run mldonkey only in runlevel5 you will nuke it. And there is no way around it, as it is impossible to query what links currently exist. (You cannot do ls in the symlink-directories, see file-rc), you may only interface with the init-stuff with invoke- and update-rc.d. > What is the standard solution for doing this in debian? Afaict the standard solutions are: - ship daemon and clients in separate packages (ftp, ssh, nfs, ...) to circumvent the problem (no option for mldonkey afaict) - Choose a default and let the user change it by hand instead of via dpkg-reconfigure. > ps : i know ssh use a file to launch or not sshd, is it a good > solution? Imnsho it is worse than using the default-file. - The default file at least provides a rather standardized location. cu andreas [1] There is lots of sugar-coating necessary, you don't want remove+(set again) if there was no change. -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash"
Re: Init.d script, preventing start of one service
I am redirecting to debian-mentors, imho the more appropriate list. On Tue, Nov 11, 2003 at 04:27:03PM +0100, Sylvain LE GALL wrote: > In one of the package i maitain i have a config script which begin by > asking if the service attached to this package need to be run. I use a > variable ( stored in /etc/default/mldonkey -- LAUNCH_AT_STARTUP="yes" ) > to determine if i need to run the service or not. > If the variable is set to yes, the init script launch the service, > otherwise it does nothing. I think that is the best solution currently possible. > The user ask me if i can use update-rc.d to create/remove symlink > depending on the former LAUNCH_AT_STARTUP value. IMHO it is dubious whether you are allowed to do that, it would work *basically*[1] like this in postinst: -- db_get mldonkey/runservice runme="$RET" if [ "$RET" = "true" ] update-rc.d -f remove mldonkey update-rc.d mldonkey defaults else update-rc.d -f remove mldonkey update-rc.d mldonkey stop 20 fi ... invoke-rc.d mldonkey start -- And invoke-rc.d will only start the service if it has a start-entry in the sysvinit system for the current runlevel. The big problem is that you loose user configuration, i.e. if $user has set up his system to run mldonkey only in runlevel5 you will nuke it. And there is no way around it, as it is impossible to query what links currently exist. (You cannot do ls in the symlink-directories, see file-rc), you may only interface with the init-stuff with invoke- and update-rc.d. > What is the standard solution for doing this in debian? Afaict the standard solutions are: - ship daemon and clients in separate packages (ftp, ssh, nfs, ...) to circumvent the problem (no option for mldonkey afaict) - Choose a default and let the user change it by hand instead of via dpkg-reconfigure. > ps : i know ssh use a file to launch or not sshd, is it a good > solution? Imnsho it is worse than using the default-file. - The default file at least provides a rather standardized location. cu andreas [1] There is lots of sugar-coating necessary, you don't want remove+(set again) if there was no change. -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Modifying other packages' conffiles: the not-so-ideal way
On Tue, Nov 11, 2003 at 03:17:10PM +0100, Frank Küster wrote: > Andreas Metzler <[EMAIL PROTECTED]> schrieb: > > On Tue, Nov 11, 2003 at 11:16:39AM +0100, Frank Küster wrote: > >> policy says in section 10.7.4: > > > >> , > >> | If it is desirable for two or more related packages to share a > >> | configuration file and for all of the related packages to be able to > >> | modify that configuration file, then the following should be done: [...] > >> ` > > [...] > >> , > >> | The maintainer scripts must not alter a conffile of any package > >> ` > > > > You are mixing up "conffile" and "configuration-file". > No, I don't think so. A conffile usually is a configuration file, > too. Yes. My point was the mentioning of policy's shared configuration-files and "conffiles" in one mail. Shared configuration-files in this sense cannot be conffiles, ever. Rereading the original mail, I see that you are aware of the difference, I was just too daft. > /etc/pcmcia/network.opts is a conffile of pcmcia-cs, and it is a > configuration file that has to be edited by the user to make it work. > In this case, a user of my package (netenv) would have to a add a couple > of lines to it - or, as I said, a script or maintainer script could do > it for him. It must not be a maintainer-script or a script invoked by a maintainer-script (Just for the archive, I don't you think are not aware of that.) > A package with similar functionality, whereami, yet has > its additions added to this file (and /etc/pcmcia/network). Your course of action, contacting the maintainer, seems to be the correct one. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash"
Re: Modifying other packages' conffiles: the not-so-ideal way
On Tue, Nov 11, 2003 at 03:17:10PM +0100, Frank Küster wrote: > Andreas Metzler <[EMAIL PROTECTED]> schrieb: > > On Tue, Nov 11, 2003 at 11:16:39AM +0100, Frank Küster wrote: > >> policy says in section 10.7.4: > > > >> , > >> | If it is desirable for two or more related packages to share a > >> | configuration file and for all of the related packages to be able to > >> | modify that configuration file, then the following should be done: [...] > >> ` > > [...] > >> , > >> | The maintainer scripts must not alter a conffile of any package > >> ` > > > > You are mixing up "conffile" and "configuration-file". > No, I don't think so. A conffile usually is a configuration file, > too. Yes. My point was the mentioning of policy's shared configuration-files and "conffiles" in one mail. Shared configuration-files in this sense cannot be conffiles, ever. Rereading the original mail, I see that you are aware of the difference, I was just too daft. > /etc/pcmcia/network.opts is a conffile of pcmcia-cs, and it is a > configuration file that has to be edited by the user to make it work. > In this case, a user of my package (netenv) would have to a add a couple > of lines to it - or, as I said, a script or maintainer script could do > it for him. It must not be a maintainer-script or a script invoked by a maintainer-script (Just for the archive, I don't you think are not aware of that.) > A package with similar functionality, whereami, yet has > its additions added to this file (and /etc/pcmcia/network). Your course of action, contacting the maintainer, seems to be the correct one. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: symlinks between two packages
On Tue, Nov 11, 2003 at 01:23:32PM +0100, Nicolas Rueff wrote: > I'm attempting to become DD, so I'm currently packaging some software. > One of this software must be packaged in two parts: one for the client > part (tty/console), one for the X frontend, so the X frontend package > depends on the client package. > My problem is that the README and changelog files are the same for both, > so instead of install 2 times the same files. I attempt to make > symlinks from README and changelog from the X frontend package to those > from the client package, which seems correct since the X frontend > package depends on the client package, so they will never be dead links. > But lintian tells me that the README and changelog files from the X > frontend package are zero-sized, which is quite normal since the links > are broken while they are not installed. > So should I install the same version for the two packages, or rely on > symlinks, ignoring lintians's errors ? The easy way around that is to make the complete directory /usr/share/doc/xfrontend a symlink to /usr/share/doc/client-part (policy 12.3). If you don't want to do that a bugreport against lintian (and linda too, if the bug applies) might be called for. I did this myself some months ago (#181899 and #181900), the bugs where supposed to be fixed but I did not do my home-work and doublecheck that. - Sorry. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash"
Re: symlinks between two packages
On Tue, Nov 11, 2003 at 01:23:32PM +0100, Nicolas Rueff wrote: > I'm attempting to become DD, so I'm currently packaging some software. > One of this software must be packaged in two parts: one for the client > part (tty/console), one for the X frontend, so the X frontend package > depends on the client package. > My problem is that the README and changelog files are the same for both, > so instead of install 2 times the same files. I attempt to make > symlinks from README and changelog from the X frontend package to those > from the client package, which seems correct since the X frontend > package depends on the client package, so they will never be dead links. > But lintian tells me that the README and changelog files from the X > frontend package are zero-sized, which is quite normal since the links > are broken while they are not installed. > So should I install the same version for the two packages, or rely on > symlinks, ignoring lintians's errors ? The easy way around that is to make the complete directory /usr/share/doc/xfrontend a symlink to /usr/share/doc/client-part (policy 12.3). If you don't want to do that a bugreport against lintian (and linda too, if the bug applies) might be called for. I did this myself some months ago (#181899 and #181900), the bugs where supposed to be fixed but I did not do my home-work and doublecheck that. - Sorry. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Modifying other packages' conffiles: the not-so-ideal way
Andreas Metzler <[EMAIL PROTECTED]> schrieb: > On Tue, Nov 11, 2003 at 11:16:39AM +0100, Frank Küster wrote: >> policy says in section 10.7.4: > >> , >> | If it is desirable for two or more related packages to share a >> | configuration file and for all of the related packages to be able to >> | modify that configuration file, then the following should be done: >> | >> |1. One of the related packages (the "owning" package) will manage >> |the configuration file with maintainer scripts as described in the >> |previous section. >> | >> |2. The owning package should also provide a program that the other >> |packages may use to modify the configuration file. >> | >> |3. The related packages must use the provided program to make any >> |desired modifications to the configuration file. >> ` > [...] >> , >> | The maintainer scripts must not alter a conffile of any package >> ` > > You are mixing up "conffile" and "configuration-file". No, I don't think so. A conffile usually is a configuration file, too. /etc/pcmcia/network.opts is a conffile of pcmcia-cs, and it is a configuration file that has to be edited by the user to make it work. In this case, a user of my package (netenv) would have to a add a couple of lines to it - or, as I said, a script or maintainer script could do it for him. A package with similar functionality, whereami, yet has its additions added to this file (and /etc/pcmcia/network). Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Re: Modifying other packages' conffiles: the not-so-ideal way
Andreas Metzler <[EMAIL PROTECTED]> schrieb: > On Tue, Nov 11, 2003 at 11:16:39AM +0100, Frank Küster wrote: >> policy says in section 10.7.4: > >> , >> | If it is desirable for two or more related packages to share a >> | configuration file and for all of the related packages to be able to >> | modify that configuration file, then the following should be done: >> | >> |1. One of the related packages (the "owning" package) will manage >> |the configuration file with maintainer scripts as described in the >> |previous section. >> | >> |2. The owning package should also provide a program that the other >> |packages may use to modify the configuration file. >> | >> |3. The related packages must use the provided program to make any >> |desired modifications to the configuration file. >> ` > [...] >> , >> | The maintainer scripts must not alter a conffile of any package >> ` > > You are mixing up "conffile" and "configuration-file". No, I don't think so. A conffile usually is a configuration file, too. /etc/pcmcia/network.opts is a conffile of pcmcia-cs, and it is a configuration file that has to be edited by the user to make it work. In this case, a user of my package (netenv) would have to a add a couple of lines to it - or, as I said, a script or maintainer script could do it for him. A package with similar functionality, whereami, yet has its additions added to this file (and /etc/pcmcia/network). Bye, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need a mentor with a !x86 machine
Bob Proulx wrote: John Lightsey wrote: If anyone with a non-x86 machine would like to take a look again and give feedback on wheter or not it compiles properly, I'd really appreciate it. The build logs that I recieved were very helpfull. I grabbed that and gave it another run. There are still -O9 references in the Makefile.in. The Makefile.am was cleaned up and so if the Makefile.in was regenerated or patched then that problem would be resolved. Those caused gcc to SIGSEGV during the compile. I am running a slightly old gcc-3.3 at the moment and that might be fixed already. But I believe you need to either regenerate the Makefile or force a distclean at the start. He has updated the packages now. I'm compiling for him on sparc and hppa. They both compiled fine today. -- David J. M. Karlsen - +47 90 68 22 43 http://www.davidkarlsen.com http://mp3.davidkarlsen.com
symlinks between two packages
Hi I'm attempting to become DD, so I'm currently packaging some software. One of this software must be packaged in two parts: one for the client part (tty/console), one for the X frontend, so the X frontend package depends on the client package. My problem is that the README and changelog files are the same for both, so instead of install 2 times the same files. I attempt to make symlinks from README and changelog from the X frontend package to those from the client package, which seems correct since the X frontend package depends on the client package, so they will never be dead links. But lintian tells me that the README and changelog files from the X frontend package are zero-sized, which is quite normal since the links are broken while they are not installed. So should I install the same version for the two packages, or rely on symlinks, ignoring lintians's errors ? -- .,p**"*=b_ Nicolas Rueff ?P" .__ `*b Montbéliard - France |P .d?'`&, 9| http://rueff.tuxfamily.org M: |} |- H' [EMAIL PROTECTED] &| `#?_._oH' +33 6 77 64 44 80 `H. "`"`' GPG 0xDD44DAB4 `#?. ICQ 97700474 `^~. We are Penguin. Resistance is futile. You will be assimilated. -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/E/IT d- s:- a24>? C++ UL+++$ P++ L !E W+++ N++ o? K- w-- !O M- V-- !PS !PE !Y PGP+++ t+ 5 X+ R* tv++ b DI++ D++ G++ e+++ h r- y++ --END GEEK CODE BLOCK-- pgp0.pgp Description: PGP signature
Re: Need a mentor with a !x86 machine
Bob Proulx wrote: John Lightsey wrote: If anyone with a non-x86 machine would like to take a look again and give feedback on wheter or not it compiles properly, I'd really appreciate it. The build logs that I recieved were very helpfull. I grabbed that and gave it another run. There are still -O9 references in the Makefile.in. The Makefile.am was cleaned up and so if the Makefile.in was regenerated or patched then that problem would be resolved. Those caused gcc to SIGSEGV during the compile. I am running a slightly old gcc-3.3 at the moment and that might be fixed already. But I believe you need to either regenerate the Makefile or force a distclean at the start. He has updated the packages now. I'm compiling for him on sparc and hppa. They both compiled fine today. -- David J. M. Karlsen - +47 90 68 22 43 http://www.davidkarlsen.com http://mp3.davidkarlsen.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
symlinks between two packages
Hi I'm attempting to become DD, so I'm currently packaging some software. One of this software must be packaged in two parts: one for the client part (tty/console), one for the X frontend, so the X frontend package depends on the client package. My problem is that the README and changelog files are the same for both, so instead of install 2 times the same files. I attempt to make symlinks from README and changelog from the X frontend package to those from the client package, which seems correct since the X frontend package depends on the client package, so they will never be dead links. But lintian tells me that the README and changelog files from the X frontend package are zero-sized, which is quite normal since the links are broken while they are not installed. So should I install the same version for the two packages, or rely on symlinks, ignoring lintians's errors ? -- .,p**"*=b_ Nicolas Rueff ?P" .__ `*b Montbéliard - France |P .d?'`&, 9| http://rueff.tuxfamily.org M: |} |- H' [EMAIL PROTECTED] &| `#?_._oH' +33 6 77 64 44 80 `H. "`"`' GPG 0xDD44DAB4 `#?. ICQ 97700474 `^~. We are Penguin. Resistance is futile. You will be assimilated. -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/E/IT d- s:- a24>? C++ UL+++$ P++ L !E W+++ N++ o? K- w-- !O M- V-- !PS !PE !Y PGP+++ t+ 5 X+ R* tv++ b DI++ D++ G++ e+++ h r- y++ --END GEEK CODE BLOCK-- pgpl0Snl6VDhy.pgp Description: PGP signature
Re: Modifying other packages' conffiles: the not-so-ideal way
On Tue, Nov 11, 2003 at 11:16:39AM +0100, Frank Küster wrote: > policy says in section 10.7.4: > , > | If it is desirable for two or more related packages to share a > | configuration file and for all of the related packages to be able to > | modify that configuration file, then the following should be done: > | > |1. One of the related packages (the "owning" package) will manage > |the configuration file with maintainer scripts as described in the > |previous section. > | > |2. The owning package should also provide a program that the other > |packages may use to modify the configuration file. > | > |3. The related packages must use the provided program to make any > |desired modifications to the configuration file. > ` [...] > , > | The maintainer scripts must not alter a conffile of any package > ` You are mixing up "conffile" and "configuration-file". cu andreas
Re: Modifying other packages' conffiles: the not-so-ideal way
On Tue, Nov 11, 2003 at 11:16:39AM +0100, Frank Küster wrote: > policy says in section 10.7.4: > , > | If it is desirable for two or more related packages to share a > | configuration file and for all of the related packages to be able to > | modify that configuration file, then the following should be done: > | > |1. One of the related packages (the "owning" package) will manage > |the configuration file with maintainer scripts as described in the > |previous section. > | > |2. The owning package should also provide a program that the other > |packages may use to modify the configuration file. > | > |3. The related packages must use the provided program to make any > |desired modifications to the configuration file. > ` [...] > , > | The maintainer scripts must not alter a conffile of any package > ` You are mixing up "conffile" and "configuration-file". cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Modifying other packages' conffiles: the not-so-ideal way
Hi, policy says in section 10.7.4: , | If it is desirable for two or more related packages to share a | configuration file and for all of the related packages to be able to | modify that configuration file, then the following should be done: | |1. One of the related packages (the "owning" package) will manage |the configuration file with maintainer scripts as described in the |previous section. | |2. The owning package should also provide a program that the other |packages may use to modify the configuration file. | |3. The related packages must use the provided program to make any |desired modifications to the configuration file. ` So this is clearly the ideal way. However, it says "it should", so it's not a must under all circumstances. Now if there isn't yet such a program, or will not be in the near future because the maintainer of the owning package doesn't regard the case important enough, how should one act then? One option, of course, would be to not modify the file at all, but refer the user to the documentation of the package that needs the file to be modified. The problem with this is that most users will simply cut&paste the suggested lines into the conffile without respecting the advice given before, namely, to read and understand it. So the alternative is to provide a configuration script to do that. This script can check one way or the other wether the conffile looks like it expects it to do, if there are conflicting options etc. From this point of view, I would consider this solution better than just documenting what should be done. If the package in question won't work at all under certain circumstances (tested in the config file), the next, logical step would be to run the configuration script in postinst. But this violates a must-clause of Policy: , | The maintainer scripts must not alter a conffile of any package ` So obviously my thoughts went in the wrong direction... In reality, I have contacted the maintainer of the "owning" package and hope that we'll find a clean solution. Still, since the question came to my mind, I would like to hear your comments. Thanks, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Modifying other packages' conffiles: the not-so-ideal way
Hi, policy says in section 10.7.4: , | If it is desirable for two or more related packages to share a | configuration file and for all of the related packages to be able to | modify that configuration file, then the following should be done: | |1. One of the related packages (the "owning" package) will manage |the configuration file with maintainer scripts as described in the |previous section. | |2. The owning package should also provide a program that the other |packages may use to modify the configuration file. | |3. The related packages must use the provided program to make any |desired modifications to the configuration file. ` So this is clearly the ideal way. However, it says "it should", so it's not a must under all circumstances. Now if there isn't yet such a program, or will not be in the near future because the maintainer of the owning package doesn't regard the case important enough, how should one act then? One option, of course, would be to not modify the file at all, but refer the user to the documentation of the package that needs the file to be modified. The problem with this is that most users will simply cut&paste the suggested lines into the conffile without respecting the advice given before, namely, to read and understand it. So the alternative is to provide a configuration script to do that. This script can check one way or the other wether the conffile looks like it expects it to do, if there are conflicting options etc. From this point of view, I would consider this solution better than just documenting what should be done. If the package in question won't work at all under certain circumstances (tested in the config file), the next, logical step would be to run the configuration script in postinst. But this violates a must-clause of Policy: , | The maintainer scripts must not alter a conffile of any package ` So obviously my thoughts went in the wrong direction... In reality, I have contacted the maintainer of the "owning" package and hope that we'll find a clean solution. Still, since the question came to my mind, I would like to hear your comments. Thanks, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Was: fastdep_0.16-2_i386.deb] [OT] Group reply
On Mon, Nov 10, 2003 at 06:58:20PM +0100, blacksheep <[EMAIL PROTECTED]> wrote: > I'm just wondering why the reply in this ML is not on > the ML itself, but on the author of each message. http://www.unicom.com/pw/reply-to-harmful.html You do mention using mutt, though, so I suggest you read about the "subscribe" and "list" config entries and the "L" key binding (list-reply) key binding. -- Mike Markley <[EMAIL PROTECTED]> GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084
Re: [Was: fastdep_0.16-2_i386.deb] [OT] Group reply
On Mon, Nov 10, 2003 at 06:58:20PM +0100, blacksheep <[EMAIL PROTECTED]> wrote: > I'm just wondering why the reply in this ML is not on > the ML itself, but on the author of each message. http://www.unicom.com/pw/reply-to-harmful.html You do mention using mutt, though, so I suggest you read about the "subscribe" and "list" config entries and the "L" key binding (list-reply) key binding. -- Mike Markley <[EMAIL PROTECTED]> GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
