Re: Handling multiple-wm packages?
Xavier Roche [EMAIL PROTECTED] writes: [...] For the gnome desktop entry: /usr/share/gnome/apps/Internet/WebHTTrack.desktop Not the right place for desktop files. See http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problems with upstream authors and the naming of perl modules
At 09:27 29/05/2003 +0200, you wrote: On Thu, May 29, 2003 at 12:44:22AM -0400, Deedra Waters wrote: [...] | If you look at the packages description, you will see thatit says This | module provides the Perl bindings to libcurl. In the description it | tells what the package is. | Could the description at least explicitly name the perl module 'WWW::Curl' as | well as descripting what it does? Imho it really should do that if it doesn't yet. You should list the included modules in the (long) description, apt-cache search WWW::Curl or apt-cache search Curl::Easy should find the module. | I think it a bit unfortunate that the | debian auto-naming looses the case and mangles the names of CPAN modules so | much - it certainly takes a few moments thinking to 'map' from one to the | other [...] Perhaps you could note that while it might look strange from the outside the *consistent* name-mangling actually makes it very easy to find the respective module for the users. cu andreas It would probably be easier for th users if the name-mangling yielded libperl-curl-easy or libperl-www-curl instead of the current one... ...any reasons for doing it otherwise i have overlooked ? J.L. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problems with upstream authors and the naming of perl modules
José Luis Tallón [EMAIL PROTECTED] writes: It would probably be easier for th users if the name-mangling yielded libperl-curl-easy or libperl-www-curl instead of the current one... ...any reasons for doing it otherwise i have overlooked ? Debian Perl Policy is quite specific: Foo::Bar should be named libfoo-bar-perl. Likewise all Java libraries must be named libXXX-java. -- * Military justice is to justice what military music is to music. * * (Groucho Marx) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problems with upstream authors and the naming of perl modules
Kalle Kivimaa wrote: José Luis Tallón [EMAIL PROTECTED] writes: It would probably be easier for th users if the name-mangling yielded libperl-curl-easy or libperl-www-curl instead of the current one... ...any reasons for doing it otherwise i have overlooked ? Debian Perl Policy is quite specific: Foo::Bar should be named libfoo-bar-perl. Likewise all Java libraries must be named libXXX-java. But is a should clause imperative enough to override die library name? IMHO (and I'm not a DD) people installing this manually will want a perl binding of libcurl. (Note that I'd be arguing for libcurl-perl with an optional added easy or www or something.) If you want to follow the spirit of perl policy you might Provide: libwww-Whatwasit-perl to reflect the name hierachy. (Though there might be policy constraints on wildly providing stuff.) Cheers T. pgp0.pgp Description: PGP signature
Sponsoring a Java package
Hi, I am a new DD, so there are a lot of subtleties out there still waiting for me to learn :) One of them is: A coworker of mine is a co-developer of a Java-based LMS, OpenUSS (http://www.openuss.org). We were talking that it would be interesting to package OpenUSS for Debian - Initially I offered him I would upload it and list him as the maintainer (this means, I would sponsor him). However, I have a big question here: If I sponsor him, I must make sure his package is correctly built. And, yes, I would check for mostpolicy details and such... But I don't know Java, so I would be unable to do much more than that. There is one important good point on me sponsoring it: We work together, if there is any problem on the Debian packaging, he can check it with me. If there is any Java-related problem, I can pass it to him... But anyway, I am a bit uneasy on this. Would I be enough to sponsor this program? Should I find someone else to do this? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SML/NJ Bugfix and New Packages
My sponsor is unavailable to upload for me right now, so I am seeking a Developer who would like to help me get the following uploaded: 1. A bugfix to the smlnj-runtime package. Fixes a compile problem with the gcc-3.3 compiler. 2. Optionally a set of new smlnj related packages: libckit-smlnj A C front end in SML libsmlnj-smlnjUseful libraries for Standard ML of New Jersey libnlffi-smlnjStandard ML No Longer Foreign Language Interface library ml-nlffigen Standard ML No Longer Foreign Language Interface tool I can wait on the new packages, but I would like to get the bug taken care of right away. These are all available on http://aread.sdf1.org Aaron -- Aaron Matthew Read [EMAIL PROTECTED] http://www.nyx.net/~amread 1024D/67A9728A: B9DE 635A 86D8 5EF5 0619 B5BB 9B81 E080 67A9 728A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
advice on closing bugs
I recently adopted several packages (jade, openjade, opensp) and several of the open bugs were fixed by NMUs, so they have fixed tags. I think all I need to do is send an email to [EMAIL PROTECTED] that says, This bug was fixed in the NMU of version 1.2.1-29.3. The fix has been propagated to the latest version, 1.2.1-32. So, as the new maintainer of the package, I am closing the bug. Do I need to say any more? (I probably wouldn't have asked if there hadn't been so much recent flamage on -devel about closing bugs.) -- Neil Roeth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: advice on closing bugs
On Thu, May 29, 2003 at 07:14:39PM -0400, Neil Roeth wrote: I recently adopted several packages (jade, openjade, opensp) and several of the open bugs were fixed by NMUs, so they have fixed tags. I think all I need to do is send an email to [EMAIL PROTECTED] that says, This bug was fixed in the NMU of version 1.2.1-29.3. The fix has been propagated to the latest version, 1.2.1-32. So, as the new maintainer of the package, I am closing the bug. Do I need to say any more? That's fine. I've been known to quote the changelog entries from the NMU fixes as well, though. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: advice on closing bugs
Neil Roeth [EMAIL PROTECTED] writes: I recently adopted several packages (jade, openjade, opensp) and several of the open bugs were fixed by NMUs, so they have fixed tags. I think all I need to do is send an email to [EMAIL PROTECTED] that says, This bug was fixed in the NMU of version 1.2.1-29.3. The fix has been propagated to the latest version, 1.2.1-32. So, as the new maintainer of the package, I am closing the bug. Do I need to say any more? (I probably wouldn't have asked if there hadn't been so much recent flamage on -devel about closing bugs.) There doesn't seem to be a clear consensus on the best way to close fixed-by-NMU bugs. Your method is of course fine (it's always acceptable to close a bug through -done, I think). Another common way (though inferior, IMO) is to close them with a changelog entry such as * Acknowledge NMU (Closes: ...) Colin's method is my favorite (dpkg-buildpackage -v ...) -- Poems... always a sign of pretentious inner turmoil. pgp0.pgp Description: PGP signature
How do I get libtool to use g++?
I recently had a bug (193950) filed against one of my packages because the shared libraries had undefined non-weak symbols - libstdc++ was not being linked in. I resolved it with what I consider a gruesome hack. I discovered that forcing libtool to use g++ while linking would automatically link in libstdc++. The hack came about because I could not figure out how to get libtool to use g++ instead of gcc. So, I did sed -e 's/CC=gcc/CC=g++/g' libtool lt.tmp mv -f lt.tmp libtool to force it. What's the right way to get libstdc++ linked in to shared libraries of C++ code? The package uses autoconf, automake, libtool, etc. -- Neil Roeth
Re: problems with upstream authors and the naming of perl modules
I really think this should go to the debian-perl list so I'm sending it there. The libc-include-perl example below is one of the best arguments I've seen for changing the perl module naming scheme. It's a pity that we didn't think it through more before deciding on it. IIRC we just took the example of a few packages using that naming scheme and blessed it. Changing the naming scheme to something saner would take at least one release, we'd want to start near the beginning of the development cycle to have time to change all the packages. Now is not the time to start that process. Of course, to make things worse, the same silly naming scheme is being used for java, python, and ruby module packages in debian now, too. :-( As far as some kind of quicker fix goes, I proposed some time ago that policy be amended to let the libfoo-bar-perl just be provided by the package, if it made better sense to use something else for the package name. Though that proposal has been stalled for *years* (I'm offline, so I cannot look up why, it's policy bug #114920), if I were you I'd go ahead and do that here. Deedra Waters wrote: I'm including the messages below, because I'm hoping that maybe one of you can help me figure out how to respond to the upstream authors on this Basically the problem seems to be that they are very unhappy with the way that debian is naming perl modules, and I'm getting to a point, where I am no longer sure how to respond to them on this Any advice would be seriously appreciated... Cris Bailiff wrote | Hi Guys, | | I'm a bit slow on the uptake, as usual, but I think I can see the issues: | | * Deedra has taken over from Domenico, and updated the release package for | debian | | * The Perl package name has changed from Curl::easy to WWW::Curl (on advice | from the CPAN maintainers) | | * Debians dh-make-perl (I don't know much about debian tools, sorry) | automatically generates the debian package name based on the perl module | name: | | Foo::Bar - libfoo-bar-perl | Curl::easy - libcurl-easy-perl | | * Unfortunately, the auto-generated name is confusing, misleading and or ugly | now that the Curl::easy module name has changed to WWW::Curl: | | WWW::Curl - libwww-curl-perl | | | This leads to Daniels objections: | | On Wed, 28 May 2003, Daniel Stenberg wrote: | 1 - You make the package associated to a project to which it has | absolutely no attachments (libwww). Thus, some people will look in the | wrong place and bother the wrong people when they search for help or just | more info. | | This is possibly the most serious - this package has nothing to do with | 'libwww' - a 'competitive' package from curls' point of view. | | 2 - By not using the name libcurl in the name, you do not make it clear | that it is in fact a libcurl binding. | | An unfortunate side effect of the auto-naming - but it was actually just a | happy accident that the old debian naming began 'libcurl-' for the old | package name. (The perl name has never clearly stated 'libcurl'.) | | 3 - By using the term 'curl' like this in the name, you make it sound as | if this package is somehow using the command line tool curl. Which AFAIK, | this doesn't do. | | I don't see this as a major issue - as long as people can see that its curl | perl, they'll probably get what they're looking for. (No, the module doesn't | use the command line tool). | | I think it all comes down to a 'not very good' auto-naming scheme for debian | perl packages, which makes them look much to much like real libraries, and | was bound to cause collisions/confusion at some point - e.g. What happens to | the perl module called 'C::Include'? You mean libc-include-perl isn't a | system library? WTF? | | On 'other distros' (RPM based, specifically), we get nicer names like | 'perl-Curl-easy' and 'perl-WWW-Curl' and 'perl-C-Include', which don't have | this issue. | | | Seriously, when I read the name first I thought someone had adjusted some | libwww things to use curl or possibly libcurl within it. | | 'Me too', only I was really thinking of the *perl* standard http library | libwww-perl, and that someone had done a libcurl backend for that (long | mooted!) I don't know what that will now be called :-) | | Daniel asks, | Can you PLEASE reconsider this name? | | and I guess I agree, if there's any scope for changing it. | | On Thu, 29 May 2003 12:02 am, Deedra Waters wrote: | Debian has rules and policies for the way that packages are done. | There's the normal debian-policy, and the debian policy for perl. This | package is named according to those guidelines. I don't really have | control over that. | | I understand that you just used what the dh-make-perl tool suggested, but | would you have a choice over continuing to use the 'old' debian package name | or not? WWW::Curl is still 100%
Re: bug reports
Neil Roeth wrote:
Thanks for the hints. I should have been more clear - I have no problem
getting the main page, i.e., [EMAIL PROTECTED] There are
links in that page to bugs.debian.org/cgi-bin/bugreport.cgi?bug=num for each
bug, and I want to get each of those as a local web page, too. That is the
part that seems to require more than a simple wget command.
You can use the following patch to the bts command from devscripts.
After patching bts, run 'bts cache package' or 'bts cache email',
then use bts -o when offline to view cached bugs. It also progressively
caches any bugs you look at while online.
--- /usr/bin/bts2003-01-01 05:37:21.0 -0500
+++ bin/bts 2003-04-08 13:42:58.0 -0400
@@ -18,11 +18,18 @@
my $browser; # Will set if necessary
my $btsurl='http://bugs.debian.org/';
+my $btscgiurl='http://bugs.debian.org/cgi-bin/';
my $btsemail='[EMAIL PROTECTED]';
+my $cachedir=$ENV{HOME}./.bts_cache/;
+
+# Add any temporary files to this array, to ensure they are cleaned up
+# properly on program exit.
+my @tmpfiles;
+$SIG{INT}=sub { unlink @tmpfiles if @tmpfiles };
=head1 SYNOPSIS
-Bbts command [args] [#comment] [.|, command [args] [#comment]] ...
+Bbts [options] command [args] [#comment] [.|, command [args] [#comment]] ...
=head1 DESCRIPTION
@@ -66,6 +73,41 @@
Please use this program responsibly, and do take our users into
consideration.
+=head1 OPTIONS
+
+=over 4
+
+=item -o, --offline
+
+Make bts use cached bugs for the 'show' and 'bugs' commands, if a cache
+is available for the requested data. See the cache command, below for
+information on setting up a cache. Setting the BUGSOFFLINE environment
+variable has the same effect.
+
+=back
+
+=cut
+
+# For now, a very simple parser, instead of Getopt::Long since there are
+# so few options.
+my $offlinemode=(exists $ENV{BUGSOFFLINE});
+foreach (@ARGV) {
+ if (/^--(.*)/ || /^-(.*)/) {
+ my $option=$1;
+ shift @ARGV;
+ if ($option eq 'offline' || $option eq 'o') {
+ $offlinemode=1;
+ }
+ else {
+ print STDERR Unknown option, \$option\\n;
+ bts_help(1);
+ }
+ }
+ else {
+ last; # end of options
+ }
+}
+
=head1 COMMANDS
For full details about the commands, see the BTS documentation.
@@ -104,7 +146,7 @@
sub bts_show {
my $thing=shift or die display what bug?\n;
-execbrowser($btsurl.$thing);
+ browse($thing);
}
=item bugs package
@@ -128,7 +170,7 @@
}
$email=$ENV{DEBEMAIL};
}
-execbrowser($btsurl.$email);
+ browse($email);
}
=item clone bug [new IDs]
@@ -314,6 +356,70 @@
mailbts(bug $bug is not forwarded, notforwarded $bug);
}
+=item cache [email address | package]
+
+Generate or update a cache of bug reports for the given email address
+or package. By default it downloads all bugs belonging to the email address
+in the DEBEMAIL environment variable. This command may be repeated to
+cache bugs belonging to several people or packages. The cached bugs are
+stored in ~/.bts_cache/
+
+Note that each update of the cache can be rather slow, as it currently
+downloads all bugs again. A better interface for programs is needed
+than the web pages..
+
+Once you have set up a cache, you can ask for it to be used with the -o
+switch. For example:
+
+ bts -o bugs
+ bts -o show 12345
+
+The BUGSOFFLINE variable can also be set to do the same thing.
+
+Also, once the cache is set up, bts will update the files in it peicemeil
+as it downloads information from the bts. You might thus set up the cache,
+and update the whole thing once a week, while letting the automatic cache
+updates update the bugs you frequently refer to during the week.
+
+=cut
+
+sub bts_cache {
+ my $tocache=shift;
+ if (! length $tocache) {
+ $tocache=$ENV{DEBEMAIL};
+ }
+ if (! length $tocache) {
+ die cache what?\n;
+ }
+
+ if (! -d $cachedir) {
+ mkdir($cachedir) || die mkdir $cachedir: $!;
+ }
+
+ my $cachefile=cachefile($tocache);
+
+ my @oldbugs = bugs_from_file($cachefile) if -e $cachefile;
+
+ # download index
+ my $data=download($tocache);
+ cache($tocache, $data);
+
+ my %bugs = map { $_ = 1 } bugs_from_file($cachefile);
+
+ # remove old bugs from cache
+ foreach my $bug (@oldbugs) {
+ if (! $bugs{$bug}) {
+ unlink cachefile($bug);
+ }
+ }
+
+ # download bugs
+ foreach my $bug (keys %bugs) {
+ cache($bug, download($bug));
+ }
+
+}
+
# Add any new commands here.
=item version
@@ -325,7 +431,7 @@
sub bts_version {
(my $progname = $0) =~ s%.*/%%;
print STDOUT $progname version
Re: bug reports
On May 30, Joey Hess ([EMAIL PROTECTED]) wrote: Neil Roeth wrote: Thanks for the hints. I should have been more clear - I have no problem getting the main page, i.e., [EMAIL PROTECTED] There are links in that page to bugs.debian.org/cgi-bin/bugreport.cgi?bug=num for each bug, and I want to get each of those as a local web page, too. That is the part that seems to require more than a simple wget command. You can use the following patch to the bts command from devscripts. After patching bts, run 'bts cache package' or 'bts cache email', then use bts -o when offline to view cached bugs. It also progressively caches any bugs you look at while online. Exactly what I wanted, and works like a charm. Thank you. -- Neil Roeth
