Re: Bug#397939: Lintian: outdated-autotools-helper-file
- to just make the
obvious corresponding change to configure and then get on with your
life. You can't realistically do that with e.g. compiled C object files,
which is one reason we treat them differently.
> Now reread the previous paragraph while thinking of Makefile.in instead
> of "normal build results". It is common practice to do exactly that:
> ship and use pre-built versions, or even ship them in the diff.gz (which
> then gets huge). Makefile.am is only present as source-file, but it
> isn't used at all during the build. Any changes the user makes will not
> be noticed by the build system.
But this simply isn't true across the board! Makefile.am changes are
only ignored if you use AM_MAINTAINER_MODE. One reason people do that is
that it produces more predictable build-dependencies that aren't
affected by timestamp skew. This was more of an issue before bug #105750
was fixed. Nowadays, while I think the jury is still out in some places
regarding AM_MAINTAINER_MODE, the case for it is much less compelling
than it used to be, and the Automake manual explicitly recommends
against it. If you don't use AM_MAINTAINER_MODE, then Makefile.am
changes are automatically noticed and taken into account. A
demonstration:
$ apt-get source man-db
[...]
dpkg-source: extracting man-db in man-db-2.5.1
dpkg-source: unpacking man-db_2.5.1.orig.tar.gz
dpkg-source: applying ./man-db_2.5.1-2.diff.gz
$ cd man-db-2.5.1/
$ touch configure.ac
$ debian/rules build
./configure --prefix=/usr --libexecdir=\${libdir} \
[...]
touch configure-stamp
dh_testdir
/usr/bin/make CFLAGS="-O2 -g -Wall" LDFLAGS="-g"
make[1]: Entering directory `/home/cjwatson/man-db-2.5.1'
cd . && /bin/bash /home/cjwatson/man-db-2.5.1/tools/missing --run
aclocal-1.10 -I m4 -I gnulib/m4
cd . && /bin/bash /home/cjwatson/man-db-2.5.1/tools/missing --run
automake-1.10 --foreign
cd . && /bin/bash /home/cjwatson/man-db-2.5.1/tools/missing --run autoconf
/bin/bash ./config.status --recheck
[...]
(The same goes for changing Makefile.am.)
Rather than incurring the pain of gratuitous full regeneration every
time, we just regenerate it when the user has changed something. Yes,
the user now gets to resolve any problems that might have been
pre-existing, but realistically either the Debian maintainer or the
upstream maintainer is probably going to run into those at some point
anyway.
I think we should recommend (but not require) that AM_MAINTAINER_MODE
not be used, and perhaps work to specify an optional debian/rules target
that regenerates the build system in an appropriate way. That seems to
provide the necessary benefits for users who need to change these files
without imposing an unacceptable burden on developers. I don't think
there's a good cause to go much further than that at this point.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#397939: Lintian: outdated-autotools-helper-file
On Sun, Feb 17, 2008 at 08:24:43PM +0100, Loïc Minier wrote: > Yes, I second Russ here and would like to add that it's very easy to > trigger the timestamp skews if you simply create a patch for > configure + configure.in/.ac as the files will be sorted as configure > first and then configure.in/.ac so that applying the patch causes > configure.in/.ac to be newer than configure... This isn't true if you just let the patch be applied by dpkg-source -x, since the timestamp-handling bug I mentioned earlier was fixed. It might be true if you use a less capable patching system. ;-) > Also, automake/autoconf/aclocal might be triggerred while e.g. some m4 > macros aren't installed on the buildd or the developer's system. Of > course these are usually shipped with the upstream tarballs, but are > often missing/incomplete. If that is the case then the end user is going to lose out anyway when trying to modify the package. I'm not arguing that such bugs shouldn't be fixed, merely that it's a mistake to turn them into showstoppers that could potentially block more urgent upload requirements. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: signed mails to control@ (was: How to set BTS tags nicely)
On Tue, Feb 12, 2008 at 03:05:25PM +0100, David Paleino wrote: > To be honest, last time I tried sending a signed mail to control@ was > something > like a year ago. Something may have changed since then, since I've just made a > "test mail" (see #455005). But I've also changed something: now I send my GPG > signature as "PGP/MIME", before I was sending it as "PGP/Inline". I bet that > control@ can't handle PGP/Inline signed messages. Please file a bug with an example; I'm sure I made this work when I originally fixed debbugs to handle PGP signatures years ago. If it's broken now then something has gone wrong since then. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: maintainer script factorization
On Fri, Feb 22, 2008 at 03:41:17PM -0500, Justin Pryzby wrote: > Colin watson wrote about a scenario where he apparently needed to do > this: > http://lists.debian.org/debian-devel/2006/12/msg00647.html Yes, if you need to use the contents of the package's files in the preinst then you need to do this sort of thing. Of course, that particular hack is only necessary for upgrades from pre-etch, thank goodness. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mail System Error - Returned Mail
On Tue, Jul 26, 2005 at 09:46:39PM +1000, Ben Finney wrote: > On 26-Jul-2005, Geert Stappers wrote: > > On Mon, Jul 25, 2005 at 05:33:57PM -0500, Stephanie da Silva wrote: > > > To send mail to me, you need to add [laundry] to the end of the > > > subject line (eg: Subject: Random message [laundry]). > > I translate that as: > >I have my head in the sand to protect me against spam E-mail. > > Hopefully it, like so many of the other automatic replies we've been > getting here, will also be translated as: > > I'm too thick to have my automatic reply software distinguish > incoming list mail from personal mail, so please remove me from > the list permanently. It's more likely a spam forging debian-mentors@lists.debian.org as its From: address. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Custom Debian Installer
On Mon, Jan 16, 2006 at 05:03:31PM -0500, Derek Wueppelmann wrote: > I've been trying to find out if there is a way to use the debian > installer to create a CD which can be used to install a preselected list > of packages onto different types of systems? Even just modifying the > installer so that it will automatically select a customized task (debian > dummy package) would be good. Yes; http://www.debian.org/releases/stable/i386/ch04s07.html.en should help you out here. Note the link to the commented preseed file example, and search for 'tasksel'. > Can someone point me in the right direction? I've been tyring to fumble > my way around the debian-installer source.. but it's a little confusing, > and I have a feeling running through the makefile to make sense of > things will take quite a while. If you mean the debian-installer source package, that's really just the d-i build system. For actual content you really need to know which package is responsible for the particular bit of the installation you're interested in, which can be something of a bootstrapping problem for those new to the code. Section 6 of the manual above can be helpful. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Q on fixed-in-experimental
On Thu, Apr 20, 2006 at 02:18:15AM +0200, Laszlo Boszormenyi wrote: > On Thu, 2006-04-20 at 00:14 +0100, Neil Williams wrote: > > When a bug is tagged "fixed-in-experimental", does that bug number still > > have to appear in debian/changelog for the next upload to unstable or > > will the BTS be updated when the package in experimental is replaced? > It has to appear in changelog. > > > I know how to filter the BTS to show bugs with these tags, just > > wondering if it's automated. > Can't be automated. An automatic system can't figure out if the fix is > still in the package or maybe dropped from the unstable upload due to > cause other problems. To clarify, it still has to appear in debian/changelog, but it doesn't have to be in the most recent version; leaving it in the version where you fixed the problem is good enough. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Man pages and UTF-8
aving gone > through 2/3 of the archive, I got 807 such pages so far. And every single > one displays lovely "ä" or similar instead. That's 9% of all mans with > non-ASCII characters in the corpus. These are bugs in the packages in question, and it would be straightforward for the maintainers to correct that even with current man-db just by using 'iconv -c' in debian/rules, if they'd actually tested those manual pages. I attempted to clarify that in the first half of the policy bug report above. The good news is that man-db 2.5.0 is coming along very well, and I may well have it complete before the initial policy amendment I proposed is accepted; that's fine and in that event I'll supersede it with another proposal and go straight to the transition plan which allows people to start using UTF-8 manual pages properly. I issued a pre-release version recently. It's probably best to check it out using bzr: http://www.chiark.greenend.org.uk/~cjwatson/bzr/man-db/trunk/ There's nothing left on my to-do list for 2.5.0 but to wait a decent length of time for translations and test it to death in the meantime. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Man pages and UTF-8
[Quotes reordered slightly to suit the flow of my reply from argument to constructive suggestion. :-)] On Mon, Sep 10, 2007 at 09:56:50PM +0200, Adam Borowski wrote: > On Mon, Sep 10, 2007 at 07:03:57PM +0100, Colin Watson wrote: > > On Wed, Aug 15, 2007 at 12:50:53AM +0200, Adam Borowski wrote: > > > (Colin, CC-ing you as I'm not sure if you're of aware of this long thread, > > > and both man-db and groff are your territory...) > > > > I wasn't aware of it, thanks. Sorry for my delay in responding. > > Woh, it's great to hear from you. I'm afraid I've been lazy too, you should > be shown ready patches instead of hearing "that's mostly working"... If you do work on patches, please make sure they're against current bzr; there have been a lot of changes since 2.4.4. > > > On Tue, Aug 14, 2007 at 05:25:27PM +0200, Nicolas François wrote: > > > > I proposed Colin to work on it during Debconf, but still had no time to > > > > do > > > > it. > > > > > > Could you tell us if anything was born? > > > > I think the best summary of the current status and planning is this > > policy proposal, on which I'd very much appreciate further comments, > > since people involved in this thread seem to have a good grip on the > > issues: > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440420 > > I would object quite strongly to that solution, for two reasons: > > 1. it leaves us with ugly manpage names until the heat death of the universe I don't think it's ugly at all. In fact I think it's more elegant to have the encoding specified explicitly. As somebody pointed out on debian-policy, what happens if we decide in ten years' time that UTF-8 wasn't such a great idea after all? The FHS says: Countries for which there is a well-accepted standard character code set may omit the field, but it is strongly recommended that it be included, especially for countries with several competing standards. Now, the FHS' recommendation to flatten character set names in directories to lowercase, remove punctuation, and remove "ISO" is obviously not based on real implementation experience (what's the use of a character set in a directory name if not to pass it to iconv? why not just use the canonical character set name?) and I've never proposed we do that - I proposed changing this text a while back, and I have an ancient thread in my inbox that I've been meaning to reply to with a proper diff. However, the strong recommendation above is absolutely on target. I think it's still quite clear that ISO-8859-1 and UTF-8 are competing standards even though UTF-8 is clearly winning, and this seems like just the kind of thing that the FHS had in mind. > 2. it's not compatible with the .rpm world, so every single manpage that >sneaks through without being changed will be misencoded This, on the other hand, I have some sympathy for (though I don't regard it as an overriding requirement). See below. > > I do need to find the stomach to look at upgrading groff again, but it's > > not *necessary* (or indeed sufficient) for this. The most important bit > > to start with is really the changes to man-db. > > We do need to change them both at once. No, we don't. Seriously, I understand the problem and it's not necessary. man-db can stick iconv pipes in wherever it likes and it's all fine. When we upgrade groff at some future point we can just declare versioned dependencies or conflicts as necessary, but it is *not* necessary for this transition. A basic rule of release management is that the more you decouple the easier it will be. > > The downside to not upgrading groff, as you note, is that you'll only be > > able to actually use those codepoints which appear in the legacy > > character set corresponding to the language you're using (e.g. German > > manual pages will only be able to use Unicode codepoints that are > > convertible to ISO-8859-1). This is annoying and I fully agree that it's > > a bug, but it's not urgent, and I want to get over the first phase of > > the transition before worrying about that. > > The meat of Red Hat changes to groff is: > > ISO-8859-1/"nippon" -> LC_CTYPE > > and then man-db converts everything into the current locale charset. (Point of information: Red Hat doesn't use man-db.) Thus what you're saying seems to be that Red Hat uses the ascii8 device, or its equivalent (ascii8 passes through any 8-bit encoding untouched, although certain characters are still reserved for internal use by groff which is why it doesn't help with UTF-8).
Re: Man pages and UTF-8
On Wed, Sep 12, 2007 at 02:25:26AM +0200, Adam Borowski wrote: > On Tue, Sep 11, 2007 at 09:55:44AM +0100, Colin Watson wrote: > > > > I do need to find the stomach to look at upgrading groff again, but it's > > > > not *necessary* (or indeed sufficient) for this. The most important bit > > > > to start with is really the changes to man-db. > > > > > > We do need to change them both at once. > > > > No, we don't. Seriously, I understand the problem and it's not > > necessary. man-db can stick iconv pipes in wherever it likes and it's > > all fine. When we upgrade groff at some future point we can just declare > > versioned dependencies or conflicts as necessary, but it is *not* > > necessary for this transition. A basic rule of release management is > > that the more you decouple the easier it will be. > > Yet if groff cannot accept any encoding other than ISO-8859-1 with hacks for > ja/ko/zh, you end with data loss for anything not representable in 8859-1. Right, but that's the current situation anyway. I'm not saying that we don't want to fix this eventually, just that it's easier to do it by baby steps. > > > The meat of Red Hat changes to groff is: > > > > > > ISO-8859-1/"nippon" -> LC_CTYPE > > > > > > and then man-db converts everything into the current locale charset. > > > > (Point of information: Red Hat doesn't use man-db.) > > I didn't look that far, I didn't bother with installing a whole Red Hat > system, just did: > > ./test-groff -man -Tutf8 > which seems to work perfectly. After extending the upper range from u > to u10 it works like: http://angband.pl/deb/man/test.png OK, I hope whatever patches they have used to make UTF-8 input work correctly have gone upstream or are from upstream; I can only go on what upstream have told me. They may just be relying on preconv, which is fair enough. > > Obviously we have to cope with what we've got, so ascii8 is a necessary > > evil, but it is just plain wrong to use it when we don't have to. > > So let's skip it? We're using it right now. I want to transition away from it, but I want to do that in a separate step. > > > My own tree instead hardcodes it to UTF-8 under the hood; now it seems > > > to me that it would probably be best to allow groff1.9-ish "-K > > > charset", so man-db would be able to say "-K utf-8" while other users > > > of groff would be unaffected (unlike Red Hat). > > > > None of this is immediately necessary. Leave groff alone for the moment > > and the problem is simpler. iconv pipes are good enough for the time > > being. When we do something better, it will be a proper upgrade of groff > > converging on real UTF-8 input with proper knowledge of typographical > > meanings of glyphs (as upstream are working on), not this badly-designed > > hodgepodge. > > Isn't reading input into a string of Unicode codepoints good enough for now? > It's a whole world better than operating on opaque binary strings (ascii8), > and works well where RTL or combining chars support is not needed. And it makes complete sense to do so *eventually*. I just don't want to do it at the same time as everything else because debugging intermediate problems will be horribly confusing, that's all. I think the disconnect throughout this thread is that you're talking about the desired final state whereas I'm just focusing on making this one initial step work properly so that future steps can be done without requiring significant coordination from other packages. These two things don't have to be in conflict. Let me get this one step sorted out and it will be easier to get to your desired final state from there. > > > So you would leave that 822 manpages broken. > > > > If the alternative is breaking the 10522 pages listed in your analysis > > that are ISO-8859-* but not declared as such in their directory name, > > absolutely! > > Yeah, breaking those 10522 pages would be outright wrong. But with a bit of > temporary ugliness in the pipeline we can have both the 10522 ones in legacy > charsets and the 822 prematurely transitioned working. That would indeed be ideal. > > > My pipeline is a hack, but it transparently supports every manpage except > > > the several broken ones. If we could have UTF-8 man in the policy, we > > > would > > > also get a guarantee that no false positive appears in the future. > > > > So, last night I was thinking about this, and wanted to propose a > > compromise wh
Re: Man pages and UTF-8
On Fri, Sep 14, 2007 at 10:39:10AM +0100, Colin Watson wrote:
> On Wed, Sep 12, 2007 at 02:25:26AM +0200, Adam Borowski wrote:
> > On Tue, Sep 11, 2007 at 09:55:44AM +0100, Colin Watson wrote:
> > > Is this what your "hack" pipeline implements? If so, I'd love to see it;
> > > if not, I'm happy to implement it.
> >
> > The prototype is:
> > pipeline_command_args (p, "perl", "-CO", "-e",
> > "use Encode;"
> > "undef $/;"
> > "$_=;"
> > "eval{print
> > decode('utf-8',$_,1)};"
> > "print decode($ARGV[0],$_) if
> > $@",
> > page_encoding,
> > NULL);
> > so it's similar. "Slurp everything into core" in C is a page of code, your
> > idea of a static buffer makes it simpler; and I'm not in a position to
> > complain that it's another hack :p
>
> Current man-db makes the buffering pretty trivial:
>
> const char *buf = pipeline_peek (p, 65536);
>
> I'll try to implement something like this in C, then.
I've now done this. The code is in bzr here and fully integrated into
all the man-db programs that care about encodings:
http://www.chiark.greenend.org.uk/~cjwatson/bzr/man-db/trunk/
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: communication, friendlyness, DDs (Re: Ubuntu-to-Debian packaging)
On Wed, Dec 05, 2007 at 09:11:00AM +0100, Patrick Schoenfeld wrote: > On Wed, Dec 05, 2007 at 01:46:49AM +0100, Ondrej Certik wrote: > > > > > Really, it may have sounded more rude to you, then it was meant to be. > > > > > > > > But I was really annoyed by such a statement, > > > > > > > > That rather implies you were unfriendly, at least I'm often (too) > > > > unfriendly, > > > > > > Misusing "then" and "than" can cause confusion. If it is read as "... than > > > it was meant to be." it takes on an entirely different meaning. :-) > > > > Good point, I read the wrong meaning too. > > yes, after all I see that I was making a mistake here. Off course the > really meant word was "than", so the sentence should read: > > "Really, it may have sounded more rude to you, than it was meant to be." And, to nitpick further, you also ought to leave out the comma before "than". (With "then", the comma is correct.) Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu-to-Debian packaging
On Wed, Dec 05, 2007 at 01:42:56PM +0100, Cesare Tirabassi wrote: > On Wednesday 05 December 2007 04:27:28 C.J. Adams-Collier wrote: > > Do you feel that it is appropriate to copy someone else's changelog > > entry verbatim without giving credit to the original author? > > I guess you refer to mono-addins, for which I prepared an SRU in Ubuntu, > using > the patches provided by Mirco? > Yes, I partly used his changelog because, quite frankly, what was the point > of > changing it? Its the author's changelog and for him it reflected best the > content of the change, beside it ties with the history of the package. For > those not familiar with our SRU, we apply the changes in the development > version (in this case from the new Debian version) to solve a problem in our > stable release. If you look at the bug report this should be clearer to you: > > https://bugs.launchpad.net/ubuntu/+source/mono-addins/+bug/149485 > > In summary, I made the (evidently wrong) assumption that it was clear that > this was a backport of an issue already fixed in Debian. > So, in retrospect, yes, it would have been clearer to quote the source in the > changelog, something that I won't forget in the future. I've now adjusted the Ubuntu stable release updates documentation to explicitly say: As with any upload, the changelog entry must properly credit the author of the change, if it was not originally made by you. I hope this will avoid such mistakes in the future. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: just beginning
On Sun, Dec 09, 2007 at 09:04:02AM -0800, Tom Hutton wrote: > hello all. i am just beginning to get into linux. i am not sure that > this is the right list for me...it seems that a lot of the discussion > here is fairly advanced. i have an old pentium II machine that i want > to install debian on, and maybe in the spring og '08 i'll buy a bare > bones machine and try that out. is this a list where i can get help > with really basic stufflike how to install my first linux OS? if > this isn't the right list, can someone direct me to a list that is > more appropriate for my level of expertise... This is a list for people starting out on the path to becoming Debian developers. You're probably looking for the debian-user list. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#735565: RFS: couriergrey/0.3.2-5
On Thu, Jan 16, 2014 at 04:52:40PM +0100, Marco Balmer wrote: > On Thu, Jan 16, 2014 at 03:48:41PM +0000, Colin Watson wrote: > > The package on mentors.d.n has an .orig.tar.bz2, but the version > > currently in the Debian archive has an .orig.tar.gz. Was this change > > intentional? (I noticed because dpkg-buildpackage complains about both > > of them being present in the parent directory.) > > No. It's because I used another git archive command. :) If it is significant > I re-upload a version with orig.tar.gz. Let me know. Thanks a lot. In that case no need for you to re-upload; I can just remove the .orig.tar.bz2 locally and rebuild the source package from the same working tree against the existing .orig.tar.gz. Is that OK with you? -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140116160349.gn8...@riva.ucam.org
Bug#735565: RFS: couriergrey/0.3.2-5
On Thu, Jan 16, 2014 at 03:45:45PM +, Colin Watson wrote: > On Thu, Jan 16, 2014 at 04:30:52PM +0100, Marco Balmer wrote: > > For your information: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735565 > > Sorry for the delay. I'm building it now. I think it's fine to upload > the watch file as it is since you say the problem there is with the > remote site. The package on mentors.d.n has an .orig.tar.bz2, but the version currently in the Debian archive has an .orig.tar.gz. Was this change intentional? (I noticed because dpkg-buildpackage complains about both of them being present in the parent directory.) -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140116154841.ga30...@riva.ucam.org
Re: moving packages from non-free to main
On Thu, Jul 17, 2003 at 06:35:40PM +0200, Ludovic Drolez wrote: > A license change in kanjidic and edict packages will allow > them to move to main. Also, xjdic which is in contrib will > also move to main (and maybe other packages depending on > edict and kanjidic). > > I've uploaded the new edict package yesterday, and I received > a message saying that 'edict is new' but 'is present in non-free'. > > So do I have to do something special ? Or only have to wait for > someone which will handle this manually ? You don't need to do anything special. Moves between sections are treated as new packages, meaning that an ftpmaster needs to look at them before they're accepted. Just wait. -- Colin Watson [EMAIL PROTECTED]
Re: Sponsor for spamass-milter
On Mon, Jul 21, 2003 at 08:17:34PM -0400, Stephen Gran wrote: > Also, you'll need to build a new package with -1 as the Debian revision, > so that it will be processed normally. If you've already been developing the package, it makes more sense to use the appropriate flags to dpkg-buildpackage (namely -sa, and possibly -v if you want to excerpt more of the changelog) than it does to have to mess about with version numbering just for the benefit of an upload. Those flags are provided for exactly this purpose. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: How to forward a bug to upstream when I'm not the maintainer?
On Tue, Jul 22, 2003 at 11:32:09AM +0200, Frank K?ster wrote: > in the last days, I have taken a look at some bugs in a package I > frequently use, tetex-base. Some of them should clearly be fixed in > upstream. > > How should I indicate this and inform upstream? I assume that anybody > who is not the maintainer (not even a DD in my case) is not allowed to > do officially tag it "upstream" and send the mail to [EMAIL PROTECTED] I would suggest asking the maintainers what they prefer. As far as I know Debian's tetex maintainers are active, just busy. -- Colin Watson [EMAIL PROTECTED]
Re: lintian W: sharedobject-in-library-directory-not-actually-a-shlib
On Thu, Jul 24, 2003 at 08:26:14PM +0200, Marc Haber wrote: > for one of my packages, later lintian versions emit a Warning saying: > W: snoopy: sharedobject-in-library-directory-not-actually-a-shlib > lib/snoopy.so That suggests that it's not a shared library *at all*, even discounting versions and so on. What do 'file' and 'objdump -p' say about that file? -- Colin Watson [EMAIL PROTECTED]
Re: What to do with RC-bug against long ago removed package?
On Fri, Jul 25, 2003 at 12:49:55AM +0200, Andreas Barth wrote: > there is a RC-bug against xserver-rage128; this package is neither in > stable, testing nor unstable. So, what to do with this bug? > http://bugs.debian.org/163631 I think it should be closed. See bug #120460. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: lintian W: sharedobject-in-library-directory-not-actually-a-shlib
On Fri, Jul 25, 2003 at 07:07:01PM +0200, Matthias Urlichs wrote: > My personal preference is to add a Lintian override, and leave it at > that. But the error says that it isn't a shared library at all, which is equally applicable to LD_PRELOADed libraries. The right approach is to find out *why* that error's being thrown. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Build-Recommends?
On Mon, Jul 28, 2003 at 08:14:03AM -0400, David Roundy wrote: > Is there such a thing as a Build-Recommends? Or a workaround that would > give you its equivalent? > > The problem is that darcs can be compiled either with or without > libcurl2-dev. The configure script will nicely notice if libcurl isn't > available, in which case it just uses an external program (either wget or > curl) if one is available. So I'd like to remove the Build-Depends, so I > won't have to use a modified control file for woody, and yet can get by > without backporting libcurl2. Is there a solution for this? No, Build-Depends are primarily there to make sure the build daemons do something consistent for unstable, so they should force your package to always build one way. Just ignore the build-deps for woody instead. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: RFS: vimoutliner
On Mon, Jul 28, 2003 at 11:20:29PM +0200, Matej Cepl wrote: > I have created a package for vimoutliner. Is there anybody who would > like to sponsor me? [...] > All relevant files are on > ftp://ftp.ceplovi.cz/data/www/ceplovi/matej/progs/debian/ I'd be happy to, but: $ lftp ftp://ftp.ceplovi.cz/data/www/ceplovi/matej/progs/debian/ cd: Access failed: 550 /data/www/ceplovi/matej/progs/debian: No such file or directory Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Sponsor for popfile
On Wed, Jul 30, 2003 at 08:20:15PM +1000, An?bal Monsalve Salazar wrote: > On Wed, Jul 30, 2003 at 04:14 -0300, Lucas Wall wrote: > > Will the bug tracking system parse the whole file or just the changes > > list for the latest version? > > You shouldn't change the log of the previous versions anyway. A 'closes > #nn' in the changes list of a previous version won't be considered. ... unless you use the -v option to dpkg-buildpackage, which is often useful anyway on an initial upload. -- Colin Watson [EMAIL PROTECTED]
Re: control mailserver and PGP/MIME?
On Thu, Jul 31, 2003 at 10:28:17AM -0400, John Belmonte wrote: > I'm wondering if the control mailserver can tolerate a PGP/MIME message. > The case is when you want to combine control commands and a bug > follow-up, and have your message signed. Yes, it can. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: changelog in utf-8 conflicts with maintainer in control
On Fri, Aug 01, 2003 at 01:14:33PM +0200, Celso Gonz?lez wrote: > I have a problem with debian policy 3.6.0 > > One of the news of this version is that changelog _should_ be in utf-8 > In my case the changelog should not be in utf-8 :) > > I have iconv'ed my changelog to be fully utf-8, but my name has a > "strange character" that gets converted > > So when the uploader checks the name of the Maintainer in the control > file (not utf-8) with the name in the changelog says that are different, > and results in a NMU Why not convert your name in the control file as well? -- Colin Watson [EMAIL PROTECTED]
Re: changelog in utf-8 conflicts with maintainer in control
On Fri, Aug 01, 2003 at 01:47:59PM +0200, Celso Gonz?lez wrote: > On Fri, Aug 01, 2003 at 01:33:18PM +0200, Eduard Bloch wrote: > > #include > > * Celso Gonz?lez [Fri, Aug 01 2003, 01:14:33PM]: > > > > > So when the uploader checks the name of the Maintainer in the control > > > file (not utf-8) with the name in the changelog says that are different, > > ^ > > > > Show me where policy tells you not to use UTF-8 in control files but > > some other non-ascii charset with some other encoding instead. > > Well, I think is not clear enough > A reflexion from the guy that suggest the change in policy > > Extracted from C2.2 > "Now, we can't switch to using UTF-8 for package control fields > and the like until dpkg has better support, but one thing we can > start doing today is requesting that Debian changelogs are UTF-8 > encoded" > > Maintainer is a control field > > The solution is that both files have the same encoding (both latin1 or > both utf-8) but i??m not sure that utf-8 is correct for debina/control Right now, dpkg has no explicit support for anything other than ASCII in debian/control: that is to say, it doesn't attempt to recode maintainer names to the current locale when asked to display control information with 'dpkg -s', etc. However, it doesn't support Latin-1 any better than it supports UTF-8! If you think that this is a problem, then the answer is not to use Latin-1, but to use only ASCII. That said, the problems caused by using an encoding that dpkg doesn't support are not serious; they just mean that some people will see your name wrongly when they type 'dpkg -s', but hey, that would happen anyway (particularly if you don't like the ASCII transliteration of your name). With that knowledge, if you're going to pick a non-ASCII encoding, then UTF-8 is almost certainly the way to go. It seems unlikely to me that we would select anything other than UTF-8 as the 8-bit encoding for control files. As a side note, I'd love to get rid of Latin-1 in maintainer names; it's currently difficult for the BTS to declare any character set in the web pages it generates, since some of the maintainer names it prints are in Latin-1 and some in UTF-8 and it can't easily tell which are which. Switching to UTF-8 throughout would solve that problem. So, to summarize, please either use plain ASCII (if you think that the lack of recoding is a problem) or UTF-8 (if you don't mind); using other legacy encodings is just storing up trouble. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Trying to make my first package...
On Fri, Aug 01, 2003 at 04:22:57PM +0200, Julien Barnier wrote: > "Bernhard R. Link" <[EMAIL PROTECTED]> : > > dpkg-buildpackage cannot create a orig.tar.gz, as something original > > has already to be there. (Try putting the upstream source code renamed > > there). In order to dpkg-buildpackage even trying, you need to have a > > version number ending with a debian-specific number. (The thing after > > -) > > As you say, I just renamed the folder where I put the original sources > with a "-1" version number, The name of that directory doesn't matter (much). It's the presence of the .orig.tar.gz and the version number at the head of debian/changelog that are important. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: search a sponsor fvwm-themes
On Sat, Aug 02, 2003 at 01:44:30PM +0200, Andrei Mitrofanow wrote:
> On Sat, Aug 02, 2003 at 12:43:40PM +0200, Geert Stappers wrote:
> > Respect the time of other people, help them helping you.
> > Tell us how to checkout from the CVS-server.
>
> It was a request from original developer,
> he want be independent of maintainers.
> And it is, i think so, verry easy to handel with cvs.
>
> you can download the source,
> ok, you must make aclocal,
> you can now say dpkg-buildpackage -rfakeroot,
> or you can say ./configure && make deb-dist{3},
> the rest i wish make automatic.
I think Geert's point is that you've asked for testers and a sponsor but
haven't told anyone where the source is!
Cheers,
--
Colin Watson [EMAIL PROTECTED]
Re: UTF-8 and changelog
On Mon, Aug 04, 2003 at 01:15:07PM -0400, Stephen Gran wrote: > Just a quick question about encoding changelog in utf-8. My normal > locale is iso-8859-1 (en_US or so, I guess), and `file changelog` > returns 'ASCII text'. I tried > `iconv -f ISO-8859-1 -t utf8 changelog -o changelog.new`, but then > `file changelog.new` returns 'ASCII text' again, and diff shows no > difference. Do I need to be doing this each time, or can I leave it be? If the file is already plain ASCII (i.e. contains no top-bit-set characters), then there is no difference between ISO-8859-1 and UTF-8, and you needn't worry. The procedure you just described demonstrates that the file is indeed plain ASCII. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: newbie packaging question
On Fri, Aug 08, 2003 at 07:38:11PM +1000, Matthew Palmer wrote: > The things which absolutely have to be in a package in order to be > built are debian/rules and debian/control. debian/rules gives the > commands required to make the package, and debian/control has the > information necessary to name the binary packages, dependencies, and > the rest. debian/changelog must also be present. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: newbie packaging question
On Fri, Aug 08, 2003 at 10:12:52PM +1000, Matthew Palmer wrote: > On Fri, Aug 08, 2003 at 11:24:13AM +0100, Colin Watson wrote: > > On Fri, Aug 08, 2003 at 07:38:11PM +1000, Matthew Palmer wrote: > > > The things which absolutely have to be in a package in order to be > > > built are debian/rules and debian/control. debian/rules gives the > > > commands required to make the package, and debian/control has the > > > information necessary to name the binary packages, dependencies, and > > > the rest. > > > > debian/changelog must also be present. > > D'oh. Knew I forgot something. > > Will the packaging tools complain if you have no copyright file, too? I > know it's necessary for uploading, of course, and I'm sure lintian would > have a right whinge, but will (eg) debhelper scripts have a complain, to > your knowledge? Don't think so; dh_installdocs is the only thing that cares about the copyright file at all, and looking at the source it doesn't look like it'll mind if it doesn't exist. I've certainly built quick test packages in the past without copyright files and had no problems other than the obvious lintian warning. I think this is correct behaviour, really. After all, packaging tools should be general where it's reasonable to be, and the copyright file is exclusively a Debian policy thing. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: newbie packaging question
On Tue, Aug 12, 2003 at 10:38:06AM -0700, Eric Winger wrote: > Matthew Palmer wrote: > >The easiest way for packages in the actual archive is to run 'apt-get > >source '. That'll download the sources and unpack them into > >the current directory. > > Ahh, this brings up a point that has bothered me about debian. Well > actually in this case, two points. > > * all the deb-src entries i tried to add to my sources.list give me > errors when I try to get the source. What is the url for sources? This > is my latest attempt: > > deb-src ftp://ftp.debian.org/debian testing main contrib free That's correct except that you want "non-free" there, not "free". (Ever think you'd hear a Debian developer say that?) > * how can one keep up on what the latest url's are for debian packages > etc. Is there a single spot where one can look? Or is this knowledge I > will only gain when I use the force? I found it easiest (years ago) to read the sources.list(5) man page and learn how those lines map into URLs, so I can then just go off with a web browser or an FTP client, figure out what URL I need, and construct the sources.list line from there. -- Colin Watson [EMAIL PROTECTED]
Re: newbie packaging question
On Tue, Aug 12, 2003 at 11:53:27AM -0700, Eric Winger wrote: > Colin Watson wrote: > >That's correct except that you want "non-free" there, not "free". > >(Ever think you'd hear a Debian developer say that?) > > would it be sacreligious to ask why sources are kept in non-free? I think one of us is confused. :) Source for non-free packages is in non-free, but if you aren't interested in that or would rather avoid it you're of course entirely welcome to omit the "non-free" word from that line. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: newbie packaging question
On Tue, Aug 12, 2003 at 04:40:42PM -0700, Eric Winger wrote: > Ok, I've managed to create a .deb package, experimented with putting > things in the rules file, installed my package locally. Learned a little > about purge and kind of have the gist of what y'all have been trying to > pound into my head. > > But now I've run into a problem. For my first package, which is nothing > but a test. I want to be able to run some commands after my package has > been installed. Simple copy & execute commands. > > I've modified the postinst.ex file, but my commands aren't being > executed. You must rename that to postinst. Your completed source package shouldn't have any of those example *.ex files in it. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Bits from the RM
On Wed, Aug 20, 2003 at 01:00:03AM +0900, Oohara Yuuma wrote: > On Tue, 19 Aug 2003 16:49:25 +1000, > Anthony Towns wrote to debian-devel-announce: > > * If you're uploading NMUs for the BSP during this period, > > you should skip DELAYED, and just upload straight to > > queue/unchecked (f.k.a Incoming). > > Does uploading to Incoming still work? Yes. (What have you been doing instead?) -- Colin Watson [EMAIL PROTECTED]
Re: when to close bugs
On Thu, Aug 21, 2003 at 03:40:50PM +0200, Robert Lemmen wrote: > i have a simple question: when am i to close bugs? once the bug is fixed > in *one* version in the debian archive (unstable) or once it is fixed in > *all*? Right now, just close it when it's fixed in unstable. A better mechanism is partly implemented and will be completed in the near future; see the archives of debian-debbugs for details. > the bts docs say as soon as a fixed version is in the archive, but there > are a lot of open bugs tagged "fixed". The fixed tag is for something different. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Update: Patch needs Sponsor - List of easily NMUed RC bugs
On Sun, Aug 24, 2003 at 03:28:00PM +0200, Goswin von Brederlow wrote: > Roland Mas <[EMAIL PROTECTED]> writes: > > Thanks again for the email, but please refresh the claims page before > > next one :-) > > I would need a parser for the claims page. Instead of writing that I > installed debbugs and are looking into adding a "claimed" field and > button on the BTS webpages. You want to use CVS, not the latest released packages. Anyway, unless I'm much mistaken, this is equivalent to bug ownership, which is already being looked at; also, it should be a control message like everything else, not a button on the web pages. -- Colin Watson [EMAIL PROTECTED]
Re: Update: Patch needs Sponsor - List of easily NMUed RC bugs
On Sun, Aug 24, 2003 at 05:26:32PM +0200, Goswin von Brederlow wrote: [Please don't send me private copies of list mail.] > Colin Watson <[EMAIL PROTECTED]> writes: > > On Sun, Aug 24, 2003 at 03:28:00PM +0200, Goswin von Brederlow wrote: > > > I would need a parser for the claims page. Instead of writing that I > > > installed debbugs and are looking into adding a "claimed" field and > > > button on the BTS webpages. > > > > You want to use CVS, not the latest released packages. Anyway, unless > > I'm much mistaken, this is equivalent to bug ownership, which is already > > being looked at; also, it should be a control message like everything > > else, not a button on the web pages. > > Why? If you mean CVS, because bug metadata has been completely upended since the last release. > The button/link can trigger a mailto all ready to send. If we're going to do a web interface we should do it properly, not by the back door in dribs and drabs. For now, just use (or hack) /usr/bin/bts. > "bts claim #number" would be the other comfortable way to claim a bug. > I would like to have both. 'bts owner', probably (because it'll be allowed to take an e-mail address so that you can pass a bug on your own package off to somebody else), but yes. It'll be documented that claiming ownership of a bug on somebody else's package is more or less equivalent in courtesy terms to declaring that you're going to NMU. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: ports attempted despite architecture?
On Wed, Aug 27, 2003 at 01:36:48PM +0200, Alexandre Fayolle wrote: > Are ports attempted on all packages, or is the Architecture field in > debian/control taken into account? > > The reason why I ask is that I maintain the python-psyco package, which > supports only i386, and the buildd logs [1] say that attempts have been > made to build the package on other archs. I event got a FTBFS bug > report. I'm not sure of how I should handle this bug, btw. You need to get a buildd admin to add your package to the centrally-maintained Packages-arch-specific list. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: removing bogus directories in my package
On Wed, Aug 27, 2003 at 04:22:48PM +0200, Robert Lemmen wrote: > one of my packages (trickle) had a problem and used to create stupid > directories (/usr/share/man1 etc) (see #207258). this is due to a typo > in debian/rules (shame on me) > > i fixed this in a new version, but i don't know how to handle the > existing directories. i could think of > > - just leavin them there > - removing them (if they are empty) in the postinst of the new version If it was created in an earlier .deb, just remove them from your current .deb. dpkg will handle the rest once no installed packages own them any more. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: RFS: sn - Small NNTP server for leaf sites
On Thu, Aug 28, 2003 at 02:13:44PM +0530, Ganesan R wrote: > >>>>> "Andreas" == Andreas Metzler <[EMAIL PROTECTED]> writes: > > I am rather fluent in sh, but need to look up "shopt -s xpg_echo". This > > is tooo ugly. Just use > > -echo -e ",s/RUNFROM=.*/RUNFROM=$RET/\nw" \ > > +printf ",s/RUNFROM=.*/RUNFROM=$RET/\nw\n" \ > > or grab the patch from the bts and use sed instead of ed (you'll need to > > depend on sed >=3.95). > > Or simply remove the -e option. builtin echo parses "\n" in bash as well as > dash. That isn't mandated by POSIX, though, and there are shells in Debian that don't do that. I agree with Andreas: use printf instead. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: RFS: sn - Small NNTP server for leaf sites
On Thu, Aug 28, 2003 at 01:24:50PM +0200, Chris Niekel wrote: > On Thu, Aug 28, 2003 at 10:43:34AM +0100, Colin Watson wrote: > > That isn't mandated by POSIX, though, and there are shells in Debian > > that don't do that. I agree with Andreas: use printf instead. > > A sponsor already uploaded the package, but a next version will use > printf. Since printf is part of coreutils, and coreutils is essential, > I don't even need an extra dependency, right? No, you don't. It's a builtin in some shells, too. -- Colin Watson [EMAIL PROTECTED]
Re: RFS: moon-lander
On Thu, Sep 04, 2003 at 11:32:39AM +0200, Geert Stappers wrote: > On Thu, Sep 04, 2003 at 04:38:09PM +1200, Mike Beattie wrote: > > So, yes, it will, since dpkg-genchanges will parse all changelog > > entries to create the Closes: field which is what katie uses. > > Mmmm, tell us more. > Where are all changelog parsed? /usr/lib/dpkg/parsechangelog/debian -- Colin Watson [EMAIL PROTECTED]
Re: Bug in update_excuses?
On Mon, Sep 08, 2003 at 01:45:43PM +0100, Mark Brown wrote: > On Mon, Sep 08, 2003 at 02:07:23PM +0200, Andreas Metzler wrote: > > So the db3-update predepends on a glibc-update, which cannot happen and > > should stop db3 3.2.9-19.0.1 from becoming "Valid candidate", > > shouldn't it? > > The script considers if things are a valid candiate on their own merits > but assesses other things like dependencies separately - if look at > something like powertweak this is explicitly stated: That's for when the dependency is a valid candidate, though. If it isn't then britney invalidates all the reverse dependencies, so you get things like the example you gave: > powertweak (0.99.4-19 to 0.99.5-1) > Maintainer: Mark Brown > 39 days old (needed 10 days) > Valid candidate > Invalidated by dependency > Not considered > Depends: powertweak glibc (not considered) The "Invalidated by dependency; Not considered" bit should have been output for db3/s390 too, but it wasn't. I think this is a bug in britney, although a minor one because db3/s390 will be thrown out at the next stage anyway due to increasing the uninstallability count. There's probably a glitch in the binary-NMU case. -- Colin Watson [EMAIL PROTECTED]
Re: Interrupted upload to erlangen, what now?
On Mon, Sep 08, 2003 at 11:59:45PM +0200, Jens Peter Secher wrote: > I started my very first (d)upload of a package to Erlangen, but then my > dog ate my mouse[1] and the transfer was interrupted. Well, actually I > realised that the changes file did not include the original tar ball. > > If I now try to dupload again, I get "Overwrite permission denied", and > if I fiddle with *.upload files, I get "dsc. already exists". I always just remove the corresponding .upload file when that happens, and I always upload straight to incoming on ftp-master/non-us rather than messing around with upload queues (which seem to be a frequent cause of problems from my impression of the number of people asking questions about them). In the case of an upload queue, you may have to upload a .commands file to delete the extra files; there's documentation of this somewhere ... Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: target specific variables in makefiles
On Mon, Sep 08, 2003 at 07:22:02PM -0400, Neil Roeth wrote: > I recently read about target-specific variables in make, so I thought I could > do this: > > pkg1-stamp: pkg1 > pkg2-stamp: pkg2 > > %-stamp: $(@:%-stamp=%) > touch $@ > > pkg1: DH_OPTIONS=-p$@ > ... > dh_install > dh_installxfonts > ... > > pkg2: DH_OPTIONS=-p$@ > ... > dh_install > dh_installemacsen > ... > > and avoid the extra call to make, but I get an error: > "*** commands commence before first target. Stop." Lines containing target-specific variables can't be followed by commands, I think, so you need to name the target again: pkg1: DH_OPTIONS=-p$@ pkg1: any-other-prerequisites-of-pkg1 ... pkg2: DH_OPTIONS=-p$@ pkg2: any-other-prerequisites-of-pkg2 ... If you want a real-life example, I can unashamedly plug the groff package, although I've just noticed that the DH_EXCLUDE := -Ngroff-x11 stuff is now obsolete. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: FAQ for debian-mentors
On Tue, Sep 09, 2003 at 06:33:01PM +0200, Ismael Valladolid Torres wrote: > El martes, 9 de septiembre de 2003, a las 14:27, Andreas Barth escribe: > > With a sid build environment you're always on the safe side. > > What about, having the choice of building against both the stable and > the unstable version of a library, choosing the stable version would > not make the path of the package into stable shorter? Not really. The autobuilders build for unstable on unstable, and it's generally not practical to have them do anything else (this has been gone over frequently). It's not uncommon for a maintainer to actually *slow things down* by building against an older library, because the older library that he compiles against is no longer in unstable and the newer library that the autobuilders compile against wasn't in stable. That tends to make the whole dependency chain deadlock. Please don't try it. :) -- Colin Watson [EMAIL PROTECTED]
Re: Request Sponsor to update mantis and php4-imagick
On Mon, Sep 08, 2003 at 07:36:45PM +0200, Bruno Rodrigues wrote: > I need a sponsor to update two packages and close some bugs: > > mantis (0.17.5-7+1) unstable; urgency=low [...] > php4-imagick (0.9.7-0+2) unstable; urgency=low I'm looking at these now. -- Colin Watson [EMAIL PROTECTED]
Re: Request Sponsor to update mantis and php4-imagick
On Mon, Sep 08, 2003 at 07:36:45PM +0200, Bruno Rodrigues wrote: > I need a sponsor to update two packages and close some bugs: > > mantis (0.17.5-7+1) unstable; urgency=low > . >* Only reconfigure if config.php doesn't exists, avoiding overwriting >* it > (Closes: #199985) >* Urlencodes before creating bug and cvs links (Closes: #200336) >* Downgraded priorities from some debconf questions >* Don't rm -fr /etc/mantis >* Debconf also askes for apache-perl (already on dependency list) >* Updated to Standards-Version 3.6.1 >* Better detection of wrong mysql's root user/pass parameters I've uploaded this (I'd prefer not to get into regular sponsorship of this as I don't know PHP, but these changes were easy enough to check without that knowledge). Steve Langasek tells me he's already looking at php4-imagick. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Using ${description}, and debian/substvars.
On Fri, Sep 12, 2003 at 12:31:24AM +0300, Shaul Karl wrote:
> Quoting http://bugs.debian.org/209569
>
> If this package is being generated from a single source package and
> you already provide a full description in your control file for the
> main package, you might want to use it automatically in
> sub-packages. If this is the case consider using ${description},
> and debian/substvars.
>
> Can you tell where using ${description} and debian/substvars being
> documented,
It's in the dpkg-gencontrol(1) man page. Look under "VARIABLE
SUBSTITUTION".
> and give some examples for package which are made from a
> single source package and automate using the description in
> sub-packages?
Not sure about that, I'm afraid. Using substvars is reasonably common
though (if nothing else, dpkg-shlibdeps uses them).
--
Colin Watson [EMAIL PROTECTED]
Re: Description help for argouml
On Fri, Sep 12, 2003 at 04:51:44PM +0100, Steve McIntyre wrote: > On Fri, Sep 12, 2003 at 08:46:11AM -0700, Josh Lauricha wrote: > >On Fri 09/12/03 17:23, Arnaud Vandyck wrote: > >> Lintian tell me that there is a problem in the description field of > >> argouml: > >> > >> W: argouml: description-synopsis-might-not-be-phrased-properly > >> > >> Here is the description field, can someone help me to solve this? > >> > >> Description: Modelling tool to help you do your design using UML. > > Try using "lintian -i" - it will tell you more about the errors and > warnings that it finds. You can also pipe the output from lintian through lintian-info if you don't want to spend time running lintian again. -- Colin Watson [EMAIL PROTECTED]
Re: Bug#210243: ITP: xspringies -- Interactive 2D mass/spring simulation system for X
On Mon, Sep 15, 2003 at 04:21:39PM +0100, Steve Kemp wrote: > On Mon, Sep 15, 2003 at 11:00:35AM -0400, Matt Zimmerman wrote: > > $PATH is almost always trusted; the exception is setuid programs which > > should sanitize PATH. xspringies is not setuid, is it? > > It is not setuid/setgid no, but I still think it's best to not trust > the PATH - sure it's not critical, but it's a good think "just in > case". Just in case somebody decides to move the programs in question? Witness grep. -- Colin Watson [EMAIL PROTECTED]
Re: [RFS]: digitaldj
On Tue, Sep 16, 2003 at 09:43:16AM -0400, Matt Zimmerman wrote: > Yes, I was referring to the second paragraph in section 6.3.1 of the > developer's reference: > > > Focus on what was changed---who, how and when are usually less > > important. Having said that, remember to politely attribute people > > who have provided notable help in making the package (e.g., those > > who have sent in patches). > > In this case, it is important to note what actually changed in the > package. Personally, I dislike the "maintainer upload, closes:" > convention, and prefer to re-summarize the changes so that it is clear > which bugs are being acknowledged. Remember that, when you use > Closes:, the submitter of the bug only gets a copy of your most recent > changelog entry, so they won't see what the NMUer wrote. ... unless you use the -v option to dpkg-buildpackage to include the changelog entries from all the NMUs, which I personally think should be best practice. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Security updates
On Fri, Oct 03, 2003 at 09:39:54AM +0200, Daniel J. Priem wrote: > 1. choice > > everytime where a new busybox | xserver_something | another package > due to security reasons is released > LTSP also needs and gets an secupdate > > 2. choice > > or having something like > > build_rootfs.sh readconf /etc/ltsp/rootfs.conf --update rootfs > > So that no secupdate is required. > > > > I prefer choice 1 > > Pro: a) apt-get update && apt-get upgrade will fix everything > b) no extra systemadministrator work is needed > > Contra : a) for every sec hole in any xserver the ltsp package also > needs an sec update (bad for the secadvisory team ?) Although I'm not a member of the security team, I'm fairly certain they will not be in the least happy about this option. The security team have enough to do without trying to keep track of random other packages that need to be updated every time they do an advisory. I'd suggest finding any other option. > b) i have more work to always have the package up to date (for me not > bad) Some day you might be busy or away from your computer when a security update to xfree86 is released. For people running testing, xfree86 and LTSP won't propagate into testing at the same time, and so on. You need to plan for these kinds of things. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Sponsorship for non-NM?
On Fri, Oct 10, 2003 at 01:54:27PM +0200, Fiona Guenther wrote: > I want to apply for Debian Maintainer some time in the future, but I > don't feel ready right now. Nevertheless, I think I'm able to maintain > one or two packages which are up for adoption. This way, I can learn > how this packaging stuff works and I can already contribute to Debian. > How is this supposed to work now? Should I look for a sponsor who > uploads my package for me? I this possible even though I don't (yet) > apply for the NM process? Yes. Sponsors will generally expect that you're at least intending to apply in the future, but this seems to be the case. Send links to source packages you've prepared to this list; if there's no response, feel free to ping occasionally. When you do decide to start NM, you'll need a developer to advocate your application. Sponsors are the best candidates for this. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Debian Installer sends acknoledgements to uploader, doesn't it?
On Tue, Oct 21, 2003 at 06:51:07PM +0200, Goswin von Brederlow wrote: > Martin Michlmayr <[EMAIL PROTECTED]> writes: > > * Andreas Metzler <[EMAIL PROTECTED]> [2003-10-21 09:34]: > > > I don't have a m68k machine and did not do the upload, so I wonder how > > > this ended up in my inbox, with me in the To:. I know you get these > > > > The guy who built the package fucked up. > ... > > exim4 > > Maintainer: Andreas Metzler <[EMAIL PROTECTED]> > > Changed-By: Goswin von Brederlow > > Sorry, I only go told after the build to use -m instead of -e. I > thought the uploader (sponsor) would override my entry when he signs > the changes too but that seems not to be neccessary. Boggle. Your sponsor just signed something you'd built? Sponsors are supposed to build packages themselves, not accept binaries from elsewhere. > Does the acknoledgements actually go to the uploder, i.e. the person > signing the changes, or just to the Maintainer and Changed-By persons? They go to the Maintainer: in the .changes file. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Debian Installer sends acknoledgements to uploader, doesn't it?
On Wed, Oct 22, 2003 at 09:53:45AM +1000, Martin Michlmayr wrote: > * Colin Watson <[EMAIL PROTECTED]> [2003-10-21 19:15]: > > Boggle. Your sponsor just signed something you'd built? Sponsors are > > supposed to build packages themselves, not accept binaries from > > elsewhere. > > He runs a m68k buildd, so building his packages again kind of defeats > the whole purpose... I'm not sure I'd ever considered the possibility of a non-developer running a buildd properly. Perhaps somebody else could be the buildd operator who does all the signing and uploading and Goswin could host and maintain it? (Or maybe this is already the case and I've just misunderstood.) -- Colin Watson [EMAIL PROTECTED]
Re: Fixing a b0rked NMU - How long do I have to wait?
On Wed, Oct 29, 2003 at 02:36:48PM +0100, Andreas Metzler wrote: > I've made a broken NMU of libgpgme0.4, introducing a > /usr/share/info/dir.* rc-bug (218083). I've submitted a patch and tagged > the bug accordingly. How long do I have to wait before I can make an > upload fixing my own broken NMU? Do I really have to wait again > sometime + sometime + delayed-7days as described in developers > reference? I think that fixing breakages introduced in your own NMU is a duty, and I don't think it's necessary to wait so long before doing so. A couple of days for the maintainer to respond is adequate, IMHO. Needless to say, though, be doubly careful to get the second NMU right. :-) You may find debdiff useful (in general, not just in this case). -- Colin Watson [EMAIL PROTECTED]
Re: Need help with Bug#217974: ttt_1.7-1(ia64/unstable): FTBFS: config.guess out of date (at least)
On Tue, Nov 04, 2003 at 09:13:14AM +0100, Marco Nenciarini wrote: > On Tue, Nov 04, 2003 at 07:41:31AM +0100, Thomas Scheffczyk wrote: > > I checked the file 'config.guess'. 'ia64' is defined and should be > > recognized. Without access to a computer of this architecture I don't > > know how to handle this error. Perhaps anybody of you can give me a clue. > > Add to your debian/rules file this target, and add a dipendency to autotools > to clean target. > Don't forget to add autotools to PHONY, and add debscripts and autotools-dev > to build deps. > > # The autotools target adds forced build-time dependencies on > # autotools-dev (for /usr/share/misc/config.*) and debscripts (for dch) > # It's also a .PHONY make target. > autotools: Or just copy in updated config.guess and config.sub files manually each time it becomes necessary; that way you might also remember to tell upstream that they should update their copies, which is something a good Debian maintainer should be doing. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: preferred method for coexistence of debconf- and manual parts in conffiles?
On Wed, Nov 05, 2003 at 03:03:24PM +0100, Frank Küster wrote: > Hi, > > if a package wants to use debconf to manage a configuration file, but > still let the user have the option to manually add entries - is there a > preferred way how to do this? Have you read debconf-devel(7), namely the section on "Config file handling"? If not, do. > Put the information from the debconf database into the file, but between > markers ### begin DEBCONF section for $package... ### end DEBCONF > section for $package. So an admin can add his customization before or > after that, and upon dpkg-reconfigure or an upgrade only the part > between the markers will be changed. > > Is this concept o.k.? I couldn't find anything in the policy about that. I dislike "debconf sections". It should be possible for the sysadmin to edit whatever he/she likes under /etc without having to learn about strange automatic configurator tools with which they may well be unfamiliar. > Here's why I come to ask the question: Recently, a bug was filed against > tetex-bin, #209395, criticizing that a configuration file, language.dat, > is not in /etc, but under /var. Yeuch, tetex is the most disastrous example of configuration file handling I can think of. I keep being repeatedly asked strange questions about merging configuration files I know for certain I've never touched, and asked incomprehensible debconf questions about files I don't care about. > He should have answered "no" to the question wether debconf should > manage this file if he wants to do that. I have to say that I'm coming to believe that anything that talks about "debconf managing this file" is a bug. If the user makes changes to the file, I think it's the package's responsibility to cope with that. A three-way diff or something would be fine if it's too difficult to merge the changes automatically. (Also, it's horribly sloppy wording. debconf is just providing the means to ask the user questions, while *your package* is managing the file. As a result, lots of people blame debconf for bugs that are the fault of individual packages, which gives debconf a bad name.) Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: subscribing to a single bug
On Thu, Nov 06, 2003 at 01:42:12AM +0100, martin f krafft wrote: > I can subscribe to the BTS traffic of a whole package through the > PTS. Is it also possible to just monitor a single bug and be emailed > when something changes? Not yet. A patch has been posted and needs one of us to have time to review and deploy it, though. -- Colin Watson [EMAIL PROTECTED]
Re: config.sub and config.guess | .diff.gz bloat
On Thu, Nov 06, 2003 at 07:14:13PM +1100, Zenaan Harkness wrote: > (Yes, I hadn't read that thread - thanks.) However, I'm still unsure > whether these (I assume _yes_ at this point) confusion came from the > fact that the upstream source does not have these files at all. In that case dh_make is just being stupid. You can delete those lines from debian/rules. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: fastdep finally packaged
On Thu, Nov 06, 2003 at 09:44:53PM +1100, Zenaan Harkness wrote: > I sent an email to lintian-maint. So at this point, can I consider my > package lintian-clean? Surely you don't add a lintian-override just > because lintian is not yet up to the current policy spec ?? Indeed. Relax, and ignore the warning. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: RFS: kdiff3 - compares and merges 2 or 3 files or directories
On Fri, Nov 07, 2003 at 04:11:51PM +0100, Eike Sauer wrote: > Another package - as pdebuild built it - is not installable > on my system due to dependency problems. > dpkg says: "kdiff3 depends on libc6 (>= 2.3.2.ds1-4)", but > I could not satisfy this with the most recent unstable libc. That's been in unstable for a while; try updating. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: RFS: msmtp, wmnetload, wmwifi
On Thu, Nov 20, 2003 at 01:14:27PM -0800, Jess Mahan wrote: > I searched the debina-mentors archive and am not sure > what to do about the no orig.tar.gz. > > I followed the Debian New Maintainers Giude to the tee, and when > packagin, it doesnt seem to generate a diff or orig.tar.gz. The packaging tools never create .orig.tar.gz. You're supposed to put it there yourself, and it should usually be an exact copy of the upstream tarball. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: lintian vs. linda error
On Mon, Dec 08, 2003 at 11:01:22AM +0100, Daniel Gubser wrote: > I have some problems to understand where I have to put the perl modules. > > When I put them in /usr/lib/perl5 I get from lintian (linda shows no > error): > > W: psad: package-installs-nonbinary-perl-in-usr-lib-perl5 > usr/lib/perl5/Psad.pm > W: psad: package-installs-nonbinary-perl-in-usr-lib-perl5 > usr/lib/perl5/IPTables/Parse.pm > > so I move this to /usr/share/perl5 and linda blubers (lintian shows no > error): > > W: psad; Architecture-dependant package installs into /usr/share/perl5. > W: psad; Architecture-dependant package installs into /usr/share/perl5. Does your package contain any architecture-dependent code, i.e. XS modules (look for .so, .bs)? If so, you probably want to put the modules in /usr/lib/perl5 and ignore lintian. If not, make sure your control file says "Architecture: all", not "Architecture: any". Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: debconf db_input in postinst / horde2
On Fri, Dec 12, 2003 at 10:42:10AM +0100, Frank Küster wrote: > "Jamin W. Collins" <[EMAIL PROTECTED]> schrieb: > > On Thu, Dec 11, 2003 at 11:51:01PM +0100, Jeremy Lain? wrote: > >> I can see how it is a Bad Thing to prompt the user for input both in > >> postinst and in config, but the fact still stands that it's the way > >> it's done in horde2, and I'm sure there must be a good reason for it! > >> Any ideas here? > > > > Ask it during config, store it in debconf until your through using it in > > postinst and then clear it from debconf. It's how I do it in mediamate. > > I can't find it right now, but isn't it written somewhere that prompting > in postinst will be a no-no in future policy releases? It shouldn't be (I think you're thinking of non-debconf prompting). Sometimes you have to prompt in the postinst, namely when you need your package to be unpacked before being able to figure out what the question should be. I don't know whether that applies in this case, but it does happen. -- Colin Watson [EMAIL PROTECTED]
Re: UTF-8 in copyright files?
On Tue, Dec 16, 2003 at 12:58:44AM +0100, Jeroen van Wolffelaar wrote: > On Mon, Dec 15, 2003 at 07:29:59PM +, Scott James Remnant wrote: > > On the other hand, policy states UTF-8 for Changelog which breaks katie > > if your name contains accented characters because you're still forbidden > > by policy to use UTF-8 in debian/control. > > Since UTF-8 isn't yet by default supported on all systems (at least not > on my sarge system), I would rather choose for going on the safe side, > using only 7-bit latin1. You must mean either "7-bit US-ASCII" or "8-bit Latin-1". "7-bit Latin-1" doesn't make sense; you might as well just say ASCII. 8-bit Latin-1 is an increasingly bad idea considering the number of users and developers whose native languages aren't compatible with Latin-1. Sarge systems support UTF-8 really quite well, though, with a tiny bit of locales configuration. Even woody systems support them with only a few unpleasant bugs. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Standards-Version
On Mon, Dec 15, 2003 at 07:19:38PM +0100, Florian Zaehringer wrote: > :D I know that, but since the debian-hack I couldn't find a server with > any packages... But perhaps I misspelled somthing because apt-get finds > packages... Packages @ http://debian.org was / is(?) unavailable. packages.debian.org is just a search engine, not the archive itself. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Conflicts: foo (>=x && <=y) - how?
On Tue, Dec 16, 2003 at 12:41:20PM +0100, Andreas Metzler wrote: > On a sidenote I wonder whether I should actually bother with this. - > The version in woody and the versions currently available in sid and > sarge are ok, 1:4.0.3-9 was uploaded almost half a year ago (20 Aug > 2003), is it necessary to carter for completely outdated sid and > sarge? I wouldn't bother. I don't think dependency relationships are necessary to work around bugs in other packages, unless there are strong practical reasons for it. You could create a postinst check with a more verbose warning if there's some serious practical problem. -- Colin Watson [EMAIL PROTECTED]
Re: UTF-8 in copyright files?
On Tue, Dec 16, 2003 at 01:40:35PM +0100, Sven Luther wrote: > On Tue, Dec 16, 2003 at 03:07:59AM +0100, David Weinehall wrote: > > Of course, UTF-8 whereever possible is a nice goal to strive after, > > and I think that the debian-specific files are a good place to start. > > Would the place to start not be to make sure that every piece of debian > supports it, and make it a release goal ? I doubt it is still time for > sarge, but maybe for sarge+1 ? Depends how practical that is, I guess. For example, it's still unknown when groff will support it properly (as in UTF-8 input; UTF-8 output is more or less OK now), since nobody's yet done the work and it's Hard. I don't think we'd want either to delay sarge+1 by an arbitrary amount of time until that happens or to drop man pages from the distribution ... erm, let's not turn this into a man vs. info war! Anyway, proper UTF-8 support often involves a significant amount of upstream design work and development, which contrasts somewhat with things that have been release goals in the past. Something with the force of a "should" is probably what we want, but I'm not sure how to phrase it. -- Colin Watson [EMAIL PROTECTED]
Re: UTF-8 in copyright files?
On Tue, Dec 16, 2003 at 04:38:23PM +0100, Sven Luther wrote:
> On Tue, Dec 16, 2003 at 02:48:01PM +0000, Colin Watson wrote:
> > Depends how practical that is, I guess. For example, it's still unknown
> > when groff will support it properly (as in UTF-8 input; UTF-8 output is
> > more or less OK now), since nobody's yet done the work and it's Hard. I
>
> Yep, noticed that also, man simply removes the - from manpages, which is
> a pain, as they get used pretty much in manpages.
See /etc/groff/{man,mdoc}.local. (And no, groff doesn't remove "-", it
renders it as the Unicode HYPHEN character.)
> > don't think we'd want either to delay sarge+1 by an arbitrary amount of
> > time until that happens or to drop man pages from the distribution ...
>
> Then, do not say that we should allow UTF-8 usage in files, if it is
> clearly not going to be supported. Come one, sarge+1 is probably more
> than 2 years away, if we cannot support UTF-8 by then, something is
> seriously wrong.
What I'm saying is that we depend on upstreams to make significant
design changes, and that's something we have little control over, so it
shouldn't be a release goal as such. Some changes can be made in Debian,
but I'm not sure radical design shifts with compatibility implications
qualify.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
Re: UTF-8 in copyright files?
On Tue, Dec 16, 2003 at 07:00:26PM +0100, Sven Luther wrote:
> On Tue, Dec 16, 2003 at 05:22:36PM +0000, Colin Watson wrote:
> > On Tue, Dec 16, 2003 at 04:38:23PM +0100, Sven Luther wrote:
> > > Yep, noticed that also, man simply removes the - from manpages,
> > > which is a pain, as they get used pretty much in manpages.
> >
> > See /etc/groff/{man,mdoc}.local. (And no, groff doesn't remove "-", it
>
> Ok, will look.
>
> > renders it as the Unicode HYPHEN character.)
>
> Well, i most definitively cannot see it, and i am using a UTF-8 aware
> xterm (uxterm if i am not wrong).
Try:
printf - | groff -Tutf8 | grep .
then:
printf - | groff -Tutf8 | grep . | od -tx1
I've seen a similar report before, but IIRC it turned out to be a
terminal/font problem.
> > > Then, do not say that we should allow UTF-8 usage in files, if it is
> > > clearly not going to be supported. Come one, sarge+1 is probably more
> > > than 2 years away, if we cannot support UTF-8 by then, something is
> > > seriously wrong.
> >
> > What I'm saying is that we depend on upstreams to make significant
> > design changes, and that's something we have little control over, so it
> > shouldn't be a release goal as such. Some changes can be made in Debian,
> > but I'm not sure radical design shifts with compatibility implications
> > qualify.
>
> It would assuredly not be the first time that we fork upstream to fit
> our goals and needs.
I'm not sure you read what I wrote about major design and compatibility
changes ...
Also, to continue the example, not only am I unwilling to make an
incompatible change to groff in Debian but I'm not even remotely capable
of making such a massively sweeping change. I think you might
underestimate how much work it can be to alter older but widely-used
programs with just-send-8-bit assumptions to use UTF-8. I'm sure
maintainers of other such programs would feel the same way. This kind of
work can and should be done upstream.
That's why I suggested making it a "should": I'm quite happy to
acknowledge that it's a bug that groff doesn't support UTF-8 input, but
I think it would be pointless to hold up a release because of that.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
Re: UTF-8 in copyright files?
On Tue, Dec 16, 2003 at 09:23:01PM +0100, Sven Luther wrote: > On Tue, Dec 16, 2003 at 07:44:35PM +0000, Colin Watson wrote: > > On Tue, Dec 16, 2003 at 07:00:26PM +0100, Sven Luther wrote: > > > Well, i most definitively cannot see it, and i am using a UTF-8 aware > > > xterm (uxterm if i am not wrong). > > > > Try: > > > > printf - | groff -Tutf8 | grep . > > > > then: > > > > printf - | groff -Tutf8 | grep . | od -tx1 > > > > I've seen a similar report before, but IIRC it turned out to be a > > terminal/font problem. > > I get an invisible - for the first one, and then : > > e2 80 90 0a > 0004 > > for the second one. groff is behaving correctly, then, which means that you must be using a font which doesn't have the U+2010 HYPHEN glyph. Fix that ... I use 'pterm -fn -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1' as a Unicode terminal. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: UTF-8 in copyright files?
On Thu, Dec 18, 2003 at 10:12:13AM +0100, Sven Luther wrote: > Other problems is sshing from a non UTF terminal, but then luit helps, > but there is not really much we can do there, no ? This is a pain in the arse, frankly, because there's no way I've found to pass environment variables such as LANG across the ssh connection. If anyone knows of a not-too-hacky way to do this, I'd be interested. -- Colin Watson [EMAIL PROTECTED]
Re: Splitting man pages
On Thu, Dec 18, 2003 at 06:55:38PM +0100, blacksheep wrote: > I had to wrote a lot of man pages for a multiple-binary package. > They have to include all the same portion of text for full > explanation. A first solution I found was to provide an > additional troff document which any man page would include as > follows: > > .so additional.1 > > But lintian shout out something like: > > WHAT IS THAT FOR ? You should not provide a mapage with no > corresponding binary ! > >For me it is _very_ important to provide such informations in a >separate file, as further modifications will reflect on any >page, without the need for editing each one by hand. > >My advocate suggested a different solution; is it legal to >write something like: > > .so /usr/share//additional.1 > > in a man page ? What solution would be cleaner to adopt ? That should be legal, but it strikes me as a little odd. How about build-depending on groff-base and preprocess your man pages using soelim at build time so that additional.1 gets included in the page installed as part of the binary package? That way you can write your documents as you suggested originally but you don't have to worry about where to put additional.1. -- Colin Watson [EMAIL PROTECTED]
Re: lintian vs. linda error
On Tue, Dec 23, 2003 at 02:43:42AM +0100, Matthias Urlichs wrote: > Hi, Colin Watson wrote: > > Does your package contain any architecture-dependent code, i.e. XS > > modules (look for .so, .bs)? If so, you probably want to put the > > modules in /usr/lib/perl5 and ignore lintian. > > ... or, better IMHO, install a lintian override. I generally dislike installing lintian overrides for things I consider to be bugs in lintian. It only serves to hide the problem. Lintian overrides are intended to document exceptions to generally correct rules. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: strange bug query error
On Tue, Dec 23, 2003 at 10:29:12AM -0600, John Belmonte wrote: > The bug query http://bugs.debian.org/223539 has been returning an error > for a week now, causing my bug mining script to fail. Anyone know > what's going on? Please report problems like this to [EMAIL PROTECTED] when you notice them. The bug tracking system has a few bugs meaning that it doesn't react very well to running out of disk space (although it does at least keep all the data *somewhere*), and this was a casualty. I've fixed up the bug log and marked the affected message for reprocessing. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: take over libghttp
On Fri, Dec 26, 2003 at 10:45:09AM +0100, GCS wrote: > Is it adviceable to take over libghttp? It seems the only one package > needs it is libhttp-ghttp-perl and also orphaned. IMHO it would be > better to remove them: gnome-vfs replaces libghttp and perl has other > bindings to http usage. A number of packages use it; telegnome, which I maintain, is one. telegnome is dead upstream AFAIK (making it a major effort to port to gnome-vfs) but it's still useful and I don't know of any alternatives providing the same functionality. I may take over libghttp1 after Christmas if I find that I have some spare time. -- Colin Watson [EMAIL PROTECTED]
Re: PearPC Section (contrib or main)
On Thu, Oct 07, 2004 at 03:22:13PM +0200, martin f krafft wrote: > also sprach Leo Costela Antunes <[EMAIL PROTECTED]> [2004.10.07.1405 +0200]: > > Maybe it's still time to contact the archive admins and change the > > section before the first version hits unstable (during security > > scrutiny). > > Just upload a new, fixed version. Note that you need to upload a new version anyway, as components (main, contrib, non-free) are not overridden by the archive administrators. -- Colin Watson [EMAIL PROTECTED]
Re: debmake or dh-make, what should I use?
On Sun, Oct 17, 2004 at 11:45:34AM +0200, martin f krafft wrote: > also sprach Magnus Therning <[EMAIL PROTECTED]> [2004.10.16.2359 +0200]: > > Ah, cool. I am not sure why, but for some reason I thought dh-make was > > the deprecated one. I just made an attempt at packaging a python lib, > > and I failed miserably. :-) I'll just forget about debmake's existance > > from now on then. > > Uh, if I understand correctly, these are apples and oranges. dh-make > creates a ./debian template set; debmake builds packages. That isn't an accurate description of debmake, as should be clear from its package description. The debmake package contains debstd, which is a monolithic program occupying roughly the same space as debhelper, and deb-make, which is analogous to dh_make. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: debmake or dh-make, what should I use?
On Sun, Oct 17, 2004 at 09:35:32PM +0200, martin f krafft wrote: > also sprach Colin Watson <[EMAIL PROTECTED]> [2004.10.17.2031 +0200]: > > That isn't an accurate description of debmake, as should be clear > > from its package description. The debmake package contains debstd, > > which is a monolithic program occupying roughly the same space as > > debhelper, and deb-make, which is analogous to dh_make. > > Apologies for spouting false information. Now I am getting > interested in this. > > So I guess the answer is: they are largely the same and differ only > in debian/rules, which dh_make creates based on debhelper and > deb-make uses debstd. > > Has anyone looked at both, debhelper and debstd? debhelper is the > quasi-standard, but is debstd worth a look? Yes, I've looked at both. It's been deprecated for years and years and years for a reason. :-) Unless you're interested in archaeology or in seeing how to do the job wrong, it's probably best avoided. Apart from bad design, debstd is unlikely to deal with many more modern packaging requirements, since it hasn't been developed for a long time. -- Colin Watson [EMAIL PROTECTED]
Re: debmake or dh-make, what should I use?
On Mon, Oct 18, 2004 at 11:19:48AM +0200, Eduard Bloch wrote: > #include > * martin f krafft [Sun, Oct 17 2004, 10:35:21PM]: > > Apart, yes, why not delete dh_* calls? > > Because you need to remember them again when you need them or look > around. Okay, it makes no difference when the day ends. debian/rules files don't need to have a complete debhelper usage manual embedded in them. Use the documentation. -- Colin Watson [EMAIL PROTECTED]
Re: RFS:tuxeyes; was: Re: RTS: tuxeyes
On Sat, Jan 03, 2004 at 08:27:04PM +0100, GCS wrote: > I have made some more progress on the package. Fixed the last bug for > the package, which caused the pupil to disappear. I have a quesion about > it: as the package hasn't uploaded into unstable, was I wrong by > incrementing the Debian version again? I think it's bad (late worry) as > the previous section of changelog won't be processed, and the bugs won't > be automagically closed. Get your sponsor to use the -v option to dpkg-buildpackage or debuild, which with an appropriate version number will include previous changelog entries. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: RFS: libxml-libxml-perl etc. to fix libxml-filter-xslt-perl FTBFS
On Sat, Jan 17, 2004 at 12:29:14AM -0800, Michael K. Edwards wrote: > I could use an upload sponsor for these packages, preferably before > libxml-filter-xslt-perl is removed from unstable due to FTBFS: > > libxml-libxml-perl (I am maintainer; this will be my second upload, and > contains a major overhaul of the XSUB code) On powerpc, 'make test' fails: t/02parse...NOK 454# Failed test 454 in t/02parse.t at line 681 # t/02parse.t line 681 is: ok( $@ =~ /^:0:/ ); t/02parse...FAILED test 454 Failed 1/460 tests, 99.78% okay t/11memory..skipped all skipped: no reason given t/26schema..ok 2/6Element has no name nor ref Facet pattern has no value Element has no name nor ref t/26schema..dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 3-6 Failed 4/6 tests, 33.33% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/02parse.t 4601 0.22% 454 t/26schema.t 255 65280 68 133.33% 3-6 1 test skipped. Failed 2/24 test scripts, 91.67% okay. 5/1079 subtests failed, 99.54% okay. Are these architecture-specific or not? Do you need help in investigating them? > libxml-sax-writer-perl (orphaned; I would like to adopt; the one outstanding > bug is fixed in this rev) > > libxml-libxslt-perl (orphaned; I would like to adopt; undoes NMU workaround > for a bug that was really in libxml-libxml-perl) > > libxml-filter-xslt-perl (orphaned; I would like to adopt; about to be removed > from sid due to FTBFS, which was mostly the fault of libxml-libxml-perl) These are all marked ITA by Jay Bonci (cced). Have you confirmed with him that he's OK with you taking them? That said, the ITA was several months ago ... Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: RFS: libxml-libxml-perl etc. to fix libxml-filter-xslt-perl FTBFS
On Mon, Jan 19, 2004 at 01:26:06AM -0800, Michael K. Edwards wrote: > Updated packages for libxml-libxml-perl and friends are in the same > place as before. (The only real differences are Uploaders: Jay Bonci > and signature with a proper securely managed key.) As I mentioned > before, the "make test" failures are harmless and will go away with > the next libxml2 upload. I've uploaded this lot now, so we can keep an eye on the build logs. > I'd also like to adopt libhttp-ghttp-perl (also needed by AxKit), > which was my reason for adopting libghttp with your help. If you > don't mind uploading it and libghttp (the changes to both are > trivial), I would appreciate it. Uploaded. No problems throughout - these were a pleasure to sponsor. The only incredibly minor nitpick I had was that `pwd` in debian/rules is better written as $(CURDIR), but I should probably take that up with dh-make-perl ... Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Maintainer: field in .changes
On Wed, Jan 21, 2004 at 12:05:59PM +, Scott James Remnant wrote: > On Tue, 2004-01-20 at 13:07, Frank Küster wrote: > > Martin Michlmayr <[EMAIL PROTECTED]> schrieb: > > > * Scott James Remnant <[EMAIL PROTECTED]> [2004-01-20 11:36]: > > >> You're breaking policy by doing that ;-) policy only allows UTF-8 > > >> in debian/changelog and not in debian/control ... so if you were to > > > > > > Does policy prohibit UTF-8 in control anywhere? > > > > zgrep -i -C3 utf /usr/share/doc/debian-policy/policy.txt.gz > > > > yields only the recommendation for the changelog, and the respective > > footnote. > > Which says you can't use it in package control fields until dpkg has > better support[0], iirc. Nothing actually breaks in dpkg; it just doesn't recode the control fields to the current locale for output by 'dpkg -s' and the like. (Likewise 'apt-cache show'.) This might make it a stretch for policy to recommend it, but I see no reason why packages can't start using UTF-8 for things like maintainer names before then. -- Colin Watson [EMAIL PROTECTED]
Re: RFS: hatari
On Sun, Jan 25, 2004 at 12:34:03PM +0100, Marco Herrn wrote: > > > I thought so, too. But it doesn't work. It is enabled in debian/rules and > > > since the manpage is installed when listed in debian/hatari.manpages this > > > can't be the problem. I called the manpage hatari.1 and it lies in the > > > debian directory, too. As far as know this must be correct. > > > > This is correct because *you* (as opposed to the upstream author) wrote > > the manpage. Then, you should be able to write something like: > > > > dh_installman [debhelper options] debian/hatari.1 > > > > in a binary target of your debian/rules and not need the > > debian/hatari.manpages file. > > Oh, then I misunderstood the New Maintainers Guide. I thought when having > only one manpage and naming it packagename.1 dh_installman would > automatically find and include the manpage. dh_installmanpages did that, but that made its interface unlike the rest of debhelper and occasionally made it do unexpected things. dh_installman was written specifically to get rid of that do-what-I-mean behaviour. If you're using debian/hatari.manpages, which is fine, then make sure you put debian/hatari.1 there and not just hatari.1. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Failed ITP?
On Sun, Jan 25, 2004 at 08:43:19PM +0100, Nico Manicone wrote: > A new Bug (227958) in the wnpp-metapackage was created, but the program > does not appear in the list for packages worked on. And the old entry at > requested packages (Bug 107407) still exist. BTS LDAP is down so those lists aren't being updated. Don't worry about it. By the way, why did you create a new bug rather than retitling the existing one? You shouldn't do that. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: RFS: hatari
On Mon, Jan 26, 2004 at 08:44:50PM +0100, Frank Küster wrote: > "Eike \"zyro\" Sauer" <[EMAIL PROTECTED]> schrieb: > > This error means that his version is _newer_ than the one > > lintian expects. So this is a lintian bug. > > But 3.6.0 is not the most recent standard version anyway, > > it's 3.6.1 now. > > 3.6.1.0 You don't need to include the final component. 5.6.10. `Standards-Version' --- The most recent version of the standards (the policy manual and associated texts) with which the package complies. The version number has four components: major and minor version number and major and minor patch level. When the standards change in a way that requires every package to change the major number will be changed. Significant changes that will require work in many packages will be signaled by a change to the minor number. The major patch level will be changed for any change to the meaning of the standards, however small; the minor patch level will be changed when only cosmetic, typographical or other edits are made which neither change the meaning of the document nor affect the contents of packages. Thus only the first three components of the policy version are significant in the _Standards-Version_ control field, and so either these three components or the all four components may be specified.[1] [1] In the past, people specified the full version number in the Standards-Version field, for example "2.3.0.0". Since minor patch-level changes don't introduce new policy, it was thought it would be better to relax policy and only require the first 3 components to be specified, in this example "2.3.0". All four components may still be used if someone wishes to do so. -- Colin Watson [EMAIL PROTECTED]
Re: RFS: fig2sxd
On Wed, Jan 28, 2004 at 06:45:41PM +0100, Alexander Bürger wrote: > Hi, > > Argh. This is just plainly _wrong_. Read policy and developers reference > > about versioning what -2.1 actually means... > > I'm sorry, but I cannot find anything negative about 2.1 as debian > revision. Debian revisions x.1, x.2, etc. are generally used for non-maintainer uploads. -- Colin Watson [EMAIL PROTECTED]
Re: Help with my program
On Wed, Feb 11, 2004 at 09:01:57PM +0100, Nico Golde wrote: > Hallo Frank, > * Frank Küster <[EMAIL PROTECTED]> [2004-02-11 20:07]: > > > every program must have a man page? > > > > Policy, 12.1: > > > > , > > | Each program, utility, and function should have an associated manual > > | page included in the same package. It is suggested that all > > | configuration files also have a manual page included as well. Manual > > | pages for protocols and other auxiliary things are optional. > > ` > > > > Why are you surprised? If it's because you prefer info, you can just > > provide a minimal manpage and refer to the info documentation in it. > > I am surprised because i saw programs with an automatic created debian > manpage or without a manpage. It's a bug not to have a man page. Sadly, we have bugs ... -- Colin Watson [EMAIL PROTECTED]
Re: buildd problem
On Mon, Feb 16, 2004 at 11:19:54AM -0500, John Belmonte wrote: > Not being much of a buildd expert, I'm wondering what is keeping my > xmlsec1 package from entering testing. There was a problem with the > s390 build attempted Feb 05: "libgnutls10-dev missing". However, I see > that the s390 binary of libgnutls10-dev has been available since Feb 10. > Will this take care of itself or must I do something to trigger a new > build attempt? It appears to be in the queue to be rebuilt (or possibly signed and uploaded by the buildd admin) at the moment, so for now I'd say just wait. -- Colin Watson [EMAIL PROTECTED]
Re: RFS: xhangglider package uploaded to mentors
On Tue, Feb 17, 2004 at 12:07:28AM -0800, Joshua Kwan wrote: > 2) You should remove Makefile from the orig.tar.gz in the clean target at > some point and upload a new one. Currently, refreshing the Makefile that > came in the orig.tar.gz causes major diff.gz bloat: Huh? I haven't looked at this, but why would one generate a new .orig.tar.gz that isn't original? .diff.gz bloat is to be lived with. -- Colin Watson [EMAIL PROTECTED]
Re: RFS: xhangglider package uploaded to mentors
On Tue, Feb 17, 2004 at 02:42:20AM -0800, Joshua Kwan wrote: > On Tue, Feb 17, 2004 at 10:16:17AM +0000, Colin Watson wrote: > > Huh? I haven't looked at this, but why would one generate a new > > .orig.tar.gz that isn't original? .diff.gz bloat is to be lived with. > > I guess the line between keeping the diff.gz bloat and orig.tar.gz > constant with upstream is a gray area. > > For example, I've had to re-tar the Visual Boy Advance sources just now > because it extracted as VisualBoyAdvance-1.7.1 and not > visualboyadvance-1.7.1, as dpkg-source expects (or at least prefers.) Is > that not justified? Not in my book, no. dpkg-source has been happy with .orig.tar.gz extracting to a different name for a long time now. To suppress warnings, you should just need to build from a directory called visualboyadvance-1.7.1. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Multi-person sponsorship
On Thu, Feb 19, 2004 at 06:42:42PM +1100, Matthew Palmer wrote: > On Wed, Feb 18, 2004 at 10:08:34AM +, Thomas Viehmann wrote: > > Maybe you could also reuse / build upon rene from the dak suite. (Maybe > > it's not > > That's the problem with the FTP masters naming everything after women - > nobody else has the slightest idea of what does what... In case you haven't seen it: http://cvs.debian.org/dak/docs/README.names?cvsroot=dak -- Colin Watson [EMAIL PROTECTED]
Re: Restoring cooledit to Debian, perhaps RFS
On Fri, Mar 05, 2004 at 12:09:10AM -0600, [EMAIL PROTECTED] wrote: > I've been thinking sometime about trying to adopt the orphaned package > cooledit since i use it every day and like it a lot. I really think > it should be included in the Debian distro. When checking the orphan > list the other day i noticed it has been removed from unstable and the > orphan bug archived which has finally spurred me into action. In > order to include it again, would it need to come in as a new package > or can it still be adopted? It needs to come in as a new package. It should be easier since you can reuse the old packaging, though (grab it from snapshot.debian.net if nothing else). Do check for bugs against it that were closed by the removal, though. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Renaming a package, proper values for replaces/conflicts?
On Sun, Mar 07, 2004 at 11:23:40AM +0100, Andreas Metzler wrote:
> When jumping from 4.3 to 4.5 I'd like to rename pgrep to pcregrep and
> to provide seamless upgrades I'd introduce a dummy package pgrep
> depending on pcregrep, however replaces/conflicts gives me a headache.
>
> Package: pcregrep
> Architecture: any
> Depends: ${shlibs:Depends}
> Conflicts: pgrep(<<4.5)
> Replaces: pgrep(<<4.5)
>
> Package: pgrep
> Section: oldlibs
> Architecture: all
> Depends: pcregrep
>
> This looks correct, doesn't it? Any[1] version of pgrep fulfilling (<<4.5)
> is no dummy package and contains /usr/bin/pcregrep, therefore pcregrep
> must conflict with it.
I think you just need Replaces: pgrep (<< 4.5), not Conflicts: at all.
It's a straightforward file conflict. Conflicts: makes the upgrade
painful because it adds extra complexity to the unpack order: this is
why policy recommends against it.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
