cryptoloop-source, anyone taking over?
Hi, The PTS shows cryptoloop-source to be orphaned, with a note that someone is intending to take over. The note is quite old now and references a bugreport which gives no further clues. At the moment, I am maintaining enterprise kernel packages which depend on this package, and I have made modifications to it to support 2.4.24. To me, enterprise means storage management with EVMS, block device encryption, and memory 1GB. My private archives are here: deb http://juergen.strobel.info/debian-strobel/ unstable kernel deb-src http://juergen.strobel.info/debian-strobel/ unstable kernel Note that the cryptoloop package there is probably not very debian compliant. It puts all the required changes in the kernel patch part, as opposed to having kernel patch and an extra module package. And I left the old module parts in the package so it has to be disabled when making kernels with make-kpkg. I found out about module-assistant co after I made this. If someone wants to sponsor me, I'd be willing to rework it. I have been working at an ISP for the last 3 years, using RedHat, Slackware, and migrating to Debian in the end. I can program or at least read code in most major languages and a few exoctic ones. I have submitted bug reports and feedback to Debian and other projects in the past, and would like to become part of the official team. My further interests are networking, apache, php, java, postgresql. cryptoloop-source seems to be a safe starting point. regards, Jürgen -- The box said it requires Windows 95 or better so I installed Linux pgp0.pgp Description: PGP signature
problem with files in /etc/dir.d (continued)
Hello,
Thanks to the persons who have kindly answered my questions about the
/etc/dir.d/ problem.
At the beginning, the software did use the /usr/etc/dir.d
configuration directory, but then the packaging system would complain
that this is not a standard location. I used this location because
that is simpler, using the ${prefix}-based variables from the
autotools (that is : ${sysconfdir} will resolve to /usr/etc if
${prefix} is /usr).
So, if it is not correct to put the stuff in /usr/etc (can someone
help me decide if this is actually forbidden ?), I'll put the conf
files in a /usr/share/thepackage/dir.d directory.
In fact, I seem to understand that /usr/etc is forbidden by the
standards. However, then, why do the autotools provide a ${sysconfdir}
variable that resolves to /usr/etc if ${prefix} is /usr ?.
Thanks so much for your help,
Cheers,
Filippo
--
Mass spectrometry in GNU/Linux ? GNU polyxmass !
www.gnu.org/software/polyxmass or www.polyxmass.org
Free software that you are welcome to distribute!
http://www.unesco.org/webworld/portal_freesoft/index.shtml
signature.asc
Description: Digital signature
Re: cryptoloop-source, anyone taking over?
On Thu, Feb 12, 2004 at 09:19:16AM +0100, Juergen Strobel wrote: The PTS shows cryptoloop-source to be orphaned, with a note that someone is intending to take over. The note is quite old now and references a bugreport which gives no further clues. Have you attempted to contact Vincent Bernat and ask if he is still intending to upload? Assuming that you've made some effort to contact Vincent, and he hasn't responded or has indicated that he is still in the process of packaging, I suggest you take over the ITA, read http://people.debian.org/~mpalmer/sponsorship.html, and if you're happy with that, contact me privately to discuss sponsorship. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Neue gdal version
Hallo list, hallo Jochen, (Jochen beeing my gdal sponsor) a few days ago someone posted an error of my gdal-package [1] on its related developer list [2]. The problem has been fixed upstream and I want now repackage gdal to eliminate this bug in debian. The problem is, that there is no official gdal release of version 1.2 so I decided in december to package a cvs snapshot (s. here [3] for a full discussion of the reasons). My question is now: should I fix the above mentioned bug based on the already used snapshot from november or can I just release a new package version named 1.2+cvs.20040212? This package would of course not only fix the bug but also include new features of gdal and fix some other bugs. I would prefer to do the second option but I am not sure whether the tarball will be accepted then. Greetings, Silke [1] http://packages.qa.debian.org/g/gdal.html [2] http://remotesensing.org/pipermail/gdal-dev/2004-February/001913.html [3] http://lists.debian.org/debian-mentors/2003/debian-mentors-200310/msg00247.html -- Silke Reimer Intevation GmbH http://intevation.de/ FreeGIShttp://freegis.org/ pgp0.pgp Description: PGP signature
Re: Neue gdal version
Hi Silke, I would prefer to do the second option but I am not sure whether the tarball will be accepted then. Then i would go for this option. As long as you believe the new snapshot is more useful and has less bugs than the old one, there is no reason to keep the old one. --jochen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problem with files in /etc/dir.d
On Thu, Feb 12, 2004 at 12:13:21AM +0100, Filippo Rusconi wrote: Hello all, in the software that I'm trying (gosh, that's not trivial...) to package, some configuration files are due to go in /etc/polyxmass.d Configuration files are configuration files, not else. If you need to rewrite files at every installation and they are not possibly hackable by the admin, that's the bad directory to place them. If the admin can change them for his needs, then u cannot rewrite them by Policy. Other good candidate dirs for those files (in the first case): /usr/share/polyxmass /usr/lib/polyxmass -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problem with files in /etc/dir.d (continued)
Filippo Rusconi [EMAIL PROTECTED] schrieb:
Hello,
Thanks to the persons who have kindly answered my questions about the
/etc/dir.d/ problem.
At the beginning, the software did use the /usr/etc/dir.d
configuration directory, but then the packaging system would complain
that this is not a standard location. I used this location because
that is simpler, using the ${prefix}-based variables from the
autotools (that is : ${sysconfdir} will resolve to /usr/etc if
${prefix} is /usr).
So, if it is not correct to put the stuff in /usr/etc (can someone
help me decide if this is actually forbidden ?), I'll put the conf
files in a /usr/share/thepackage/dir.d directory.
First check whether these files are configuration files:
,
| 10.7 Configuration files
| 10.7.1 Definitions
|
| configuration file
|A file that affects the operation of a program, or provides site-
|or host-specific information, or otherwise customizes the behavior of
|program. Typically, configuration files are intended to be modified
|by the system administrator (if needed or desired) to conform to local
|policy or to provide more useful site-specific behavior.
`
If it isn't, it should probably go to /usr/share. If it is a
configuration file, you have to put it somewhere under /etc and decide
whether it should be a conffile, too. If there is a reasonable default
that will make your program work und normal circumstances, and only has
to be modified occasionally, you should make it a conffile. If not, you
can use debconf or other means to create one, and then it may _not_ be a
conffile. This is usually achieved by not shipping it in /etc in the
package, but to generate it or modify a template and then copy the
resulting file to /etc in postinst.
One more remark: You used the term /etc/dir.d. There is no official
policy for this AFAIK, but usually directories like this are used in a
special way: A program called foo reads it's configuration file foo.conf
from either /etc/foo.conf or /etc/foo/foo.conf (if there are a lot of
configuration files for foo). But other packages that use foo need to
add configuration items to foo.conf. They cannot if foo.conf belongs to
the foo package (i.e. is a configuration file), and they cannot simply
add stuff if foo.conf was created by foo's postinst, because this will
be overriden upon upgrade of foo. So the solution is to
- create a directory /etc/foo.d (or /etc/foo.conf.d or
/etc/foo/foo.conf.d)
- foo itself, as well as other packages using foo place a confile in
this directory
- There is some mechanism by which foo then can get the information
stored in the conffiles in /etc/foo.d. Either it reads it directly,
like pam does, or there's a script called update-foo.conf or the like
that is called in the postinst scripts of foo and depending
packages. It creates /etc/foo.conf from the information taken from the
files in /etc/foo.d/.
I would suggest to _not_ use the name foo.d for a directory under /etc
that does _not_ use this principle.
Regards, 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: Help with my program
On Wed, Feb 11, 2004 at 09:01:57PM +0100, Nico Golde wrote: Hallo Frank, * Frank Küster [EMAIL PROTECTED] [2004-02-11 20:07]: every program must have a man page? Policy, 12.1: , | Each program, utility, and function should have an associated manual | page included in the same package. It is suggested that all | configuration files also have a manual page included as well. Manual | pages for protocols and other auxiliary things are optional. ` Why are you surprised? If it's because you prefer info, you can just provide a minimal manpage and refer to the info documentation in it. I am surprised because i saw programs with an automatic created debian manpage or without a manpage. It's a bug not to have a man page. Sadly, we have bugs ... -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adopting xcruiser
Sorry, http://www.fast.sh/~vi64pa/ Ville Palo wrote: Hi I fixed one little bug (213654) and some lintian reported errors. New debian package can be downloaded from http://www.fast.sh/~vi64pa/debian I need sponsor for checking this packet and possibly uploading it. ville -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adopting xcruiser
Hi. Ville Palo ([EMAIL PROTECTED]) wrote: I fixed one little bug (213654) and some lintian reported errors. Just a few thoughts - The package presently in Debian is xcruise, not xcruiser. - Declare your intend to adopt the package by appropriatly changing the orphaning bug. Debian has policy on this and potential sponsors most likely prefer sponsoring people following them. - Maybe get the bug reporter of the other important bug to test your package. If it's the same problem as 213654, you can ask can I find a sponsor for adopting xcruise, my package fixes all bugs with severity =important. Cheers T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adopting xcruiser
Ok, now there is a .tar.gz. It should contain all the necessary files. Thomas Viehmann wrote: Hi. Ville Palo wrote: http://www.fast.sh/~vi64pa/ The directory you pointed to does not contain the files necessary to review your package. Kind regards Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: adopting xcruiser
Ville Palo wrote: Ok, now there is a .tar.gz. It should contain all the necessary files. The canonical way to do this (and thus probably the best way to get your package looked at is to have *.orig.tar.gz, *.diff.gz, *.dsc and possibly *.changes and *.deb in a directory. Note also that you also need to include a about yourself adopting the package (closing the orphaning bug) after you have declared yourself maintainer in the debian/control. Cheers T. -- Thomas Viehmann, http://beamnet.de/tv/ pgp0.pgp Description: PGP signature
Re: adopting xcruiser
Ok, I just uploaded *.orig.tar.gz *.diff.gz *.dsc *.changes *.deb I haven't decclared my self maintainer yet, Before I do that, i want to be sure the package is ok. And thanks for helping me with this. Thomas Viehmann wrote: Ville Palo wrote: Ok, now there is a .tar.gz. It should contain all the necessary files. The canonical way to do this (and thus probably the best way to get your package looked at is to have *.orig.tar.gz, *.diff.gz, *.dsc and possibly *.changes and *.deb in a directory. Note also that you also need to include a about yourself adopting the package (closing the orphaning bug) after you have declared yourself maintainer in the debian/control. Cheers T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problem with files in /etc/dir.d
On 2004-02-12 Filippo Rusconi [EMAIL PROTECTED] wrote: [...] I effectively get the said file in debian/polyxmassdata/etc/polyxmass.d/polyxmassdata.conf telling me that the make install target has worked ok. However, I also noticed that this file is referenced here: debian/polyxmassdata/DEBIAN/conffiles Debhelper in =v3 mode will automaticaly flag all files in /etc as conffiles. although I never had a conffiles for this package, because the polyxmassdata.conf SHOULD be overwritten upon a new install. Then it is misplaced in /etc (which is a release-critical bug) and should go to /usr/share/. The result of all this is that the polyxmassdata.conf seems to be included in the deb file (as seen using dpkg -X file.deb /tmp), but does not get installed (presumably because, indeed, the debian packaging system does think it is a conffile). dpkg-conffile handling preserves file-removal. So my question ? How can I have a configuration file installed somewhere in /etc without having the debian packaging system think it is a conffile ? [...] Please read policy 10.7 and check whether this indeed is a configuration file as specified by policy (Typically, configuration files are intended to be modified by the system administrator) which requires you to fulfill 10.7.3, local changes must be preserved. 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: Help with my program
Nico Golde wrote: I am surprised because i saw programs with an automatic created debian manpage or without a manpage. If you find a program in Debian without a manpage, please file a bug (severity normal) against the package that provides it. --Joe
cryptoloop-source, anyone taking over?
Hi, The PTS shows cryptoloop-source to be orphaned, with a note that someone is intending to take over. The note is quite old now and references a bugreport which gives no further clues. At the moment, I am maintaining enterprise kernel packages which depend on this package, and I have made modifications to it to support 2.4.24. To me, enterprise means storage management with EVMS, block device encryption, and memory 1GB. My private archives are here: deb http://juergen.strobel.info/debian-strobel/ unstable kernel deb-src http://juergen.strobel.info/debian-strobel/ unstable kernel Note that the cryptoloop package there is probably not very debian compliant. It puts all the required changes in the kernel patch part, as opposed to having kernel patch and an extra module package. And I left the old module parts in the package so it has to be disabled when making kernels with make-kpkg. I found out about module-assistant co after I made this. If someone wants to sponsor me, I'd be willing to rework it. I have been working at an ISP for the last 3 years, using RedHat, Slackware, and migrating to Debian in the end. I can program or at least read code in most major languages and a few exoctic ones. I have submitted bug reports and feedback to Debian and other projects in the past, and would like to become part of the official team. My further interests are networking, apache, php, java, postgresql. cryptoloop-source seems to be a safe starting point. regards, Jürgen -- The box said it requires Windows 95 or better so I installed Linux pgp8nd9gRexwv.pgp Description: PGP signature
problem with files in /etc/dir.d (continued)
Hello,
Thanks to the persons who have kindly answered my questions about the
/etc/dir.d/ problem.
At the beginning, the software did use the /usr/etc/dir.d
configuration directory, but then the packaging system would complain
that this is not a standard location. I used this location because
that is simpler, using the ${prefix}-based variables from the
autotools (that is : ${sysconfdir} will resolve to /usr/etc if
${prefix} is /usr).
So, if it is not correct to put the stuff in /usr/etc (can someone
help me decide if this is actually forbidden ?), I'll put the conf
files in a /usr/share/thepackage/dir.d directory.
In fact, I seem to understand that /usr/etc is forbidden by the
standards. However, then, why do the autotools provide a ${sysconfdir}
variable that resolves to /usr/etc if ${prefix} is /usr ?.
Thanks so much for your help,
Cheers,
Filippo
--
Mass spectrometry in GNU/Linux ? GNU polyxmass !
www.gnu.org/software/polyxmass or www.polyxmass.org
Free software that you are welcome to distribute!
http://www.unesco.org/webworld/portal_freesoft/index.shtml
signature.asc
Description: Digital signature
Re: cryptoloop-source, anyone taking over?
On Thu, Feb 12, 2004 at 09:19:16AM +0100, Juergen Strobel wrote: The PTS shows cryptoloop-source to be orphaned, with a note that someone is intending to take over. The note is quite old now and references a bugreport which gives no further clues. Have you attempted to contact Vincent Bernat and ask if he is still intending to upload? Assuming that you've made some effort to contact Vincent, and he hasn't responded or has indicated that he is still in the process of packaging, I suggest you take over the ITA, read http://people.debian.org/~mpalmer/sponsorship.html, and if you're happy with that, contact me privately to discuss sponsorship. - Matt
Neue gdal version
Hallo list, hallo Jochen, (Jochen beeing my gdal sponsor) a few days ago someone posted an error of my gdal-package [1] on its related developer list [2]. The problem has been fixed upstream and I want now repackage gdal to eliminate this bug in debian. The problem is, that there is no official gdal release of version 1.2 so I decided in december to package a cvs snapshot (s. here [3] for a full discussion of the reasons). My question is now: should I fix the above mentioned bug based on the already used snapshot from november or can I just release a new package version named 1.2+cvs.20040212? This package would of course not only fix the bug but also include new features of gdal and fix some other bugs. I would prefer to do the second option but I am not sure whether the tarball will be accepted then. Greetings, Silke [1] http://packages.qa.debian.org/g/gdal.html [2] http://remotesensing.org/pipermail/gdal-dev/2004-February/001913.html [3] http://lists.debian.org/debian-mentors/2003/debian-mentors-200310/msg00247.html -- Silke Reimer Intevation GmbH http://intevation.de/ FreeGIShttp://freegis.org/ pgpDpVNCTFk1v.pgp Description: PGP signature
Re: Neue gdal version
Hi Silke, I would prefer to do the second option but I am not sure whether the tarball will be accepted then. Then i would go for this option. As long as you believe the new snapshot is more useful and has less bugs than the old one, there is no reason to keep the old one. --jochen
Re: problem with files in /etc/dir.d
On Thu, Feb 12, 2004 at 12:13:21AM +0100, Filippo Rusconi wrote: Hello all, in the software that I'm trying (gosh, that's not trivial...) to package, some configuration files are due to go in /etc/polyxmass.d Configuration files are configuration files, not else. If you need to rewrite files at every installation and they are not possibly hackable by the admin, that's the bad directory to place them. If the admin can change them for his needs, then u cannot rewrite them by Policy. Other good candidate dirs for those files (in the first case): /usr/share/polyxmass /usr/lib/polyxmass -- Francesco P. Lovergine
Re: problem with files in /etc/dir.d (continued)
Filippo Rusconi [EMAIL PROTECTED] schrieb:
Hello,
Thanks to the persons who have kindly answered my questions about the
/etc/dir.d/ problem.
At the beginning, the software did use the /usr/etc/dir.d
configuration directory, but then the packaging system would complain
that this is not a standard location. I used this location because
that is simpler, using the ${prefix}-based variables from the
autotools (that is : ${sysconfdir} will resolve to /usr/etc if
${prefix} is /usr).
So, if it is not correct to put the stuff in /usr/etc (can someone
help me decide if this is actually forbidden ?), I'll put the conf
files in a /usr/share/thepackage/dir.d directory.
First check whether these files are configuration files:
,
| 10.7 Configuration files
| 10.7.1 Definitions
|
| configuration file
|A file that affects the operation of a program, or provides site-
|or host-specific information, or otherwise customizes the behavior of
|program. Typically, configuration files are intended to be modified
|by the system administrator (if needed or desired) to conform to local
|policy or to provide more useful site-specific behavior.
`
If it isn't, it should probably go to /usr/share. If it is a
configuration file, you have to put it somewhere under /etc and decide
whether it should be a conffile, too. If there is a reasonable default
that will make your program work und normal circumstances, and only has
to be modified occasionally, you should make it a conffile. If not, you
can use debconf or other means to create one, and then it may _not_ be a
conffile. This is usually achieved by not shipping it in /etc in the
package, but to generate it or modify a template and then copy the
resulting file to /etc in postinst.
One more remark: You used the term /etc/dir.d. There is no official
policy for this AFAIK, but usually directories like this are used in a
special way: A program called foo reads it's configuration file foo.conf
from either /etc/foo.conf or /etc/foo/foo.conf (if there are a lot of
configuration files for foo). But other packages that use foo need to
add configuration items to foo.conf. They cannot if foo.conf belongs to
the foo package (i.e. is a configuration file), and they cannot simply
add stuff if foo.conf was created by foo's postinst, because this will
be overriden upon upgrade of foo. So the solution is to
- create a directory /etc/foo.d (or /etc/foo.conf.d or
/etc/foo/foo.conf.d)
- foo itself, as well as other packages using foo place a confile in
this directory
- There is some mechanism by which foo then can get the information
stored in the conffiles in /etc/foo.d. Either it reads it directly,
like pam does, or there's a script called update-foo.conf or the like
that is called in the postinst scripts of foo and depending
packages. It creates /etc/foo.conf from the information taken from the
files in /etc/foo.d/.
I would suggest to _not_ use the name foo.d for a directory under /etc
that does _not_ use this principle.
Regards, Frank
--
Frank Küster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie
Re: Help with my program
On Wed, Feb 11, 2004 at 09:01:57PM +0100, Nico Golde wrote: Hallo Frank, * Frank Küster [EMAIL PROTECTED] [2004-02-11 20:07]: every program must have a man page? Policy, 12.1: , | Each program, utility, and function should have an associated manual | page included in the same package. It is suggested that all | configuration files also have a manual page included as well. Manual | pages for protocols and other auxiliary things are optional. ` Why are you surprised? If it's because you prefer info, you can just provide a minimal manpage and refer to the info documentation in it. I am surprised because i saw programs with an automatic created debian manpage or without a manpage. It's a bug not to have a man page. Sadly, we have bugs ... -- Colin Watson [EMAIL PROTECTED]
adopting xcruiser
Hi I fixed one little bug (213654) and some lintian reported errors. New debian package can be downloaded from http://www.fast.sh/~vi64pa/debian I need sponsor for checking this packet and possibly uploading it. ville
Re: adopting xcruiser
Sorry, http://www.fast.sh/~vi64pa/ Ville Palo wrote: Hi I fixed one little bug (213654) and some lintian reported errors. New debian package can be downloaded from http://www.fast.sh/~vi64pa/debian I need sponsor for checking this packet and possibly uploading it. ville
Re: adopting xcruiser
Hi. Ville Palo ([EMAIL PROTECTED]) wrote: I fixed one little bug (213654) and some lintian reported errors. Just a few thoughts - The package presently in Debian is xcruise, not xcruiser. - Declare your intend to adopt the package by appropriatly changing the orphaning bug. Debian has policy on this and potential sponsors most likely prefer sponsoring people following them. - Maybe get the bug reporter of the other important bug to test your package. If it's the same problem as 213654, you can ask can I find a sponsor for adopting xcruise, my package fixes all bugs with severity =important. Cheers T.
Re: adopting xcruiser
Hi. Ville Palo wrote: http://www.fast.sh/~vi64pa/ The directory you pointed to does not contain the files necessary to review your package. Kind regards Thomas -- Thomas Viehmann, http://beamnet.de/tv/ pgphFsV0NXP1u.pgp Description: PGP signature
Re: adopting xcruiser
Ok, now there is a .tar.gz. It should contain all the necessary files. Thomas Viehmann wrote: Hi. Ville Palo wrote: http://www.fast.sh/~vi64pa/ The directory you pointed to does not contain the files necessary to review your package. Kind regards Thomas
Re: adopting xcruiser
Hi Thomas Thomas Viehmann wrote: Hi. Ville Palo ([EMAIL PROTECTED]) wrote: I fixed one little bug (213654) and some lintian reported errors. Just a few thoughts - The package presently in Debian is xcruise, not xcruiser. - Declare your intend to adopt the package by appropriatly changing the orphaning bug. Debian has policy on this and potential sponsors most likely prefer sponsoring people following them. Ok, done that. - Maybe get the bug reporter of the other important bug to test your package. If it's the same problem as 213654, you can ask can I find a sponsor for adopting xcruise, my package fixes all bugs with severity =important. Those other bugs are not fixed, I'm sure about that. ville
Re: adopting xcruiser
Ville Palo wrote: Ok, now there is a .tar.gz. It should contain all the necessary files. The canonical way to do this (and thus probably the best way to get your package looked at is to have *.orig.tar.gz, *.diff.gz, *.dsc and possibly *.changes and *.deb in a directory. Note also that you also need to include a about yourself adopting the package (closing the orphaning bug) after you have declared yourself maintainer in the debian/control. Cheers T. -- Thomas Viehmann, http://beamnet.de/tv/ pgpLw2Ksgu2Ka.pgp Description: PGP signature
Re: adopting xcruiser
Ok, I just uploaded *.orig.tar.gz *.diff.gz *.dsc *.changes *.deb I haven't decclared my self maintainer yet, Before I do that, i want to be sure the package is ok. And thanks for helping me with this. Thomas Viehmann wrote: Ville Palo wrote: Ok, now there is a .tar.gz. It should contain all the necessary files. The canonical way to do this (and thus probably the best way to get your package looked at is to have *.orig.tar.gz, *.diff.gz, *.dsc and possibly *.changes and *.deb in a directory. Note also that you also need to include a about yourself adopting the package (closing the orphaning bug) after you have declared yourself maintainer in the debian/control. Cheers T.
data files in /etc?
Hi! There are some files in /etc which are actually data files representing the state of the system. Like /etc/mtab, /etc/network/ifstate, or /etc/lvmconf/* (it is not even a text file). These files are written by programs in occasions one cannot with good heart call configuration. Isn't it against the policy? There are practical reasons behind my question: -if one uses a configuration management tool (like tla) to track changes in the configuration, one will stumble upon them sooner or later. -if one wants to make the boot process unable to modify configuration, they will also be stumbled upon. (And given the fact that mount actually deletes and recreates /etc/mtab, the challenge is... challenging.) -- GNU GPL: csak tiszta forrásból
Re: data files in /etc?
On Thu, Feb 12, 2004 at 10:47:15PM +0100, Magos?nyi ?rp?d wrote: There are some files in /etc which are actually data files representing the state of the system. Like /etc/mtab, /etc/network/ifstate, or /etc/lvmconf/* (it is not even a text file). These files are written by programs in occasions one cannot with good heart call configuration. Isn't it against the policy? mtab is explicitly blessed by the FHS. The other files are there for the same reason that mtab is, which is that they must be on the root filesystem. -- - mdz
Re: data files in /etc?
On Thu, Feb 12, 2004 at 10:47:15PM +0100, Magosányi Árpád wrote: There are some files in /etc which are actually data files representing the state of the system. Like /etc/mtab, /etc/network/ifstate, or /etc/lvmconf/* (it is not even a text file). These files are written by programs in occasions one cannot with good heart call configuration. Isn't it against the policy? There are practical reasons behind my question: -if one uses a configuration management tool (like tla) to track changes in the configuration, one will stumble upon them sooner or later. -if one wants to make the boot process unable to modify configuration, they will also be stumbled upon. (And given the fact that mount actually deletes and recreates /etc/mtab, the challenge is... challenging.) There is a gray area currently, because the FHS contains no provision for state files (persistent or not) that are available prior to /var being mounted. Discussion of this issue on debian-devel was extensive last year, but it seems the farthest it got was get the FHS to sanction it, then we'll consider it. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
