Re: data files in /etc?
On 2004-02-12 Magosányi Árpád <[EMAIL PROTECTED]> 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? [...] Yes, but. ;-) There for two reasons for files like mtab: * history. * These files need to be available early the boot process, and therefore reside on the root file-system. There has been a _big_ discussion about this -devel in 2003, search for readonly root file-system. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash"
auto reply inactive
The e-mail address [EMAIL PROTECTED] is no longer active. Please direct your inquary to [EMAIL PROTECTED] Thanks.
Re: data files in /etc?
* Magosányi Árpád <[EMAIL PROTECTED]> [040212 22:52]: > -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.) At least some time ago mount was able to deal with /etc/mtab beeing a link to /proc/mounts. (As long as no loop-devices where involved). This should at least make this work. (lvm could be tougher, I never looked at it but the idea looks a bit suspicous in the whole...) Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: data files in /etc?
On 2004-02-13 "Bernhard R. Link" <[EMAIL PROTECTED]> wrote: > * Magosányi Árpád <[EMAIL PROTECTED]> [040212 22:52]: > > -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.) > At least some time ago mount was able to deal with /etc/mtab > beeing a link to /proc/mounts. (As long as no loop-devices > where involved). [...] Besides breaking -o loop this also breaks the "user" option, the can user can mount the filesystem but is not allowed to unmount it because /proc/mounts does not hold the name of the user who mounted the file system. cu andreas
Re: data files in /etc?
On Fri, Feb 13, 2004 at 07:25:42PM +0100, Bernhard R. Link wrote: > * Magos?nyi ?rp?d <[EMAIL PROTECTED]> [040212 22:52]: > > -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.) > > At least some time ago mount was able to deal with /etc/mtab > beeing a link to /proc/mounts. (As long as no loop-devices It breaks usrquota --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Looking for sponsor for Gnosis-Utils, pure python package
On Mon, Feb 09, 2004 at 07:35:30PM +0100, Thomas Viehmann wrote: >Magnus Therning wrote: >> I have consulted the people on debian-legal, and it seems I have been >> pointed to a reasonable solution[1]. The original author is also happy >> with it. >Yeah. Always good to talk to the original author. :) >Onto technical issues: >- Your packaging is probably. (Native package where it shouldn't.) > Also, stripped, but otherwise intact tar archives are preferred > as orig.tar.gz. (What is the arch stuff doing there?) You are right it was. In a somewhat misguided attempt to do version control I did this. I have reverted back to using the original tar-ball (excluding the copyrighted articles). >- The description looks funny. In particular, the second paragraph > should only be in README.Debian or somesuch. Other things might be > improved as well, but other people are bound to be more competent on > this. (But is the URL missing a "/"?) The second paragraph is gone. And a '/' is added. >- Documentation probably belongs in /usr/share/doc/$package, not > /usr/lib/pythonX.Y. How do I get it there? Or rather, the documentation is installed in a hierarchy, and there are references (e.g. doc/GETTING_HELP refers to gnosis/xml/pickle/doc/HISTORY), how can I preserve the hierarchy, but install it in /usr/share/doc/$package instead? >- Don't know, do you follow the python policy (in package python)? I have taken a look, and made some changes. I am not sure I am 100% compliant. This made me change the name of the package to python-gnosis rather than gnosis-utils. As before it is all available at: http://magnus.therning.org/gnosis/ /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) [EMAIL PROTECTED] http://magnus.therning.org/ Discovery consists of seeing what everybody has seen and thinking what nobody has thought. -- Albert Szent-Gyorgyi signature.asc Description: Digital signature
RFS[4]: popfile -- Email classification tool
Hi! I'm still looking for a sponsor for the popfile[1] package I made. POPFile is an email classification tool with a Naive Bayes classifier, a POP3 proxy and a web interface. Its not only useful to filter spam, but also to sort legitimate mail into different folders. POPFile can be trained to recognize and sort mails even when no regular mail rules based on header can be made. The package and source can be downloaded from my site[2], or from mentors[3] package repository. The package is lintian (and linda) clean and closes WNPP bug #203349. I've also been using it over six months with no problems. K. [1] http://popfile.sourceforge.net [2] http://www.kadath.com.ar/popfile/ [3] http://mentors.debian.net/ signature.asc Description: OpenPGP digital signature
Re: data files in /etc?
On 2004-02-12 Magosányi Árpád <[EMAIL PROTECTED]> 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? [...] Yes, but. ;-) There for two reasons for files like mtab: * history. * These files need to be available early the boot process, and therefore reside on the root file-system. There has been a _big_ discussion about this -devel in 2003, search for readonly root file-system. 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]
auto reply inactive
The e-mail address [EMAIL PROTECTED] is no longer active. Please direct your inquary to [EMAIL PROTECTED] Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: data files in /etc?
* Magosányi Árpád <[EMAIL PROTECTED]> [040212 22:52]: > -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.) At least some time ago mount was able to deal with /etc/mtab beeing a link to /proc/mounts. (As long as no loop-devices where involved). This should at least make this work. (lvm could be tougher, I never looked at it but the idea looks a bit suspicous in the whole...) Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: data files in /etc?
On 2004-02-13 "Bernhard R. Link" <[EMAIL PROTECTED]> wrote: > * Magosányi Árpád <[EMAIL PROTECTED]> [040212 22:52]: > > -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.) > At least some time ago mount was able to deal with /etc/mtab > beeing a link to /proc/mounts. (As long as no loop-devices > where involved). [...] Besides breaking -o loop this also breaks the "user" option, the can user can mount the filesystem but is not allowed to unmount it because /proc/mounts does not hold the name of the user who mounted the file system. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: data files in /etc?
On Fri, Feb 13, 2004 at 07:25:42PM +0100, Bernhard R. Link wrote: > * Magos?nyi ?rp?d <[EMAIL PROTECTED]> [040212 22:52]: > > -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.) > > At least some time ago mount was able to deal with /etc/mtab > beeing a link to /proc/mounts. (As long as no loop-devices It breaks usrquota --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for sponsor for Gnosis-Utils, pure python package
On Mon, Feb 09, 2004 at 07:35:30PM +0100, Thomas Viehmann wrote: >Magnus Therning wrote: >> I have consulted the people on debian-legal, and it seems I have been >> pointed to a reasonable solution[1]. The original author is also happy >> with it. >Yeah. Always good to talk to the original author. :) >Onto technical issues: >- Your packaging is probably. (Native package where it shouldn't.) > Also, stripped, but otherwise intact tar archives are preferred > as orig.tar.gz. (What is the arch stuff doing there?) You are right it was. In a somewhat misguided attempt to do version control I did this. I have reverted back to using the original tar-ball (excluding the copyrighted articles). >- The description looks funny. In particular, the second paragraph > should only be in README.Debian or somesuch. Other things might be > improved as well, but other people are bound to be more competent on > this. (But is the URL missing a "/"?) The second paragraph is gone. And a '/' is added. >- Documentation probably belongs in /usr/share/doc/$package, not > /usr/lib/pythonX.Y. How do I get it there? Or rather, the documentation is installed in a hierarchy, and there are references (e.g. doc/GETTING_HELP refers to gnosis/xml/pickle/doc/HISTORY), how can I preserve the hierarchy, but install it in /usr/share/doc/$package instead? >- Don't know, do you follow the python policy (in package python)? I have taken a look, and made some changes. I am not sure I am 100% compliant. This made me change the name of the package to python-gnosis rather than gnosis-utils. As before it is all available at: http://magnus.therning.org/gnosis/ /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) [EMAIL PROTECTED] http://magnus.therning.org/ Discovery consists of seeing what everybody has seen and thinking what nobody has thought. -- Albert Szent-Gyorgyi signature.asc Description: Digital signature
RFS[4]: popfile -- Email classification tool
Hi! I'm still looking for a sponsor for the popfile[1] package I made. POPFile is an email classification tool with a Naive Bayes classifier, a POP3 proxy and a web interface. Its not only useful to filter spam, but also to sort legitimate mail into different folders. POPFile can be trained to recognize and sort mails even when no regular mail rules based on header can be made. The package and source can be downloaded from my site[2], or from mentors[3] package repository. The package is lintian (and linda) clean and closes WNPP bug #203349. I've also been using it over six months with no problems. K. [1] http://popfile.sourceforge.net [2] http://www.kadath.com.ar/popfile/ [3] http://mentors.debian.net/ signature.asc Description: OpenPGP digital signature
Re: RFS[4]: popfile -- Email classification tool
On Sat, Feb 14, 2004 at 02:47:00AM -0300, Lucas Wall wrote: > Hi! I'm still looking for a sponsor for the popfile[1] package I made. Interesting. Have a look at http://people.debian.org/~mpalmer/sponsorship.html, and if you like, contact me privately and we can discuss sponsorship. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
