Bug 510765 won't appear as closed
Can someone help me understand why 510765 keeps on appearing on liferea's bug page? It's been closed in all the relevant versions, and the little graph on the left shows nothing but green boxes, but everything (the bts, the pts, my qa page) show liferea as having 1 open rc bug. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug 510765 won't appear as closed
On Thu, May 14, 2009 at 01:24:29PM -0700, Don Armstrong wrote: On Thu, 14 May 2009, Rodrigo Gallardo wrote: Can someone help me understand why 510765 keeps on appearing on liferea's bug page? Because it's not -done. Thanks, I get it now. Finally, if you don't know why it's not being fixed, feel free to ask here or in #debbugs on irc.debian.org; mucking with the found/fixed versions when the bug was actually found in that version generally isn't a good idea. So, what exactly is the use case for fixed? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Substituting the doc/package dir with a symlink
Policy 6.6.4 says that, when unpacking an upgraded package ... A directory will never be replaced by a symbolic link to a directory or vice versa; instead, the existing state (symlink or not) will be left alone and dpkg will follow the symlink if there is one. Which means that, when naively trying to replace the doc dir of a package with a symlink to my arch indep -data package I get bugs like #521047. Is the 'right' solution to that adding a postinst check that deletes a leftover empty dir and manually creates the symlink? Or will I get into a worse mess? What do I do if the dir is not empty (which could only happen if the dir was locally messed up with)? Do I just error out? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: A question about adopting a package
On Thu, Apr 24, 2008 at 11:25:11PM +0400, Stanislav Maslovski wrote: As I have never worked with the BTS control bot, I am asking for directions. Shall this mail sent from my own address to [EMAIL PROTECTED] suffice for setting an ITA? === 8 package wnpp retitle 465910 ITA: nec -- NEC2 Antenna Modelling System owner 465910 ! quit === 8 Yes, it would. You don't actually need the 'quit', but it hurts noone. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: Lintian: outdated-autotools-helper-file
On Sun, Feb 10, 2008 at 08:27:52PM +0100, David Paleino wrote: Hi *, I'm packaging gnome-translate (ITP #292909), and everything builds fine. A lintian check on the .changes file throws: E: gnome-translate source: outdated-autotools-helper-file config.guess 2003-07-02 What am I supposed to do? I believe that Build-Depending on autotools-dev | automake is not sufficient, as it seems that those files won't be updated anyways. Should I update them manually? This will introduce those changes in the .diff.gz outside the debian/ dir Build-Depend on autotools-dev, move the ofending files aside and put the new copy in thier place before running ./configure, copy the originals back at the end of clean. Autotools-dev's documentation contains an explanation for all this dance, and code snippets, IIRC. signature.asc Description: Digital signature
Re: RFS: gthumb (updated and adopted package)
On Fri, Dec 28, 2007 at 11:59:37PM +0100, David Paleino wrote: I am looking for a sponsor for the new version 3:2.10.7-1 of the package gthumb, which I'm adopting. The package is not lintian clean, it has 3 overrides: - gthumb: no-shlibs-control-file and package-name-doesnt-match-sonames(libgthumb is a private library and should not be used by any other program; libgthumb.so doesn't even have a proper SONAME and version number.) Don't override this, it *is* a bug in the package. The propper fix is to move the library into a private directory inside /usr/lib, say /usr/lib/gthumb -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
ITU: wmanager (update, adopt, fix bugs)
On Thu, Dec 20, 2007 at 05:11:35PM +0200, Peter Pentchev wrote: On Wed, Dec 19, 2007 at 07:04:25PM -0600, Luis Rodrigo Gallardo Cruz wrote: On Mon, Dec 17, 2007 at 02:02:06PM -0600, Luis Rodrigo Gallardo Cruz wrote: On Mon, Dec 17, 2007 at 06:44:23PM +0200, Peter Pentchev wrote: Dear mentors, I am looking for a sponsor for the new version 0.2.1-3 of the wmanager package; I am hereby attempting to adopt it, fix its two bugs, and bring it up-to-date with the Debian policy and the modern world in general :) I will review your package. You made quite a few changes, so it might take me several days. Ok, my (very few) comments: Done, see below for the updated package. However, there just might be a problem here - not with wmanager itself, but a more general problem. I pretty much copied those rules from the dpatch manual - the DPATCH IN DEBIAN PACKAGES section. The examples given there will not work with parallel make either. Should a bug against dpatch be filed to update the manual? Or should we wait until people come to at least some sort of agreement on the parallel make issue before filing any bugs and making changes? :) (yeah, I guess you can tell I've been following the parallel make discussion on debian-policy ;) Well, even if we decide not to support paralel builds at all, I see no reason to make them difficult on purpose, so I guess it's still a bug in dpatch to be suggesting this ;) 2. It would be nice to pass along at least the makefile patch upstream. Actually I intend to pass *all* the changes upstream ... On to your actual question - yes, if the upstream author turns out to be inactive, I do intend to take up maintainership of wmanager Cool. 3. Will you be wanting to keep debian/rules as is, or are you planning to migrate to some helper package? If the second, be aware that I'm not willing to sponsor cdbs based packages. I don't understand it and I'm not really willing to learn it. Thus, I'd politely recommend ;) you use debhelper. Well, I myself like debhelper very much, and both my local packages (most of which will never see the light of day for work-related reasons) and the timelimit package that I've RFS'd recently are all done using debhelper. With wmanager, the situation is somewhat weird - Tommi Virtanen actually used it in the past, but dropped it in version 0.2-4 seven years ago. We'll see - there's a very good chance that I will reintroduce debhelper at some point instead of doing things by hand (like the md5sums file creation). In this version, I just wanted to deviate as little as possible from Tommi Virtanen's work. That's good. And it's good you started small, too. Other than that, your package is very nicely updated, so as soon as you do the patching rules fixes, I can sponsor this version. Thanks a lot! :) I uploaded an updated version to mentors.debian.net - http://mentors.debian.net/debian/pool/main/w/wmanager/wmanager_0.2.1-3.dsc Got it. I'm currently building and testing a final time, and will upload it shortly. Feel free to contact me privately for further sponsoring for this package. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: How to get an issue resolved
On Sat, Dec 22, 2007 at 12:35:43PM +1100, David Schulberg wrote: Hi, I have an issue in that my Debian Linux browsers are unable to connect to our server via SSL through stunnel. Windows browsers, both IE and Firefox, connect fine. I read again your post to stunnel-users. Given that your problem seems to have more to do with the browser than with stunnel, it's not much of a surprise you got no answers there. You'll probably be better served by going to a mailing list related to the browser itself. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: RFS: dblatex (updated package): 2nd try
On Wed, Dec 19, 2007 at 10:12:03PM +0100, Andreas Hoenen wrote: I don't know if there's anything on mentors.d.o that stops you from doing this, but I'd personally say you don't need to bump versions before the package actually gets into the archive, so you could just stick with '-1' for a Debian version, so merging the changelog entries should do the trick. I rememer a thread on this mailing list starting with [1] that discussed the issue of reusing the same version number for different uploads to mentors.debian.net. Most participants agreed to use a new version number for each upload. I like this approach, as m.d.n. is public, thus somehow the upload to m.d.n already is a form of distribution. And it gets quite confusing if there exist different distributions with the same version number. What I did with the last times I was sponsored, and what I'll ask those I sponsor in the future, is to use ~n suffixes in the m.d.n uploads. Thus, if the desired debian upload is n.n-1, I'd recommend your mentors upload to be -1~1 Then, if there are modifications, work thru -1~2 ... When the final version for upload is reached, I'll merge the changelog entries and upload -1. That has the virtue of * Never releasing different versions under the same number. * Allowing *me* to easily compare and archive intermediate versions. * All mentors uploads have version numbers than debian uploads. This, of course, is not my idea. Someone in that thread proposed it and I liked it. In the end, as that thread concluded, all this is highly a matter of sponsor taste. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: ITR: wmanager (update, adopt, fix bugs)
On Mon, Dec 17, 2007 at 02:02:06PM -0600, Luis Rodrigo Gallardo Cruz wrote: On Mon, Dec 17, 2007 at 06:44:23PM +0200, Peter Pentchev wrote: Dear mentors, I am looking for a sponsor for the new version 0.2.1-3 of the wmanager package; I am hereby attempting to adopt it, fix its two bugs, and bring it up-to-date with the Debian policy and the modern world in general :) I will review your package. You made quite a few changes, so it might take me several days. Ok, my (very few) comments: 1. You have in debian/rules build: patch build-stamp build-stamp: debian/control $(MAN) and clean: clean-patched unpatch clean-patched: debian/control That's bad, because those rules might fail if the package is ever built with -j, since they don't enforce patching before building and cleaning before unpatching. Please change them to something like build: patch-stamp build-stamp build-stamp: debian/control patch-stamp $(MAN) and clean: debian/control [commands ...] $(MAKE) -f debian/rules unpatch 2. It would be nice to pass along at least the makefile patch upstream. Now, upstream does not seem to be very active. Is that because of lack of bugs, or a lack of upstream? If the second case is true, you will be having to act as _de facto_ upstream. Are you willing and able to do this? I'm not raising an objection here, I just want you to state it explicitely. 3. Will you be wanting to keep debian/rules as is, or are you planning to migrate to some helper package? If the second, be aware that I'm not willing to sponsor cdbs based packages. I don't understand it and I'm not really willing to learn it. Thus, I'd politely recommend ;) you use debhelper. Other than that, your package is very nicely updated, so as soon as you do the patching rules fixes, I can sponsor this version. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
ITR: wmanager (update, adopt, fix bugs)
On Mon, Dec 17, 2007 at 06:44:23PM +0200, Peter Pentchev wrote: Dear mentors, I am looking for a sponsor for the new version 0.2.1-3 of the wmanager package; I am hereby attempting to adopt it, fix its two bugs, and bring it up-to-date with the Debian policy and the modern world in general :) I will review your package. You made quite a few changes, so it might take me several days. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: ITR: blam 1.8.4-3
On Mon, Dec 10, 2007 at 07:29:39PM +0100, Carlos Martín Nieto wrote:
On lun, 2007-12-10 at 11:35 -0600, Luis Rodrigo Gallardo Cruz wrote:
On Mon, Dec 10, 2007 at 06:25:34PM +0100, Carlos Martín Nieto wrote:
On dom, 2007-12-09 at 16:52 -0600, Luis Rodrigo Gallardo Cruz wrote:
You can find it at http://www.cmartin.tk/blam/blam_1.8.4-3.dsc
I had a first look through the package. Several of the debian patches
look like they belong upstream. Since you're him ;) Is there a reason
they have not been included?
Indeed there is. Those patches were made after the 1.8.4 version was
released and there isn't going to be a 1.8.5 version (well, that was the
plan, I may yet release it) those patches end up in Debian. They are
upstream, just in a later version.
Ok, good enough.
Also, some changes from -2.1 to -3 are patches to upstream but are not
in a separate patch but included in the .diff.gz Please separate them.
I think the reason Makefile.{am,in} are patched directly is because the
patches are applied too late in the process and by then the Makefile has
already been created.
Mmm. cdbs at work.
Ok, if you can't get them to apply soon enough, it's ok to leave those
(but just those) directly in the .diff.gz.
A few more comments:
dpkg-shlibdeps complains about many unnecesary libraries linked to
libblam.so. It would be good if you could check upstream's build
systema and try to eliminate them, but this is not a show stopper and
can well wait for another release.
I get the following warning:
dh_clideps: Warning! No Build-Depends(-Indep) on cli-common-dev (= 0.4.4)!
dh_clideps: Warning: Could not resolve moduleref: libblam.so for: blam.exe!
dh_clideps: Warning: No Debian dependency data for Atom.NET
(0.4.3.27119__dfd513aadd65a3d3)!
I don't know enough about mono to know how serious these are, so
please either fix them or explain to me why it's not needed ;)
linda complains that:
E: blam; Uses cdbs and debhelper.mk, but debhelper Build-Depends is too old.
This package uses cdbs and includes debhelper.mk, but the version of
debhelper the package Build-Depends on is too old. To use
debhelper.mk you currently must Build-Depend on at least debhelper (=
4.1.0).
lintian complains that:
W: blam source: out-of-date-standards-version 3.7.2 (current is 3.7.3)
Please check if the new changes to policy apply to your package and
update Standard-versions accordingly.
W: blam: description-contains-homepage
Please move the Homepage from inside the description into its own
control field, which is now supported.
I: blam: desktop-entry-contains-encoding-key
/usr/share/applications/blam.desktop:3 Encoding
That's for your upstream ;) .desktop files should no longer include
the Encoding entry, it's now obligatory to encode them in utf8.
(BTW. Always use the lintian from unstable to check your packages.)
***
Otherwise, your package looks good. The only changes I will insist on
are the updating of standards-version and the explanation about the
dh_clideps warnings.
signature.asc
Description: Digital signature
Re: ITR: blam 1.8.4-3
On Tue, Dec 11, 2007 at 07:21:23PM +0100, Carlos Martín Nieto wrote: On mar, 2007-12-11 at 08:52 -0600, Luis Rodrigo Gallardo Cruz wrote: (BTW. Always use the lintian from unstable to check your packages.) I do. I've just updated lintian but it won't give me those errors even with -i. Do you use any other switches? -I (note upercase). The new package is at the same place as before. It shouldn't have any problems now. I'll check it tonight. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Uploaded: blam 1.8.4-3
On Tue, Dec 11, 2007 at 12:49:22PM -0600, Luis Rodrigo Gallardo Cruz wrote: The new package is at the same place as before. It shouldn't have any problems now. I'll check it tonight. Good work. I've uploaded the package. You should receive confirmations for the upload shortly. Please keep an eye on the build daemons and try to spot any problems ASAP. Feel free to contact me directly for future uploads of this package. signature.asc Description: Digital signature
Re: ITR: blam 1.8.4-3
On Mon, Dec 10, 2007 at 06:25:34PM +0100, Carlos Martín Nieto wrote: On dom, 2007-12-09 at 16:52 -0600, Luis Rodrigo Gallardo Cruz wrote: You can find it at http://www.cmartin.tk/blam/blam_1.8.4-3.dsc I will review your package for upload. It will take a little while, since you will be my first sponsoree. Please be patient. Thanks, I'll try to backport a few fixes from the dev version meanwhile. I had a first look through the package. Several of the debian patches look like they belong upstream. Since you're him ;) Is there a reason they have not been included? Also, some changes from -2.1 to -3 are patches to upstream but are not in a separate patch but included in the .diff.gz Please separate them. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
ITR: blam 1.8.4-3
On Sat, Dec 08, 2007 at 11:24:41PM +0100, Carlos Martín Nieto wrote: My usual sponsor (Amaya) is away for a while and so I've been orphaned :( ... Blam is a news feed reader written in C# which supports Atom and RSS. It is already in Debian but I need a new sponsor. You can find it at http://www.cmartin.tk/blam/blam_1.8.4-3.dsc I will review your package for upload. It will take a little while, since you will be my first sponsoree. Please be patient. signature.asc Description: Digital signature
Re: dpkg-shlibdeps: warning: symbol ... found in none of the libraries
On Thu, Dec 06, 2007 at 02:09:48PM +0100, Cesare Tirabassi wrote: On Thursday 06 December 2007 03:39:38 Luis Rodrigo Gallardo Cruz wrote: The new dpkg-shlibdeps is giving me tons of messages of the form dpkg-shlibdeps: warning: symbol ui_node_remove_node used by debian/liferea/usr/lib/liferea/libliscrlua.so found in none of the libraries I also noticed the same behaviour on sid. I think this bug report is covering it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454036 No, that's the oposite mistake. In the bug report, dpkg-shlibdeps thinks the .so has no need of another .so In my case, dpkg-shlibdeps knows my .so should be using some other, but doesn't know which. Or something like that. signature.asc Description: Digital signature
dpkg-shlibdeps: warning: symbol ... found in none of the libraries
The new dpkg-shlibdeps is giving me tons of messages of the form dpkg-shlibdeps: warning: symbol ui_node_remove_node used by debian/liferea/usr/lib/liferea/libliscrlua.so found in none of the libraries The .so in question is a plugin meant to be dlopened by the main program. The symbols reported all come from the main binary, and not from any other lib. From some other threads in -devel I understand that dpkg-shlibdeps would not be reporting these if my .so had no SONAME. The .so is being built *with* -avoid-version -module being passed to libtool, but libtool is seemingly ignoring that and passing -Wl,-soname -Wl,libliscrlua.so to the final linker line. Any suggestions? -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: alguien que me ayude
[English reply at the end] On Wed, Oct 31, 2007 at 01:48:02AM +0100, kingworld360 wrote: OLA si hay alguien que no le importe ayudar soi nuevo con este sistema operativo cuando sepa are programas y mantendre los paquetes Hola. Esta lista a la que escribiste se maneja en inglés y está dedicada a temas de desarrollo, no de uso general. Para información básica de uso del sistema, visita http://www.debian.org/ y las páginas de información ligadas desde ahí en la sección primeros pasos. Si tienes dudas en general respecto al uso, la lista [EMAIL PROTECTED] se encarga de esta clase de apoyo en español. Cuando estés listo para empezar a desarrollar [EMAIL PROTECTED] te podrá servir de apoyo. *** English (gist of a) translation ** Hi. The list you've written to is handled in English and is not dedicated to general use questions, but to developement ones. [Pointers to the website and to the spanis user and devel lists] -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: RFS: grun -- GTK based Run dialog [delayed-7 NMU]
Bas Wijnen [EMAIL PROTECTED] writes: On Mon, Oct 15, 2007 at 10:20:06AM -0500, Luis Rodrigo Gallardo Cruz wrote: Bas Wijnen [EMAIL PROTECTED] writes: Why do you need to #define this? Just because I dislike using magic constants. But looking at the rest of the code, I would just use the string literal directly. I agree with you that a define would be nicer, but it's not how the rest of the code is done, and NMUs should be in the style of the original as much as possible. Is it ok with you if I upload it with a string literal instead of a define? Yes, no problem. Thanks for the review. pgpso78dn5GEA.pgp Description: PGP signature
Re: RFS: grun -- GTK based Run dialog [delayed-7 NMU]
On Tue, Oct 16, 2007 at 04:02:28PM +0200, Bas Wijnen wrote: On Tue, Oct 16, 2007 at 07:52:33AM -0500, Luis Rodrigo Gallardo Cruz wrote: Bas Wijnen [EMAIL PROTECTED] writes: Is it ok with you if I upload it with a string literal instead of a define? Yes, no problem. Thanks for the review. One more thing, the package failed to build a second time, because the contents of the *gmo files were changed the first time. I solved this by moving their removal to the clean target (and updated debian/changelog). I suppose you don't have a problem with that? No. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: [Uploaded] Re: RFS: grun -- GTK based Run dialog [delayed-7 NMU]
On Tue, Oct 16, 2007 at 09:08:12PM +0200, Bas Wijnen wrote: Hi, I've uploaded the package with those changes to the 7-day delayed queue. Please let me know if there are any problems (I'll subscribe to the PTS, but I don't get the reply e-mails from the upload). Tks. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: RFS: grun -- GTK based Run dialog [delayed-7 NMU]
Bas Wijnen [EMAIL PROTECTED] writes: I have just one question about this part: @@ -40,6 +40,7 @@ #include grun2.xpm #if defined (HAVE_GETTEXT) || defined (HAVE_CATGETS) #include libintl.h +#define UTF8 UTF-8 #else #include intl/libintl.h #endif @@ -1107,6 +1108,7 @@ int PASCAL WinMain(HINSTANCE hInst, HINS #ifndef WIN32 setlocale (LC_ALL, ); bindtextdomain (PACKAGE, LOCALEDIR); + bind_textdomain_codeset (PACKAGE, UTF8); textdomain (PACKAGE); #endif /* WIN32 */ Why do you need to #define this? Just because I dislike using magic constants. When I started writing the patch I expected having to use it in more than one place. Then it turned out there was no need, but I didn't think to change it. Does it also work when intl/libintl.h is included? No idea :( pgpIhUWJwVWr7.pgp Description: PGP signature
RFS: grun -- GTK based Run dialog [delayed-7 NMU]
Dear mentors,
I am looking for a sponsor for a 7 days delayed NMU of package grun.
The upload would fix these bugs: 438704
This is a long standing (but recently reported, sadly) bug that has
just become grave, because with gtk 2.12 it now results on inmediate
segfaults when using grun. The package's maintainer has not
responded to the bug report at all since the original report a month
ago, nor since the severity upgrade, last friday.
The package is not lintian clean, because I have not changed anything
beyond what's neeeded to patch this bug.
The interdiff between 0.9.2-14 and 0.9.2-14.1 is a little larger than
the minimal patch, because the package's build system updates
config.{sub,guess} automatically on creating the source package.
The true patch can be found in the bug log, or by removing those two
files from the interdiff.
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/g/grun
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/g/grun/grun_0.9.2-14.1.dsc
It builds these binary packages:
grun - GTK based Run dialog
I would be glad if someone uploaded this package to the delayed-7
queue for me.
Thank you,
--
Rodrigo Gallardo
GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28
signature.asc
Description: Digital signature
Re: daemon stop and start during upgrade
On Thu, Sep 13, 2007 at 08:33:16AM +0200, Patrick Schoenfeld wrote: Felipe Sateler wrote: - Behave sensibly when invoked with 'start' and already running - Behave sensibly when invoked with 'stop' and not running So in the end I agree that would be sensible to exit with 0, if the process is not running, cause their might be different errors to occur when stopping (even though I never met one), but that it would make sense to describe this more clear in the policy. IIRC, lsb requires exiting with 0 in this case. signature.asc Description: Digital signature
Re: [RFS] stunnel4 (updated package, adoption, RFS repost)
On Mon, Aug 27, 2007 at 06:37:36AM +0530, Kapil Hari Paranjape wrote: Hello, On Sun, 26 Aug 2007, Luis Rodrigo Gallardo Cruz wrote: Should I upload with just the change from (1)? Yes. I agree with your reasoning. Ready. The new package at http://mentors.debian.net/debian/pool/main/s/stunnel4/stunnel4_4.20-4~2.dsc -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: [RFS] stunnel4 (updated package, adoption, RFS repost)
On Sat, Aug 25, 2007 at 11:11:05AM +0530, Kapil Hari Paranjape wrote: Hello, On Thu, 23 Aug 2007, Kapil Hari Paranjape wrote: Package looks fine. I'm currently updating my local pbuilder base and will upload when that is done. Unfortunately, I just realised that there are a few more changes that I think you should make! 1. I think it is better to use $(MAKE) -C src and $(MAKE) -C doc instead of the cd src; $(MAKE) and cd doc; $(MAKE) constructs. Done, but not uploaded yet. install -p -m 0644 tools/stunnel.conf-sample\ $(CURDIR)/debian/stunnel4/etc/stunnel/stunnel.conf # mv executables into /usr/bin, with propper names mv $(CURDIR)/debian/stunnel4/usr/sbin/stunnel \ $(CURDIR)/debian/stunnel4/usr/bin/stunnel4 mv $(CURDIR)/debian/stunnel4/usr/sbin/stunnel3 \ $(CURDIR)/debian/stunnel4/usr/bin/stunnel3 rmdir $(CURDIR)/debian/stunnel4/usr/sbin/ # Move docs into propper dir mv $(CURDIR)/debian/stunnel4/usr/share/doc/stunnel \ $(CURDIR)/debian/stunnel4/usr/share/doc/stunnel4 2. Since you use debhelper, I think it is better if you use debhelper's .install files to move/install files in the correct places (man dh_install). Sorry, I disagree here. The problem is I'm not only moving things around, I'm also renaming files and getting rid of empty dirs left behind. man dh_install explicitely states that dh_install cannot rename files or directories, it can only install them with the names they already have into wherever you want in the package build tree. Thus, if use dh_install for this, I'd still have to leave commands to rename, completely negating the point of using it, as I'd still have pretty much the same clutter in debian/rules *and* I'd split the handling of this files over several places. Should I upload with just the change from (1)? signature.asc Description: Digital signature
Skipping version numbers in adopted packages
So far, all discussion I've seen about whether to collapse changes made during sponsorship review into a single debian revision for upload have focused in the case of an initial package upload. Does anyone have any special arguments for doing it one way or another in the case of an upgrade? Thanks. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: [RFS] stunnel4 (updated package, adoption, RFS repost)
On Thu, Aug 16, 2007 at 08:03:04PM +0530, Kapil Hari Paranjape wrote: On Fri, 10 Aug 2007, Luis Rodrigo Gallardo Cruz wrote: I am looking for a sponsor for the new version 3:4.20-3 of my package stunnel4. I have some fixes/suggestions for you. Since this would be the first package that I would sponsor, I hope we can learn from each other! :) I have uploaded a new version with the suggested fixes. Following your sugestion I used 3:4.20-4~1 as version. If you consider it worthy of upload, please change it to -4. And please build with -v3:4.20-2 Thanks http://mentors.debian.net/debian/pool/main/s/stunnel4/stunnel4_4.20-4~1.dsc General remark: === Please go through the package completely *as if* I were the person who had done the packaging and you were the person performing the sponsor-ship. Experience says that the time of adoption is probably the time when the maximum effort is/can be put into cleaning up packaging issues. Thanks, that's a good idea. It actually prompted two more changes: * Remove empty /usr/sbin dir. * Avoid linking to libz.so. configure checks for an specific function from it, required by openssl. But, as stunnel itself does not use the library, the generated dependency in zlib1g was bogus and marked as such by the checklib report. http://rerun.lefant.net/checklib/index.html http://rerun.lefant.net/checklib/[EMAIL PROTECTED] Must fixes: == - The author of debian/StunnelConf-0.1.pl is not mentioned in the debian/copyright file. I have *not* checked all the files in your tree. Please check each file of the unpacked source and the debian/ directory to find relevant attributions. - Please fix the debian/copyright file. See http://lists.debian.org/debian-devel-announce/2003/12/msg7.html Specifically, one thing that *is* missing is the dates of the copyright assertion by the upstream author. Done. - Avoid patching tools/script.sh in your diff. Use quilt instead. Ups. That was a mistake, I intended to do that from the start. In fact your collab-maint repository should ideally only contain the debian/ directory. I've been playing with both kinds of repositories, with and without upstream sources, in my packages, but I'm not sure yet which workflow is easier. Do you have some description on pros/cons from others, to help decide? - linda complains about the empty directory /usr/share/lintian/overrides/ I am not sure what you are using overrides here for. I just think it's easier to have debian/rules try to install the overrides file always, instead of adding/removing the snippet whenever the file gets empty. Anyways, the directory creation *is* a mistake. Fixed. - This changelog entry is not clearly written. * Use less cmd line args to debhelper commands in debian/rules. An alternative may be * Rewrite dh_* invocations in debian/rules. Or * Shorten dh_* invocations in debian/rules. Done Optional fixes: == - IMHO the README.Debian file needs better organisation. Perhaps three or four sections. One Upgrading from stunnel to stunnel4, two Sample Stunnel configurator, three Howto create Tunnels, four Howto create SSL keys for stunnel. Done - debian/StunnelConf-0.1.pl could perhaps be placed in /usr/share/doc/stunnel4/contrib/ as it is not a document but contributed code. Done - The preferred debian/changelog entry format seems to be. New maintainer. Closes: #416955. rather than Adopt package (closes: #416955). Done - I (have learnt to) prefer changelog entries that clearly indicate which files were changed rather than those that just describe the effect of the changes. Done. Kind of. I think some of the entries were explicit enough already. Not sure aspects: === - I am not sure that the warnings in the doc/ directory are enough of a warning for those who have so far been using stunnel3. Since stunnel starts network tunnels through init.d or inetd someone could suffer quite a bit in the transition. We should think about this some more ... I don't think there's much problem. Any automatic tunnel the user had will continue to work, thanks to the wrapper compatibility script. No new automatic tunnels will be created, because that requires manual enabling. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
FSF old address in coyright statements
My upstream's copyright statements in source files contain the old FSF mailing address. I will contact them about this problem but, while they react should I a) Faithfully reproduce their copyright statement in the package's debian/copyright and give wrong information to users, or b) Use the current address, at the cost of not using upstream's licence statement verbatim. ? Thanks, -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
[RFS] stunnel4 (updated package, adoption, RFS repost)
Dear mentors, I am looking for a sponsor for the new version 3:4.20-3 of my package stunnel4. It builds these binary packages: stunnel- dummy upgrade package stunnel4 - Universal SSL tunnel for network daemons The package is lintian/linda clean. It is not piuparts clean because it does not remove logfiles on purge, but I don't really want to do that, as I consider it a data loss, and policy only has it as a should (section 1.8). The upload would fix these bugs: 382099, 416955, 419842, 432304 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/stunnel4 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/stunnel4/stunnel4_4.20-3.dsc This upload will deprecate the stunnel source package, which contains upstream's version 3. I will be glad if someone uploads this package for me. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: RFS: ntfs-3g (updated package)
On Wed, Aug 08, 2007 at 07:57:18PM +0200, Piotr O??arowski wrote: [Adam Cécile (Le_Vert), 08.08.2007] Could your remind me which packages have you sponsored ? for i in list of your source packages; do who-uploads $i|grep naoliv echo $i done But, where do we find this who-uploads? If it's in some debian machine, it's useless to us nonDDs. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: RFS: ntfs-3g (updated package)
On Wed, Aug 08, 2007 at 08:08:49PM +0200, Piotr O??arowski wrote: [Luis Rodrigo Gallardo Cruz, 08.08.2007] But, where do we find this who-uploads? If it's in some debian machine, it's useless to us nonDDs. $ apt-file search bin/who-uploads devscripts: usr/bin/who-uploads Duh. Sorry. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
[RFS] stunnel4 (updated package)
Dear mentors, I am looking for a sponsor for the new version 3:4.20-3 of my package stunnel4. It builds these binary packages: stunnel- dummy upgrade package stunnel4 - Universal SSL tunnel for network daemons The package is lintian/linda clean. It is not piuparts clean because it does not remove logfiles on purge. The upload would fix these bugs: 382099, 416955, 419842, 432304 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/stunnel4 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/stunnel4/stunnel4_4.20-3.dsc This upload will deprecate the old stunnel package, which used to contain version 3. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: Sponsor Checklist
On Tue, Jul 31, 2007 at 01:21:23PM -0400, Justin Pryzby wrote: On Tue, Jul 31, 2007 at 05:53:49PM +0100, Neil Williams wrote: On Mon, 30 Jul 2007 21:40:26 -0500 Manoj Srivastava [EMAIL PROTECTED] wrote: Hmm. Since the DD/sponsor is the one who creates the uploaded packages, they do not have to insis; they can just make it so. I hope DD's do the actual tend build/clean/rebuild/piuparts-run personally. I can never run piuparts - it just takes far too long over my crippled internet connection. Isn't there some way of getting piuparts to use the cached archives like pbuilder does? Perhaps apt-cacher? It uses /var/cache/apt-cacher/ though perhaps it could use .../apt/ I don't know if this would pull in things downloaded by apt and not -cacher.. I use that, and point *everything* at it, my sources.list, my pbuilder chroots, and piuparts. That way everything one thing downloads gets used by all others. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: [RFS] stunnel -- Universal SSL tunnel for network daemons
On Sat, Jul 28, 2007 at 08:55:01PM +0200, Christoph Haas wrote: On Thu, Jul 26, 2007 at 05:51:18PM -0500, Luis Rodrigo Gallardo Cruz wrote: I am looking for a sponsor for the new version 2:4.20-1 of the package stunnel, which I'm adpoting. The syntax in the debian/changelog is not correct to close the bugs automatically. E.g. (Closes: stunnel4#419842) is not quite correct. See http://www.debian.org/doc/debian-policy/footnotes.html#f17 I appologize, my mail was amazingly incomplete. I somehow assumed everyone knew the situation. Debian currently has a stunnel package, containing upstream's version 3, and stunnel4 with, clearly, version 4. Both used to have the same maintainer and were orphaned at the same time. I took the ITA on both. Now, having stunnel 3 is suboptimal, since that branch has not seen an upstream update in about 4 years. Thus I decided to transtition stunnel to version 4, and to turn stunnel4 into a dummy upgrade package. This upload is the first part of that transition. The bugs I marked as stunel4#nn are not bugs in stunnel, but bugs in stunnel4 which this upload contains fixes for. I know they will not be automatically closed, but I do not want them to, as they do not belong (yet) to this package. My intention is to, after the upload, clone all the bugs in stunnel4 and reassign the clones to the newly uploaded stunnel, then manually close those that this upload has fixed. Not a pretty solution, but I could come up with nothing better. The changelog entries are meant as documentation, so it will be known they were closed, and so that I remember which ones to close. This is a major update to the package, since I'm transitioning to version 4. Eventually I'll upload a new stunnel4, which will be a simple dummy upgrade package to pull in stunnel. I think it would be convenient if both packages were to be sponsored by the same person. So now you maintain an stunnel version 4 while there is an stunnel4 package. I don't understand the reasons yet. The expected next upload of stunnel4 will be an empty dummy package that pulls stunnel as a dependency. It will also mark all stunnel4 bugs as closed on that version. Would it be a better idea to ask *now* for stunnel4 removal and have stunnel provide the dummy stunnel4 binary? I think I'd have to bump the epoch on the stunnel version, to make sure all the depends/conflicts are sane. Also consider using debhelper version 5 (debian/compat and debian/control). Will do. Thanks for your review. signature.asc Description: Digital signature
Re: List of (un)sponsored packages on Mentors (approximate)
On Fri, Jul 27, 2007 at 03:03:22PM -0500, Raphael Geissert wrote: Can mark comments as 'advocating an upload' By the way, is there any way to make sure that the person marking a comment as 'advocating an upload' is really a DD Why this? If someone is a DD, and they advocate uploading a package, wouldn't it be easier if they did the upload? OTOH, some of us non-DDs sometimes work with potential packagers, helping them improve their work. If my advocacy of a package is going to be downgraded, I would not be so keen on helping them. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
[RFS] stunnel -- Universal SSL tunnel for network daemons
Dear mentors, I am looking for a sponsor for the new version 2:4.20-1 of the package stunnel, which I'm adpoting. It builds these binary packages: stunnel- Universal SSL tunnel for network daemons The package is lintian/linda/piuparts clean. The upload would fix these bugs: 382099, 416955 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/stunnel - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/stunnel/stunnel_4.20-1.dsc This is a major update to the package, since I'm transitioning to version 4. Eventually I'll upload a new stunnel4, which will be a simple dummy upgrade package to pull in stunnel. I think it would be convenient if both packages were to be sponsored by the same person. I would also appreciate your guidance as to the handling of the open bugs in this package and in stunnel4. My plan, right now, is to wait for the upload, then clone and reassign the open bugs in stunnel4 to stunnel, mark them all as found in the uploaded version, then manualy send -done messages for the ones this upload closes. After that, when I upload the new stunnel4 version, mark that as closing the original stunnel4 bugs. Kind regards, -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: RFS: python-plastex
On Mon, Jul 23, 2007 at 11:47:25PM +0200, Bernd Zeimetz wrote: * debian/docs: what about the documentation in Doc? You want to add it to the pacakge, if the license allows it. Please note that latex2html is in non-free. You may not use it or the results form it. But using latex to create pdfs/ps files is fine. of course, that's not a problem here, as plastex seems to be a nice replacement for latex2html - I just realized that. If so, is it mentioned in the description? I guess it ought to. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: dpatch or quilt? in maintainer guide
On Sun, Jul 22, 2007 at 05:59:20AM +0900, Osamu Aoki wrote: If someone makes checking on the archive how many packages build depends on dpatch and quit $ grep-dctrl -FBuild-Depends dpatch -sPackage /var/lib/apt/lists/ftp.mx.debian.org_debian_dists_unstable_main_source_Sources|wc -l 1461 $ grep-dctrl -FBuild-Depends quilt -sPackage /var/lib/apt/lists/ftp.mx.debian.org_debian_dists_unstable_main_source_Sources|wc -l 574 signature.asc Description: Digital signature
Re: Svn-buildpakcage ignoring some directories.
On Thu, Jul 19, 2007 at 06:27:10PM +0900, Charles Plessy wrote: Le Thu, Jul 19, 2007 at 10:07:28AM +0100, Jon Dowland a écrit : Why do you want the directory in the diff.gz? If you need it at build time, create it in the build rules. I just thought it was simpler if there were no build rule to create the directory. Actually, if I were investigating a bug in a package and found and empty debian/foo dir I'd get confused. Is it intentional? I think a build rule makes the intent clearer. -- Rodrigo Gallardo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How much free must a package be to be included in non-free (was: Re: CC by-SA 3.0 is DFSG-free?)
On Mon, Jul 02, 2007 at 10:43:05PM -0300, Rogério Brito wrote: Can anybody explain how packages go into non-free? I mean: how much free the package has to be to be considered to non-free and which issues are blocker that would forbid the package into entering non-free? A package can go into main if it complies with the DFSG[1]. If it doesn't, but the copyright holder allows redistribution, it can go into non-free. Thus, Netscape used to be there, before it was freed. But Sun's jvm wasn't, because Sun insisted you had to download it from their site. Apart from that, in certain cases, of which multimedia programs are a big part, the fact that the package infringes software patents whose holder is known to actively prosecute infringement is enough to completely forbid the package from being in Debian's archive at all, either in main, contrib or non-free. That's because carrying the package would be a liability for the project or for the mirror operators. [1] That's the short version. Read Policy 2.1, 2.2 for the full story. signature.asc Description: Digital signature
Merging packages
stunnel (which I'm adpoting) has two mutually incompatible major upstream versions, 3 and 4. Back when 4 was first released, the maintainer packaged it separately, as stunnel4, to avoid the major grief of forcing such an update on users. Since then, stunnel4 has grown a compatibility wrapper script and stunnel3 has been deprecated upstream, with no releases for several years. I would like to finally move the stunnel package over to upstream version 4 and remove the stunnel4 package but I have some doubts on how to proceed and would like some comments. 1. I'll be shipping the compatibility script as /usr/bin/stunnel3 and the main v4 binary as /usr/bin/stunnel4. I'll ship a /usr/bin/stunnel symlink pointing at the wrapper for now, and eventually (after lenny, for sure) change it to point at the v4 binary. 2. Ditto for manpages 3. I will turn the stunnel4 package into a dummy that just pulls the new stunnel. 4. stunnel v3 uses no configuration files, stunnel4 does and its package has them installed on /etc/stunnel4 and similarly named files and dirs. Since the surviving package is to be called stunnel, I think it would be correct for its config files to have no '4' suffix on their names. Nevertheles, I'd like stunnel4 users to have a painles migration, which means somehow grabbing their stunnel4 files and putting them in the new places. Is that a good idea? Should such migration logic be put in the dummy transitional package? Or maybe I should just live with funnily-named conf files for stunnel? Thanks, -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: request for sponsoring = RFS, intent to sponsor = ITS ?
On Sun, May 06, 2007 at 12:20:10PM +0200, Nico Golde wrote: If not, could ITS = intent to sponsor work? Would a 'review without ITS' be done by a simple reply to the RFS without a subject marking? signature.asc Description: Digital signature
Re: RFS: brightd
On Thu, Apr 26, 2007 at 02:55:35PM +0200, Evgeni Golov wrote: * Do not change file permissions in postinst, unless you do it with dpkg-statoverride. In this case, given that what you want are standard execute permissions for a binary, you just need to do it when packaging. Which is already happening, in the call to dh_fixperms. This will leave your postinst empty, so just remove it. Hm, could you explain that a bit more? I need the binary setuid-root, so $USER is able to write to /sys/class/backlight/ I previously used install -M 4755 in debian/rules, but this did not work, because I don't build as root : ( Oh, ok. Well, packages *need* to be built as root, precisely so that they can have any set of needed ownerships and permissions. You can use fakeroot to do the build. If, however, you really need to set the permissions in the postinst (say, if you were to have the binary setgid to a group without a static gid) you still need to take care, because the user might have changed the permissions and you don't want to override them. Take a look at the discussion and example in policy 10.9 and 10.9.1: http://www.debian.org/doc/debian-policy/ch-files.html#s10.9 -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: RFS: brightd
On Thu, Apr 26, 2007 at 08:46:09PM +0200, Evgeni Golov wrote: On Thu, 26 Apr 2007 12:38:49 -0500 Luis Rodrigo Gallardo Cruz wrote: Hm, could you explain that a bit more? I need the binary setuid-root, so $USER is able to write to /sys/class/backlight/ I previously used install -M 4755 in debian/rules, but this did not work, because I don't build as root : ( Oh, ok. Well, packages *need* to be built as root, precisely so that they can have any set of needed ownerships and permissions. You can use fakeroot to do the build. I _USE_ fakeroot. And after the install /usr/bin/brightd is 0755, because only root (and not fakeroot) can setuid - if this would not be like this, everyone could create suidroot binaries... Wrong. suid works under fakeroot (I actually ran it to check). What happened in your package is that dh_fixperms strips suid bits from files (see man dh_fixperms). Sorry for not noticing that before. (And yes, anyone can run fakeroot and create a binary that, under fakeroot, looks as if it had suid bits. Does not matter, since it doesn't really have them.) So can I just chmod in debian/rules and hope the package will be rebuild as root on the buildds? No, you *also* need to ensure dh_fixperms does not strip the bits away. Change the call to dh_fixperms -X usr/bin/brightd -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: RFS: brightd
On Wed, Apr 25, 2007 at 07:47:51PM +0200, Evgeni Golov wrote: On Tue, 17 Apr 2007 09:57:45 +0200 Evgeni Golov wrote: I am looking for a sponsor for my package brightd. IANADD, so I can't sponsor you. I can, however, offer you some comments: * Your watch file is wrong, the line should be http://pberndt.com/Programme/Linux/brightd/_download .*/brightd-(.*)\.tar\.bz2 and you should remove the rest of the commented examples. Given upstream's weird download site, I don't think there's a 'correct' way to do it, but at least this one will alert you to new versions, even if they can't be downloaded automatically. * You should not ship upstream's copy of the gpl (debian/docs) * Do not change file permissions in postinst, unless you do it with dpkg-statoverride. In this case, given that what you want are standard execute permissions for a binary, you just need to do it when packaging. Which is already happening, in the call to dh_fixperms. This will leave your postinst empty, so just remove it. * Many sponsors object to having commented out lines in debian/rules. Please be ready to remove them or have a convincing argument of why you won't. * Have you distributed this package publicly? If not, you should colapse the debian/changelog entries into a single one for the last version and revert the debian revision to -1. You should probably also remove final empty lines form all of your debian/* files. debian/changelog in particular has many. And there's a minor bug in the manpage. Line 26 says (spelled out to avoid encoding problems): ... n*1000 Acircumflexmus between ... I assume the Acircumflex has nothing to do there and is the result of an encoding error somewhere. That's an upstream bug, just inform them. I hope you find a sponsor for your package. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: RFS: MMS - My Media System
On Wed, Mar 14, 2007 at 12:51:17AM +0100, Ricardo Mones wrote: On Tue, 13 Mar 2007 12:58:15 +0100 Roman Müllenschläder [EMAIL PROTECTED] wrote: Am Sonntag, 11. März 2007 schrieb Ricardo Mones: and, also an informative hint about splitting the (large) arch-independent portion in mms-common in another package (mms-common-data fore example) which I think is a good idea in this case. Would you mind helping me a little to get the things splitted between mms-common and mms-common-data? ... use dh_install, install or mv to put the arch-independent files in the right place after building. Actually, in this case it is a little trickier. The package is doing a bit of dark make magic in order to build several -flavour packages. Hint for Roman: the mv calls would have to be added in the install-common target, at the end of it. Basically, move /usr/share/* to a debian/mms-common-data dir. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Re: packages for netcdf 3.6.2 (released today)
On Wed, Mar 07, 2007 at 02:51:06PM -0700, Warren Turkal wrote: * I'm not sure the BTS is smart enough to close #278739 that appears with a newline between it and closes:. (If I'm wrong, someone please correct me.) Done, but does anyone know if BTS is smart enough to handle this? No. devref 5.8.4: Technically speaking, the following Perl regular expression describes how bug closing changelogs are identified: /closes:\s*(?:bug)?\#\s*\d+(?:,\s*(?:bug)?\#\s*\d+)*/ig -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Re: new package splix
On Fri, Feb 16, 2007 at 09:41:50AM +0100, Thijs Kinkhorst wrote: On Thu, 2007-02-15 at 18:09 -0300, Carlos Pasqualini wrote: [ slightly confusing description ] I do not understand the situation with this package. You do claim to support some SPL printers, but the last sentence asks for people with a (any?) SPL-printer to implement it as soon as possible. Implement what? This description could be improved. Hi, Carlos. I assume from your name (and your .ar address) your native language is spanish. If so, and if that's causing trouble with writing the description, you could ask us over at debian-devel-spanish@lists.debian.org for help in getting it in english. signature.asc Description: Digital signature
Re: RFS: liferea 1.0.27-2 [Uploaded]
On Thu, Feb 15, 2007 at 06:44:58PM +1100, Matthew Palmer wrote: New, working, package at the same URL. I ended up removing the patch from the last update, as the poster wrote later saying it didn't solve the problems after all. Took us a while, but it's now sorted and I've just uploaded it. I've just received the confirmation mail. Thank you. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Re: RFS: liferea 1.0.27-2 [Upgrading problems]
On Sun, Feb 11, 2007 at 01:43:52PM +1100, Matthew Palmer wrote: On Fri, Feb 09, 2007 at 10:39:28PM -0600, Luis Rodrigo Gallardo Cruz wrote: [EMAIL PROTECTED]:/# apt-get dist-upgrade [...] The following packages have been kept back: liferea I've got a question on your transition decision, which I can't work out: you got rid of the liferea-gtkhtml package completely, but the liferea-mozilla package is a stub. Why not either get rid of liferea-mozilla or leave liferea-gtkhtml as a stub as well? After all, if liferea-gtkhtml is a stub package, then the upgrade works fine as liferea-xulrunner gets pulled in as expected. Yes, this was the way. I decided to leave liferea-gtkhtml as a stub, I'll work on finally removing it for lenny. New, working, package at the same URL. I ended up removing the patch from the last update, as the poster wrote later saying it didn't solve the problems after all. Thank you. signature.asc Description: Digital signature
Re: RFS: liferea 1.0.27-2 [Upgrading problems]
On Fri, Feb 09, 2007 at 05:08:36PM +1100, Matthew Palmer wrote: On Thu, Feb 08, 2007 at 01:33:54PM -0600, Luis Rodrigo Gallardo Cruz wrote: On Thu, Feb 08, 2007 at 06:37:28PM +1100, Matthew Palmer wrote: I suspect you need the third horseman of the package apocalypse, Replaces:, Nope, no good. Still doesn't work. ... ... I'm pretty sure that apt works based on URLs rather than names. The release names are used by the '-t' option to apt-get, and also in pinning, but I presume that there's no pinning rules that are relevant in your apt config? [Note: I updated the package to backport a patch from 1.2.5, which both a reporter and upstream agree should close #379900. Please, if you deem the package uploadable, do grab the new version first, from the same URL: http://www.nul-unu.com/quien/rodrigo/debian/liferea/liferea_1.0.27-2.dsc ] Not at all. I have no /etc/apt/preferences in the chroot. After adding the private repository and doing an apt-get update I get [EMAIL PROTECTED]:/# apt-cache policy liferea liferea: Installed: 1.0.27-1 Candidate: 1.0.27-2 Version table: 1.0.27-2 0 500 http://localhost unstable/main Packages *** 1.0.27-1 0 500 http://localhost unstable/main Packages 100 /var/lib/dpkg/status [EMAIL PROTECTED]:/# apt-get dist-upgrade Reading package lists... Done Building dependency tree... Done Calculating upgrade... Done The following NEW packages will be installed: libmozjs0d libnspr4-0d libnss3-0d libxt6 libxul-common libxul0d liferea-xulrunner The following packages have been kept back: liferea But [EMAIL PROTECTED]:/# aptitude dist-upgrade Reading package lists... Done Building dependency tree... Done Initializing package states... Done Building tag database... Done The following NEW packages will be automatically installed: libmozjs0d libnspr4-0d libnss3-0d libxt6 libxul-common libxul0d liferea-xulrunner The following packages will be automatically REMOVED: liferea-gtkhtml The following NEW packages will be installed: libmozjs0d libnspr4-0d libnss3-0d libxt6 libxul-common libxul0d liferea-xulrunner The following packages will be REMOVED: liferea-gtkhtml The following packages will be upgraded: libdb4.3 liferea (libdb4.3 gets upgraded because it's a two days old sid chroot :-) /me is lost. PD. BTW, the real-time thing would probably not work, we have a 17 hour time difference :-( -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Re: RFS: liferea 1.0.27-2 [Upgrading problems]
On Thu, Feb 08, 2007 at 06:37:28PM +1100, Matthew Palmer wrote: On Wed, Feb 07, 2007 at 10:22:41PM -0600, Luis Rodrigo Gallardo Cruz wrote: What happens is that liferea is held-back. I've tried adding or taking out a Provides: liferea-gtkhtml to the liferea package, with no results. I suspect you need the third horseman of the package apocalypse, Replaces:, Nope, no good. Still doesn't work. Actually, what happens at the dist-upgrade is that the *new* liferea-xulrunner get pulled, but liferea itself is held back at the old version and liferea-gtkhtml is not removed. Is there something wrong with calling your private's repository distribution 'unstable'? Does having two repositories called the same but with different contents confuse apt somehow? -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
RFS: liferea 1.0.27-2
My regular sponsor for this package has been busy lately. Could someone review and do a one time sponsoring of this? http://www.nul-unu.com/quien/rodrigo/debian/liferea/liferea_1.0.27-2.dsc I do have an issue I need help testing before upload. If I install etch/sid liferea + liferea-gtkhtml in a chroot, then add a sources line for my private repository with this new version, apt-get update, apt-get dist-upgrade the package does not upgrade cleanly. What I need to happen is that liferea-gtkhtml is removed and liferea-xulrunner_1.0.27-2, liferea_1.0.27-2 are installed. What happens is that liferea is held-back. I've tried adding or taking out a Provides: liferea-gtkhtml to the liferea package, with no results. $ apt-get install liferea works properly as I expect. So far, I have not been able to find out if this is a bug in my packaging, my private repository setup, my chroot, or what. Thanks. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Re: RFS: NMU for mrd6 package
On Tue, 30 Jan 2007 17:23:33 +0100 Laurent Bigonville [EMAIL PROTECTED] wrote: I've opened bug #394590 for about 100 days now and got no answer from the maintainer (Anand Kumria [EMAIL PROTECTED]). The maintainer is known to be MIA. I have sent him an email today to explain my intent to do a NMU. Upstream has already applied the patch in his svn. There is actually no patch system in this package so I applied the patch directly in the sources. Could someone review and upload it in the delayed queue? If you know the maintainer is MIA, maybe you should ask -qa to orphan his packages, then do a qa-upload of this, instead of an NMU. As it stands, given that your bug is of mormal priority, I don't think an NMU is warranted. FWIW, I did review the package and it would make a proper NMU, given that it is identical to the existing version plus an upstream-aproved patch. But I am not a DD, so I could not upload it for you. signature.asc Description: Digital signature
Re: Linda question: Maintainer script prerm uses debhelper, but does not use #DEBHELPER#.
On Sun, Jan 28, 2007 at 08:46:57PM +0100, Maximilian Wilhelm wrote: | $ linda -i *.dsc | W: conntrackd; Maintainer script postinst uses debhelper, but does not use #DEBHELPER#. I do not use any debhelper-magic in the scripts and do not understand what linda wants me to do. I could simply include '#DEBHELPER#' in the scripts but I do not want any debhelper magic to change the scripts. Why not? dh_installinit is called with --noscripts to accomplish this. That's OK. But *other* debhelpers might want to insert snippets into your maintainer scripts. Are you sure you don't and won't need any of them? In that case, you ought to call them all with --noscripts, to make it evident to everyone looking at your package. signature.asc Description: Digital signature
Re: RFS: ballview : new package version
On Thu, Jan 25, 2007 at 12:37:24AM +0100, Andreas Moll wrote: make: execvp: debian/debian-ball-install: Permission denied make: *** [clean] Error 127 Hi, I dont have any clue what went wrong with the permissions of this file since I have tested the package multiple times on several computers by calling dpkg-buildpackage -rfakeroot It never showed me an error like this before. I'd guess it's because the debian .diff does not preserve execute permissions in files. Maybe, if you want to keep using that file, you could chmod it in debian/rules *before* calling it. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
How to drop a package from some architectures?
Upstream's response to #361376 is to recommend the dropping of liferea-gtkhtml from 64bit arches. How does one go about that? -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Can liferea-gtkhtml be removed from etch?
[Summary for -release: Is removing liferea-gtkhtml too disruptive for etch?] On Tue, Jan 23, 2007 at 03:04:29PM -0800, Steve Langasek wrote: On Tue, Jan 23, 2007 at 04:36:20PM -0600, Luis Rodrigo Gallardo Cruz wrote: Upstream's response to #361376 is to recommend the dropping of liferea-gtkhtml from 64bit arches. How does one go about that? Change the Architecture: field for liferea-gtkhtml in debian/control to list the 32-bit archs, instead of any. But wouldn't it be fine to just drop this binary package on all archs? I seem to remember that liferea-gtkhtml has had other problems on all archs in the past, and that the -xulrunner variant was recommended? Yes, Lars has stated his intention to completely remove this rendering engine. To do so, I'd assume the right way to go would be to turn -gtkhtml into a dummy package that pulls -xulrunner in. In that case, the separate liferea-xulrunner package would be rather pointless, as liferea would just pull it inconditionally. Should both packages be just merged into one? Would *that* be too much of a change to get into etch? -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Re: RFS: Need help packaging MMS (My Media System) and get it into Debian
On Thu, Jan 11, 2007 at 09:27:27AM +0100, Roman Müllenschläder wrote: For over 3 years now I help out on a multimedia-project named MMS ... we realy would like to see it as part of debian, as we think it's stable, tested and well documented. I started packaging (with the help of the web and some maintainers of VDR) but am new to packaging at all ;) I am not a DD, but I can help you get your package in a good enough shape for you to request a sponsor. Please send the URL to your source package's .dsc file so I can have a look at it. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Zenophobia: the irrational fear of convergent sequences. signature.asc Description: Digital signature
Re: RFS: LiE computer algebra for Lie groups
On Tue, Dec 12, 2006 at 10:35:00PM +0100, Kasper Peeters wrote: Please post the complete URL to your .dsc file, it's easier for potential sponsors to grab it. http://www.aei.mpg.de/~peekas/debian/lie_2.2.2-1.dsc FWIW: Dear DD's, pending minor comments below, I believe this package is close to ready for sponsorhip. I have fixed all the remaining problems, except for: And, a final comment, please give some license statement concerning the packaging itself, in the copyright file. I have been unable to contact the authors so far, so it's probably best to keep things in non-free for the time being. Or did you mean a statement about my copyright? What's appropriate in this case? Yes, that's what I meant. Your work in packaging has a copyright and thus needs a license. Given upstream's licensing status I recommend you go for a permissive license, to avoid the possibility that upstream+packaging is undistributable. BSD should be OK. So, something like the following, right at the end of the copyright file: Packaging is Copyright 2006 - Kasper Peeters It can be distributed under the terms of the so and so license, available at /usr/share/licences/so-and-so in a Debian system. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Billboard billboard burning bright / in my windshield every night. Lead me to a decent joint / where I can stop and get a bite. signature.asc Description: Digital signature
Re: RFS: LiE computer algebra for Lie groups
On Tue, Dec 12, 2006 at 12:32:06AM +0100, Kasper Peeters wrote: Once you make these changes, repost your sponsor request. I have made all the changes you mentioned in your two previous emails. New files are at http://www.aei.mpg.de/~peekas/debian/ Please post the complete URL to your .dsc file, it's easier for potential sponsors to grab it. FWIW: Dear DD's, pending minor comments below, I believe this package is close to ready for sponsorhip. There's only one warning left when running lintian on the package: W: lie: description-synopsis-might-not-be-phrased-properly What am I supposed to do with this? Your description: lie- A computer algebra package for Lie group computations. Dev-ref says: It's a good idea to think of the synopsis as an appositive clause, not a full sentence. An appositive clause is defined in WordNet as a grammatical relation between a word and a noun phrase that follows, e.g., Rudolph the red-nosed reindeer. The appositive clause here is red-nosed reindeer. Since the synopsis is a clause, rather than a full sentence, we recommend that it neither start with a capital nor end with a full stop (period). It should also not begin with an article, either definite (the) or indefinite (a or an). It might help to imagine that the _synopsis_ is combined with the _package name_ in the following way: _package-name_ is a _synopsis_ So, I suggest something like lie - computer algebra package for Lie group computations note no 'A' and no final '.' When running lintian, do it over the .changes file, so it gets to check the source package too. That way, I also get: W: lie source: dh-make-template-in-source debian/manpage.1.ex which is a debhelper example file you missed. It's better if the manpage you wrote is put inside the debian dir. That way is clearer to anyone getting the source package it was added for debian. The information you give in the new README adds nothing to the package description and copyright. I suggest you simply ship no README. In any case, don't rename it in the source package to INSTALL, that's a gratuituous modification of the source package that only adds in size to the diff. Also: Your debian/dirs contains usr/sbin, which is unneeded, since you ship it empty. Take it out. Better yet, take the whole file out, as you do not need to ship any dir that's not created by your install. And, a final comment, please give some license statement concerning the packaging itself, in the copyright file. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Billboard billboard burning bright / in my windshield every night. Lead me to a decent joint / where I can stop and get a bite. signature.asc Description: Digital signature
Re: RFS: LiE computer algebra for Lie groups
On Thu, Dec 07, 2006 at 11:03:11PM +0100, Kasper Peeters wrote: We need to see your source package to comment. Please post an URL to the .dsc .dsc:http://www.aei.mpg.de/~peekas/lie_2.2.2-1.dsc .tar.gz: http://www.aei.mpg.de/~peekas/lie_2.2.2-1.tar.gz You should not be making a native package. Place upstream's tarball, renamed to lie_2.2.2.orig.tar.gz one directory above lie-2.2.2, so dpke-source will find it and create the proper kind of package. Don't ship CVS dirs. Remove debhelper example files from yout debian/ dir. README.Debian is debhelper template. Remove it if there's nothing to be said. debian/changelog: - Have you filed an ITP for this package? If not, do so. If you have, put the bug number in the changelog. debian/copyright: - Upstream has two available tarballs. Please document in copyright which one you're using (I believe it's http://young.sp2mi.univ-poitiers.fr/~marc/LiE/conLiE.tar.gz) debian/control: - I believe this package should be section: math - You need a long description for the package. - libc6-dev is build-essential, you do not need to depend on it. - debhelper (= 4.0.0) is over-specified. (= 4) is enough. - You missed a build-depends on bison. debian/rules: - Remove commented out lines I'll probably have further comment, as soon as my local mirror stops sulking and it lets me upgrade my pbuild chroot :-/ -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Billboard billboard burning bright / in my windshield every night. Lead me to a decent joint / where I can stop and get a bite. signature.asc Description: Digital signature
Re: RFS: LiE computer algebra for Lie groups
Ok. Further comment: debian/dirs is not needed, the build system creates the dirs anyways. You should ship manual.dvi in /usr/share/doc/lie Read about doc-base and register it there, too. Upstream's readme contains only compilation instructions. These are not needed in a debian package, and thus should not be shipped. The program uses less to show its internal help. You need to patch it so that it uses sensible-pager instead. If the program can launch an editor, it needs to be sensible-editor. (If the program's choice is configurable by the user, those two should be its defaults) Running lintian: $ lintian -iI /var/cache/pbuilder/result/lie_2.2.2-1_i386.changes E: lie_2.2.2-1_i386.changes: bad-section-in-changes-file lie_2.2.2-1.dsc contrib N: Refer to Policy Manual, section 2.4 for details. As I said before, I believe this should be section: math In case the license does not get sorted out, it would be in non-free/math W: lie source: out-of-date-standards-version 3.6.2 (current is 3.7.2) Update the standards version. There are no changes that affect this package, so no further action is needed. W: lie source: source-contains-CVS-dir CVS W: lie source: source-contains-CVS-dir box/CVS W: lie source: source-contains-CVS-dir util/CVS W: lie source: source-contains-CVS-dir static/CVS W: lie source: source-contains-CVS-dir progs/CVS W: lie source: source-contains-CVS-dir manual/CVS W: lie source: source-contains-CVS-dir gapfiles/CVS These dirs should not be shipped. They seem not to come from upstream's tarball, but from your own system. Use cvs export to create the dir from which you create the package. Better still, install and use the cvs-buildpackage package to manage the whole thing. W: lie: binary-without-manpage Lie.exe W: lie: binary-without-manpage lie N: N: Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games should N: have a manual page N: Please write manpages for these commands. You can write just one and symlink it under both names. Document the command line options, if they have them, or the lack of them. Mention the run time help. See the debhelper example for a template. W: lie: executable-not-elf-or-script ./usr/bin/lie This file should have #!/bin/sh as its first line W: lie: executable-not-elf-or-script ./usr/share/LiE/INFO.0 W: lie: executable-not-elf-or-script ./usr/share/LiE/INFO.ind W: lie: executable-not-elf-or-script ./usr/share/LiE/LEARN.ind W: lie: executable-not-elf-or-script ./usr/share/LiE/INFO.4 W: lie: executable-not-elf-or-script ./usr/share/LiE/INFO.3 W: lie: executable-not-elf-or-script ./usr/share/LiE/INFO.2 W: lie: executable-not-elf-or-script ./usr/share/LiE/INFO.1 These should probably not be executable. /usr/share/LiE should be renamed to /usr/share/lie The following files are not text: /usr/share/LiE/INFO.a /usr/share/LiE/INFO.ind /usr/share/LiE/LEARN.ind Please make sure they are architecture independent. If not, they need to be moved to /usr/lib. In that case, and seeing the way the program seems to use them, the whole /usr/share/LiE dir should move to /usr/lib --- Once you make these changes, repost your sponsor request. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 Billboard billboard burning bright / in my windshield every night. Lead me to a decent joint / where I can stop and get a bite. signature.asc Description: Digital signature
Re: RFS: harminv
On Mon, Nov 13, 2006 at 09:04:49PM +, Loic Le Guyader wrote: Ok, I fixed the manpage with a patch applied with dpatch. The update version is available on http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=harminv One minor nitpick: Your .diff.gz contains libharminv.postinst.debhelper libharminv.postrm.debhelper libharminv.substvars from the previous version, I guess. Please remove those. I've now checked the copyright file too, and it seems to be completely fine. Dear sponsors, I believe this package is ready for your revision and upload. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: RFS: harminv
On Sat, Nov 11, 2006 at 07:36:42PM +0100, Loïc Le Guyader wrote:
Dear mentors,
I am looking for a sponsor for my package harminv.
IANADD, so I can't sponsor, but I have reviewed your package and have
the following comments:
$ lintian -I
W: libharminv: non-dev-pkg-with-shlib-symlink usr/lib/libharminv.so.2.0.4
usr/lib/libharminv.so
You need to move the libharmin.so symlink to the -dev package, as it
is only used when developing with the library and not at runtime.
related to this:
$dpkg --contents /var/cache/pbuilder/result/libharminv_1.3.1-1_i386.deb
-rw-r--r-- root/root 479 2006-11-11 13:57 ./usr/lib/pkgconfig/harminv.pc
-rw-r--r-- root/root 1061 2006-11-11 13:57 ./usr/lib/libharminv.la
-rw-r--r-- root/root 21314 2006-11-11 13:57 ./usr/lib/libharminv.a
Those files belong in the -dev package, too. And, unless you know
there's specific reason, you should not even ship the .la and .a
files. The *pc file replaces the *la in a better way. The *.a file is
only needed for static linking, which is frowned upon.
W: libharminv: package-name-doesnt-match-sonames libharminv2
Your library package should be called libharminv2, so that different
versions of the library can coexist in the system.
For both messages, read extra explanations in
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
I: harminv: hyphen-used-as-minus-sign usr/share/man/man1/harminv.1.gz:57
I: harminv: hyphen-used-as-minus-sign usr/share/man/man1/harminv.1.gz:67
I: harminv: hyphen-used-as-minus-sign usr/share/man/man1/harminv.1.gz:69
I: harminv: hyphen-used-as-minus-sign usr/share/man/man1/harminv.1.gz:89
I: harminv: hyphen-used-as-minus-sign usr/share/man/man1/harminv.1.gz:180
Minor bugs: Run lintian with -i to get a detailed explanation. Submitt
this changes upstream, they're bugs there, too.
$ dpkg --info /var/cache/pbuilder/result/libharminv-dev_1.3.1-1_all.deb
[...]
Package: libharminv-dev
Version: 1.3.1-1
Section: libdevel
Priority: optional
Architecture: all
Depends: libharminv
I believe the -dev package should depend on libharminv (= ${Source:version})
I did no review of your debian/copyright file, so there might be
issues with it.
I wish you good luck in finding a sponsor.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Handling bugs
What does one do with an inactive unreproducible important bug? (#368546) Close it? After how long? Last mail from submitter was four months ago. No one else has ever seen it, either in Debian or in upstream mailing list. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: Overriding linda source package warnings
On Tue, Oct 10, 2006 at 03:05:21PM +0200, Bas Wijnen wrote: On Tue, Oct 10, 2006 at 03:36:41PM +0300, Damyan Ivanov wrote: The check is done on the source package - .orig.tar.gz+diff. The problem is in the .orig.tar.gz, so clean target has no chance to correct it. Yes, that's what I was trying to say. The warning talks about removing the files in the clean target. That suggests that doing so would make the warning go away. Because it is about the source package, this is not the case, so the wording of the warning is wrong. Ok. I'll file a bug agains linda asking to fix it's wording. lintian's wording is clear enough IMHO, I'll suggest they copy that one. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Overriding linda source package warnings
I'm getting the following linda error: linda -i ../result/keytouch_2.2.2-1_i386.changes E: keytouch; Package contains autoconf-generated files. The package contains the file shown above, which is generated by autoconf. This may confuse the buildd's, and should be removed by the clean target of the package. I know what causes it, and have corrected it, and have put an override for lintian[1]. But I haven't found a way to override this for linda. Files in /usr/share/linda/overrides seem to apply only to the binary package they're contained in, and this error is produced by the source package. Any hints? [1] I need to override because the error could only be *fixed* by repackaging the .orig.tar.gz, which I don't want to do for so little a thing, when the problem can be adequately worked around. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: RFS: drapes (updated)
On Wed, Sep 27, 2006 at 10:42:21AM +0200, Francesco Namuri wrote: On Mon, Sep 25, 2006 at 07:41:06PM +0100, James Westby wrote: On (25/09/06 01:48), Francesco Namuri wrote: On Sun, Sep 24, 2006 at 11:15:22PM +0100, James Westby wrote: If copyright has been asserted on the file then it must be mentioned in debian/rules, along with its distribution license. If there isn't one you should find out what it is and add it, or drop the file. hi, yesterday I have written to the author of the patch, this morning I have received an answer... in short, the author (Ralf Treinen [EMAIL PROTECTED]) says that: (quoting his words) You may use, modify, redistribute with or without modifications in any way you wish. and that it's not necessary to put information about the copyright of the patch in debian/copyright... So, probably the right thing is to put the copyright information and quote the author's mail in there. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: RFS: personalbackup
On Mon, Sep 25, 2006 at 10:32:29PM +0100, James Westby wrote: * You ship an empty /tmp/ in the deb, please drop this. Personalbackup depends on the existence of the /tmp folder...so is it ok to just assume that it is always there ? Other packages assume it is there I guess, but I have never seen one ship it. I think you will be safe to remove it, but the /var/run discussion on -devel recently highlights what it means to assume a directory will exist. /tmp is part of base-files, so you can safelly assume it exists. What you can't assume is any file there will exist for long. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Licence issues
I'm making a package for internal use, but want to get it right in case I decide to try to get it uploaded. Some of the upstream code has the license quoted at the end. That license IMHO makes the code not only non-free but actually not source-distributable. However, that code is unmaintained upstream and not used in the version i'm compiling. Should I repackage upstream's tarball to exclude it? The license: /* * * RADIUS -- Remote Authentication Dial In User Service * * COPYRIGHT (c) 1992, 1993, 1994, 1995, 1996 * THE REGENTS OF THE UNIVERSITY OF MICHIGAN AND MERIT NETWORK, INCORPORATED * ALL RIGHTS RESERVED * * PERMISSION IS GRANTED TO USE, COPY, CREATE DERIVATIVE WORKS AND REDISTRIBUTE * THIS SOFTWARE AND SUCH DERIVATIVE WORKS IN BINARY FORM ONLY FOR ANY PURPOSE, * SO LONG AS NO FEE IS CHARGED, AND SO LONG AS THE COPYRIGHT NOTICE ABOVE, THIS * GRANT OF PERMISSION, AND THE DISCLAIMER BELOW APPEAR IN ALL COPIES MADE; AND * SO LONG AS THE NAME OF THE UNIVERSITY OF MICHIGAN IS NOT USED IN ANY * ADVERTISING OR PUBLICITY PERTAINING TO THE USE OR DISTRIBUTION OF THIS * SOFTWARE WITHOUT SPECIFIC, WRITTEN PRIOR AUTHORIZATION. * * THIS SOFTWARE IS PROVIDED AS IS, WITHOUT REPRESENTATION FROM THE UNIVERSITY * OF MICHIGAN AS TO ITS FITNESS FOR ANY PURPOSE, AND WITHOUT WARRANTY BY THE * UNIVERSITY OF MICHIGAN OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING * WITHOUT LIMITATION THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR * A PARTICULAR PURPOSE. THE REGENTS OF THE UNIVERSITY OF MICHIGAN SHALL NOT BE * LIABLE FOR ANY DAMAGES, INCLUDING SPECIAL, INDIRECT, INCIDENTAL, OR * CONSEQUENTIAL DAMAGES, WITH RESPECT TO ANY CLAIM ARISING OUT OF OR IN * CONNECTION WITH THE USE OF THE SOFTWARE, EVEN IF IT HAS BEEN OR IS HEREAFTER * ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. * * For a License to distribute source code or to charge a fee for the program * or a product containing the program, contact MERIT at the University of * Michigan: * * [EMAIL PROTECTED] * * [This version puts NO LIMITS on the use. It grants the right to create * DERIVATIVE WORKS. The user may copy and distribute the code in the form * received AND DERIVATIVE WORKS, so long as no fee is charged. If copies are * made, our copyright notice and the disclaimer must be included on them. USE * THIS VERSION WITH CARE. THIS VERSION VERY LIKELY WILL KILL ANY POTENTIAL * FOR LATER COMMERCIALIZATION OF THE SOFTWARE.] -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: Re: RFS: personalbackup
On Thu, Sep 07, 2006 at 08:27:43PM +0200, kku wrote: You are programaticaly managing a configuration file in /etc. You should look into using ucf, that already handles this. I've had a look at ucf, but I do not think it fits my need (unless I have overlooked something). I have a template file /usr/share/doc/personalbackup/personalbackup.apache and the parameter webalias is being replaced in that template during postinst. Depending on the user's choose for apache/apache2 this file will be placed in '/etc/apache/conf.d/personalbackup' or '/etc/apache2/sites-enabled/personalbackup' Now to detect that the user did (not) change the conf file, I check the md5sum of the content of the appropriate conf file 'except' for the Alias line. And as far as I can see this is something ucf cannot handle...or am I wrong here? Uhh. From apt-cache show ucf ... This script attempts to provide conffile like handling for files that can not be labelled conffiles, are not shipped in a Debian package, but handled by the postinst instead. This script allows one to maintain files in /etc, preserving user changes and in general offering the same facilities while upgrading that dpkg normally provides for conffiles. ... -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: RFS: personalbackup
On Fri, Sep 08, 2006 at 10:01:47AM +1000, Matthew Palmer wrote: On Thu, Sep 07, 2006 at 05:26:53PM -0500, Luis Rodrigo Gallardo Cruz wrote: On Thu, Sep 07, 2006 at 08:27:43PM +0200, kku wrote: Now to detect that the user did (not) change the conf file, I check the md5sum of the content of the appropriate conf file 'except' for the Alias line. And as far as I can see this is something ucf cannot handle...or am I wrong here? Uhh. From apt-cache show ucf Luis, I think you missed a critical bit of what's being done with the config file -- the md5sum of only part of the config file is being checked, which (unless it's has had some *very* interesting features added lately) ucf can't do. Indeed. Must read more carefuly next time. Now, from a mentoring point of view, what should kku do? Create the file on first install acording to the user's answer, then consider the *resulting* file a conffile and treat it accordingly? -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: RFS: personalbackup
Dear mentors, I am looking for a sponsor for my package personalbackup. IANADD, so I can't sponsor. But my comments, anyways: You should not depend in postgresql, since that is just a transitional package. Depend on an specific version, or on several. In a related note, should you depend on postgresql at all? Does the server *need* to be on the same machine as personalbackup? Maybe you could just recommend: it or even suggest: it. You are programaticaly managing a configuration file in /etc. You should look into using ucf, that already handles this. Others might have more comments. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: piuparts and sarge
On Wed, Aug 02, 2006 at 06:40:23PM +0200, Thibaut Paumard wrote: I have split my package since the last upload. Therefore two of the packages I have to test are not known to apt-get, only one is. Therefore, piuparts won't do the upgrade test. Is there a way I can get it to do this test? (I can setup a small repository if necessary). Yep, that's the way. I used reprepro, but any way of creating it should work, then added the deb line to the chroot's /etc/apt/sources.list Use --keep-sources-list and a prebuilt base.tgz -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Is leaving files on purge a bug?
Upon completing a piuparts run I get 7m19.8s ERROR: Package purging left files on system: /etc/xml /usr/share/applications owned by: gnome-terminal-data, gnome-menus, desktop-file-utils, capplets-data /usr/share/applications/mimeinfo.cache /var/log/scrollkeeper.log None of those files or packages are mine. I have added those files as -i options and completed the run that way. The question is, should I file bugs against those packages? -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: binary-or-shlib-defines-rpath documentation
On Wed, Jul 12, 2006 at 09:58:25PM +0100, Neil Williams wrote: Charles Fry wrote: A package I am creating from scratch is giving me the lintian warning binary-or-shlib-defines-rpath. I've looked for this kind of answer before - it's not as simple as it appears. rpath arises from libraries in non-standard locations, either alone or when linked to a binary. I'd certainly like to know just what others have done to solve rpath issues. In my case (sawfish) I run configure then delete the -Wl--rpath,... stuff from where it appears in the Makefiles before running make. But this case is easy, because it's only put in one place (by rep-config) and I checked manually that everything still compiles/runs afterwards. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: binary-or-shlib-defines-rpath documentation
On Wed, Jul 12, 2006 at 05:05:36PM -0400, Charles Fry wrote: So, my questions are: Have I succesfully identified the currently accepted ways of fixing this warning? Depends. Does it actually fix the warning? Yes, but it also broke my binary, which can no longer find the needed library. Any suggestions? Is rpath okay in this case? The needed library is coming from /usr/lib/courier-authlib. In this case, I believe it is correct. rpath is bad when it points to a system dir such as /usr/lib. Is good when it points to an application private dir. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
Re: binary-or-shlib-defines-rpath documentation
On Wed, Jul 12, 2006 at 05:32:12PM -0400, Charles Fry wrote: So is the lintian test wrong? Should it only be checking for rpaths that aren't system directories? good question! -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
When to split a package?
Having recently taken over maintaining sawfish, I ran lintian -I on it and got I: sawfish: arch-dep-package-has-big-usr-share 4848kB 90% which refers me to http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-archindepdata ... However, if the size of the data is considerable, consider splitting it out into a separate, architecture-independent package (_all.deb) ... Now, I plainly see that in this case 'the size of the data' is 'considerable' and will work on splitting the package. But ... is there some sort of general guideline on when to do this? Creating more binary packages certainly has some sort of cost (The size of the packages file, at least). How do I estimate those costs? How do I estimate the savings gained from splitting? (number of archs) * (size of _all.deb)? -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
How to split a package?
I another thread I said: Having recently taken over maintaining sawfish, I ran lintian -I on it and got I: sawfish: arch-dep-package-has-big-usr-share 4848kB 90% and said also that I'll work on splitting that off. So ... do I just move /usr/share/* to the _all.deb package? Obviously not, since I must keep at least /usr/share/doc/sawfish, but what else do I move? /usr/share/locale/*/*.mo ? /usr/share/man ? /usr/share/info ? Tha arch-dependent package will Depend: on the arch-indep one, so having those files on the -indep would not cause trouble, but, still, it kind of feels wrong to separate them, even though they clearly are arch-indep files. And, another question, should the -indep package Depend: on the -dep one? Its files are, on the whole, useles without it, but I don't really understand if it's right to have such interdependency. Thanks. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
RFS sawfish
On Sun, Jun 18, 2006 at 07:07:10PM +1000, Aníbal Monsalve Salazar wrote: On Sun, Jun 18, 2006 at 12:46:37AM -0500, Luis Rodrigo Gallardo Cruz wrote: sawfish, a window manager implemented in lisp, has been orphaned by its previous maintainer (#373702) I would like to adopt it, I may help you with the upload. Let me know when you have a new debian package to review. I have completed a new version. It is available on http://www.nul-unu.com/quien/rodrigo/debian/sawfish I would appreciate everyone's comments. -- Rodrigo Gallardo GPG-Fingerprint: 7C81 E60C 442E 8FBC D975 2F49 0199 8318 ADC9 BC28 signature.asc Description: Digital signature
ITA and RFH for sawfish
sawfish, a window manager implemented in lisp, has been orphaned by its previous maintainer (#373702) I would like to adopt it, but I would require help and an sponsor. sawfish does not appear to be heavy on maintenance (upstream CVS shows 37 commits over the last year, there are 26 normal and 20 minor/wishlist bugs. And, of course, one RC bug (#368546), which the previous maintainer has issues with) The kind of help required would basically revolve around the proper handling of bugs. I'm not yet on NM, but taking care of this package would be a good way to get there, right? Thanks. -- Rodrigo Gallardo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: urw-garamond-no8
On Sun, Jun 18, 2006 at 09:09:04PM +0200, Florent Rougon wrote: Kevin Bube [EMAIL PROTECTED] wrote: Hi all, I uploaded a new package version to mentors.debian.net. The changelog file lists all changes done. I think I addressed all problems which still remained. http://mentors.debian.net/debian/pool/non-free/u/ is currently empty. Huh? mentors.debian.net just changed server/implementation/you-name-it. Users need to re-register and re-upload their packages. -- Rodrigo Gallardo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
