Re: UTF-8 in copyright files?
On Thu, Dec 18, 2003 at 01:38:35PM +, Colin Watson wrote:
> On Thu, Dec 18, 2003 at 10:12:13AM +0100, Sven Luther wrote:
> > Other problems is sshing from a non UTF terminal, but then luit helps,
> > but there is not really much we can do there, no ?
> This is a pain in the arse, frankly, because there's no way I've found
> to pass environment variables such as LANG across the ssh connection. If
> anyone knows of a not-too-hacky way to do this, I'd be interested.
A colleague of mine wrote the attached Perl script to detect UTF-8 (the only
real language setting he, and I, want to transparently inherit over SSH (and
other) connections is LC_CTYPE, anyway.) Place it somewhere, and call it
from your .bashrc with something like:
if [ -n "$PS1" ]; then
eval `detect-utf8-term`
fi
You'll have to fiddle the script itself to use it with tcsh, but not in any
spectacular way. It needs Term::ReadKey (libterm-readkey-perl). It only sets
LC_CTYPE, and it sets it hardcoded to en_US.UTF-8 when it detects UTF-8.
It also eats all typeahead, unfortunately, which may be annoying depending
on your habits.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
#!/usr/bin/perl -w
# Written by Jan-Pieter Cornet <[EMAIL PROTECTED]>,
# released to the public domain. If you break it, you get to keep both pieces.
use strict;
use Term::ReadKey;
use bytes;
my $lc_ctype = $ENV{LC_CTYPE} || $ENV{LC_ALL} || $ENV{LANG};
if ( defined($lc_ctype) && $lc_ctype =~ /utf-?8/i ) {
### uncomment me if you want silly messages in normal xterms
#print STDERR "Already UTF-8 enabled\n";
exit;
}
ReadMode 'cbreak';
### Send CR, test sequence that's valid ISO8859-1 and valid UTF8, and
### cursor reporting escape ^[[6n.
print STDERR "\r", chr 0xC2, chr 0xA4, chr 27, '[6n';
### read response from terminal, usually ^[[#;#R
my $r = '';
while ( my $c = ReadKey 0.1 ) {
$r .= $c;
last if $c eq 'R';
}
ReadMode 'restore';
### parse returned string
my($x) = $r =~ /^\x1B\[\d+;(\d+)R$/;
if ( !defined $x ) {
print STDERR "Couldn't parse return: ",
( map { sprintf "%02x ", ord } split //, $r ), "\n";
}
elsif ( $x == 2 ) {
### It's UTF-8 enabled, search for a valid locale
my @locales = `locale -a`;
my($utflocale) = grep /utf-?8/i, @locales;
### sensible default...?
$utflocale ||= 'en_US.UTF-8';
print STDERR "\r \r";
print "export LC_CTYPE=$utflocale\n";
}
elsif ( $x == 3 ) {
### it's standard ISO8859
print STDERR "\r \r";
}
else {
### dunno?
print STDERR "Strange x-coord after test: $x\n";
}
Mentor needed for python-opengl2
Hi, my name is Thomas Wouters and I'm looking for a mentor. :) The PyOpenGL debian package, python-opengl, is heavily outdated, being version 1.5.7 whereas the upstream stable version is 2.0.0.44 by now. It also has some other issues, like being built against the wrong version of Tk. PyOpenGL 2.0 is a not-quite-compatible release though, being one of those 'rewrite' major changes. It does improve greatly on the Python OpenGL bindings, and fixes a bunch of bugs. Python-opengl's maintainer, Enrique Zanardi (see Cc), doesn't have the time or inclination anymore to maintain the package, as he explained in a seperate email to me, and offered I adopt the package or build new binary packages. In either case, I'm in need of a mentor. I've debianized PyOpenGL 2.0.0.44 based on how python-opengl 1.5.7 does it, naming it python-opengl2 to avoid the API compatibility issues. I've tested the resulting .deb fairly thoroughly on my own system, including with lintian. There are a few minor policy issues though, including the fact that the software falls (partially) under the SGI Free Software License B... I'm not sure if I should elaborate here or not. A mentor would be greatly appreciated. :) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor for distributed computation daemon: protein folding
On Mon, Jan 27, 2003 at 08:38:10PM +0100, Daniel Bonniot wrote: > The original tar file is huge (22MB) because it contains the (big) > binaries for three architectures (i386, powerpc and hppa). The software is binary-only ? In that case, it can never become a Debian package itself, at most an installer. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor for distributed computation daemon: protein folding
On Mon, Jan 27, 2003 at 10:41:29PM +0100, Daniel Bonniot wrote: > >The software is binary-only ? In that case, it can never become a Debian > >package itself, at most an installer. > As far as I know there is no source download at the moment. The license > is: http://www.distributedfolding.org/license.html I don't think this license satisifies the DFSG, but you're better off asking debian-legal. > Redistribution is explicitely authorized if not-for-profit in the > license, which makes it not free. Couldn't it be a non-free package? > I think it would not change much the structure of the package to make it > an installer. Is it necessary per Debian policy? Could it be in main then? Eh, no, that isn't quite how it works. Better check the Debian Policy Manual: http://www.debian.org/doc/debian-policy/ It explains it a lot better than I could :) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mentor needed for python-opengl2
On Thu, Jan 23, 2003 at 05:23:17PM +0100, Thomas Wouters wrote: > Hi, my name is Thomas Wouters and I'm looking for a mentor. :) > The PyOpenGL debian package, python-opengl, is heavily outdated, being > version 1.5.7 whereas the upstream stable version is 2.0.0.44 by now. It > also has some other issues, like being built against the wrong version of > Tk. PyOpenGL 2.0 is a not-quite-compatible release though, being one of > those 'rewrite' major changes. It does improve greatly on the Python OpenGL > bindings, and fixes a bunch of bugs. Python-opengl's maintainer, Enrique > Zanardi (see Cc), doesn't have the time or inclination anymore to maintain > the package, as he explained in a seperate email to me, and offered I adopt > the package or build new binary packages. In either case, I'm in need of a > mentor. > I've debianized PyOpenGL 2.0.0.44 based on how python-opengl 1.5.7 does it, [...] I subsequently re-did the debianization the Proper way, yielding separate packages for each of the available Python versions. I also split off the Togl part (Tkinter bindings for OpenGL) into seperate packages so python-opengl2 doesn't depend on python-tk. Unfortunately, because python2.1-tk is built against a different tk (8.3, rather than 8.4) I can't build python2.1-togl from the same source package. Not too big a deal, I think. The licensing is still a bit vague. One of the licenses that covers it is the SGI Free Software License B, which is only available in PostScript or MS Word format. I converted it to text for the copyright file for reference, and included the original postscript. I've also emailed about the legality and DSFG-compliance of that conversion, the SGI license and the other licenses to debian-legal, but haven't heard back yet. Another problem I had was with lintian: E: python2.3-togl: python-script-but-no-python-dep ./usr/lib/python2.3/site-packages/OpenGL/Tk/__init__.py E: python2.2-togl: python-script-but-no-python-dep ./usr/lib/python2.2/site-packages/OpenGL/Tk/__init__.py Both packages only depend on python2.x, as they should be installable even if the 'python' package is of a different version. Yet lintian does not complain about the python2.x-opengl packages ? I'm confused. Lintian gives no other errors, however. The end result is this list (I should probably change the short descriptions a bit :-) python-opengl2 - Python binding to OpenGL python-togl - Python binding to OpenGL python2.1-opengl2 - Python binding to OpenGL python2.2-opengl2 - Python binding to OpenGL python2.2-togl - Python binding to OpenGL python2.3-opengl2 - Python binding to OpenGL python2.3-togl - Python binding to OpenGL The packages can be had from here: deb http://www.xs4all.nl/~thomas/debian ./ deb-src http://www.xs4all.nl/~thomas/debian ./ Testing and bugreports would of course be appreciated, especially with different GL libraries (Mesa, nVidia, utah ?) There are some demo scripts in the doc/examples/ directories of both the opengl and the togl packages, but they aren't very good quality. I also have a simple python script that uses GL, GLU and GLUT from the python-opengl2 package, as well as python-numeric, that might be more obvious to test with: http://www.xs4all.nl/~thomas/torus.py It has a solid torus orbited by three suns of different sizes and colours. The largest, white sun is actually a spotlight aiming slightly off-center of the torus. Depending on your GLUT library, the edges of the spotlight on the torus will seem 'blocky'; this is 'correct'. The suns start rotating when you press the left mousebutton (in the window.) Holding down the left button and dragging the mouse rotates your point of view. Pressing escape exits. It doesn't do much beyond that. It's an heavily-added-on example from the OpenGL Programming Guide, please don't judge my Python programming abilities from this script :) I would still very much appreciate a mentor or sponsor (or advocate ;) for these packages. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! msg08447/pgp0.pgp Description: PGP signature
Re: PythonCard packaging advice?
On Tue, Feb 04, 2003 at 10:59:17AM -0600, Kenneth Pronovici wrote: > > > I've now noticed that this doesn't conform to policy and I'm a little > > > confused about what packages I should provide. > > Only the name of the module package is against policy - it should be > > python-pythoncard. > I'm going to take this to mean python2.2-pythoncard/python2.3-pythoncard > based on the rest of your reply. Let me know if I'm wrong. In general, you have a single source package (e.g. python-pythoncard) which builds/installs for each available Python version (and Build-Depends on the -dev version for each of those, obviously) into a python-pythoncard package, and an empty python-pythoncard package that Depends on the currently-preferred python version (2.2 at the moment.) There are several examples to be found in current unstable; practically all hits on: apt-cache search --names-only python2.2- You can just apt-get source one of them, or a few of them, and see how they did it. I did it with python-opengl2 using a single variable in debian/rules holding all to-be-built-against Python versions, but you can also check the dependencies in your own controls file, so you only have to change one location when adding Python versions. > Anyway, I had been thinking that /usr/share/pythoncard was a better > place for a set of samples this big. If I'm wrong about that, I guess > I'll move the samples into /usr/share/doc/pythoncard along with the rest > of the documentation. The examples typically belong to the documentation. If people really worry about the diskspace, they aren't likely to install the documentation either. Be sure to either refer people from /usr/share/doc/python-pythoncard/ to /usr/share/doc/python-pythoncard-doc (or wherever you install it) or have your -doc package install the docs in /usr/share/doc/python-pythoncard, though. > > python2.2-pythoncard Depends: python2.2 > > python2.3-pythoncard Depends: python2.3 > > pythoncard-doc Depends: python2.2-pythoncard | python2.3-pythoncard > To the point of the other reply on this thread, why make the docs depend > on the other two packages? In case it matters, the documentation I > split off is mostly developer documentation. You're thinking the wrong way around. In the above example, pythoncard-doc depends on python2.2-pythoncard or python2.3-pythoncard. You need either of the latter two installed to install the former. In other words, you can't install pythoncard-doc (with examples) if you don't have the python libraries installed to actually run the examples or your own developed code :) Makes sense, right ? -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The "Replaces:" Field
On Wed, Feb 05, 2003 at 10:56:50AM +0100, Tore Anderson wrote: > * David Lloyd > > I don't know if this is the right forum to ask, but I want to replace: > > > > lloy0076@cirith:/usr/share/apps/ksplash/pics$ ls > >splash_bottom.pngsplash_top.png > > splash_active_bar.png splash_inactive_bar.png splash_top.png.backup > (..) > > Replaces: kdebase > You don't want to do that, then your package would make apt de-install > kdebase upon installing your own. Not according to the Policy Manual. A Replaces: header without a Conflicts: header tells dpkg that the package replaces some files in the package(s) listed in the Replaces: header(s). See: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces > You're looking for `dpkg-divert'. Alternatively, you could ask the KDE > maintainers to split the ksplash theme into a separate package, then you > could conflict with that instead. I agree that both of these are better solutions. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wmget bugs
On Wed, Feb 05, 2003 at 12:28:17PM +0100, Rafal Zawadzki wrote:
> There is no new version this utility. I tried contact developer, but got
> no answer. What can i do ? (I can't fix it by myself).
I don't use wmget myself, but you can try the attached patch for bug
#176558 :-)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
*** wmget-0.4.4.orig/request.c Mon May 6 05:08:06 2002
--- wmget-0.4.4/request.c Wed Feb 5 16:34:17 2003
***
*** 205,212
{ 0, 0, 0, 0 }
};
! j.continue_download_from = 0;
! j.opt_overwrite = 0;
while ((o = getopt_long (argc, argv, shortopts, longopts, 0))
!= EOF) {
--- 205,211
{ 0, 0, 0, 0 }
};
! memset(&j, 0, sizeof(j));
while ((o = getopt_long (argc, argv, shortopts, longopts, 0))
!= EOF) {
Re: wmget bugs
On Wed, Feb 05, 2003 at 04:57:06PM +0100, Thomas Wouters wrote: > On Wed, Feb 05, 2003 at 12:28:17PM +0100, Rafal Zawadzki wrote: > > There is no new version this utility. I tried contact developer, but got > > no answer. What can i do ? (I can't fix it by myself). > I don't use wmget myself, but you can try the attached patch for bug > #176558 :-) Oh, and for the other one, #162989, you can try this patch :) Neither is tested, as I don't seem to be able to use wmget with my KDE. This particular change is possibly best included as a separate command line option, though it probably doesn't hurt to have it the default. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! *** wmget-0.4.4.orig/retrieve.c Wed Jun 19 23:47:19 2002 --- wgmet-0.4.4/retrieve.c Wed Feb 5 17:15:23 2003 *** *** 114,119 --- 114,120 curl_easy_setopt (curl, CURLOPT_PROGRESSFUNCTION, progress_callback); curl_easy_setopt (curl, CURLOPT_PROGRESSDATA, (void *)job); curl_easy_setopt (curl, CURLOPT_ERRORBUFFER, curl_error_string); + curl_easy_setopt (curl, CURLOPT_FOLLOWLOCATION, 1); /* this didn't used to be necessary, now it is... seems * counterintuitive, since we don't want the builtin meter and we
Re: UTF-8 in copyright files?
On Thu, Dec 18, 2003 at 01:38:35PM +, Colin Watson wrote:
> On Thu, Dec 18, 2003 at 10:12:13AM +0100, Sven Luther wrote:
> > Other problems is sshing from a non UTF terminal, but then luit helps,
> > but there is not really much we can do there, no ?
> This is a pain in the arse, frankly, because there's no way I've found
> to pass environment variables such as LANG across the ssh connection. If
> anyone knows of a not-too-hacky way to do this, I'd be interested.
A colleague of mine wrote the attached Perl script to detect UTF-8 (the only
real language setting he, and I, want to transparently inherit over SSH (and
other) connections is LC_CTYPE, anyway.) Place it somewhere, and call it
from your .bashrc with something like:
if [ -n "$PS1" ]; then
eval `detect-utf8-term`
fi
You'll have to fiddle the script itself to use it with tcsh, but not in any
spectacular way. It needs Term::ReadKey (libterm-readkey-perl). It only sets
LC_CTYPE, and it sets it hardcoded to en_US.UTF-8 when it detects UTF-8.
It also eats all typeahead, unfortunately, which may be annoying depending
on your habits.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
#!/usr/bin/perl -w
# Written by Jan-Pieter Cornet <[EMAIL PROTECTED]>,
# released to the public domain. If you break it, you get to keep both pieces.
use strict;
use Term::ReadKey;
use bytes;
my $lc_ctype = $ENV{LC_CTYPE} || $ENV{LC_ALL} || $ENV{LANG};
if ( defined($lc_ctype) && $lc_ctype =~ /utf-?8/i ) {
### uncomment me if you want silly messages in normal xterms
#print STDERR "Already UTF-8 enabled\n";
exit;
}
ReadMode 'cbreak';
### Send CR, test sequence that's valid ISO8859-1 and valid UTF8, and
### cursor reporting escape ^[[6n.
print STDERR "\r", chr 0xC2, chr 0xA4, chr 27, '[6n';
### read response from terminal, usually ^[[#;#R
my $r = '';
while ( my $c = ReadKey 0.1 ) {
$r .= $c;
last if $c eq 'R';
}
ReadMode 'restore';
### parse returned string
my($x) = $r =~ /^\x1B\[\d+;(\d+)R$/;
if ( !defined $x ) {
print STDERR "Couldn't parse return: ",
( map { sprintf "%02x ", ord } split //, $r ), "\n";
}
elsif ( $x == 2 ) {
### It's UTF-8 enabled, search for a valid locale
my @locales = `locale -a`;
my($utflocale) = grep /utf-?8/i, @locales;
### sensible default...?
$utflocale ||= 'en_US.UTF-8';
print STDERR "\r \r";
print "export LC_CTYPE=$utflocale\n";
}
elsif ( $x == 3 ) {
### it's standard ISO8859
print STDERR "\r \r";
}
else {
### dunno?
print STDERR "Strange x-coord after test: $x\n";
}
Mentor needed for python-opengl2
Hi, my name is Thomas Wouters and I'm looking for a mentor. :) The PyOpenGL debian package, python-opengl, is heavily outdated, being version 1.5.7 whereas the upstream stable version is 2.0.0.44 by now. It also has some other issues, like being built against the wrong version of Tk. PyOpenGL 2.0 is a not-quite-compatible release though, being one of those 'rewrite' major changes. It does improve greatly on the Python OpenGL bindings, and fixes a bunch of bugs. Python-opengl's maintainer, Enrique Zanardi (see Cc), doesn't have the time or inclination anymore to maintain the package, as he explained in a seperate email to me, and offered I adopt the package or build new binary packages. In either case, I'm in need of a mentor. I've debianized PyOpenGL 2.0.0.44 based on how python-opengl 1.5.7 does it, naming it python-opengl2 to avoid the API compatibility issues. I've tested the resulting .deb fairly thoroughly on my own system, including with lintian. There are a few minor policy issues though, including the fact that the software falls (partially) under the SGI Free Software License B... I'm not sure if I should elaborate here or not. A mentor would be greatly appreciated. :) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Re: Sponsor for distributed computation daemon: protein folding
On Mon, Jan 27, 2003 at 08:38:10PM +0100, Daniel Bonniot wrote: > The original tar file is huge (22MB) because it contains the (big) > binaries for three architectures (i386, powerpc and hppa). The software is binary-only ? In that case, it can never become a Debian package itself, at most an installer. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Re: Sponsor for distributed computation daemon: protein folding
On Mon, Jan 27, 2003 at 10:41:29PM +0100, Daniel Bonniot wrote: > >The software is binary-only ? In that case, it can never become a Debian > >package itself, at most an installer. > As far as I know there is no source download at the moment. The license > is: http://www.distributedfolding.org/license.html I don't think this license satisifies the DFSG, but you're better off asking debian-legal. > Redistribution is explicitely authorized if not-for-profit in the > license, which makes it not free. Couldn't it be a non-free package? > I think it would not change much the structure of the package to make it > an installer. Is it necessary per Debian policy? Could it be in main then? Eh, no, that isn't quite how it works. Better check the Debian Policy Manual: http://www.debian.org/doc/debian-policy/ It explains it a lot better than I could :) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Re: Mentor needed for python-opengl2
On Thu, Jan 23, 2003 at 05:23:17PM +0100, Thomas Wouters wrote: > Hi, my name is Thomas Wouters and I'm looking for a mentor. :) > The PyOpenGL debian package, python-opengl, is heavily outdated, being > version 1.5.7 whereas the upstream stable version is 2.0.0.44 by now. It > also has some other issues, like being built against the wrong version of > Tk. PyOpenGL 2.0 is a not-quite-compatible release though, being one of > those 'rewrite' major changes. It does improve greatly on the Python OpenGL > bindings, and fixes a bunch of bugs. Python-opengl's maintainer, Enrique > Zanardi (see Cc), doesn't have the time or inclination anymore to maintain > the package, as he explained in a seperate email to me, and offered I adopt > the package or build new binary packages. In either case, I'm in need of a > mentor. > I've debianized PyOpenGL 2.0.0.44 based on how python-opengl 1.5.7 does it, [...] I subsequently re-did the debianization the Proper way, yielding separate packages for each of the available Python versions. I also split off the Togl part (Tkinter bindings for OpenGL) into seperate packages so python-opengl2 doesn't depend on python-tk. Unfortunately, because python2.1-tk is built against a different tk (8.3, rather than 8.4) I can't build python2.1-togl from the same source package. Not too big a deal, I think. The licensing is still a bit vague. One of the licenses that covers it is the SGI Free Software License B, which is only available in PostScript or MS Word format. I converted it to text for the copyright file for reference, and included the original postscript. I've also emailed about the legality and DSFG-compliance of that conversion, the SGI license and the other licenses to debian-legal, but haven't heard back yet. Another problem I had was with lintian: E: python2.3-togl: python-script-but-no-python-dep ./usr/lib/python2.3/site-packages/OpenGL/Tk/__init__.py E: python2.2-togl: python-script-but-no-python-dep ./usr/lib/python2.2/site-packages/OpenGL/Tk/__init__.py Both packages only depend on python2.x, as they should be installable even if the 'python' package is of a different version. Yet lintian does not complain about the python2.x-opengl packages ? I'm confused. Lintian gives no other errors, however. The end result is this list (I should probably change the short descriptions a bit :-) python-opengl2 - Python binding to OpenGL python-togl - Python binding to OpenGL python2.1-opengl2 - Python binding to OpenGL python2.2-opengl2 - Python binding to OpenGL python2.2-togl - Python binding to OpenGL python2.3-opengl2 - Python binding to OpenGL python2.3-togl - Python binding to OpenGL The packages can be had from here: deb http://www.xs4all.nl/~thomas/debian ./ deb-src http://www.xs4all.nl/~thomas/debian ./ Testing and bugreports would of course be appreciated, especially with different GL libraries (Mesa, nVidia, utah ?) There are some demo scripts in the doc/examples/ directories of both the opengl and the togl packages, but they aren't very good quality. I also have a simple python script that uses GL, GLU and GLUT from the python-opengl2 package, as well as python-numeric, that might be more obvious to test with: http://www.xs4all.nl/~thomas/torus.py It has a solid torus orbited by three suns of different sizes and colours. The largest, white sun is actually a spotlight aiming slightly off-center of the torus. Depending on your GLUT library, the edges of the spotlight on the torus will seem 'blocky'; this is 'correct'. The suns start rotating when you press the left mousebutton (in the window.) Holding down the left button and dragging the mouse rotates your point of view. Pressing escape exits. It doesn't do much beyond that. It's an heavily-added-on example from the OpenGL Programming Guide, please don't judge my Python programming abilities from this script :) I would still very much appreciate a mentor or sponsor (or advocate ;) for these packages. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! pgpNWCBhF8p0g.pgp Description: PGP signature
Re: PythonCard packaging advice?
On Tue, Feb 04, 2003 at 10:59:17AM -0600, Kenneth Pronovici wrote: > > > I've now noticed that this doesn't conform to policy and I'm a little > > > confused about what packages I should provide. > > Only the name of the module package is against policy - it should be > > python-pythoncard. > I'm going to take this to mean python2.2-pythoncard/python2.3-pythoncard > based on the rest of your reply. Let me know if I'm wrong. In general, you have a single source package (e.g. python-pythoncard) which builds/installs for each available Python version (and Build-Depends on the -dev version for each of those, obviously) into a python-pythoncard package, and an empty python-pythoncard package that Depends on the currently-preferred python version (2.2 at the moment.) There are several examples to be found in current unstable; practically all hits on: apt-cache search --names-only python2.2- You can just apt-get source one of them, or a few of them, and see how they did it. I did it with python-opengl2 using a single variable in debian/rules holding all to-be-built-against Python versions, but you can also check the dependencies in your own controls file, so you only have to change one location when adding Python versions. > Anyway, I had been thinking that /usr/share/pythoncard was a better > place for a set of samples this big. If I'm wrong about that, I guess > I'll move the samples into /usr/share/doc/pythoncard along with the rest > of the documentation. The examples typically belong to the documentation. If people really worry about the diskspace, they aren't likely to install the documentation either. Be sure to either refer people from /usr/share/doc/python-pythoncard/ to /usr/share/doc/python-pythoncard-doc (or wherever you install it) or have your -doc package install the docs in /usr/share/doc/python-pythoncard, though. > > python2.2-pythoncard Depends: python2.2 > > python2.3-pythoncard Depends: python2.3 > > pythoncard-doc Depends: python2.2-pythoncard | python2.3-pythoncard > To the point of the other reply on this thread, why make the docs depend > on the other two packages? In case it matters, the documentation I > split off is mostly developer documentation. You're thinking the wrong way around. In the above example, pythoncard-doc depends on python2.2-pythoncard or python2.3-pythoncard. You need either of the latter two installed to install the former. In other words, you can't install pythoncard-doc (with examples) if you don't have the python libraries installed to actually run the examples or your own developed code :) Makes sense, right ? -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Re: The "Replaces:" Field
On Wed, Feb 05, 2003 at 10:56:50AM +0100, Tore Anderson wrote: > * David Lloyd > > I don't know if this is the right forum to ask, but I want to replace: > > > > [EMAIL PROTECTED]:/usr/share/apps/ksplash/pics$ ls > >splash_bottom.pngsplash_top.png > > splash_active_bar.png splash_inactive_bar.png splash_top.png.backup > (..) > > Replaces: kdebase > You don't want to do that, then your package would make apt de-install > kdebase upon installing your own. Not according to the Policy Manual. A Replaces: header without a Conflicts: header tells dpkg that the package replaces some files in the package(s) listed in the Replaces: header(s). See: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces > You're looking for `dpkg-divert'. Alternatively, you could ask the KDE > maintainers to split the ksplash theme into a separate package, then you > could conflict with that instead. I agree that both of these are better solutions. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Re: wmget bugs
On Wed, Feb 05, 2003 at 12:28:17PM +0100, Rafal Zawadzki wrote:
> There is no new version this utility. I tried contact developer, but got
> no answer. What can i do ? (I can't fix it by myself).
I don't use wmget myself, but you can try the attached patch for bug
#176558 :-)
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
*** wmget-0.4.4.orig/request.c Mon May 6 05:08:06 2002
--- wmget-0.4.4/request.c Wed Feb 5 16:34:17 2003
***
*** 205,212
{ 0, 0, 0, 0 }
};
! j.continue_download_from = 0;
! j.opt_overwrite = 0;
while ((o = getopt_long (argc, argv, shortopts, longopts, 0))
!= EOF) {
--- 205,211
{ 0, 0, 0, 0 }
};
! memset(&j, 0, sizeof(j));
while ((o = getopt_long (argc, argv, shortopts, longopts, 0))
!= EOF) {
Re: wmget bugs
On Wed, Feb 05, 2003 at 04:57:06PM +0100, Thomas Wouters wrote: > On Wed, Feb 05, 2003 at 12:28:17PM +0100, Rafal Zawadzki wrote: > > There is no new version this utility. I tried contact developer, but got > > no answer. What can i do ? (I can't fix it by myself). > I don't use wmget myself, but you can try the attached patch for bug > #176558 :-) Oh, and for the other one, #162989, you can try this patch :) Neither is tested, as I don't seem to be able to use wmget with my KDE. This particular change is possibly best included as a separate command line option, though it probably doesn't hurt to have it the default. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! *** wmget-0.4.4.orig/retrieve.c Wed Jun 19 23:47:19 2002 --- wgmet-0.4.4/retrieve.c Wed Feb 5 17:15:23 2003 *** *** 114,119 --- 114,120 curl_easy_setopt (curl, CURLOPT_PROGRESSFUNCTION, progress_callback); curl_easy_setopt (curl, CURLOPT_PROGRESSDATA, (void *)job); curl_easy_setopt (curl, CURLOPT_ERRORBUFFER, curl_error_string); + curl_easy_setopt (curl, CURLOPT_FOLLOWLOCATION, 1); /* this didn't used to be necessary, now it is... seems * counterintuitive, since we don't want the builtin meter and we
RFS: python-opengl2 (PyOpenGL 2.0)
I'm looking for a sponsor for the PyOpenGL 2.0.0 packages I created to replace the current python-opengl (1.5) packages. The new packages have seen some use, and have produced positive feedback :) I've used them myself without problems, and haven't had any complaints other than "why aren't they in unstable". Because the python-opengl package is somewhat problematic (it doesn't build properly against python2.2 because of a Tk version issue) several people have offered to temporarily sponsor the packages, but it would be nice to have a sponsor that actually knows both Python and OpenGL, and preferably PyOpenGL :) Also, Enrique Zanardi, the python-opengl maintainer, indicated he would be fixing that package to work properly with python2.2 (and if he ends up not having the time to do it, I can provide an NMU for it) so the need isn't that pressing, in my eyes. PyOpenGL 2.0 isn't quite compatible with PyOpenGL 1.5, so I don't think we can replace python-opengl just yet. Any sponsor should know that I intend to package some of the 2.0.1 alpha's or at least some CVS snapshots too, when they stabilize some, and later versions. The 2.0.0.44 packages still have two caveats, by the way: - The licensing is somewhat unclear. PyOpenGL 2.0 claims to be covered by the SGI FreeB license, but I cannot figure out why. The package includes the license, both in its original PostScript and a text version I made myself. I am not certain what the status of the FreeB license wrt. the DFSG is; it seems to be okay, but see http://lists.debian.org/debian-legal/2003/debian-legal-200301/msg00042.html - Togl is still included in the python*-togl packages. Togl is actually a Tcl/Tk package in its own right, and could certainly be packaged independantly; it would remove the need to include Togl in each python-version-specific python*-togl package. However, I don't know enough about Tcl/Tk packaging to make it work. The upstream source also doesn't support this yet (because before, it required a modified Togl to work properly) but that's easily fixed. See also my original mentor request: http://lists.debian.org/debian-mentors/2003/debian-mentors-200301/msg00164.html and its followup. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Re: First steps in packaging
On Fri, Apr 18, 2003 at 01:54:59PM +1000, Matthew Palmer wrote: > Out of interest, are there any MUAs which have a separate "reply to list" > function? Yes, Mutt. See the 'Mailing Lists' and 'Handling Mailing Lists' sections of its manual (/usr/share/doc/mutt/manual.txt.gz in its package.) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
