Re: Plea for mentor help
On Wed, Dec 10, 2003 at 12:38:23PM -0700, Jamin W. Collins wrote: > What do you mean by "autoconfiscate"? Presumably to make it compile and build with autoconf/automake. For that the "GNU Autoconf, Automake and Libtool" book is very useful. It's available online and in print: http://sources.redhat.com/autobook/ Steve --
Location of/methods of handling themes.
I am trying to package the bootsplash userland utilites. Boot splash stores themes in /etc/bootsplash/themes/$THEME/ Should I make a link (/etc/bootsplash/themes/current/) to the theme to use, then make an entry in /etc/alternatives to that link, or should I make a variable in an /etc/default/bootsplash file? -- Matthew A. Nicholson Matt-Land.com
Sponsor for Scorched3D (game) wanted
Hello - I'm looking for a sponsor for the game Scorched 3D which I am currently packaging. I have the support of the original author and the packaging process is almost finished (must only correct a few paths and rebuild). Original website: http://www.scorched3d.co.uk/ The game is GPL. -- PGP/GPG key: http://web.lemuria.org/pubkey.html pub 1024D/2D7A04F5 2002-05-16 Tom Vogt <[EMAIL PROTECTED]> Key fingerprint = C731 64D1 4BCF 4C20 48A4 29B2 BF01 9FA1 2D7A 04F5
Packaging a perl-script
Hello, I'd like to see http://www.jetmore.org/john/code/swaks (Swiss Army Knife SMTP) in Debian. As the name suggests this is a wonderful tool to test SMTP servers (including starttls and lots of SMTP auth), for all of us who are tired of "telnet foo 25". ;-) However this is only 40KB (with pod) and I think it might be rejected by ftp-master. - Are there any better possibilities? This is not very urgent, I have to clear up a copyright issue (it is GPL and uses libnet-ssleay-perl) anyway. 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: Plea for mentor help
Sorry, yes, I mean automake/autoconf. I do already have that book and followed it to get what I have now working. I only have a small problem in that in that some scripts are not being marked as executable. The main problem is trying to get the deb correctly generated by fixing the lintian errors. Rather than hassling this list with this, I was hoping somone would step forward and help me out. I've alrady got one package correctly done (sux) so I do have some idea already of what is needed, but this package is more complex. Thanks, Millis On Thu, 2003-12-11 at 07:47, Steve Kemp wrote: > On Wed, Dec 10, 2003 at 12:38:23PM -0700, Jamin W. Collins wrote: > > > What do you mean by "autoconfiscate"? > > Presumably to make it compile and build with autoconf/automake. > > For that the "GNU Autoconf, Automake and Libtool" book is very useful. > It's available online and in print: > > http://sources.redhat.com/autobook/ > > Steve > -- > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > signature.asc Description: This is a digitally signed message part
Re: Sponsor for Scorched3D (game) wanted
On Thu, Dec 11, 2003 at 10:19:23AM +0100, Tom wrote: > Hello - > > I'm looking for a sponsor for the game Scorched 3D which I am currently > packaging. I have the support of the original author and the packaging > process is almost finished (must only correct a few paths and rebuild). > > Original website: http://www.scorched3d.co.uk/ Cool graphics. > > The game is GPL. Fine. > > But where is the work that your wannabee sponsor should look at? Geert Stappers P.S. Matt, people.d.o. is still download, would you please post the mentor FAQ here?
Re: Packaging a perl-script
Andreas Metzler <[EMAIL PROTECTED]> writes: > However this is only 40KB (with pod) and I think it might be rejected > by ftp-master. - Are there any better possibilities? Why should they reject it? "Only 40kb" is not a reason. (If its split out from another source into too small packages, then yes, a reject maybe ok. But not if the whole tool is 40kb). -- bye Joerg Linus: "Wenn Darl McBride die Macht hätte, würde er wahrscheinlich die Ehe als Verletzung der Verfassung auslegen, weil sie ganz klar die kommerzielle Natur der menschlichen Interaktion entwertet und damit ein großes Hindernis für die kommerzielle Entwicklung der Prostitution darstellt."
Re: Packaging a perl-script
On Thu, Dec 11, 2003 at 01:46:58PM +0100, Joerg Jaspert wrote: > Andreas Metzler <[EMAIL PROTECTED]> writes: > > However this is only 40KB (with pod) and I think it might be rejected > > by ftp-master. - Are there any better possibilities? > Why should they reject it? "Only 40kb" is not a reason. > (If its split out from another source into too small packages, then > yes, a reject maybe ok. But not if the whole tool is 40kb). I see. Thanks. cu andreas
Re: How to package a database (not program)?
On Tue, Dec 09, 2003 at 11:06:51PM -0800, David Braun wrote: > The data comes from the USDA as a file designed to be imported into a > relational database (such as MySQL). It's really not very useful > otherwise. My question is how do I package this correctly? I want my > package to import it into a database, but I don't want to dictate to the > user which database program to use. Something appropriate might be for > the configure script to ask the user for the name of a SQL server, along > with a user name and a password. I'm not sure this would be sufficient, > though, because as a new student of SQL I'm learning there's no standard > way of creating a database (horror!). So maybe this would mean the > package would have to look for local client drivers of MySQL, > PostgreSQL, etc. Not only that, the data types often vary for different databases, though hopefully your data is simple enough that this isn't a problem. I would simply include the SQL dump under /usr/share and leave it to the user where to import it. It's possible that they will want to create a new database, or import it into an existing one (perhaps even with different table names), or transform it from SQL into something else. -- - mdz
Standards-Version
Hi folks! I am planing to adopt my first package (emelfm, orphaned). So I checked what needs to be done to equip myself for this task. There seems to be one current problems with that package: The ToDo says the Standards-Version is too old 3.5.2. Should be 3.6.1. So I wonder how I can do that? Is there some ChangeLog for the Debian Policy? Does somebody know where I can find the right docs? Or better: Does somebody perhaps know what needs to be done for a simple gtk-program to be moved from 3.5.2 to 3.6.1? Thanks for any help, flo
Re: Standards-Version
On Thu, Dec 11, 2003 at 05:31:51PM -0500, Matt Zimmerman wrote: > On Thu, Dec 11, 2003 at 11:00:45PM +0100, Florian Zaehringer wrote: > > > I am planing to adopt my first package (emelfm, orphaned). So I checked > > what needs to be done to equip myself for this task. > > > > There seems to be one current problems with that package: ToDo says the > > TheStandards-Version is too old 3.5.2. Should be 3.6.1. > > > > So I wonder how I can do that? Is there some ChangeLog for the Debian > > Policy? Does somebody know where I can find the right docs? Or > > better: Does somebody perhaps know what needs to be done for a simple > > gtk-program to be moved from 3.5.2 to 3.6.1? > > /usr/share/doc/debian-policy/upgrading-checklist.txt.gz Which can be found in the debian-policy package. Which can safely be installed from unstable, even on non-unstable systems (as far as I can tell; I keep that one package manually up to date, since I develop on a woody system and use pbuilder to run my builds/lintian/linda checks). Have I mentioned lately how much I love pbuilder hooks? :) Now, to get the NetBSD port up to the point that I can make pbuilder-bind (bind-mounts /var/cache/pbuilder/build/ on top of a single unpacked copy of base.tgz, rather than unpacking the tarball every time - saves an unbelieveable amount of time on systems with only moderately fast disks). -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpIYYBK1ttk4.pgp Description: PGP signature
Re: Standards-Version
On Thu, Dec 11, 2003 at 11:00:45PM +0100, Florian Zaehringer wrote: > I am planing to adopt my first package (emelfm, orphaned). So I checked what > needs to be done to equip myself for this task. > > There seems to be one current problems with that package: > The ToDo says the Standards-Version is too old 3.5.2. Should be 3.6.1. > > So I wonder how I can do that? Is there some ChangeLog for the Debian Policy? > Does somebody know where I can find the right docs? Or better: Does somebody > perhaps know what needs to be done for a simple gtk-program to be moved from > 3.5.2 to 3.6.1? /usr/share/doc/debian-policy/upgrading-checklist.txt.gz -- - mdz
Re: Standards-Version
On Qui, 2003-12-11 at 20:00, Florian Zaehringer wrote: > Hi folks! Hi > So I wonder how I can do that? Is there some ChangeLog for the Debian Policy? > Does somebody know where I can find the right docs? Or better: Does somebody > perhaps know what needs to be done for a simple gtk-program to be moved from > 3.5.2 to 3.6.1? Read: /usr/share/doc/debian-policy/upgrading-checklist.txt.gz (package debian-policy) There souldn't be much that needs to be done to keep your package up to date policy-wise. Using lintian and linda should catch most mistakes before you upload anything. Good luck Cheers -- Leo Costela <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> "you must cut down the mightiest tree in the forest... with... a herring!" signature.asc Description: This is a digitally signed message part
debconf db_input in postinst / horde2
Hi! I am trying to put the finishing touches on a package of Diogenes, a web content management system. The package relies on a MySQL database, and this database is created based on some information provided by the user through debconf. I am down to one lintian warning : W: diogenes: postinst-uses-db-input N: It is generally not a good idea for postinst scripts to use debconf N: commands like db_input. Typically, they should restrict themselves to N: db_get to request previously acquired information, and have the config N: script do the actual prompting. My debian/postinst and debian/config are heavily based on those of the horde2 package so I checked, and sure enough the "db_input" in postinst which is causing the warning came from horde2. It concerns the MySQL admin user and password, which is in fact already asked for in the debian/config file. I can see how it is a Bad Thing to prompt the user for input both in postinst and in config, but the fact still stands that it's the way it's done in horde2, and I'm sure there must be a good reason for it! Any ideas here? Is there any scenario (recovering from a failed install..) which would involve running the postinst without the config, and hence justify the prompt for the admin user/password? In a similar line of thought, the admin password is stored in the debconf database in config and reset in postinst, so I suppose that means that if for some reason the installation fails, we still have the password stored in database. Any pointers to policy reference on dealing with this? Thanks for your time and have a pleasant day! Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/: MPman MP-F70 support for Linux
Re: Standards-Version
On Thu, Dec 11, 2003 at 11:00:45PM +0100, Florian Zaehringer wrote: > So I wonder how I can do that? Is there some ChangeLog for the Debian Policy? > Does somebody know where I can find the right docs? Or better: Does somebody > perhaps know what needs to be done for a simple gtk-program to be moved from > 3.5.2 to 3.6.1? > install the debian-policy package (from unstable of course) and read /usr/share/doc/debian-policy/upgrading-checklist.txt.gz Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/
Re: debconf db_input in postinst / horde2
On Thu, Dec 11, 2003 at 11:51:01PM +0100, Jeremy Lain? wrote: > > I can see how it is a Bad Thing to prompt the user for input both in > postinst and in config, but the fact still stands that it's the way > it's done in horde2, and I'm sure there must be a good reason for it! > Any ideas here? Ask it during config, store it in debconf until your through using it in postinst and then clear it from debconf. It's how I do it in mediamate. > Is there any scenario (recovering from a failed install..) which would > involve running the postinst without the config, and hence justify the > prompt for the admin user/password? Honestly don't know. -- Jamin W. Collins Remember, root always has a loaded gun. Don't run around with it unless you absolutely need it. -- Vineet Kumar
Re: Standards-Version
On 2003-12-11 22:00:45 + Florian Zaehringer <[EMAIL PROTECTED]> wrote: I am planing to adopt my first package (emelfm, orphaned). So I checked what needs to be done to equip myself for this task. Hasn't upstream gone away? Are you taking that over too? You probably should retitle bug 158150 and note your intentions. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ [EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/
Re: Plea for mentor help
On Dec 11, Steve Kemp ([EMAIL PROTECTED]) wrote: > On Wed, Dec 10, 2003 at 12:38:23PM -0700, Jamin W. Collins wrote: > > > What do you mean by "autoconfiscate"? > > Presumably to make it compile and build with autoconf/automake. > > For that the "GNU Autoconf, Automake and Libtool" book is very useful. > It's available online and in print: > > http://sources.redhat.com/autobook/ > > Steve apt-get install autobook :-) -- Neil Roeth
Re: Plea for mentor help
On Wed, 10 Dec 2003, Millis Miller wrote: > my curent mentor > seems to be a bit busy and hasn't replied to my emails for a good few > weeks. > That's because your current mentor has a memory like a sieve. :-) I took a look at the package. First problem is you need a build dependency on libpcap-dev and rrdtool Second, the scripts do get made executable by your auto* stuff so that's working ok. It's dh_fixperms which is unsetting them again. After the call to dh_fixperms, add something like the following code ($ signs have to be doubled because debian/rules is a Makefile.) : for i in $(CURDIR)/debian/iptotal/var/www/iptotal/*.cgi; do chmod +x $$i; done which brings me to the third problem. Your scripts are actually getting installed into /var/www/iptotal/iptotal/www. iptotal.cfg is getting installed into /. I'm guessing that's not actually what you want. To get the proper behavior you're going to have to restructure your Makefile.am The top level Makefile.am will look like this: [EMAIL PROTECTED]@ sbin_PROGRAMS = iptotal sbin_SCRIPTS = src/iptotald src/makegraph iptotal_SOURCES = iptotal.c iptotal_LDADD = -lpcap EXTRA_DIST = src/iptotald.in src/makegraph.in www/*.in www/images/* \ www/archive/* iptotal.1 iptotald.8 iptotal_config.5 \ etc/iptotal.cfg etc/iptotal.cfg.in SUBDIRS = etc www Note the SUBDIRS statement. This says to call 2nd level Makefile.am's in etc like this: sysconf_DATA = iptotal.cfg and in www like this: nobase_pkgdata_DATA = archive.cgi iptotal.cgi iptotal_w.cgi iptotal_m.cgi \ iptotal_y.cgi images/* archive/* Don't forget to run automake, aclocal, and autoconf afterwards. Then in the call to configure in debian/rules, change --datadir to /var/www and --sysconfdir to /etc This together with the permissions fix should get rid of most of the issues. Lintian complains about a few minor things though. * makegraph needs a manpage * there are typos in the path to the GPL in debian/copyright * the short description ends with a . It should be a phrase not a sentence. You can ask for advice on the debian-i10n-en mailing list. The other warnings can be ignored or overriden. -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/
Re: Plea for mentor help
On Wed, Dec 10, 2003 at 12:38:23PM -0700, Jamin W. Collins wrote: > What do you mean by "autoconfiscate"? Presumably to make it compile and build with autoconf/automake. For that the "GNU Autoconf, Automake and Libtool" book is very useful. It's available online and in print: http://sources.redhat.com/autobook/ Steve -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sponsor for Scorched3D (game) wanted
Hello - I'm looking for a sponsor for the game Scorched 3D which I am currently packaging. I have the support of the original author and the packaging process is almost finished (must only correct a few paths and rebuild). Original website: http://www.scorched3d.co.uk/ The game is GPL. -- PGP/GPG key: http://web.lemuria.org/pubkey.html pub 1024D/2D7A04F5 2002-05-16 Tom Vogt <[EMAIL PROTECTED]> Key fingerprint = C731 64D1 4BCF 4C20 48A4 29B2 BF01 9FA1 2D7A 04F5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packaging a perl-script
Hello, I'd like to see http://www.jetmore.org/john/code/swaks (Swiss Army Knife SMTP) in Debian. As the name suggests this is a wonderful tool to test SMTP servers (including starttls and lots of SMTP auth), for all of us who are tired of "telnet foo 25". ;-) However this is only 40KB (with pod) and I think it might be rejected by ftp-master. - Are there any better possibilities? This is not very urgent, I have to clear up a copyright issue (it is GPL and uses libnet-ssleay-perl) anyway. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Plea for mentor help
Sorry, yes, I mean automake/autoconf. I do already have that book and followed it to get what I have now working. I only have a small problem in that in that some scripts are not being marked as executable. The main problem is trying to get the deb correctly generated by fixing the lintian errors. Rather than hassling this list with this, I was hoping somone would step forward and help me out. I've alrady got one package correctly done (sux) so I do have some idea already of what is needed, but this package is more complex. Thanks, Millis On Thu, 2003-12-11 at 07:47, Steve Kemp wrote: > On Wed, Dec 10, 2003 at 12:38:23PM -0700, Jamin W. Collins wrote: > > > What do you mean by "autoconfiscate"? > > Presumably to make it compile and build with autoconf/automake. > > For that the "GNU Autoconf, Automake and Libtool" book is very useful. > It's available online and in print: > > http://sources.redhat.com/autobook/ > > Steve > -- > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > signature.asc Description: This is a digitally signed message part
Re: Sponsor for Scorched3D (game) wanted
On Thu, Dec 11, 2003 at 10:19:23AM +0100, Tom wrote: > Hello - > > I'm looking for a sponsor for the game Scorched 3D which I am currently > packaging. I have the support of the original author and the packaging > process is almost finished (must only correct a few paths and rebuild). > > Original website: http://www.scorched3d.co.uk/ Cool graphics. > > The game is GPL. Fine. > > But where is the work that your wannabee sponsor should look at? Geert Stappers P.S. Matt, people.d.o. is still download, would you please post the mentor FAQ here? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a perl-script
Andreas Metzler <[EMAIL PROTECTED]> writes: > However this is only 40KB (with pod) and I think it might be rejected > by ftp-master. - Are there any better possibilities? Why should they reject it? "Only 40kb" is not a reason. (If its split out from another source into too small packages, then yes, a reject maybe ok. But not if the whole tool is 40kb). -- bye Joerg Linus: "Wenn Darl McBride die Macht hätte, würde er wahrscheinlich die Ehe als Verletzung der Verfassung auslegen, weil sie ganz klar die kommerzielle Natur der menschlichen Interaktion entwertet und damit ein großes Hindernis für die kommerzielle Entwicklung der Prostitution darstellt." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a perl-script
On Thu, Dec 11, 2003 at 01:46:58PM +0100, Joerg Jaspert wrote: > Andreas Metzler <[EMAIL PROTECTED]> writes: > > However this is only 40KB (with pod) and I think it might be rejected > > by ftp-master. - Are there any better possibilities? > Why should they reject it? "Only 40kb" is not a reason. > (If its split out from another source into too small packages, then > yes, a reject maybe ok. But not if the whole tool is 40kb). I see. Thanks. cu andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to package a database (not program)?
On Tue, Dec 09, 2003 at 11:06:51PM -0800, David Braun wrote: > The data comes from the USDA as a file designed to be imported into a > relational database (such as MySQL). It's really not very useful > otherwise. My question is how do I package this correctly? I want my > package to import it into a database, but I don't want to dictate to the > user which database program to use. Something appropriate might be for > the configure script to ask the user for the name of a SQL server, along > with a user name and a password. I'm not sure this would be sufficient, > though, because as a new student of SQL I'm learning there's no standard > way of creating a database (horror!). So maybe this would mean the > package would have to look for local client drivers of MySQL, > PostgreSQL, etc. Not only that, the data types often vary for different databases, though hopefully your data is simple enough that this isn't a problem. I would simply include the SQL dump under /usr/share and leave it to the user where to import it. It's possible that they will want to create a new database, or import it into an existing one (perhaps even with different table names), or transform it from SQL into something else. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Standards-Version
Hi folks! I am planing to adopt my first package (emelfm, orphaned). So I checked what needs to be done to equip myself for this task. There seems to be one current problems with that package: The ToDo says the Standards-Version is too old 3.5.2. Should be 3.6.1. So I wonder how I can do that? Is there some ChangeLog for the Debian Policy? Does somebody know where I can find the right docs? Or better: Does somebody perhaps know what needs to be done for a simple gtk-program to be moved from 3.5.2 to 3.6.1? Thanks for any help, flo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Standards-Version
On Thu, Dec 11, 2003 at 11:00:45PM +0100, Florian Zaehringer wrote: > I am planing to adopt my first package (emelfm, orphaned). So I checked what needs > to be done to equip myself for this task. > > There seems to be one current problems with that package: > The ToDo says the Standards-Version is too old 3.5.2. Should be 3.6.1. > > So I wonder how I can do that? Is there some ChangeLog for the Debian Policy? > Does somebody know where I can find the right docs? Or better: Does somebody perhaps > know what needs to be done for a simple gtk-program to be moved from 3.5.2 to 3.6.1? /usr/share/doc/debian-policy/upgrading-checklist.txt.gz -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Standards-Version
On Thu, Dec 11, 2003 at 11:00:45PM +0100, Florian Zaehringer wrote: > So I wonder how I can do that? Is there some ChangeLog for the Debian Policy? > Does somebody know where I can find the right docs? Or better: Does somebody perhaps > know what needs to be done for a simple gtk-program to be moved from 3.5.2 to 3.6.1? > install the debian-policy package (from unstable of course) and read /usr/share/doc/debian-policy/upgrading-checklist.txt.gz Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Standards-Version
On Thu, Dec 11, 2003 at 05:31:51PM -0500, Matt Zimmerman wrote: > On Thu, Dec 11, 2003 at 11:00:45PM +0100, Florian Zaehringer wrote: > > > I am planing to adopt my first package (emelfm, orphaned). So I checked > > what needs to be done to equip myself for this task. > > > > There seems to be one current problems with that package: ToDo says the > > TheStandards-Version is too old 3.5.2. Should be 3.6.1. > > > > So I wonder how I can do that? Is there some ChangeLog for the Debian > > Policy? Does somebody know where I can find the right docs? Or > > better: Does somebody perhaps know what needs to be done for a simple > > gtk-program to be moved from 3.5.2 to 3.6.1? > > /usr/share/doc/debian-policy/upgrading-checklist.txt.gz Which can be found in the debian-policy package. Which can safely be installed from unstable, even on non-unstable systems (as far as I can tell; I keep that one package manually up to date, since I develop on a woody system and use pbuilder to run my builds/lintian/linda checks). Have I mentioned lately how much I love pbuilder hooks? :) Now, to get the NetBSD port up to the point that I can make pbuilder-bind (bind-mounts /var/cache/pbuilder/build/ on top of a single unpacked copy of base.tgz, rather than unpacking the tarball every time - saves an unbelieveable amount of time on systems with only moderately fast disks). -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgp0.pgp Description: PGP signature
Re: Standards-Version
On Qui, 2003-12-11 at 20:00, Florian Zaehringer wrote: > Hi folks! Hi > So I wonder how I can do that? Is there some ChangeLog for the Debian Policy? > Does somebody know where I can find the right docs? Or better: Does somebody perhaps > know what needs to be done for a simple gtk-program to be moved from 3.5.2 to 3.6.1? Read: /usr/share/doc/debian-policy/upgrading-checklist.txt.gz (package debian-policy) There souldn't be much that needs to be done to keep your package up to date policy-wise. Using lintian and linda should catch most mistakes before you upload anything. Good luck Cheers -- Leo Costela <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> "you must cut down the mightiest tree in the forest... with... a herring!" signature.asc Description: This is a digitally signed message part
debconf db_input in postinst / horde2
Hi! I am trying to put the finishing touches on a package of Diogenes, a web content management system. The package relies on a MySQL database, and this database is created based on some information provided by the user through debconf. I am down to one lintian warning : W: diogenes: postinst-uses-db-input N: It is generally not a good idea for postinst scripts to use debconf N: commands like db_input. Typically, they should restrict themselves to N: db_get to request previously acquired information, and have the config N: script do the actual prompting. My debian/postinst and debian/config are heavily based on those of the horde2 package so I checked, and sure enough the "db_input" in postinst which is causing the warning came from horde2. It concerns the MySQL admin user and password, which is in fact already asked for in the debian/config file. I can see how it is a Bad Thing to prompt the user for input both in postinst and in config, but the fact still stands that it's the way it's done in horde2, and I'm sure there must be a good reason for it! Any ideas here? Is there any scenario (recovering from a failed install..) which would involve running the postinst without the config, and hence justify the prompt for the admin user/password? In a similar line of thought, the admin password is stored in the debconf database in config and reset in postinst, so I suppose that means that if for some reason the installation fails, we still have the password stored in database. Any pointers to policy reference on dealing with this? Thanks for your time and have a pleasant day! Jeremy -- http://www.jerryweb.org/ : JerryWeb.org http://sailcut.sourceforge.net/ : Sailcut CAD http://mpf70.sourceforge.net/: MPman MP-F70 support for Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf db_input in postinst / horde2
On Thu, Dec 11, 2003 at 11:51:01PM +0100, Jeremy Lain? wrote: > > I can see how it is a Bad Thing to prompt the user for input both in > postinst and in config, but the fact still stands that it's the way > it's done in horde2, and I'm sure there must be a good reason for it! > Any ideas here? Ask it during config, store it in debconf until your through using it in postinst and then clear it from debconf. It's how I do it in mediamate. > Is there any scenario (recovering from a failed install..) which would > involve running the postinst without the config, and hence justify the > prompt for the admin user/password? Honestly don't know. -- Jamin W. Collins Remember, root always has a loaded gun. Don't run around with it unless you absolutely need it. -- Vineet Kumar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Standards-Version
On 2003-12-11 22:00:45 + Florian Zaehringer <[EMAIL PROTECTED]> wrote: I am planing to adopt my first package (emelfm, orphaned). So I checked what needs to be done to equip myself for this task. Hasn't upstream gone away? Are you taking that over too? You probably should retitle bug 158150 and note your intentions. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ [EMAIL PROTECTED] Creative copyleft computing services via http://www.ttllp.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Plea for mentor help
On Dec 11, Steve Kemp ([EMAIL PROTECTED]) wrote: > On Wed, Dec 10, 2003 at 12:38:23PM -0700, Jamin W. Collins wrote: > > > What do you mean by "autoconfiscate"? > > Presumably to make it compile and build with autoconf/automake. > > For that the "GNU Autoconf, Automake and Libtool" book is very useful. > It's available online and in print: > > http://sources.redhat.com/autobook/ > > Steve apt-get install autobook :-) -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Plea for mentor help
On Wed, 10 Dec 2003, Millis Miller wrote: > my curent mentor > seems to be a bit busy and hasn't replied to my emails for a good few > weeks. > That's because your current mentor has a memory like a sieve. :-) I took a look at the package. First problem is you need a build dependency on libpcap-dev and rrdtool Second, the scripts do get made executable by your auto* stuff so that's working ok. It's dh_fixperms which is unsetting them again. After the call to dh_fixperms, add something like the following code ($ signs have to be doubled because debian/rules is a Makefile.) : for i in $(CURDIR)/debian/iptotal/var/www/iptotal/*.cgi; do chmod +x $$i; done which brings me to the third problem. Your scripts are actually getting installed into /var/www/iptotal/iptotal/www. iptotal.cfg is getting installed into /. I'm guessing that's not actually what you want. To get the proper behavior you're going to have to restructure your Makefile.am The top level Makefile.am will look like this: [EMAIL PROTECTED]@ sbin_PROGRAMS = iptotal sbin_SCRIPTS = src/iptotald src/makegraph iptotal_SOURCES = iptotal.c iptotal_LDADD = -lpcap EXTRA_DIST = src/iptotald.in src/makegraph.in www/*.in www/images/* \ www/archive/* iptotal.1 iptotald.8 iptotal_config.5 \ etc/iptotal.cfg etc/iptotal.cfg.in SUBDIRS = etc www Note the SUBDIRS statement. This says to call 2nd level Makefile.am's in etc like this: sysconf_DATA = iptotal.cfg and in www like this: nobase_pkgdata_DATA = archive.cgi iptotal.cgi iptotal_w.cgi iptotal_m.cgi \ iptotal_y.cgi images/* archive/* Don't forget to run automake, aclocal, and autoconf afterwards. Then in the call to configure in debian/rules, change --datadir to /var/www and --sysconfdir to /etc This together with the permissions fix should get rid of most of the issues. Lintian complains about a few minor things though. * makegraph needs a manpage * there are typos in the path to the GPL in debian/copyright * the short description ends with a . It should be a phrase not a sentence. You can ask for advice on the debian-i10n-en mailing list. The other warnings can be ignored or overriden. -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to package a database (not program)?
On Thu, 2003-12-11 at 12:42, Matt Zimmerman wrote: > I would simply include the SQL dump under /usr/share and leave it to the > user where to import it. It's possible that they will want to create a new > database, or import it into an existing one (perhaps even with different > table names), or transform it from SQL into something else. Thanks for the advice. Since sending my original message I've discovered SQLite and think it's the most appropriate database for my application (and probably for anyone else's application). SQLite stores its data in a file and doesn't use a server so it simplifies the problem significantly--all my package has to do is provide the file (under /usr/share as you suggest). There is value in my providing an SQLite file instead of what one gets from the USDA because they describe their tables in a PDF document, and it's nontrivial to type in the table description for the import process. If in the future someone has a need that goes beyond an SQLite file I'll be happy to package it differently, but I think this should be fine for now. Thanks, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
