Re: Mentors upload authentication
]] Michael Gilbert In this case, I think it would be possible to use ssh public keys as that authentication. The process would be: This seems overly complex, why not just have the user put all those files in a well-known location on alioth (or some other host) and have the mentors code download and DTRT with that bunch of files. As for removing non-distributable files, that's not something we're going to entrust to another team, any such removal requests will go through admin@alioth. [...] Just to be clear, alioth is not a regular debian.org machine. It isn't admined by the same team, accounts are not handled in the same way, and privileged groups on Debian machines have no special privilege on alioth machines. I understand that, but I don't see how that has to do with the DMUP, which is a usage policy intended for debian machines of which alioth is one. Otherwise, it seems like it fine to misuse alioth in ways that violate the DMUP, but not any other machine. That a machine is not subject to agreement to the DMUP does not mean any other use of said machine is ok. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874nukjip2@qurzaw.varnish-software.com
Re: Source Code One Line Change [patch] and Copyright holder
]] Nanakos V. Chrysostomos | recently I have contributed a on-line patch [0] that resolves a | significant and major security bug in a PAM module. I added myself to the | Copyright holders of the file and added this change to the changelog file | as you can easily see in [1]. The upstream author and developer of this | software claims that I am not intended to add my name for such a small | change to the Copyright holders of the file and he should ask for legal | advise. What is your opinion? Is this right? I think he's in the right, your contribution does not really consist of any significant creative effort. I'm also unable to reproduce your bug. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkiwqvmx@qurzaw.varnish-software.com
Re: RFS: gnus (second try)
]] Tommi Vainikainen | Hi, | | I am still looking for a sponsor for the new version 5.11+v0.10.dfsg-1 | of my package gnus. While I don't usually sponsor packages any more, I do use gnus and so has an interest in it being good. debian/gnus-init.el has a typo: ;; laod-path, though near the end. Apart from that, it looks good and I've uploaded it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Packaging of freenx
* Roberto C. Sanchez | On Tue, Jun 07, 2005 at 04:27:58PM +0200, Fabio Tranchitella wrote: | On Tue, 07 Jun 2005 at 10:16 -0400, Roberto C. Sanchez wrote: | I asked a while back (on IRC) about packaging the NX components that are | under the GPL. Someone pointed me to Fabian's packages in Skole Linux. | Anyhow, those packages are 6 months old and probably not going into | Debian. Fabian has also not responded to my email. | | See #255850, maybe it could give you some information. | | OK. No activity in more than a year. The website where the packages | were offered early in the thread no longer exists. | | If there are no objections, I will take over the ITP. I talked with Stefan Lippers-Hollmann a few days ago about it and apart from some technical problems with it (namely that the NX build system is an interesting case of let's see how messed-up we can make this build and no development package), it's almost ready to go into sid. I've offered to sponsor him if he needs that and would be interested in helping out with packaging. Note that there's a pkg-nx repository on alioth too, even though it hasn't been used for anything yet. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: NMU with new upstream
* Oliver Kurth | But he seems to be MIA. I reported the bug 16 days ago, told him about my | package 9 days ago. I never got a response. The bug itself is even older. MIA is a lot longer than 9 or 16 days.. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for upload
* Will Newton | clisp now depends on a library that was once distributed inside the tarball, | libsigsegv, which I have now packaged separately. This package needs to be | uploaded first I would imagine. I'll look into this, comments follow in a separate mail. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: NMU with new upstream
* Oliver Kurth | But he seems to be MIA. I reported the bug 16 days ago, told him about my | package 9 days ago. I never got a response. The bug itself is even older. MIA is a lot longer than 9 or 16 days.. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Request for upload
* Will Newton | clisp now depends on a library that was once distributed inside the tarball, | libsigsegv, which I have now packaged separately. This package needs to be | uploaded first I would imagine. I'll look into this, comments follow in a separate mail. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Use of the BTS for managing sponsorship
* Raphael Hertzog | Fortunately, it looks like some people are more constructive than you. | Tollef and Rune are going to look for a new sponsor tracking system | this weekend. some random notes are now available at http://home.mihtjel.dk/~mihtjel/sponsorship/ and http://sponsor.raw.no/ Comments appreciated -- here or on IRC. Talk to mihtjel or me (Mithrandir). -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Use of the BTS for managing sponsorship
* Raphael Hertzog | Fortunately, it looks like some people are more constructive than you. | Tollef and Rune are going to look for a new sponsor tracking system | this weekend. some random notes are now available at http://home.mihtjel.dk/~mihtjel/sponsorship/ and http://sponsor.raw.no/ Comments appreciated -- here or on IRC. Talk to mihtjel or me (Mithrandir). -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Use of the BTS for managing sponsorship
* Raphael Hertzog | I'm the guy who invented sponsorship, I'm the one who wrote the | sponsorhip CGI. Most of my sponsorees haven't come from the CGI of yours, but from this list, or #debian-devel. So, even though you might know stuff about sponsorship, you do not own the term. What I (and it seems a lot of other people) think is that the current system works fine. At least, it works a lot better than having to handle it through the BTS. IMO. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Use of the BTS for managing sponsorship
* Jérôme Marant | On Thu, Aug 29, 2002 at 02:00:40PM +0200, Tollef Fog Heen wrote: | | So, even though you might know stuff about sponsorship, you do not own | the term. What I (and it seems a lot of other people) think is that | the current system works fine. At least, it works a lot better than | having to handle it through the BTS. IMO. | | No, from my point of view it is not enough. I have no way to | keep track of the sponsorship work. Then I suggest you scratch your itch without forcing everybody else to have the same itch as you. | I have a recent case of someone who NMU'ed packages of someone | I do sponsor but I wasn't aware of that. Then you hadn't subscribed to the package through the PTS, I think. What I understand buxy wants the BTS for is for making sure people are able to find a sponsor, and a way to see which sponsorees who don't have a sponsor. Not do all the sponsor/sponsoree comms through the BTS. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Use of the BTS for managing sponsorship
* Raphael Hertzog | Le Thu, Aug 29, 2002 at 02:00:40PM +0200, Tollef Fog Heen écrivait: | | Most of my sponsorees haven't come from the CGI of yours, but from | this list, or #debian-devel. | | I know that. I observe myself that the CGI is most of the time out of | touch with the reality. That's why I want to get rid of it. | | Still, if we created the CGI in the first place, it's because we wanted | to keep a track of who's looking for a sponsor and so on. | | That's why I want us to switch to use the BTS. This is usually called shotgun debugging. Try another solution until you find one which fits. Obviously, this is not a good way to debug problems. | the term. What I (and it seems a lot of other people) think is that | the current system works fine. At least, it works a lot better than | having to handle it through the BTS. IMO. | | You don't know if the current system works well enough (neither do I). | Do you know if all sponsoree find a sponsor ? I know that not all sponsorees find a sponsor. The BTS isn't a silver bullet for fixing that. If a package is interesting above some threshold, it will get sponsored, whether it be on -mentors or the BTS. | What I see is that the CGI has a big list of people who haven't find a | sponsor, and I don't know if they have asked here, or if they have one | but forgot to update the entry and so on ... the BTS would keep track of | what happens wrt each sponsored packages. I could find answers to | questions like that. Why do you think the BTS would be kept more up-to-date? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Use of the BTS for managing sponsorship
* Raphael Hertzog | And I'm going to push the BTS as long as nobody provides me | another working replacement to the current CGI. How about scratching your own itch instead of forcing everybody else to have the same itch _and_ scratch yours? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Use of the BTS for managing sponsorship
* Jérôme Marant | On Thu, Aug 29, 2002 at 03:21:11PM +0200, Tollef Fog Heen wrote: | | Then I suggest you scratch your itch without forcing everybody else to | have the same itch as you. | | I want something that you don't need. Then, I win. | | 'Tell me what you need and I'll tell you how not to need it' | That's what you are proposing. No, it's not. I am saying that I don't think this is a problem. You are proposing to change how I do my stuff, not the other way around. | | I have a recent case of someone who NMU'ed packages of someone | | I do sponsor but I wasn't aware of that. | | Then you hadn't subscribed to the package through the PTS, I think. | | Of course I did, but NMU requests have never been implied | access to the BTS. I want an entry point for contacts with the | sponsoree. I don't have any currently. Parse error for the first part. Uhm, you don't have an entry point? Like -mentors? | It is a matter of practice. The one Raphaël is proposing would not | be annoying at all. For me it would, because of the amount of noise. The BTS is quite noisy. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Use of the BTS for managing sponsorship
* Raphael Hertzog | I'm the guy who invented sponsorship, I'm the one who wrote the | sponsorhip CGI. Most of my sponsorees haven't come from the CGI of yours, but from this list, or #debian-devel. So, even though you might know stuff about sponsorship, you do not own the term. What I (and it seems a lot of other people) think is that the current system works fine. At least, it works a lot better than having to handle it through the BTS. IMO. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Use of the BTS for managing sponsorship
* Jérôme Marant | On Thu, Aug 29, 2002 at 02:00:40PM +0200, Tollef Fog Heen wrote: | | So, even though you might know stuff about sponsorship, you do not own | the term. What I (and it seems a lot of other people) think is that | the current system works fine. At least, it works a lot better than | having to handle it through the BTS. IMO. | | No, from my point of view it is not enough. I have no way to | keep track of the sponsorship work. Then I suggest you scratch your itch without forcing everybody else to have the same itch as you. | I have a recent case of someone who NMU'ed packages of someone | I do sponsor but I wasn't aware of that. Then you hadn't subscribed to the package through the PTS, I think. What I understand buxy wants the BTS for is for making sure people are able to find a sponsor, and a way to see which sponsorees who don't have a sponsor. Not do all the sponsor/sponsoree comms through the BTS. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Use of the BTS for managing sponsorship
* Raphael Hertzog | Le Thu, Aug 29, 2002 at 02:00:40PM +0200, Tollef Fog Heen écrivait: | | Most of my sponsorees haven't come from the CGI of yours, but from | this list, or #debian-devel. | | I know that. I observe myself that the CGI is most of the time out of | touch with the reality. That's why I want to get rid of it. | | Still, if we created the CGI in the first place, it's because we wanted | to keep a track of who's looking for a sponsor and so on. | | That's why I want us to switch to use the BTS. This is usually called shotgun debugging. Try another solution until you find one which fits. Obviously, this is not a good way to debug problems. | the term. What I (and it seems a lot of other people) think is that | the current system works fine. At least, it works a lot better than | having to handle it through the BTS. IMO. | | You don't know if the current system works well enough (neither do I). | Do you know if all sponsoree find a sponsor ? I know that not all sponsorees find a sponsor. The BTS isn't a silver bullet for fixing that. If a package is interesting above some threshold, it will get sponsored, whether it be on -mentors or the BTS. | What I see is that the CGI has a big list of people who haven't find a | sponsor, and I don't know if they have asked here, or if they have one | but forgot to update the entry and so on ... the BTS would keep track of | what happens wrt each sponsored packages. I could find answers to | questions like that. Why do you think the BTS would be kept more up-to-date? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Use of the BTS for managing sponsorship
* Raphael Hertzog | And I'm going to push the BTS as long as nobody provides me | another working replacement to the current CGI. How about scratching your own itch instead of forcing everybody else to have the same itch _and_ scratch yours? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Use of the BTS for managing sponsorship
* Jérôme Marant | On Thu, Aug 29, 2002 at 03:21:11PM +0200, Tollef Fog Heen wrote: | | Then I suggest you scratch your itch without forcing everybody else to | have the same itch as you. | | I want something that you don't need. Then, I win. | | 'Tell me what you need and I'll tell you how not to need it' | That's what you are proposing. No, it's not. I am saying that I don't think this is a problem. You are proposing to change how I do my stuff, not the other way around. | | I have a recent case of someone who NMU'ed packages of someone | | I do sponsor but I wasn't aware of that. | | Then you hadn't subscribed to the package through the PTS, I think. | | Of course I did, but NMU requests have never been implied | access to the BTS. I want an entry point for contacts with the | sponsoree. I don't have any currently. Parse error for the first part. Uhm, you don't have an entry point? Like -mentors? | It is a matter of practice. The one Raphaël is proposing would not | be annoying at all. For me it would, because of the amount of noise. The BTS is quite noisy. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: User interaction in postinst
* Roger Leigh | From what I have read about debconf, the questions it asks are static. | However, in this case, I can't generate the questions until the | package is installed: the translations are gettext .mo files in the | gimpprint-locales package (which may be not installed or incomplete), | and the list of printer drivers is extracted from libgimpprint.so.1 by | genppd at run-time (and the list of printers changes as new ones are | added). | | Is using debconf possible in this case? Preconfiguring will fail, as | I can't get the data to list at that point. The multiselect widget | type is just what I'm looking for, though. db_subst in the postinst, or make it possible to run it after the package has been installed? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: User interaction in postinst
* Roger Leigh | From what I have read about debconf, the questions it asks are static. | However, in this case, I can't generate the questions until the | package is installed: the translations are gettext .mo files in the | gimpprint-locales package (which may be not installed or incomplete), | and the list of printer drivers is extracted from libgimpprint.so.1 by | genppd at run-time (and the list of printers changes as new ones are | added). | | Is using debconf possible in this case? Preconfiguring will fail, as | I can't get the data to list at that point. The multiselect widget | type is just what I'm looking for, though. db_subst in the postinst, or make it possible to run it after the package has been installed? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Mentor Requests?
* Philip S. Hempel | I wanted to know after looking at the stats on this list for mentors | and new maint. What is a normal time to wait until you should say | something to someone about your status/request for a Mentor? | | I was concerned with the time I saw for some that have waited at | least 3 weeks to 6 months to become a maintainer. I noticed some had | not yet to have recieved a mentor. a mentor is not a necessary part of the NM process, though it often helps, and s/he can offer you help and advice through the process. | Thanks, I put in a request last week for a mentor for my Debian | packages of MessageWall located at | http://ns.linuxhardcore.com/debian/ I've been interested in looking at them, but haven't had the time yet. I'll try to look at them in a few days. Bug me if you don't get any response. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mentor Requests?
* Philip S. Hempel | I wanted to know after looking at the stats on this list for mentors | and new maint. What is a normal time to wait until you should say | something to someone about your status/request for a Mentor? | | I was concerned with the time I saw for some that have waited at | least 3 weeks to 6 months to become a maintainer. I noticed some had | not yet to have recieved a mentor. a mentor is not a necessary part of the NM process, though it often helps, and s/he can offer you help and advice through the process. | Thanks, I put in a request last week for a mentor for my Debian | packages of MessageWall located at | http://ns.linuxhardcore.com/debian/ I've been interested in looking at them, but haven't had the time yet. I'll try to look at them in a few days. Bug me if you don't get any response. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package status overview for developers (was: auto-builders..)
* Christian Hammers | On Thu, Jul 18, 2002 at 11:54:43AM +0900, Oohara Yuuma wrote: | or http://people.debian.org/~igenibel/ | | Wow, this is great! Can you please convince the Debian webmasters to | put this script somewhere more easily accessable on the web pages? in a while, we will hopefully have developer.debian.org which will act as an information portal (oh, how I hate that word) for developers, with their bugs and packages and various statuses. Currently, we are waiting for an interface to debbugs which we can use. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: package status overview for developers (was: auto-builders..)
* Christian Hammers | On Thu, Jul 18, 2002 at 11:54:43AM +0900, Oohara Yuuma wrote: | or http://people.debian.org/~igenibel/ | | Wow, this is great! Can you please convince the Debian webmasters to | put this script somewhere more easily accessable on the web pages? in a while, we will hopefully have developer.debian.org which will act as an information portal (oh, how I hate that word) for developers, with their bugs and packages and various statuses. Currently, we are waiting for an interface to debbugs which we can use. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Safe removal of a user while purging
* Magnus Ekdahl
| I'm trying to remove the clamav user when purging the clamav package. The
| user clamav is created in postinst using:
Why are you removing that user?
| case $1 in
| purge)
| TMPFILE=`tempfile`
| chown root:root $TMPFILE
| chmod 600 $TMPFILE
|
| sed 's/clamav:!:[0-9]*:[0-9]*:[0-9]*:[0-9]*::://' /etc/shadow $TMPFILE
| sed '/^$/d' $TMPFILE /etc/shadow
|
| sed 's/clamav:x:[0-9]*:[0-9]*::\/var:\/bin\/false//' /etc/passwd $TMPFILE
| sed '/^$/d' $TMPFILE /etc/passwd
|
| rm $TMPFILE
| ;;
| remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
| ;;
| *)
| echo postrm called with unknown argument \`$1' 2
| exit 0
| esac
This will grant you a serious or grave bug. Don't mess with
/etc/{passwd,shadow} directly -- that will break if people use
something like ldap for handling those files.
--
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Safe removal of a user while purging
* Magnus Ekdahl
| I'm trying to remove the clamav user when purging the clamav package. The
| user clamav is created in postinst using:
Why are you removing that user?
| case $1 in
| purge)
| TMPFILE=`tempfile`
| chown root:root $TMPFILE
| chmod 600 $TMPFILE
|
| sed 's/clamav:!:[0-9]*:[0-9]*:[0-9]*:[0-9]*::://' /etc/shadow $TMPFILE
| sed '/^$/d' $TMPFILE /etc/shadow
|
| sed 's/clamav:x:[0-9]*:[0-9]*::\/var:\/bin\/false//' /etc/passwd
$TMPFILE
| sed '/^$/d' $TMPFILE /etc/passwd
|
| rm $TMPFILE
| ;;
| remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
| ;;
| *)
| echo postrm called with unknown argument \`$1' 2
| exit 0
| esac
This will grant you a serious or grave bug. Don't mess with
/etc/{passwd,shadow} directly -- that will break if people use
something like ldap for handling those files.
--
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor requested for Linux Bluetooth tools
* Edd Dumbill | The BlueZ kernel modules are likely to be in kernel 2.4.19 and so I'm | packaging up the accompanying tools (GPL licensed) in readiness for | this. I'm looking for a sponsor for these packages, and after a while I | will start the NM process. If I can get those to work with the 3com card I am getting my hands on in about 12 hours, I'd be happy to sponsor you. -- Tollef Fog Heen ,''`. : :' : Unix IS user friendly... It's just `. `' selective about who its friends are. `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keysigning in Phoenix, AZ
* Bill Jonas | I searched, but there was only country-level granularity, and location | wasn't included. Does location show up only if you're a member? yes. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keysigning in Phoenix, AZ
* Bill Jonas | I searched, but there was only country-level granularity, and location | wasn't included. Does location show up only if you're a member? yes. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sorting of wordlists
See bug #133795, is there any policy regarding how the word lists are supposed to be sorted? If I do what the submitter wants, look will break with LANG != n[nbo]_NO, so I am somewhat reluctant to do it. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sorting of wordlists
See bug #133795, is there any policy regarding how the word lists are supposed to be sorted? If I do what the submitter wants, look will break with LANG != n[nbo]_NO, so I am somewhat reluctant to do it. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Moving a package from main to non-US/main
* Michael Beattie | On Fri, Feb 15, 2002 at 01:43:32PM +0100, J?r?me Marant wrote: |IIRC, it is not non-US/main but simply non-US. |Other sections are non-US/contrib and non-US/non-free. | | either works. 2.1.7. Subsections -- [snip] * `non-US', `non-US/contrib' or `non-US/non-free' if the package is in _non-US/main_, _non-US/contrib_ or _non-US/non-free_ respectively. So it should be non-US. non-US/main works just because it is such a common error. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving a package from main to non-US/main
* Michael Beattie | On Fri, Feb 15, 2002 at 01:43:32PM +0100, J?r?me Marant wrote: |IIRC, it is not non-US/main but simply non-US. |Other sections are non-US/contrib and non-US/non-free. | | either works. 2.1.7. Subsections -- [snip] * `non-US', `non-US/contrib' or `non-US/non-free' if the package is in _non-US/main_, _non-US/contrib_ or _non-US/non-free_ respectively. So it should be non-US. non-US/main works just because it is such a common error. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Moving a package from main to non-US/main
* Josip Rodin | So it should be non-US. non-US/main works just because it is such a | common error. | | Or maybe it works because it's pointless and absurd to force people to use | just one name when the other sounds perfectly fine, too. Hmm, I saw some comment about this when we discussed this on irc the other day. Oh well, nevermind. :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Re: binary-or-shlib-defines-rpath
| [Tollef Fog Heen] | chrpath isn't packaged yet, but I am sure Petter Reinholdsen | wouldn't object. | | Petter _Reinholdtsen_ do not object at all. Sorry, my misspelling. All those ds and ts an everything. I apologize. | Note that chrpath isn't able to add an rpath section to an ELF file, | only modify and remove one. (If anyone know how to add one, please | send patches. :-) no idea about the internal structure of the elf format. | There is no web page, but the source is available from | URL:ftp://ftp.hungry.com/pub/hungry/chrpath/. I started on the | packaging once, but did not complete the task. Still some fragments | left in CVS. :-) ok, will look into it. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: some questions about DBS
* Robert Bihlmeyer | Michael Moerz [EMAIL PROTECTED] writes: | | Well is there any documentation out there that would line out | the usage of the DBS (doogie build system)? | [...] | Is there any url where I could fetch a debian/scripts tarball | from? (or should I stick to the mentioned packages?) | | I think you want to install the dbs package. It should include | proper documentation (unless buggy). It doesn't. There are absolutely no docs, IIRC. Though, have a look at cfengine for another example of DBS, and a clean one, IMHO. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: some questions about DBS
* Robert Bihlmeyer | Michael Moerz [EMAIL PROTECTED] writes: | | Well is there any documentation out there that would line out | the usage of the DBS (doogie build system)? | [...] | Is there any url where I could fetch a debian/scripts tarball | from? (or should I stick to the mentioned packages?) | | I think you want to install the dbs package. It should include | proper documentation (unless buggy). It doesn't. There are absolutely no docs, IIRC. Though, have a look at cfengine for another example of DBS, and a clean one, IMHO. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Private perl modules
* Robert Bihlmeyer [snip advice] I agree; thanks for your advice. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Private perl modules
* Robert Bihlmeyer [snip advice] I agree; thanks for your advice. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Private perl modules
I am currently packaging Request Tracker, a web/email/cli-based trouble ticket system. It includes some private perl modules, which are only used internally. Is it okay to put those in /usr/share/request-tracker/lib or should I try to put them somewhere sane in /usr/share/perl5/ ? I don't think they are useful for any application except RT. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
HTML files
I am currently packaging Request Tracker ( http://fsck.com/projects/rt/ ), and have stumbled into a few problems. This package contains some HTML files (it's a web/mail/CLI application). Those are not meant to be modified and are by default installed into /usr/share/request-tracker/WebRT/html/. Is this OK? If not, where should I put them. And, where should I put the CSS file? Those HTML files are not intended to be modified; if one wants to do that, you should drop an HTML file in /etc/request-tracker/html Should /etc/request-tracker/html be rm -rf'ed when the package is purged? I am unsure, since the package itself just provides the directory, it does not mandate which files the admin puts there. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug in stable, fixed in unstable
* Jesus M. Gonzalez-Barahona | What should I do with the bug report? Should I just close it, stating | that it is fixed in woodysid? This is a pretty severy bug report; should be serious at least. I would upload a fixed package to proposed-updates and ask for it to be included in 2.2r6 (if that ever comes out). -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: HTML files
* Robert Bihlmeyer | Tollef Fog Heen [EMAIL PROTECTED] writes: | | I am currently packaging Request Tracker ( | http://fsck.com/projects/rt/ ), and have stumbled into a few problems. | | This is different from the existing package webrt, isn't it? It's version 2. And yes, we are coordinated. :) | This package contains some HTML files (it's a web/mail/CLI | application). Those are not meant to be modified and are by default | installed into /usr/share/request-tracker/WebRT/html/. Is this OK? | | Looks good, if the webserver is configured to be able to access them. They'll be accessed through a modperl handler, so that won't be an issue. | Should /etc/request-tracker/html be rm -rf'ed when the package is | purged? I am unsure, since the package itself just provides the | directory, it does not mandate which files the admin puts there. | | Since all other config files are removed when purging, I'd say remove | them. ok, thanks for your advice. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Private perl modules
I am currently packaging Request Tracker, a web/email/cli-based trouble ticket system. It includes some private perl modules, which are only used internally. Is it okay to put those in /usr/share/request-tracker/lib or should I try to put them somewhere sane in /usr/share/perl5/ ? I don't think they are useful for any application except RT. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Bug in stable, fixed in unstable
* Jesus M. Gonzalez-Barahona | What should I do with the bug report? Should I just close it, stating | that it is fixed in woodysid? This is a pretty severy bug report; should be serious at least. I would upload a fixed package to proposed-updates and ask for it to be included in 2.2r6 (if that ever comes out). -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: HTML files
* Robert Bihlmeyer | Tollef Fog Heen [EMAIL PROTECTED] writes: | | I am currently packaging Request Tracker ( | http://fsck.com/projects/rt/ ), and have stumbled into a few problems. | | This is different from the existing package webrt, isn't it? It's version 2. And yes, we are coordinated. :) | This package contains some HTML files (it's a web/mail/CLI | application). Those are not meant to be modified and are by default | installed into /usr/share/request-tracker/WebRT/html/. Is this OK? | | Looks good, if the webserver is configured to be able to access them. They'll be accessed through a modperl handler, so that won't be an issue. | Should /etc/request-tracker/html be rm -rf'ed when the package is | purged? I am unsure, since the package itself just provides the | directory, it does not mandate which files the admin puts there. | | Since all other config files are removed when purging, I'd say remove | them. ok, thanks for your advice. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Conditional use of debconf
* Bob Hilliard | if !grep -q include /etc/dictd.conf |then |[Display message] | fi if !grep -q include /etc/dictd.conf then db_input high package/foo || true fi -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Conditional use of debconf
* Bob Hilliard | if !grep -q include /etc/dictd.conf |then |[Display message] | fi if !grep -q include /etc/dictd.conf then db_input high package/foo || true fi -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Howto remove the source package
* Takashi Okamoto | So, I want to remove jakarta-commons source package. What should I do | and where can I get information about it? File a bug against ftp.debian.org asking for their removal. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Howto remove the source package
* Takashi Okamoto | So, I want to remove jakarta-commons source package. What should I do | and where can I get information about it? File a bug against ftp.debian.org asking for their removal. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Packaging something with a PostgreSQL database.
* Matt Zimmerman | On Sat, Dec 29, 2001 at 04:01:40PM +0100, Tollef Fog Heen wrote: | | * Gaetano Paolone | | #DEBHELPER# | | ** end postinst *** | | | | ** begin makedb.sh *** | | #!/bin/bash | | #set -e | | export SHAREDIR=/usr/share/odontolinux | | export TMPDIR=/var/tmp/odontolinux | | export PATH=$PATH:/usr/lib/postgresql/bin | | | | mkdir -p $TMPDIR | | mkdir -p $TMPDIR || exit 1, I presume? | | Or, uncomment set -e and guard whichever commands (presumably few) should | be allowed to fail. Actually, neither your nor my suggestion will work. mkdir -p doesn't fail if the directory already exists, so you probably want something like mkdir $TMPDIR || exit 1 (or mkdir $TMPDIR with set -e active). And it should respect TMPDIR if it is already set, and I see no reason why it uses /var/tmp instead of /tmp. :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging something with a PostgreSQL database.
* Matt Zimmerman | Is there some reason that it _should_ fail if the directory already | exists? Normally, that is not an error condition. It is a race condition and a possible security hole, since /var/tmp is publically writeable. If he used some other non-trwxrwxrwx-dir it would be better. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging something with a PostgreSQL database.
* Matt Zimmerman | On Sat, Dec 29, 2001 at 04:01:40PM +0100, Tollef Fog Heen wrote: | | * Gaetano Paolone | | #DEBHELPER# | | ** end postinst *** | | | | ** begin makedb.sh *** | | #!/bin/bash | | #set -e | | export SHAREDIR=/usr/share/odontolinux | | export TMPDIR=/var/tmp/odontolinux | | export PATH=$PATH:/usr/lib/postgresql/bin | | | | mkdir -p $TMPDIR | | mkdir -p $TMPDIR || exit 1, I presume? | | Or, uncomment set -e and guard whichever commands (presumably few) should | be allowed to fail. Actually, neither your nor my suggestion will work. mkdir -p doesn't fail if the directory already exists, so you probably want something like mkdir $TMPDIR || exit 1 (or mkdir $TMPDIR with set -e active). And it should respect TMPDIR if it is already set, and I see no reason why it uses /var/tmp instead of /tmp. :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Packaging something with a PostgreSQL database.
* Matt Zimmerman | Is there some reason that it _should_ fail if the directory already | exists? Normally, that is not an error condition. It is a race condition and a possible security hole, since /var/tmp is publically writeable. If he used some other non-trwxrwxrwx-dir it would be better. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Packaging something with a PostgreSQL database.
* Gaetano Paolone | ** begin preinst *** | #!/bin/bash | # Pre-installation script for odontolinux debian package | | grep -s -q '^gestionestudio:' /etc/group || | ( | echo Adding gestionestudio group | groupadd gestionestudio | grep '^gestionestudio:' /etc/group) | grep -s -q '^gestionestudio:' /etc/passwd || | ( echo Adding gestionestudio user | useradd -c Odontolinux superuser -d /home/gestionestudio -g gestionestudio |-s /bin/bash gestionestudio | grep '^gestionestudio:' /etc/passwd) use `id` instead of grepping the password and group files, or you'll get a serious bug. :) | ** begin postinst *** | #!/bin/bash | | if [ $1 = configure ]; then | if [ -d /usr/doc -a ! -e /usr/doc/odontolinux -a -d /usr/share/doc/odontolinux ]; |then | ln -sf ../share/doc/odontolinux /usr/doc/odontolinux | fi | fi | export PGUSER=postgres | /usr/share/odontolinux/makedb.sh su - postgres -c /usr/share/odontolinux/makedb.sh | #DEBHELPER# | ** end postinst *** | | ** begin makedb.sh *** | #!/bin/bash | #set -e | export SHAREDIR=/usr/share/odontolinux | export TMPDIR=/var/tmp/odontolinux | export PATH=$PATH:/usr/lib/postgresql/bin | | mkdir -p $TMPDIR mkdir -p $TMPDIR || exit 1, I presume? | if psql -ltq |grep 'gestionestudio' | then | echo Database exists. | else | echo Database does not exists, creating it. | createdb gestionestudio | echo Creating postgres users... What happens if I happen to have a db called gestionestudio? I think you should rather have the admin run this by hand. It will be less error prone. Or you can ask whether he wants to run it automatically when installing, but please don't just do it. | userid=`psql -qt -d gestionestudio -c | DELETE FROM pg_shadow where usename ~ '^gestionestudio_' ; | DELETE FROM pg_group where groname ~ '^gestionestudio_'; | create user gestionestudio createuser;` Deleting froma pg_shadow and pg_group is _evil_. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging something with a PostgreSQL database.
* Gaetano Paolone | ** begin preinst *** | #!/bin/bash | # Pre-installation script for odontolinux debian package | | grep -s -q '^gestionestudio:' /etc/group || | ( | echo Adding gestionestudio group | groupadd gestionestudio | grep '^gestionestudio:' /etc/group) | grep -s -q '^gestionestudio:' /etc/passwd || | ( echo Adding gestionestudio user | useradd -c Odontolinux superuser -d /home/gestionestudio -g gestionestudio -s /bin/bash gestionestudio | grep '^gestionestudio:' /etc/passwd) use `id` instead of grepping the password and group files, or you'll get a serious bug. :) | ** begin postinst *** | #!/bin/bash | | if [ $1 = configure ]; then | if [ -d /usr/doc -a ! -e /usr/doc/odontolinux -a -d /usr/share/doc/odontolinux ]; then | ln -sf ../share/doc/odontolinux /usr/doc/odontolinux | fi | fi | export PGUSER=postgres | /usr/share/odontolinux/makedb.sh su - postgres -c /usr/share/odontolinux/makedb.sh | #DEBHELPER# | ** end postinst *** | | ** begin makedb.sh *** | #!/bin/bash | #set -e | export SHAREDIR=/usr/share/odontolinux | export TMPDIR=/var/tmp/odontolinux | export PATH=$PATH:/usr/lib/postgresql/bin | | mkdir -p $TMPDIR mkdir -p $TMPDIR || exit 1, I presume? | if psql -ltq |grep 'gestionestudio' | then | echo Database exists. | else | echo Database does not exists, creating it. | createdb gestionestudio | echo Creating postgres users... What happens if I happen to have a db called gestionestudio? I think you should rather have the admin run this by hand. It will be less error prone. Or you can ask whether he wants to run it automatically when installing, but please don't just do it. | userid=`psql -qt -d gestionestudio -c | DELETE FROM pg_shadow where usename ~ '^gestionestudio_' ; | DELETE FROM pg_group where groname ~ '^gestionestudio_'; | create user gestionestudio createuser;` Deleting froma pg_shadow and pg_group is _evil_. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: dpkg-reconfigure, policy, and least surprise principle
* Mark Brown | On Sun, Dec 02, 2001 at 12:36:26PM +0100, Tollef Fog Heen wrote: | * Roland Mas | | | A hypothetical third hand would be holding this: the postinst first | | reads the master config file and shoves its values into Debconf, then | | This is the right way, though. Note that unless the admin has asked | for it, previously answered debconf questions won't be asked again, | so you wouldn't bother the admin too much. | | I've done this in one of my packages too but I worry what will happen | when Debconf finally gets support for remote databases. That will probably be a problem if the DB is read-only, yes. joeyh, any thoughts on this one? | At that point the configuration on the system where the | configuration front end is running may not be the configuration of | the system that is being configured. I don't care where the frontend is running, but I know that the system where the config script is running is the system which is being configured. This might not be the place where the backend DB is running, though. So we might have a problem with code which looks like: #! /bin/sh -e . /usr/share/debconf/confmodule if [ -e /etc/suck/get-news.conf ]; then remoteserver=`grep remoteserver /etc/suck/get-news.conf | cut -d: -f 2-` fi if [ $remoteserver ]; then db_set suck/get-news/remoteserver $remoteserver fi db_input medium suck/get-news/remoteserver || true db_go || true and then postinst: #! /bin/sh -e . /usr/share/debconf/confmodule if [ ! -f /etc/suck/get-news.conf ]; then cp /usr/share/doc/suck/examples/get-news.conf /etc/suck/get-news.conf fi db_get suck/get-news/remoteserver sed -e s/remoteserver:.*$/remoteserver: $RET/ /etc/suck/get-news.conf /etc/suck/get-news.conf.tmp$$ mv /etc/suck/get-news.conf.tmp$$ /etc/suck/get-news.conf (Yes, I know about not copying from /usr/share/doc, but haven't fixed it yet.) This _will_ overwrite the local values, unless Debconf has a writable, local DB as well. I really don't see how to implement this without a writable DB. Is having a writable DB somewhere a requirement of Debconf or is my code broken? If it's broken, what is the fix? -- Tollef Fog Heen Axiom #1: You Can't Win -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-reconfigure, policy, and least surprise principle
* Mark Brown | On Sun, Dec 02, 2001 at 12:36:26PM +0100, Tollef Fog Heen wrote: | * Roland Mas | | | A hypothetical third hand would be holding this: the postinst first | | reads the master config file and shoves its values into Debconf, then | | This is the right way, though. Note that unless the admin has asked | for it, previously answered debconf questions won't be asked again, | so you wouldn't bother the admin too much. | | I've done this in one of my packages too but I worry what will happen | when Debconf finally gets support for remote databases. That will probably be a problem if the DB is read-only, yes. joeyh, any thoughts on this one? | At that point the configuration on the system where the | configuration front end is running may not be the configuration of | the system that is being configured. I don't care where the frontend is running, but I know that the system where the config script is running is the system which is being configured. This might not be the place where the backend DB is running, though. So we might have a problem with code which looks like: #! /bin/sh -e . /usr/share/debconf/confmodule if [ -e /etc/suck/get-news.conf ]; then remoteserver=`grep remoteserver /etc/suck/get-news.conf | cut -d: -f 2-` fi if [ $remoteserver ]; then db_set suck/get-news/remoteserver $remoteserver fi db_input medium suck/get-news/remoteserver || true db_go || true and then postinst: #! /bin/sh -e . /usr/share/debconf/confmodule if [ ! -f /etc/suck/get-news.conf ]; then cp /usr/share/doc/suck/examples/get-news.conf /etc/suck/get-news.conf fi db_get suck/get-news/remoteserver sed -e s/remoteserver:.*$/remoteserver: $RET/ /etc/suck/get-news.conf /etc/suck/get-news.conf.tmp$$ mv /etc/suck/get-news.conf.tmp$$ /etc/suck/get-news.conf (Yes, I know about not copying from /usr/share/doc, but haven't fixed it yet.) This _will_ overwrite the local values, unless Debconf has a writable, local DB as well. I really don't see how to implement this without a writable DB. Is having a writable DB somewhere a requirement of Debconf or is my code broken? If it's broken, what is the fix? -- Tollef Fog Heen Axiom #1: You Can't Win
Re: dpkg-reconfigure, policy, and least surprise principle
* Roland Mas | A hypothetical third hand would be holding this: the postinst first | reads the master config file and shoves its values into Debconf, then | asks the debconf questions, then updates the sourceforge.conf file | with the new values from Debconf. It sounds horribly messy, though, | and I'm not sure it's doable without too much hackery. This is the right way, though. Note that unless the admin has asked for it, previously answered debconf questions won't be asked again, so you wouldn't bother the admin too much. Look at suck or mailman for examples on how to do this. -- Tollef Fog Heen Axiom #1: You Can't Win -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-reconfigure, policy, and least surprise principle
* Roland Mas | A hypothetical third hand would be holding this: the postinst first | reads the master config file and shoves its values into Debconf, then | asks the debconf questions, then updates the sourceforge.conf file | with the new values from Debconf. It sounds horribly messy, though, | and I'm not sure it's doable without too much hackery. This is the right way, though. Note that unless the admin has asked for it, previously answered debconf questions won't be asked again, so you wouldn't bother the admin too much. Look at suck or mailman for examples on how to do this. -- Tollef Fog Heen Axiom #1: You Can't Win
Re: webserver directory locations when you're not using a webserver
* Hereward Cooper | Now what happens when you either don't have a local webserver, or | are not creating the gallery for it? Should the package put the | images/ directory in a directory some where (/etc/tigger/images/) | then get the user to move it to the apporiate place and telling them | to use --imagedir=, noting this in the README.debian and man | page. I take it that making a depend on apache, and auto placing the | images/ in /var/www/images/ is out of the question. There isn't any policy on this one, but I have proposed one in bug #89867 against policy. If you think that is a good solution, please second my proposal. -- Tollef Fog Heen Axiom #1: You Can't Win -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian - man pages
* Robert Bihlmeyer | Tollef Fog Heen [EMAIL PROTECTED] writes: | | If the INSTALL file contains both building and installation | instructions, and how to set up the package, what is then the correct | way to handle that? | | Cut and paste the relevant portions into README.Debian or something? | | That's obviously the most correct solution; but you should do this | only if you're comfortable with keeping this in sync with the | actual INSTALL file. This was one of my worries. | Personally, I have no problems with /usr/share/doc/foo/INSTALL that | contains set-up (or similar) information and some useless stuff. It | only annoys me if an INSTALL file is wholly useless to users of binary | packages -- e.g. GNU's standard INSTALL instructions. Ack, true, I agree Would this be too much magic to add to lintian -- check whether those are the generic GNU installation instructions or something else? -- Tollef Fog Heen Axiom #1: You Can't Win -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian - man pages
* Sean 'Shaleh' Perry (please don't Cc me, I read the list) | On 19-Oct-2001 Tollef Fog Heen wrote: | If the INSTALL file contains both building and installation | instructions, and how to set up the package, what is then the correct | way to handle that? | | Cut and paste the relevant portions into README.Debian or something? | | | The other choice is to rename the file. Which is just as good a solution as adding a lintian override in order to shut lintian up. That is IMHO not a very good one. -- Tollef Fog Heen Axiom #1: You Can't Win -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian - man pages
* Robert Bihlmeyer | Tollef Fog Heen [EMAIL PROTECTED] writes: | | If the INSTALL file contains both building and installation | instructions, and how to set up the package, what is then the correct | way to handle that? | | Cut and paste the relevant portions into README.Debian or something? | | That's obviously the most correct solution; but you should do this | only if you're comfortable with keeping this in sync with the | actual INSTALL file. This was one of my worries. | Personally, I have no problems with /usr/share/doc/foo/INSTALL that | contains set-up (or similar) information and some useless stuff. It | only annoys me if an INSTALL file is wholly useless to users of binary | packages -- e.g. GNU's standard INSTALL instructions. Ack, true, I agree Would this be too much magic to add to lintian -- check whether those are the generic GNU installation instructions or something else? -- Tollef Fog Heen Axiom #1: You Can't Win
Re: lintian - man pages
* Sean 'Shaleh' Perry (please don't Cc me, I read the list) | On 19-Oct-2001 Tollef Fog Heen wrote: | If the INSTALL file contains both building and installation | instructions, and how to set up the package, what is then the correct | way to handle that? | | Cut and paste the relevant portions into README.Debian or something? | | | The other choice is to rename the file. Which is just as good a solution as adding a lintian override in order to shut lintian up. That is IMHO not a very good one. -- Tollef Fog Heen Axiom #1: You Can't Win
Re: lintian - man pages
* Stephen Stafford [from policy] | It is often a good idea to put text information files (`README's, | changelogs, and so forth) that come with the source package in | `/usr/share/doc/package' in the binary package. However, you don't | need to install the instructions for building and installing the | package, of course! If the INSTALL file contains both building and installation instructions, and how to set up the package, what is then the correct way to handle that? Cut and paste the relevant portions into README.Debian or something? -- Tollef Fog Heen Axiom #1: You Can't Win -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian - man pages
* Stephen Stafford [from policy] | It is often a good idea to put text information files (`README's, | changelogs, and so forth) that come with the source package in | `/usr/share/doc/package' in the binary package. However, you don't | need to install the instructions for building and installing the | package, of course! If the INSTALL file contains both building and installation instructions, and how to set up the package, what is then the correct way to handle that? Cut and paste the relevant portions into README.Debian or something? -- Tollef Fog Heen Axiom #1: You Can't Win
Re: Native packages
* peter karlsson | Colin Watson: | | If you can't build the Debian package as part of the process of | generating the tarball from CVS, I suppose you could use -b and hack the | .changes by hand to include the source, although that's rather ugly. | | I tried hacking the changes file by hand, but my upload got rejected three | times so I gave up... :-/ dinstall -n will go through the installation process without actually installing anything in the archive (and is runnable by normal users). That might help. :) -- Tollef Fog Heen You Can't Win
Re: Adoption of xcopilot: Who wants to be my sponsor?
* Ludovic Drolez | Also, why Pose is in contrib ? It needs the ROMs from the Palm, afaik. Which aren't free themselves. -- Tollef Fog Heen You Can't Win -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Adoption of xcopilot: Who wants to be my sponsor?
* Ludovic Drolez | Also, why Pose is in contrib ? It needs the ROMs from the Palm, afaik. Which aren't free themselves. -- Tollef Fog Heen You Can't Win
Re: Lintian overrides
* Richard A Nelson (Please don't cc me. It says so in the headers) | On 24 Aug 2001, Tollef Fog Heen wrote: | | * Richard A Nelson | | | * sendmail source: dh_testversion-is-deprecated | | Just | | sendmail: dh_testversion-is-deprecated | | should work. | | Thats what I thought ! | $grep 'dh_t' lintian-overrides | sendmail: dh_testversion-is-deprecated Where do you place the lintian-overrides? They have to be installed into the package in /usr/share/lintian/overrides with the name of the package. -- Tollef Fog Heen You Can't Win -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian overrides
* Richard A Nelson (Please don't cc me. It says so in the headers) | On 24 Aug 2001, Tollef Fog Heen wrote: | | * Richard A Nelson | | | * sendmail source: dh_testversion-is-deprecated | | Just | | sendmail: dh_testversion-is-deprecated | | should work. | | Thats what I thought ! | $grep 'dh_t' lintian-overrides | sendmail: dh_testversion-is-deprecated Where do you place the lintian-overrides? They have to be installed into the package in /usr/share/lintian/overrides with the name of the package. -- Tollef Fog Heen You Can't Win
Re: Lintian overrides
* Richard A Nelson | * sendmail source: dh_testversion-is-deprecated Just sendmail: dh_testversion-is-deprecated should work. -- Tollef Fog Heen You Can't Win -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lintian overrides
* Richard A Nelson | * sendmail source: dh_testversion-is-deprecated Just sendmail: dh_testversion-is-deprecated should work. -- Tollef Fog Heen You Can't Win
Re: Sponsors?
* Martin Sj|gren | I just entered an application for a sponsor on | http://www.internatif.org/bortzmeyer/debian/sponsor/ | | Is there anything else I should do? Ask here, if there is somebody who are interested in the packages you have packaged, you might get a sponsor quicker. -- Tollef Fog Heen You Can't Win -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsors?
* Martin Sj|gren | On Wed, Aug 01, 2001 at 09:21:52PM +0200, Tollef Fog Heen wrote: | | Ask here, if there is somebody who are interested in the packages you | have packaged, you might get a sponsor quicker. | | Why that's a terrific idea =) :) | So, there you have it. The reason I picked this package is that I think | it's an extremely cool program, and I'm a math nerd, my minor is in maths, | focusing in algebra, so... Is it available via apt somewhere? (I might be interested in sponsoring you.) -- Tollef Fog Heen You Can't Win -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packaging HTML, CGIs, etc.
* Jimmy Kaplowitz | On Mon, Jul 16, 2001 at 12:47:39PM +0200, Tollef Fog Heen wrote: | * Britton | | (don't cc me on lists.) | | Why don't you set Mail-Followup-To: accordingly? Because, in Gnus it's a lot easier to set 'Mail-Copies-To: never' globally than a per-group mail-followup-to. And Debian policy says that you shouldn't Cc unless explicitly stated. | I know the default mutt setup respects that when I invoke the 'reply | all' feature (i.e., it won't reply to you if you have that set | right), whereas it ignores Mail-Copies-To: never. In mutt, it's a | simple matter of adding 'subscribe debian-' to your ~/.muttrc - this | takes care of adding the header for all mails sent to Debian mailing | lists. As you would have seen, if you had read my headers, is that I use gnus. And have no intention of switching. About 1.5GB/173K mails would be a small obstacle if I wanted to switch. -- Tollef Fog Heen You Can't Win
Re: packaging HTML, CGIs, etc.
* Michael Wiedmann | - make the package dependend on httpd reasonable | - install the files into /var/www/openwebschool reasonable | - should I install the CGI-scripts to /usr/lib/cgi-bin or somewhere in | a separate directory (how do I tell in this case the user to edit | /etc/apache/srm.conf or is there a generic way to edit the apache | conf files?) I'd install them into /usr/lib/cgi-bin/openwebschool, if there are many of them. Don't edit apache's config files yourself - leave that to the admin. -- Tollef Fog Heen You Can't Win
Re: packaging HTML, CGIs, etc.
* Britton (don't cc me on lists.) | | - install the files into /var/www/openwebschool | | reasonable | | What is our policy regarding /var/www? I sort of thought this was a place | where local sys admins could install their sites without worrying about | bumping into packages. from Debian Policy, 12.5. Web servers and applications 3. Web Document Root Web Applications should try to avoid storing files in the Web Document Root. Instead they should use the /usr/share/doc/package directory for documents and register the Web Application via the menu package. If access to the web document root is unavoidable then use /var/www as the Document Root. This might be just a symbolic link to the location where the system administrator has put the real document root. -- Tollef Fog Heen You Can't Win
Re: Fwd: ITP: glib2, gtk2, inti
* Christian Marillat | MAS Indeed, but for package naming purpose I guess calling | MAS them libglib2 and libgtk2 would work. | | I disagree. The API may change between 1.3.5 and 2.0 GTK has a very, very broken versioning. There is no connection between the soname of a library and the version of it. Take a library like slang. The package name is slang1, which means that the soname has a major version number which is 1. The version number of the package is 1.4.4-1 (in testing). This is the right way to do it - if you make backwards-incompatible changes, bump the soname's version number. Else, don't. Take another package - xlibs6g. It conforms to version 6 of the Xlib specification, while the package's version number is 4.0.3-3. Please LART upstream heavily and give the packages a proper name. That tradition has done it wrong is no reason to continue doing it the wrong way. *sigh* /rant-of-the-week -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: porting problem and how to request help
* Stefano Zacchiroli | How can I solve the problem? May I ask for help on debian-devel or on | debian-m68k ML? That is one of the ways of doing it, yes. m68k would probably be best. | Cause the problem is related to another package, may I close the bug on | ocaml-xstr and fill a new one against ocaml-findlib? No, you'd have to reassign it, not close and open a new one. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: question on a licence
* Noel Koethe | $ less COPYRIGHT | /* | * Copyright University of Manitoba 1998. | * Written by J. Gary mills | * | * Permission is granted to anyone to use this software for any purpose on | * any computer system, and to alter it and redistribute it freely, | subject | * to the following restrictions: | * | * 1. The author and the University of Manitoba are not responsible | *for the consequences of use of this software, no matter how awful, | *even if they arise from flaws in it. | * | * 2. The origin of this software must not be misrepresented, either by | *explicit claim or by omission. Since few users ever read sources, | *credits must appear in the documentation. | * | * 3. Altered versions must be plainly marked as such, and must not be | *misrepresented as being the original software. Since few users | *ever read sources, credits must appear in the documentation. | * | * 4. This notice may not be removed or altered. | */ I don't see any problems with this license, it says that you have to say that if you modify the sources, you have to say where you got the sources from - similar to the BSD license. Also, they have a no-warranty section, which is just fine. So, I don't see what you might think that would be a problem with the license. | Sorry, if this is the wrong list. Please tell me the right one. debian-legal, but -mentors isn't too bad either. :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question on a licence
* Noel Koethe | $ less COPYRIGHT | /* | * Copyright University of Manitoba 1998. | * Written by J. Gary mills | * | * Permission is granted to anyone to use this software for any purpose on | * any computer system, and to alter it and redistribute it freely, | subject | * to the following restrictions: | * | * 1. The author and the University of Manitoba are not responsible | *for the consequences of use of this software, no matter how awful, | *even if they arise from flaws in it. | * | * 2. The origin of this software must not be misrepresented, either by | *explicit claim or by omission. Since few users ever read sources, | *credits must appear in the documentation. | * | * 3. Altered versions must be plainly marked as such, and must not be | *misrepresented as being the original software. Since few users | *ever read sources, credits must appear in the documentation. | * | * 4. This notice may not be removed or altered. | */ I don't see any problems with this license, it says that you have to say that if you modify the sources, you have to say where you got the sources from - similar to the BSD license. Also, they have a no-warranty section, which is just fine. So, I don't see what you might think that would be a problem with the license. | Sorry, if this is the wrong list. Please tell me the right one. debian-legal, but -mentors isn't too bad either. :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: web app packaging question
* David LaBissoniere | I am packaging the freeside isp billing and account management program. | This package consists largely of many (44) cgi scripts (which reference | each other often) spread into several subdirectories. Some of the | scripts have the same name (for example, view/cust_bill.cgi and | search/cust_bill.cgi). Debian policy states that cgi scripts should be | placed in /usr/lib/cgi. I am guessing that I am not allowed to create | subdirectories in here as apache would no longer view the scripts as | executable? Well, a subdirectory works for mailman, so it should work for you as well. And it is the right way when using many CGIs, imho. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: web app packaging question
* David LaBissoniere | I am packaging the freeside isp billing and account management program. | This package consists largely of many (44) cgi scripts (which reference | each other often) spread into several subdirectories. Some of the | scripts have the same name (for example, view/cust_bill.cgi and | search/cust_bill.cgi). Debian policy states that cgi scripts should be | placed in /usr/lib/cgi. I am guessing that I am not allowed to create | subdirectories in here as apache would no longer view the scripts as | executable? Well, a subdirectory works for mailman, so it should work for you as well. And it is the right way when using many CGIs, imho. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: My First Package. Wheee.
* Warren Anthony Stramiello
| a) inclusion in the testing distribution, if still possible
Is handled automagically, if you haven't screwed up anything ;) (that
is, it goes into testing after 10 days of testing in unstable, unless
it has RC bugs, that is). Read more at http://ftp-master.debian.org/testing/
| b) inclusion in the unstable distribution, if still possible
That's were we all upload to.
| c) uploading using dupload and scp
Add something like
package config;
$cfg{'ftp-master'} = {
fqdn = ftp-master.debian.org,
login = getlogin() || $ENV{USER} || $ENV{LOGNAME},
incoming = /org/ftp.debian.org/incoming/,
mailto = [EMAIL PROTECTED], # stable
mailtx = [EMAIL PROTECTED], # unstable, exper.
visibleuser = getlogin() || $ENV{USER} || $ENV{LOGNAME},
visiblename = ,
fullname = ,
# The dinstall on master now sends announcement itself. May 1999.
dinstall_runs = 1,
method = scpb
};
$default_host = ftp-master;
1;
to ~/.dupload.conf
and run
dupload xdrawchem_0.85-1_i386.changes
The changelog decides whether it goes into stable or unstable. Unless
you have _very_ good reasons for it going into stable, it should go
into unstable. Very good reasons include security holes and that the
package as it is in stable is totally unuseable.
Be sure to run lintian on your package before uploading it, though. :)
--
Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.
Re: gpg keyrings.
* Britton | On 30 Apr 2001, James Troup wrote: | | Julian Gilbey [EMAIL PROTECTED] writes: | | (1) It could be documented on http://keyring.debian.org/ | | I'm sure it could...[0] | | Is the procedure for useing anon-rsync documented somewhere else? rsync keyring.debian.org::keyrings/keyrings/debian-keyring.gpg ~/.gnupg/ and add keyring debian-keyring.gpg to ~/.gnupg/options -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gpg keyrings.
* Britton | On 30 Apr 2001, James Troup wrote: | | Julian Gilbey [EMAIL PROTECTED] writes: | | (1) It could be documented on http://keyring.debian.org/ | | I'm sure it could...[0] | | Is the procedure for useing anon-rsync documented somewhere else? rsync keyring.debian.org::keyrings/keyrings/debian-keyring.gpg ~/.gnupg/ and add keyring debian-keyring.gpg to ~/.gnupg/options -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: lintian -i file.changes error
* Sean 'Shaleh' Perry | However, as I stated in my reply when this came up on lintian -- | hard links are BAD. Symlinks were invented for a reason. I believe you mean something like 'multiple hard links to the same file are bad'. A single hard link is _very_ useful, imho. ;-) And multiple ones for directories. /nitpick -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: directory in .deb
* M G Berberich | I'm not sure if I'm welcome her, because I'm not maintaining a | official debian-package but trying to make .deb's out of my tools. No problem. We are including here. :) | I have a tool that needs a directory /var/log/ppplog. It is contained | in data.tar.gz, but tar does not set the required right on the | directory (right?). So I set the right in the postinst script. It's usually better to set it in the package building script. Less messy, IMHO. | The package also puts a executable in /etc/ppp/ip-down.d. Building the | binary leads to a complain about an executable in unusual place (or | so). Can I prevent this? Are there naming-conventions for script in | /etc/ppp/ip-down.d? I don't know. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Undocumented binary
* Sven LUTHER | Maybe all manpage needing binaries could be listed somewhere, and we could | have a manpage writing task ? http://qa.debian.org/man-pages.html :) -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: ldd, dpkg-shlibdeps and libsocks.so
* Ben Collins | It is a bug in libsocks4, which should compile the library with -soname | libsocks.so.4. I'm willing to bet that libsocks.so is created by | ldconfig when libsocks4 is installed, else it wouldn't even work without | the -dev package installed. So reassigning the bug against libsocks-dev is the right thing to do? Thanks! -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ldd, dpkg-shlibdeps and libsocks.so
* Ben Collins | It is a bug in libsocks4, which should compile the library with -soname | libsocks.so.4. I'm willing to bet that libsocks.so is created by | ldconfig when libsocks4 is installed, else it wouldn't even work without | the -dev package installed. So reassigning the bug against libsocks-dev is the right thing to do? Thanks! -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
ldd, dpkg-shlibdeps and libsocks.so
I am the maintainer of suck, which links against libsocks. However, it seems like there is something strange going on when it comes to linking: $ldd `which suck` libsocks.so = /usr/lib/libsocks.so (0x4001f000) libnsl.so.1 = /lib/libnsl.so.1 (0x4002d000) libc.so.6 = /lib/libc.so.6 (0x40043000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) $ Here, suck is linked against libsocks.so, without a version number. This makes dpkg-shlibdeps complain about 'format of libsocks.so not recognized'. (Which really is 'format of file name libsocks.so not recognized'). Why does this happen, and is this a bug in suck, dpkg-shlibdeps or libsocks4? -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: Binary-only upload
* peter karlsson | Tollef Fog Heen: | | Increase the version number by 0.01, recompile and upload. See the | developers reference 8.2, third paragraph. | | So, how do I change the version number without touching the changelog? You touch the changelog, but you don't include that changelog entry in the next 'normal' upload. IIRC, that is what the consensus on -mentors was last time it was discussed. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Binary-only upload
* peter karlsson | Tollef Fog Heen: | | Increase the version number by 0.01, recompile and upload. See the | developers reference 8.2, third paragraph. | | So, how do I change the version number without touching the changelog? You touch the changelog, but you don't include that changelog entry in the next 'normal' upload. IIRC, that is what the consensus on -mentors was last time it was discussed. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
Re: e-mail address changed
* Stefano Zacchiroli | I've changed my e-mail address, so my last upload of a package seems to | be a NMU, how I fix the problem ? Change the email address in the control file as well. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: e-mail address changed
* Stefano Zacchiroli | I've changed my e-mail address, so my last upload of a package seems to | be a NMU, how I fix the problem ? Change the email address in the control file as well. -- Tollef Fog Heen Unix _IS_ user friendly... It's just selective about who its friends are.
