debian/templates and Select/Choices:
Hello *,
Since my packages are working fine, I have a problem with an generated
list in Choices:. I have a directory with plugins
/usr/lib/tddyndns
and I want to put the files into the Choices: list and I have done:
[ '/var/lib/dpkg/info/tddyndns.templates' ]---
Template: tddyndns/dd_router_type
Type: select
Choices: ${AVAILLABLE_ROUTERS}
Description: Choose the router you want to use.
Description-de.ISO-8859-15: Wählen Sie den zu verwendenden Router aus.
--
which give me after installation:
[ '/var/cache/debconf/config.dat' ]-
Name: tddyndns/dd_router_type
Template: tddyndns/dd_router_type
Value:
Owners: tddyndns
Variables:
availrouters = netgear_dm602, netgear_dm835, zyxel_2002, zyxel_761
Which is OK. Then I have in my
[ '/var/lib/dpkg/info/tddyndns.config' ]-
. /usr/share/debconf/confmodule
snip
AVAILLABLE_ROUTERS=$(ls /usr/lib/tddyndns |tr \n , |sed s/,/, /g)
db_subst tddyndns/dd_router_type availrouters ${AVAILLABLE_ROUTERS}
db_fset tddyndns/dd_router_type seen false
snip
# Let the user go back in the configuration
db_capb backup
STATE=1
while [ $STATE != 0 -a $STATE != 18 ] ; do
case $STATE in
1)
db_input medium tddyndns/dd_email_to || true
;;
snip
5)
db_input medium tddyndns/dd_router_type || true
;;
snip
17)
db_input medium tddyndns/dd_backmx || true
;;
esac
if db_go ; then
STATE=$(($STATE + 1))
else
STATE=$(($STATE - 1))
fi
done
# Program End
exit 0
-
All is working fine, except 5), :-(
I was reading /usr/share/doc/debconf-doc/tutorial-html forward and
backward but now my brain is smoking!
I was thinking, this has something to do with the variable
availrouters but all what I have tried does not work (for me).
Any suggestions?
Thanks, have a nice week
Michelle Konzack
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libcpufreq and the small libsysfs transition
On Sun, Feb 12, 2006 at 02:19:08PM -0800, Steve Langasek wrote:
On Sun, Feb 12, 2006 at 07:06:00PM +0100, Mattia Dongili wrote:
I need a quick suggestion how to handle libcpufreq{0,-dev} within the
libsysfs transition.
Facts:
- current cpufrequtils is compatible with both libsysfs1 and libsysfs2
- the source package depends on libsysfs-dev = 1.0.0
- libcpufreq0 uses ${shlibs:Depends} to build dependencies
Now, my understanding is that a binNMU is sufficient to rebuild binaries
and fill the correct dependencies?
Looks like it to me.
If so, is pinging about it [EMAIL PROTECTED] usually sufficient to
ask request the binNMU?
Yes.
Ooops :)
My mail was indended as just a suggestion on how to proceed, I was
waiting the availability of libsysfs2 in sid before actually pinging
debian-release@ for the binNMU.
I did see that the package was rebuilt on 02/12 actually :)
Apologies for not being clear enough...
--
mattia
:wq!
signature.asc
Description: Digital signature
RFC/RFS: PyKaraoke
PyKaraoke is a free karaoke player. You can use this program to play your collection of CDG, MIDI and MPEG karaoke songs. This package includes the command-line programs to play CDG files, MIDI/KAR files and MPEG files. Features: * CDG (MP3+G, OGG+G) playback - Play standard CDG karaoke files * MIDI (.MID/.KAR) playback - Play MIDI format karaoke files * MPEG playback - Play karaoke songs and movies in MPEG format MIDI/KAR support on Linux, requires the following: * Timidity++ * Sounds/patches for Timidity++ (e.g. freepats or eawpatches) Homepage: http://www.kibosh.org/pykaraoke/ My packages are available at http://baby.yi.org/packages/pykaraoke/ Greetings, Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
looking for a sponsor
__ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: PyKaraoke
On Wed, 2006-02-15 at 20:41 +0100, Miriam Ruiz wrote:
PyKaraoke is a free karaoke player. You can use this program to play your
collection of CDG, MIDI and MPEG karaoke songs.
This package includes the command-line programs to play CDG files, MIDI/KAR
files and MPEG files.
...
My packages are available at http://baby.yi.org/packages/pykaraoke/
Some issues:
Your debian/control should not depend directly on python, but use
${python:Depends} and call dh_python in its binary-indep target. You
also need to Build-Depend on Python.
You patch the upstream source in a number of places. The reasons seem
good, but you also moved the cdgBorderPreset function which makes the
diff unnecessarily hard to check. Also,
self.FileName[len(self.FileName)-1] is much clearer as just
self.FileName[-1]. If you haven't sent the changes upstream, you
probably should.
debian/copyright lists the authors and the license, but does not have a
proper copyright notice. Looking at the source, it seems to be
Copyright (C) 2005 Kelvin Lawson ([EMAIL PROTECTED]). The
source also specifies LGPL 2.1, but debian/copyright says LGPL 2.
Once these are fixed, I would be happy to sponsor this.
Just a warning (for you and upstream, if you didn't know) -- Pygame's
MPEG support, and pygame.mixer.music in general, are both very flakey.
--
Joe Wreschnig [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: looking for a sponsor
john aikins [EMAIL PROTECTED] writes: [nothing] It's customary to provide details of what you would like sponsoring, plus pointers to the sources. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpXxPm6h7SjW.pgp Description: PGP signature
Re: RFC/RFS: PyKaraoke
--- Joe Wreschnig [EMAIL PROTECTED] escribió:
Some issues:
Your debian/control should not depend directly on python, but use
${python:Depends} and call dh_python in its binary-indep target. You
also need to Build-Depend on Python.
I did that in one of my packages, which I co-maintain, that is written in
python, and it was converted to something similar to what i did this time.
Which is the best approach and why?
You patch the upstream source in a number of places. The reasons seem
good, but you also moved the cdgBorderPreset function which makes the
diff unnecessarily hard to check. Also,
self.FileName[len(self.FileName)-1] is much clearer as just
self.FileName[-1]. If you haven't sent the changes upstream, you
probably should.
To be honest, I reported some bugs after trying the package to upstream and it
was him who sent me the patches.
debian/copyright lists the authors and the license, but does not have a
proper copyright notice. Looking at the source, it seems to be
Copyright (C) 2005 Kelvin Lawson ([EMAIL PROTECTED]). The
source also specifies LGPL 2.1, but debian/copyright says LGPL 2.
Thanks, I'll fix that :) I should have checked it, it was the default template
created with dh_make --copyright lgpl slightly changed.
Once these are fixed, I would be happy to sponsor this.
Thanks, I'll email you when it's ready :)
Just a warning (for you and upstream, if you didn't know) -- Pygame's
MPEG support, and pygame.mixer.music in general, are both very flakey.
I didn't know. Anyway I guess it will improve :) I didn't have any problems
playing my karaoke files back anyway.
Greetings,
Miry
__
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: PyKaraoke
On Wed, 2006-02-15 at 22:16 +0100, Miriam Ruiz wrote:
--- Joe Wreschnig [EMAIL PROTECTED] escribió:
Some issues:
Your debian/control should not depend directly on python, but use
${python:Depends} and call dh_python in its binary-indep target. You
also need to Build-Depend on Python.
I did that in one of my packages, which I co-maintain, that is written in
python, and it was converted to something similar to what i did this time.
Which is the best approach and why?
Depending on just python is fine if you're providing a Python program
with no modules (i.e. just an executable). However, if you have .py
modules that get imported, you need to make sure the modules are
compiled for the right version of Python (not doing this is a minor
bug), and also that the compiled modules are removed when the package is
removed (not doing this is a serious bug). dh_python will use a stronger
dependency to enforce the former, and include some code in the
postinst/prerm to automatically do the latter.
In the future, using dh_python may also do more magic to help Python
transitions and dependency issues. So it's good to use it to help
transitions remain as consistent and simple as possible. Exactly when in
the future, and what kind of magic should be done, is an active debate
on debian-python right now.
You patch the upstream source in a number of places. The reasons seem
good, but you also moved the cdgBorderPreset function which makes the
diff unnecessarily hard to check. Also,
self.FileName[len(self.FileName)-1] is much clearer as just
self.FileName[-1]. If you haven't sent the changes upstream, you
probably should.
To be honest, I reported some bugs after trying the package to upstream and it
was him who sent me the patches.
Okay, then I have no problem with it.
--
Joe Wreschnig [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: RFC/RFS: PyKaraoke
--- Miriam Ruiz [EMAIL PROTECTED] escribió:
--- Joe Wreschnig [EMAIL PROTECTED] escribió:
Some issues:
Your debian/control should not depend directly on python, but use
${python:Depends} and call dh_python in its binary-indep target. You
also need to Build-Depend on Python.
I did that in one of my packages, which I co-maintain, that is written in
python, and it was converted to something similar to what i did this time.
Which is the best approach and why?
I've tried that, and it adds the dependencies:
python (= 2.3), python ( 2.4)
Why can't it be used with python 2.4?
Greetings,
Miry
__
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: PyKaraoke
Done, new packages are (again) at: http://baby.yi.org/packages/pykaraoke/ Thanks :) Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: PyKaraoke
On Wed, 2006-02-15 at 22:38 +0100, Miriam Ruiz wrote:
--- Miriam Ruiz [EMAIL PROTECTED] escribió:
--- Joe Wreschnig [EMAIL PROTECTED] escribió:
Some issues:
Your debian/control should not depend directly on python, but use
${python:Depends} and call dh_python in its binary-indep target. You
also need to Build-Depend on Python.
I did that in one of my packages, which I co-maintain, that is written in
python, and it was converted to something similar to what i did this time.
Which is the best approach and why?
I've tried that, and it adds the dependencies:
python (= 2.3), python ( 2.4)
Why can't it be used with python 2.4?
The modules are byte-compiled for Python 2.3, and should be recompiled
when Debian ships Python 2.4 as the default. There's no way to
automatically do that yet, so instead dh_python sets it up so that a
simple rebuild will cause it to upgrade properly. It's messy, and should
be done more automatically, but isn't yet.
--
Joe Wreschnig [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: RFC/RFS: PyKaraoke
--- Joe Wreschnig [EMAIL PROTECTED] escribió: Why can't it be used with python 2.4? The modules are byte-compiled for Python 2.3, and should be recompiled when Debian ships Python 2.4 as the default. There's no way to automatically do that yet, so instead dh_python sets it up so that a simple rebuild will cause it to upgrade properly. It's messy, and should be done more automatically, but isn't yet. I guess you're talking about the future, as I don't see any .pyc file in the package, even using dh_python and so. Anyway I guess it'll help maintaining the compatibility in the future for what I understood. Right now the only change I noticed in the package is that one I mentioned about the dependencies. Thanks :) Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Depending on both runtime and dev packages?
Hi, I'm building a package (a Scheme-to-C compiler) and I split it into three different debs: libfoo0 (runtime libs), libfoo-dev (.a and .la files and includes) and foo-bin (compiler and other tools). The depends are a big problem: foo-bin needs to depend on libfoo0 (otherwise the compiler won't run) but without the -dev package you won't be able to convert a Scheme file into a C one, so a Depends on libfoo-dev is needed, too: I don't think someone will ever use a program just to see the -help screen. Other idea could be to merge -bin and -dev packages, but in this way the new package will have to depend on both libpcre3 (the compiler is linked against it) and libpcre3-dev (you need it to compile .scm files into .c ones), so this seems a chicken-and-egg problem! Can someone suggest me a better idea to resolve the problem? Thanks in advance. -- Davide Puricelli, [EMAIL PROTECTED] Debian Developer: [EMAIL PROTECTED] | http://www.debian.org Time looked like snow dropping silently into a black room -- Ray Bradbury signature.asc Description: Digital signature
Re: RFC/RFS: PyKaraoke
On Wed, 2006-02-15 at 23:21 +0100, Miriam Ruiz wrote: --- Joe Wreschnig [EMAIL PROTECTED] escribió: Why can't it be used with python 2.4? The modules are byte-compiled for Python 2.3, and should be recompiled when Debian ships Python 2.4 as the default. There's no way to automatically do that yet, so instead dh_python sets it up so that a simple rebuild will cause it to upgrade properly. It's messy, and should be done more automatically, but isn't yet. I guess you're talking about the future, as I don't see any .pyc file in the package, even using dh_python and so. Anyway I guess it'll help maintaining the compatibility in the future for what I understood. Right now the only change I noticed in the package is that one I mentioned about the dependencies. The pyc files are generated in the postinst, you won't see them in dpkg -L/-c output. There's one problem left with the most recent package, it has the proper license, but still lacks the copyright notice. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: RFC/RFS: PyKaraoke
Joe Wreschnig wrote: The pyc files are generated in the postinst, you won't see them in dpkg -L/-c output. So, if you upgrade to a newer version of python, it won't work, as the compiled files would not be regenerated. is that it? I guess I understand why it cannot be run with python2.4 then. I hope someone finds a better solution anyway :) There's one problem left with the most recent package, it has the proper license, but still lacks the copyright notice. Done. Sorry. Same URL: http://baby.yi.org/packages/pykaraoke/ :) Miry __ LLama Gratis a cualquier PC del Mundo. Llamadas a fijos y móviles desde 1 céntimo por minuto. http://es.voice.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libcpufreq and the small libsysfs transition
On Wed, Feb 15, 2006 at 07:47:11PM +0100, Mattia Dongili wrote:
On Sun, Feb 12, 2006 at 02:19:08PM -0800, Steve Langasek wrote:
On Sun, Feb 12, 2006 at 07:06:00PM +0100, Mattia Dongili wrote:
I need a quick suggestion how to handle libcpufreq{0,-dev} within the
libsysfs transition.
Facts:
- current cpufrequtils is compatible with both libsysfs1 and libsysfs2
- the source package depends on libsysfs-dev = 1.0.0
- libcpufreq0 uses ${shlibs:Depends} to build dependencies
Now, my understanding is that a binNMU is sufficient to rebuild binaries
and fill the correct dependencies?
Looks like it to me.
If so, is pinging about it [EMAIL PROTECTED] usually sufficient to
ask request the binNMU?
Yes.
Ooops :)
My mail was indended as just a suggestion on how to proceed, I was
waiting the availability of libsysfs2 in sid before actually pinging
debian-release@ for the binNMU.
I did see that the package was rebuilt on 02/12 actually :)
Apologies for not being clear enough...
Hmm... sloppy of me for not noticing. Well, let me know when libsysfs2
actually hits unstable then...
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
Re: RFC/RFS: PyKaraoke
On Thu, 2006-02-16 at 00:08 +0100, Miriam Ruiz wrote: Joe Wreschnig wrote: The pyc files are generated in the postinst, you won't see them in dpkg -L/-c output. So, if you upgrade to a newer version of python, it won't work, as the compiled files would not be regenerated. is that it? I guess I understand why it cannot be run with python2.4 then. I hope someone finds a better solution anyway :) There's one problem left with the most recent package, it has the proper license, but still lacks the copyright notice. Done. Sorry. Same URL: http://baby.yi.org/packages/pykaraoke/ :) Uploaded, thanks! If you need a sponsor for future versions, feel free to contact me directly; I don't always get around to -mentors quickly. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: RFC/RFS: PyKaraoke
On Thu, Feb 16, 2006 at 12:08:21AM +0100, Miriam Ruiz wrote: The pyc files are generated in the postinst, you won't see them in dpkg -L/-c output. So, if you upgrade to a newer version of python, it won't work, as the compiled files would not be regenerated. is that it? I guess I understand why it cannot be run with python2.4 then. I hope someone finds a better solution anyway :) Yeah, we've been working on it... discussion on debian-python over the past month or two. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Depending on both runtime and dev packages?
On Wed, 2006-02-15 at 23:42 +0100, Davide Puricelli wrote: Can someone suggest me a better idea to resolve the problem? Felix has the same issue (also a compiler). Debian is built for non-programmer end users using apps built with C. When targeting programmers, or dealing with non C code, you will need to re-interpret the policy. I decided that every package XYZ has an intent, use, or purpose, and should depend on every other package which is required to satisfy that purpose. OTOH a component which is NOT in some way separately useful should not be made into a package. For Felix the runtime library is currently regarded as an implementation detail. It is not documented and it has no .soname so it shouldn't even be going into /usr/lib. This is because I'm not providing the translator application separately. Any smart programmer wanting to use the standalone translator separately is on their own at the moment. I can't support that -- because it would require documenting the runtime library, giving it a .so name, and installing it in the proper place. Q: So what about binary applications built with Felix? A: They're not supported. I define execution in terms of source code. The system knows when sources change and rebuilds automatically. The generated binaries are an implementation detail. Clearly you have different needs and requirements for your translator. BTW: can I have a look? -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: python-harvestman
Dear Mentors, I'd like you to see HarvestMan (http://harvestman.freezope.org) (ITP bug #352012). I have made some updates to the package over the last week. Description: quote HarvestMan can be used to download files from websites, according to a number of user-specified rules. The latest version of HarvestMan supports as much as 60 plus customization options. HarvestMan is a console (command-line) application. HarvestMan is the only public-domain, multithreaded web-crawler program written in the Python language. HarvestMan is released under the GNU General Public License. /quote The package is quite small and simple. The current tarball is available at http://download.berlios.de/harvestman/HarvestMan-1.4.6.tar.bz2 ( 100KB) and my diff is at: http://www.ee.iitm.ac.in/~ee03b091/debpkgs The current status is, that I have a source package which generates python2.3-harvestman, python2.4-harvestman and python-harvestman. python-harvestman depends on the 2.3 version and ships with a symbolic link to the executable script present in the site-packages directory. I have also outlined the advantage of using the 2.4 package in README.Debian. It is almost lintian clean; upstream uses two changelog files, on of which is called Changes.txt, so that causes a warning. Please send in your comments, so that I can improve it. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
