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
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
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: 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: 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: 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: 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]
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: 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: 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: 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
[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
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: 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: 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: 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: still need a sponsor for quik
On Sun, Jan 02, 2005 at 06:25:38AM -0500, [EMAIL PROTECTED] wrote: > Ce jour Sun, 02 Jan 2005, simon raven a dit: > > i need a sponsor to upload quik, and i need to upload it ASAP. the > > upload i want to do closes a policy bug. i've run linda and lintian on > > it, and both check out a-ok. > > URI to .dsc & .diff.gz files: > > http://simonraven.nuit.ca/src/quik/quik_2.1-3.diff.gz > http://simonraven.nuit.ca/src/quik/quik_2.1-3.dsc Uploaded. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: About creating .deb packages
On Wed, Dec 29, 2004 at 10:58:09PM -0800, TIFR students wrote: > We would like to know which files are absolutely necessary for > creating .deb package (assuming u have all the source files needed). > We know about control file,changelog,rules,conffile, n scripts like > postrm,prerm,preinst,postinst. > > We have an idea of contents of a control file.But what is to be > contained in the scripts ? Are rules,changelog and conffile > necessary?? The standard package building scripts in dpkg-dev (and you shouldn't attempt to build Debian packages using anything less, although it's technically possible to put the bytes together in the right order in other ways) require debian/control, debian/changelog, and debian/rules. Debian policy further requires debian/copyright. Depending on the package you're creating, other files may be useful. For your other questions, see the Debian New Maintainer's Guide, the Debian Policy Manual, the documentation in the dpkg-dev package, and the documentation for any package-building helpers you're using. For instance, debhelper has a fine set of man pages. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pkg-classifier appliance
On Tue, Dec 14, 2004 at 09:12:02AM -0400, vegetax wrote: > martin f krafft wrote: > > also sprach vegetax <[EMAIL PROTECTED]> [2004.12.14.1346 +0100]: > >> The url for the tgz containing the source code, just 1 python file > >> and a README is http://files.bighosting.net/lh13023.zip , can > >> someone please check it and upload it to the testing or unstable > >> dist ? > > > > Please read the Debian NM FAQ and submit all files that we need. > > Sorry =P , here it is again a zip that contains: > > |-- pkg-classifier_0.5-1.dsc > |-- pkg-classifier_0.5-1.tar.gz > |-- pkg-classifier_0.5-1_i386.changes > |-- pkg-classifier_0.5-1_i386.deb Hmm, if it's python then why does it need to be architecture-specific? -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: some questions on multiple binaries per source
On Wed, Dec 01, 2004 at 03:38:40PM -0500, Justin Pryzby wrote: > On Wed, Dec 01, 2004 at 09:06:24PM +0100, Eric Lavarde wrote: > > - more specific question: one of the additional packages is a plugin, > > FreeMind itself "requires" Java, the plugin "requires" Java and > > FreeMind. Am I supposed to write in the control file that the plugin > > does depend on Java, if it's already depending on something that depend > > on Java? > > Nope, Debian is sane like that. However, if the plugin itself uses Java, it should also depend on it directly. Consider (however unlikely) that FreeMind stopped using Java; if the plugin still must have Java itself independent of FreeMind, it should have its own dependency on it. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [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: 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [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 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [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: 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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debuild: producing diff.gz and signing issues
On Wed, Sep 29, 2004 at 05:58:52PM +0200, Alexandre wrote: > On Wed, Sep 29, 2004 at 06:47:46PM +0300, George Danchev wrote: > > * I am always asked twice to provide my passphrase when signing the .dsc > > and > > other files after the build. > > I think this is normal (but if someone has a way around this, I'm > interested). It happens because the md5sum of the signed .dsc has to be included in the .changes, so two separate gpg runs are required. -- Colin Watson [EMAIL PROTECTED]
Re: debuild: producing diff.gz and signing issues
On Wed, Sep 29, 2004 at 05:58:52PM +0200, Alexandre wrote: > On Wed, Sep 29, 2004 at 06:47:46PM +0300, George Danchev wrote: > > * I am always asked twice to provide my passphrase when signing the .dsc and > > other files after the build. > > I think this is normal (but if someone has a way around this, I'm > interested). It happens because the md5sum of the signed .dsc has to be included in the .changes, so two separate gpg runs are required. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On Sat, Sep 04, 2004 at 02:50:35PM +0100, James Troup wrote: > Colin Watson <[EMAIL PROTECTED]> writes: > > On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote: > >> Why do you call dpatch 'obfuscated' ? > >> Before I used it for one of my packages i quickly checked the code and it > >> simply works. No big fancy stuff etc. > >> > >> Did I miss a part? > > > > Compared to simply making the source changes directly, it's obfuscated. > > Personally I find a bunch of unrelated changes lumped together in a > big diff (like, say, in openssh to pick a purely random example) is a > much worse obfuscation than being forced to learn './debian/rules > patch'. Or 'debian/rules patched-source' or 'debian/rules source.make' or 'make -f debian/scripts/somethingorother blah' or any number of other things; every time I unpack a separated-patches source package and want to look at it I always have to either read lots of twisty included makefiles (and my make is pretty fluent, I dread to think what it would be like if it weren't) or else run random debian/rules targets until I find one that works. Sometimes I just give up, run 'debian/rules build', and Ctrl-C it part-way through, which is just crap. If they all had the common decency to use the same simple target name I probably wouldn't mind, but every patch system in Debian is so freaking NIH that they're never going to cooperate enough for that to happen. openssh is not my most shining example of source packaging; it's maintained in a strange way (CVS, God help me) for historical reasons. Some day I'll fix it. > > I recommend using a good revision control system instead, which > > offers similar benefits to developers while leaving things clear for > > users. > > A good revision control system is of little use to other developers if > it's not available to them ... Like I say, I'm happy with the patches being exposed in debian/patches/, I just want them pre-applied if they're there. perl does this, and it's *so* much easier to deal with. Lots of people arguing for patch systems are arguing for their own convenience, not for other people's. Revision control should be able to solve that part of the puzzle. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On Sat, Sep 04, 2004 at 09:17:20AM +0200, Andreas Metzler wrote: > On 2004-09-04 Colin Watson <[EMAIL PROTECTED]> wrote: > > I recommend using a good revision control system instead, which offers > > similar benefits to developers while leaving things clear for users. > > I disagree that this is so clear-cut. The still most popular system > CVS simply does not offer this functionality. e.g. you have two > distinct patchsets: patchset A fixing issue A touching files 1, 2, > and 3 and patchset B fixing issue B touching files 2, 3 and 4. > > CVS simply does not offer the possibility to keep these patchsets > separate (except for checking in diff-files.) over several generations > of a file. CVS clearly doesn't count as a good revision control system (any more, at least). > I doubt svn favours a lot better in this respect (otherwise why would > xfree-packaging still use a dpatch-like system?) Subversion at least has changesets, so it's not anywhere near as bad. It doesn't have proper merge tracking yet. This is not necessarily a big problem if you don't have too many branches of the repository. I don't think "xfree86 still uses separated patches" implies that Subversion can't do what you want here; it implies that the xfree86 maintainers didn't want to overhaul their build system too much when they moved to Subversion and have had better things to do since, but that's about it. I believe xfree86's build system is derived from an early version of DBS. > Bitkeeper can do it, and I guess arch, too. Arch can, yes. > If you are thinking "use separate .diff files in your repository but > upload a plain diff.gz with everything mangled together" I disagree. > I'd rather have slightly more complicated but usable sourcepackages in > the archive. I don't mind if there's also a debian/patches/ directory in the source package (yes, I know that would double the size of the diff, but I don't think that's important), but I think it should be a requirement that 'dpkg-source -x foo.dsc' should produce the code that is built. (I don't expect this requirement to start being fulfilled again in Debian any time soon, but that doesn't stop me trying to stop the situation getting worse.) Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On Sat, Sep 04, 2004 at 02:50:35PM +0100, James Troup wrote: > Colin Watson <[EMAIL PROTECTED]> writes: > > On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote: > >> Why do you call dpatch 'obfuscated' ? > >> Before I used it for one of my packages i quickly checked the code and it > >> simply works. No big fancy stuff etc. > >> > >> Did I miss a part? > > > > Compared to simply making the source changes directly, it's obfuscated. > > Personally I find a bunch of unrelated changes lumped together in a > big diff (like, say, in openssh to pick a purely random example) is a > much worse obfuscation than being forced to learn './debian/rules > patch'. Or 'debian/rules patched-source' or 'debian/rules source.make' or 'make -f debian/scripts/somethingorother blah' or any number of other things; every time I unpack a separated-patches source package and want to look at it I always have to either read lots of twisty included makefiles (and my make is pretty fluent, I dread to think what it would be like if it weren't) or else run random debian/rules targets until I find one that works. Sometimes I just give up, run 'debian/rules build', and Ctrl-C it part-way through, which is just crap. If they all had the common decency to use the same simple target name I probably wouldn't mind, but every patch system in Debian is so freaking NIH that they're never going to cooperate enough for that to happen. openssh is not my most shining example of source packaging; it's maintained in a strange way (CVS, God help me) for historical reasons. Some day I'll fix it. > > I recommend using a good revision control system instead, which > > offers similar benefits to developers while leaving things clear for > > users. > > A good revision control system is of little use to other developers if > it's not available to them ... Like I say, I'm happy with the patches being exposed in debian/patches/, I just want them pre-applied if they're there. perl does this, and it's *so* much easier to deal with. Lots of people arguing for patch systems are arguing for their own convenience, not for other people's. Revision control should be able to solve that part of the puzzle. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On Sat, Sep 04, 2004 at 09:17:20AM +0200, Andreas Metzler wrote: > On 2004-09-04 Colin Watson <[EMAIL PROTECTED]> wrote: > > I recommend using a good revision control system instead, which offers > > similar benefits to developers while leaving things clear for users. > > I disagree that this is so clear-cut. The still most popular system > CVS simply does not offer this functionality. e.g. you have two > distinct patchsets: patchset A fixing issue A touching files 1, 2, > and 3 and patchset B fixing issue B touching files 2, 3 and 4. > > CVS simply does not offer the possibility to keep these patchsets > separate (except for checking in diff-files.) over several generations > of a file. CVS clearly doesn't count as a good revision control system (any more, at least). > I doubt svn favours a lot better in this respect (otherwise why would > xfree-packaging still use a dpatch-like system?) Subversion at least has changesets, so it's not anywhere near as bad. It doesn't have proper merge tracking yet. This is not necessarily a big problem if you don't have too many branches of the repository. I don't think "xfree86 still uses separated patches" implies that Subversion can't do what you want here; it implies that the xfree86 maintainers didn't want to overhaul their build system too much when they moved to Subversion and have had better things to do since, but that's about it. I believe xfree86's build system is derived from an early version of DBS. > Bitkeeper can do it, and I guess arch, too. Arch can, yes. > If you are thinking "use separate .diff files in your repository but > upload a plain diff.gz with everything mangled together" I disagree. > I'd rather have slightly more complicated but usable sourcepackages in > the archive. I don't mind if there's also a debian/patches/ directory in the source package (yes, I know that would double the size of the diff, but I don't think that's important), but I think it should be a requirement that 'dpkg-source -x foo.dsc' should produce the code that is built. (I don't expect this requirement to start being fulfilled again in Debian any time soon, but that doesn't stop me trying to stop the situation getting worse.) Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote: > On Fri, Sep 03, 2004 at 07:04:52PM +0100, Colin Watson wrote: > > ... or indeed any such obfuscated patching system ... > > Why do you call dpatch 'obfuscated' ? > Before I used it for one of my packages i quickly checked the code and it > simply works. No big fancy stuff etc. > > Did I miss a part? Compared to simply making the source changes directly, it's obfuscated. It's also obfuscated for users who can no longer use 'dpkg-source -x' (as documented since the dawn of time) to see the source code from which programs are built; instead, they have to hunt through a maze of twisty makefiles in order to work out the correct debian/rules invocation to produce the patched source, which is different for almost every patch system used in Debian and is often poorly documented. I recommend using a good revision control system instead, which offers similar benefits to developers while leaving things clear for users. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On Fri, Sep 03, 2004 at 11:02:26PM +0200, Michael Schiansky wrote: > On Fri, Sep 03, 2004 at 07:04:52PM +0100, Colin Watson wrote: > > ... or indeed any such obfuscated patching system ... > > Why do you call dpatch 'obfuscated' ? > Before I used it for one of my packages i quickly checked the code and it > simply works. No big fancy stuff etc. > > Did I miss a part? Compared to simply making the source changes directly, it's obfuscated. It's also obfuscated for users who can no longer use 'dpkg-source -x' (as documented since the dawn of time) to see the source code from which programs are built; instead, they have to hunt through a maze of twisty makefiles in order to work out the correct debian/rules invocation to produce the patched source, which is different for almost every patch system used in Debian and is often poorly documented. I recommend using a good revision control system instead, which offers similar benefits to developers while leaving things clear for users. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On Fri, Sep 03, 2004 at 07:26:56PM +0200, Nicolas Boullis wrote: > On Fri, Sep 03, 2004 at 03:08:28PM +0200, Michael Schiansky wrote: > > Remarks: > > > > - diff.gz > >please use dpatch to manage paches on upstream source > > Since when is the use of dpatch mandatory? ... or indeed any such obfuscated patching system ... -- Colin Watson [EMAIL PROTECTED]
Re: RFS: viewglob -- A graphical display of directories referenced at the shell prompt
On Fri, Sep 03, 2004 at 07:26:56PM +0200, Nicolas Boullis wrote: > On Fri, Sep 03, 2004 at 03:08:28PM +0200, Michael Schiansky wrote: > > Remarks: > > > > - diff.gz > >please use dpatch to manage paches on upstream source > > Since when is the use of dpatch mandatory? ... or indeed any such obfuscated patching system ... -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: streamline
On Tue, Aug 31, 2004 at 03:00:00PM -0400, Michael MacFadden wrote: > Allow me to be ignorant for a moment. I am familiar with using apt-src > to get the source for packages, so I sort of know what is in a source > package. But I am not sure what makes up a source package for > "uploading". When I built the package (according to the new maintainers > guide) the following files were generated: > > streamline_0.0.20040901-1_all.deb > streamline_0.0.20040901-1.diff.gz > streamline_0.0.20040901-1.dsc > streamline_0.0.20040901-1_i386.changes > streamline_0.0.20040901.orig.tar.gz Formally, a source package consists of a .dsc plus the files mentioned in its Files: section, which are currently either .orig.tar.gz+.diff.gz or .tar.gz. A binary package consists of a .deb or a .udeb. An upload consists of a .changes plus the files mentioned in its Files: section. These files may be any of the above (or occasionally other objects, for those who know what they're doing and have cleared the BYHAND upload with ftpmaster). If the upload includes a .dsc, it is "sourceful", otherwise it's "binary-only". If a particular .orig.tar.gz has been part of a previous upload, it need not and probably should not be mentioned in later .changes that use the same original upstream source archive. HTH, -- Colin Watson [EMAIL PROTECTED]
Re: RFS: streamline
On Tue, Aug 31, 2004 at 03:00:00PM -0400, Michael MacFadden wrote: > Allow me to be ignorant for a moment. I am familiar with using apt-src > to get the source for packages, so I sort of know what is in a source > package. But I am not sure what makes up a source package for > "uploading". When I built the package (according to the new maintainers > guide) the following files were generated: > > streamline_0.0.20040901-1_all.deb > streamline_0.0.20040901-1.diff.gz > streamline_0.0.20040901-1.dsc > streamline_0.0.20040901-1_i386.changes > streamline_0.0.20040901.orig.tar.gz Formally, a source package consists of a .dsc plus the files mentioned in its Files: section, which are currently either .orig.tar.gz+.diff.gz or .tar.gz. A binary package consists of a .deb or a .udeb. An upload consists of a .changes plus the files mentioned in its Files: section. These files may be any of the above (or occasionally other objects, for those who know what they're doing and have cleared the BYHAND upload with ftpmaster). If the upload includes a .dsc, it is "sourceful", otherwise it's "binary-only". If a particular .orig.tar.gz has been part of a previous upload, it need not and probably should not be mentioned in later .changes that use the same original upstream source archive. HTH, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor for a new package
On Thu, Aug 26, 2004 at 03:52:34PM -0300, Nelson A. de Oliveira wrote: > So... even with the author giving us permission to put Raster3D on > Debian, it's necessary to have a license? Explicit permission to distribute should be enough for non-free. Include all the documentation you have (e.g. the text of an e-mail) in debian/copyright. > And using Raster3D for commercial purposes, still includes it on > non-free category? Restrictions on commercial use definitely exclude it from main. Sounds like non-free. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Sponsor for a new package
On Thu, Aug 26, 2004 at 03:52:34PM -0300, Nelson A. de Oliveira wrote: > So... even with the author giving us permission to put Raster3D on > Debian, it's necessary to have a license? Explicit permission to distribute should be enough for non-free. Include all the documentation you have (e.g. the text of an e-mail) in debian/copyright. > And using Raster3D for commercial purposes, still includes it on > non-free category? Restrictions on commercial use definitely exclude it from main. Sounds like non-free. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: uninstallable on hurd-i386 sh
On Thu, Aug 05, 2004 at 07:19:58PM +0200, Luk Claes wrote: > Christoph Wegscheider wrote: > | I have one sponsored package in the archive (rsnapshot) and > | http://qa.debian.org/[EMAIL PROTECTED] > | shows me under Uninstallable->unstable->hurd-i386 sh. > | > | * What does uninstallable means here? missing dependencies? > > I think it means: not tried yet. Because neither hurd, nor sh are part > of the official release. sh doesn't even have a libc6 in the archive. I always ignore both of these. -- Colin Watson [EMAIL PROTECTED]
Re: simple cron packaging question
On Thu, Aug 05, 2004 at 08:42:50AM -0700, Josh Lauricha wrote: > On Thu 08/05/04 17:35, Brian Sutherland wrote: > > Make sure that if the package is uninstalled, the cron job is > > disabled? > > I'd do something like: > # a bunch of lines for setting the command-line options or sourceing > # /etc/default/ > [ -f /usr/lib//scriptname ] && /usr/lib//scriptname Be careful about that in 'set -e' mode or if non-zero exit statuses will be otherwise reported. I often use one of these idioms instead: if [ -f /usr/lib//scriptname ]; then /usr/lib//scriptname; fi [ ! -f /usr/lib//scriptname ] || /usr/lib//scriptname Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: buildds
On Thu, Aug 05, 2004 at 07:29:02PM +0200, Alexander List wrote: > On Thu, 5 Aug 2004, Andreas Metzler wrote: > > The autobuilders will not build nonfree packages no matter what you > > try. - You can build manually on one of Debian's machines if you are > > a DD. > > OK, how do I cope with missing build-depends? I tried to build on one of > the chroots on pergolesi, but that doesn't know about dpkg-checkbuilddeps > or dpkg-buildpackage... There's no point in building on pergolesi for uploads to the archive yet anyway. amd64 isn't in unstable. -- Colin Watson [EMAIL PROTECTED]
Re: uninstallable on hurd-i386 sh
On Thu, Aug 05, 2004 at 07:19:58PM +0200, Luk Claes wrote: > Christoph Wegscheider wrote: > | I have one sponsored package in the archive (rsnapshot) and > | http://qa.debian.org/[EMAIL PROTECTED] > | shows me under Uninstallable->unstable->hurd-i386 sh. > | > | * What does uninstallable means here? missing dependencies? > > I think it means: not tried yet. Because neither hurd, nor sh are part > of the official release. sh doesn't even have a libc6 in the archive. I always ignore both of these. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: simple cron packaging question
On Thu, Aug 05, 2004 at 08:42:50AM -0700, Josh Lauricha wrote: > On Thu 08/05/04 17:35, Brian Sutherland wrote: > > Make sure that if the package is uninstalled, the cron job is > > disabled? > > I'd do something like: > # a bunch of lines for setting the command-line options or sourceing > # /etc/default/ > [ -f /usr/lib//scriptname ] && /usr/lib//scriptname Be careful about that in 'set -e' mode or if non-zero exit statuses will be otherwise reported. I often use one of these idioms instead: if [ -f /usr/lib//scriptname ]; then /usr/lib//scriptname; fi [ ! -f /usr/lib//scriptname ] || /usr/lib//scriptname Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildds
On Thu, Aug 05, 2004 at 07:29:02PM +0200, Alexander List wrote: > On Thu, 5 Aug 2004, Andreas Metzler wrote: > > The autobuilders will not build nonfree packages no matter what you > > try. - You can build manually on one of Debian's machines if you are > > a DD. > > OK, how do I cope with missing build-depends? I tried to build on one of > the chroots on pergolesi, but that doesn't know about dpkg-checkbuilddeps > or dpkg-buildpackage... There's no point in building on pergolesi for uploads to the archive yet anyway. amd64 isn't in unstable. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Build-Conficts: gcc-3.3, and varargs
On Sat, Jul 31, 2004 at 08:39:52PM -0400, Justin Pryzby wrote: > If I read the code, it seems like there's something funky with the first > variable argument. What I have for now is: > > -Tcl_AppendResult(Tcl_Interp *interp, char *p, va_alist) > +void Tcl_AppendResult(Tcl_Interp *interp, ...) > > Can this be right (neglecting the char *p parameter)? It seems like > they're reading in the first argument (the constant, interp) using > va_arg. That's why I left out p; it never gets used! It's usually better to leave char *p in the prototype and adjust the code that's using it to use that argument as a normal function argument, then read the remaining arguments using va_arg(). Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: for a Perl script to find a module
On Sun, Aug 01, 2004 at 12:23:17AM +, Thaddeus H. Black wrote:
> That is the problem. After a fair bit of experimentation, here is my
> kludge of a solution thus far:
>
> BEGIN {
> my $dir = `readlink -f $0`;
> chomp $dir;
> $dir =~ s/^(.*)\/.*?$/$1/ or $dir = '.';
> unshift @INC, $dir;
> }
> use MyModule;
>
> Does this kludge work? Yes, it does seem to work, but it's a kludge,
> and it's not right. It marshals a BEGIN block and a foreign utility
> program to trick perl into doing something simple and straightforward.
> Even if it were not ugly, it is sly and I cannot trust it. How can I
> fix it? All I want the script to do is to find a module. The module
> is not sneaking around, hiding somewhere, after all; it stands right
> there at the script's shoulder, ready to serve.
Use the FindBin module. It's in the perl-modules package.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
Re: Build-Conficts: gcc-3.3, and varargs
On Sat, Jul 31, 2004 at 08:39:52PM -0400, Justin Pryzby wrote: > If I read the code, it seems like there's something funky with the first > variable argument. What I have for now is: > > -Tcl_AppendResult(Tcl_Interp *interp, char *p, va_alist) > +void Tcl_AppendResult(Tcl_Interp *interp, ...) > > Can this be right (neglecting the char *p parameter)? It seems like > they're reading in the first argument (the constant, interp) using > va_arg. That's why I left out p; it never gets used! It's usually better to leave char *p in the prototype and adjust the code that's using it to use that argument as a normal function argument, then read the remaining arguments using va_arg(). Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: for a Perl script to find a module
On Sun, Aug 01, 2004 at 12:23:17AM +, Thaddeus H. Black wrote:
> That is the problem. After a fair bit of experimentation, here is my
> kludge of a solution thus far:
>
> BEGIN {
> my $dir = `readlink -f $0`;
> chomp $dir;
> $dir =~ s/^(.*)\/.*?$/$1/ or $dir = '.';
> unshift @INC, $dir;
> }
> use MyModule;
>
> Does this kludge work? Yes, it does seem to work, but it's a kludge,
> and it's not right. It marshals a BEGIN block and a foreign utility
> program to trick perl into doing something simple and straightforward.
> Even if it were not ugly, it is sly and I cannot trust it. How can I
> fix it? All I want the script to do is to find a module. The module
> is not sneaking around, hiding somewhere, after all; it stands right
> there at the script's shoulder, ready to serve.
Use the FindBin module. It's in the perl-modules package.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gbuffy (adopted)
On Thu, Jul 29, 2004 at 12:11:25PM +0200, Nico Golde wrote: > * Adeodato Simó <[EMAIL PROTECTED]> [2004-07-29 11:43]: > > I'm looking for a sponsor to upload a new gbuffy version for me. I've > > decided to adopt the gbuffy package since it is in bad shape, I use it > > every day and I wouldn't like it to be removed from Debian. The wnpp > > bug is #242096. > > i havent checked you complete package, only the changes file in the > attachment. why is the upstream source not listet in the changes file? It's not a new upstream version, so there's no reason for the upstream source to be listed in the .changes file. -- Colin Watson [EMAIL PROTECTED]
Re: RFS: gbuffy (adopted)
On Thu, Jul 29, 2004 at 12:11:25PM +0200, Nico Golde wrote: > * Adeodato Simó <[EMAIL PROTECTED]> [2004-07-29 11:43]: > > I'm looking for a sponsor to upload a new gbuffy version for me. I've > > decided to adopt the gbuffy package since it is in bad shape, I use it > > every day and I wouldn't like it to be removed from Debian. The wnpp > > bug is #242096. > > i havent checked you complete package, only the changes file in the > attachment. why is the upstream source not listet in the changes file? It's not a new upstream version, so there's no reason for the upstream source to be listed in the .changes file. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Seeking sponsor for Emilda and related packages
On Sun, Jul 25, 2004 at 08:12:35PM -0700, Russ Allbery wrote: > This will be fixed in the next release, although unfortunately it will > take a little while for that to percolate into Perl. Note that the > effects of this are probably not obvious unless one uses troff instead of > nroff, and may not be that apparent even then (the hyphens will be a > little shorter than they should be). The effects will be very obvious in a UTF-8 terminal, where you'll see Unicode hyphens instead of the ASCII HYPHEN-MINUS character and thus have problems cutting-and-pasting from man pages. (You can use the workaround in /usr/share/doc/groff/README.Debian locally; upstream disapproves of this being the default, though, and I tend to agree.) Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Seeking sponsor for Emilda and related packages
On Sun, Jul 25, 2004 at 08:12:35PM -0700, Russ Allbery wrote: > This will be fixed in the next release, although unfortunately it will > take a little while for that to percolate into Perl. Note that the > effects of this are probably not obvious unless one uses troff instead of > nroff, and may not be that apparent even then (the hyphens will be a > little shorter than they should be). The effects will be very obvious in a UTF-8 terminal, where you'll see Unicode hyphens instead of the ASCII HYPHEN-MINUS character and thus have problems cutting-and-pasting from man pages. (You can use the workaround in /usr/share/doc/groff/README.Debian locally; upstream disapproves of this being the default, though, and I tend to agree.) Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Silly question about man page
On Fri, Jul 23, 2004 at 08:34:12AM -0400, Nathaniel W. Turner wrote: > On Thursday 22 July 2004 10:39 pm, Justin Pryzby wrote: > > FYI, dh_installman is, by default, commented out in debian/rules, if you > > use dh_make to create debian/. > > > But why on earth would anyone use dh_make when we have cdbs? ;-) > I avoid dh_make (debhelper code is easy to write), but in general I prefer systems with fewer build-dependencies to systems with more build-dependencies. In particular, many of my users find it very helpful if all the build-dependencies are in stable. debhelper is well enough deployed now that that build-dependency isn't a problem, and I find that it enhances readability enough over plain dpkg-dev that it's worth it. I tend to find it very hard to work out what a cdbs package is really doing behind the scenes, though. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Silly question about man page
On Fri, Jul 23, 2004 at 08:34:12AM -0400, Nathaniel W. Turner wrote: > On Thursday 22 July 2004 10:39 pm, Justin Pryzby wrote: > > FYI, dh_installman is, by default, commented out in debian/rules, if you > > use dh_make to create debian/. > > > But why on earth would anyone use dh_make when we have cdbs? ;-) > I avoid dh_make (debhelper code is easy to write), but in general I prefer systems with fewer build-dependencies to systems with more build-dependencies. In particular, many of my users find it very helpful if all the build-dependencies are in stable. debhelper is well enough deployed now that that build-dependency isn't a problem, and I find that it enhances readability enough over plain dpkg-dev that it's worth it. I tend to find it very hard to work out what a cdbs package is really doing behind the scenes, though. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Follow-Up to a pending bug
On Thu, Jul 22, 2004 at 05:43:11PM +0200, Tilman Koschnick wrote: > I'm new to the Debian BTS, so I might ask the obvious... but I didn't > find anything in the documentation. > > I want to make an addition to a bug report tagged pending. It's about > #260810, which suggests a couple of new logcheck rules for postfix. I > want to suggest a change of one of the rules (it's a fairly minor issue > anyway), so what do I do? Re-open the bug, although it is pending upload > and the original thing is fixed alright? You can't reopen the bug, since it isn't closed. > Send a follow-up without changing the state of the bug? This is the right thing to do. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Follow-Up to a pending bug
On Thu, Jul 22, 2004 at 05:43:11PM +0200, Tilman Koschnick wrote: > I'm new to the Debian BTS, so I might ask the obvious... but I didn't > find anything in the documentation. > > I want to make an addition to a bug report tagged pending. It's about > #260810, which suggests a couple of new logcheck rules for postfix. I > want to suggest a change of one of the rules (it's a fairly minor issue > anyway), so what do I do? Re-open the bug, although it is pending upload > and the original thing is fixed alright? You can't reopen the bug, since it isn't closed. > Send a follow-up without changing the state of the bug? This is the right thing to do. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: manpage: Section 1L
On Wed, Jul 21, 2004 at 05:22:39PM +0100, Steve McIntyre wrote: > On Wed, Jul 21, 2004 at 05:07:36PM +0100, Colin Watson wrote: > >I think lintian is way too pedantic here. It doesn't actually make any > >particular difference to anything; the only thing I know of that > >programmatically cares about the section in .TH is dh_installman, and if > >that were a problem for you you'd already know about it. > > I agree. The nas man pages all appear in sections 1nas, 3nas and > 4nas. There are lots of them, and I've just been ignoring the lintian > warnings for a while. You can certainly get rid of the warnings by moving the files, though. -- Colin Watson [EMAIL PROTECTED]
Re: manpage: Section 1L
On Wed, Jul 21, 2004 at 05:51:49PM +0200, Frank Küster wrote: > "Thomas Viehmann" <[EMAIL PROTECTED]> schrieb: > > Here's a random quote from the FHS: > > In addition, some large sets of application-specific manual pages have an > > additional suffix appended to the manual page filename. For example, the MH > > mail handling system manual pages should have mh appended to all MH manuals. > > All X Window System manual pages should have an x appended to the filename. > > > > The L probably stands for latex (OK, you knew that) and if they ship enough > > manpages, they might want to add a suffix. > > Okay, but then all LaTeX-related manpages should have that suffix (and > I'd prefer T for TeX, catching much more manpages). And the files should > be named accordingly, right? If that were the case, you'd want /usr/share/man/man1/foo.1L.gz, yes. This is only really necessary if you're having problems with man page name clashes, though; and I'd prefer '1latex' or '1tex' myself. -- Colin Watson [EMAIL PROTECTED]
Re: manpage: Section 1L
On Wed, Jul 21, 2004 at 04:40:04PM +0200, Frank Küster wrote: > teTeX comes with some manpages of section "1L" according to the header > entry in the file, and lintian complains about > > W: tetex-bin: manpage-section-mismatch usr/share/man/man1/makeindex.1.gz:9 1 > != 1L > > It is clear that a manpage in Debian should not have such a section, > however I would like to know whether this is Debian- (or > Linux-)specific, so that we should change it during packaging, or > whether I should ask upstream to change it. Dr. Google wasn't helpful, > unfortunately. I think lintian is way too pedantic here. It doesn't actually make any particular difference to anything; the only thing I know of that programmatically cares about the section in .TH is dh_installman, and if that were a problem for you you'd already know about it. However, man page sections do vary between Unixes, so it seems reasonable to change this in the packaging. -- Colin Watson [EMAIL PROTECTED]
Re: manpage: Section 1L
On Wed, Jul 21, 2004 at 05:22:39PM +0100, Steve McIntyre wrote: > On Wed, Jul 21, 2004 at 05:07:36PM +0100, Colin Watson wrote: > >I think lintian is way too pedantic here. It doesn't actually make any > >particular difference to anything; the only thing I know of that > >programmatically cares about the section in .TH is dh_installman, and if > >that were a problem for you you'd already know about it. > > I agree. The nas man pages all appear in sections 1nas, 3nas and > 4nas. There are lots of them, and I've just been ignoring the lintian > warnings for a while. You can certainly get rid of the warnings by moving the files, though. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: manpage: Section 1L
On Wed, Jul 21, 2004 at 05:51:49PM +0200, Frank Küster wrote: > "Thomas Viehmann" <[EMAIL PROTECTED]> schrieb: > > Here's a random quote from the FHS: > > In addition, some large sets of application-specific manual pages have an > > additional suffix appended to the manual page filename. For example, the MH > > mail handling system manual pages should have mh appended to all MH manuals. > > All X Window System manual pages should have an x appended to the filename. > > > > The L probably stands for latex (OK, you knew that) and if they ship enough > > manpages, they might want to add a suffix. > > Okay, but then all LaTeX-related manpages should have that suffix (and > I'd prefer T for TeX, catching much more manpages). And the files should > be named accordingly, right? If that were the case, you'd want /usr/share/man/man1/foo.1L.gz, yes. This is only really necessary if you're having problems with man page name clashes, though; and I'd prefer '1latex' or '1tex' myself. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: manpage: Section 1L
On Wed, Jul 21, 2004 at 04:40:04PM +0200, Frank Küster wrote: > teTeX comes with some manpages of section "1L" according to the header > entry in the file, and lintian complains about > > W: tetex-bin: manpage-section-mismatch usr/share/man/man1/makeindex.1.gz:9 1 != 1L > > It is clear that a manpage in Debian should not have such a section, > however I would like to know whether this is Debian- (or > Linux-)specific, so that we should change it during packaging, or > whether I should ask upstream to change it. Dr. Google wasn't helpful, > unfortunately. I think lintian is way too pedantic here. It doesn't actually make any particular difference to anything; the only thing I know of that programmatically cares about the section in .TH is dh_installman, and if that were a problem for you you'd already know about it. However, man page sections do vary between Unixes, so it seems reasonable to change this in the packaging. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packaging newbie...: .svn directories / perldoc --> manpage
On Tue, Jul 06, 2004 at 10:01:40AM +0200, David Weinehall wrote:
> On Tue, Jul 06, 2004 at 08:54:44AM +0100, Colin Watson wrote:
> > On Tue, Jul 06, 2004 at 08:50:38AM +0200, Adrian 'Dagurashibanipal' von
> > Bidder wrote:
> > > (i)
> > > I have the package in subversion, so the .svn directories are included
> > > in the diff. Can I avoid this easily?
> >
> > $ grep DEBUILD_DPKG_BUILDPACKAGE_OPTS .devscripts
> >
> > DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i'(?:^|/).*~$|(?:^|/)\..*\.swp|DEADJOE|(?:/CVS|/RCS|/\.svn|/\.deps)(?:$|/)'
> > -ICVS -I.svn -uc -us"
> >
> > (and then use debuild)
>
> Could this be made a default for debuild, perhaps? I've seen far too
> many packages containing .svn or {arch}-droppings.
The -i part is already the default in dpkg-source (actually its default
is better); it's the -I options that are still needed.
> The number of CVS-droppings seems to be low, either because the
> CVS-users are dwindling, or that they have learned by now...
And even older versions of dpkg-source excluded CVS directories from
diffs by default.
--
Colin Watson [EMAIL PROTECTED]
Re: packaging newbie...: .svn directories / perldoc --> manpage
On Tue, Jul 06, 2004 at 10:01:40AM +0200, David Weinehall wrote:
> On Tue, Jul 06, 2004 at 08:54:44AM +0100, Colin Watson wrote:
> > On Tue, Jul 06, 2004 at 08:50:38AM +0200, Adrian 'Dagurashibanipal' von Bidder
> > wrote:
> > > (i)
> > > I have the package in subversion, so the .svn directories are included
> > > in the diff. Can I avoid this easily?
> >
> > $ grep DEBUILD_DPKG_BUILDPACKAGE_OPTS .devscripts
> >
> > DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i'(?:^|/).*~$|(?:^|/)\..*\.swp|DEADJOE|(?:/CVS|/RCS|/\.svn|/\.deps)(?:$|/)'
> > -ICVS -I.svn -uc -us"
> >
> > (and then use debuild)
>
> Could this be made a default for debuild, perhaps? I've seen far too
> many packages containing .svn or {arch}-droppings.
The -i part is already the default in dpkg-source (actually its default
is better); it's the -I options that are still needed.
> The number of CVS-droppings seems to be low, either because the
> CVS-users are dwindling, or that they have learned by now...
And even older versions of dpkg-source excluded CVS directories from
diffs by default.
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packaging newbie...: .svn directories / perldoc --> manpage
On Tue, Jul 06, 2004 at 08:50:38AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: > (i) > I have the package in subversion, so the .svn directories are included > in the diff. Can I avoid this easily? $ grep DEBUILD_DPKG_BUILDPACKAGE_OPTS .devscripts DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i'(?:^|/).*~$|(?:^|/)\..*\.swp|DEADJOE|(?:/CVS|/RCS|/\.svn|/\.deps)(?:$|/)' -ICVS -I.svn -uc -us" (and then use debuild) > (I looked at cvs-buildpackage a while ago and didn't really like it, > so if svn-buildpackage is similar, I don't think I'll like it.) I avoid svn-buildpackage too. > (ii) > postgrey includes perldoc documentation. Obviously this should be > included with the package as a manpage. That's fairly easy; just run pod2man over it at build-time. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: packaging newbie...: .svn directories / perldoc --> manpage
On Tue, Jul 06, 2004 at 08:50:38AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: > (i) > I have the package in subversion, so the .svn directories are included > in the diff. Can I avoid this easily? $ grep DEBUILD_DPKG_BUILDPACKAGE_OPTS .devscripts DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i'(?:^|/).*~$|(?:^|/)\..*\.swp|DEADJOE|(?:/CVS|/RCS|/\.svn|/\.deps)(?:$|/)' -ICVS -I.svn -uc -us" (and then use debuild) > (I looked at cvs-buildpackage a while ago and didn't really like it, > so if svn-buildpackage is similar, I don't think I'll like it.) I avoid svn-buildpackage too. > (ii) > postgrey includes perldoc documentation. Obviously this should be > included with the package as a manpage. That's fairly easy; just run pod2man over it at build-time. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: cc65 - Cross development suite for 65xxx processors
On Mon, Jul 05, 2004 at 08:04:19PM +1000, Anibal Monsalve Salazar wrote: > On Mon, Jul 05, 2004 at 02:40:51AM -0600, Benjamin Cutler wrote: > >I could pull the compiler out of the package entirely, but one problem with > >that is that it's required to build some of the libraries that come with the > >package. I'd have to make some rather sweeping changes to the upstream > >tarball, removing the non-free bits or the bits that need non-free to build. > >It's possible, but impractical and I'm not totally sure it's worth the > >effort, to be honest. Perhaps you could make some suggestions on how exactly > >to split the free parts out? I have some ideas myself but I'd like to hear > >yours. :) > > The upstream tarball shouldn't be changed [0]: That's certainly desirable, but there's very good precedent for modifying upstream tarballs when necessary, such as removing non-free material. -- Colin Watson [EMAIL PROTECTED]
Re: RFS: cc65 - Cross development suite for 65xxx processors
On Mon, Jul 05, 2004 at 08:04:19PM +1000, Anibal Monsalve Salazar wrote: > On Mon, Jul 05, 2004 at 02:40:51AM -0600, Benjamin Cutler wrote: > >I could pull the compiler out of the package entirely, but one problem with > >that is that it's required to build some of the libraries that come with the > >package. I'd have to make some rather sweeping changes to the upstream > >tarball, removing the non-free bits or the bits that need non-free to build. > >It's possible, but impractical and I'm not totally sure it's worth the > >effort, to be honest. Perhaps you could make some suggestions on how exactly > >to split the free parts out? I have some ideas myself but I'd like to hear > >yours. :) > > The upstream tarball shouldn't be changed [0]: That's certainly desirable, but there's very good precedent for modifying upstream tarballs when necessary, such as removing non-free material. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CVS versions
On Sun, Jul 04, 2004 at 07:02:08PM +0400, Dan Korostelev wrote: > How to properly debianize and maintain CVS versions of software? There's > no tarballs Make one yourself from whatever you're using as upstream source. For instance, if upstream has a 'make dist' target or similar, you could run that yourself. > and no in directory name. That doesn't actually matter, despite dpkg-source's warnings. -- Colin Watson [EMAIL PROTECTED]
Re: CVS versions
On Sun, Jul 04, 2004 at 07:02:08PM +0400, Dan Korostelev wrote: > How to properly debianize and maintain CVS versions of software? There's > no tarballs Make one yourself from whatever you're using as upstream source. For instance, if upstream has a 'make dist' target or similar, you could run that yourself. > and no in directory name. That doesn't actually matter, despite dpkg-source's warnings. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: akregator - RSS feed aggregator for KDE
On Sat, Jul 03, 2004 at 01:32:37PM +0200, Pierre HABOUZIT wrote: > But I have a doubt suddently, since the (close: #ITP_nb) is not in the > changelog of the _last_ revision ... Do I need it to be in the last > revision to be taken into account ? dpkg-buildpackage -v is your friend. -- Colin Watson [EMAIL PROTECTED]
Re: RFS: akregator - RSS feed aggregator for KDE
On Sat, Jul 03, 2004 at 01:32:37PM +0200, Pierre HABOUZIT wrote: > But I have a doubt suddently, since the (close: #ITP_nb) is not in the > changelog of the _last_ revision ... Do I need it to be in the last > revision to be taken into account ? dpkg-buildpackage -v is your friend. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for a sponsor to upload GNOME PPP
On Mon, Jun 28, 2004 at 01:15:58AM +0200, Laszlo 'GCS' Boszormenyi wrote: > * Dan Korostelev <[EMAIL PROTECTED]> [2004-06-28 02:33:37 +0400]: > > On Sun, 2004-06-27 at 23:36 +0200, Nico Golde wrote: > > > > Psst, okay, download it here: > > http://warqraft.sourceforge.net/temporary/ ;-) > > Psst, that's look like a dead project. But be serious; your package has > fatal problems: > 1) in the clean target use 'rm -f debian/gnome-ppp.1' otherwise the > build fails for me, > 2) configure fails with the following: > checking for perl... /usr/bin/perl > configure: error: XML::Parser perl module is required for intltool > > Anyway I think as perl is not build-essential, itself should show up in > Build-Depends even. /usr/bin/perl is in perl-base, which is Essential and therefore build-essential. XML::Parser does need to be in the build-dependencies. -- Colin Watson [EMAIL PROTECTED]
Re: Looking for a sponsor to upload GNOME PPP
On Mon, Jun 28, 2004 at 01:15:58AM +0200, Laszlo 'GCS' Boszormenyi wrote: > * Dan Korostelev <[EMAIL PROTECTED]> [2004-06-28 02:33:37 +0400]: > > On Sun, 2004-06-27 at 23:36 +0200, Nico Golde wrote: > > > > Psst, okay, download it here: > > http://warqraft.sourceforge.net/temporary/ ;-) > > Psst, that's look like a dead project. But be serious; your package has > fatal problems: > 1) in the clean target use 'rm -f debian/gnome-ppp.1' otherwise the > build fails for me, > 2) configure fails with the following: > checking for perl... /usr/bin/perl > configure: error: XML::Parser perl module is required for intltool > > Anyway I think as perl is not build-essential, itself should show up in > Build-Depends even. /usr/bin/perl is in perl-base, which is Essential and therefore build-essential. XML::Parser does need to be in the build-dependencies. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: One Source with Different Build Dependancies?
On Thu, Jun 24, 2004 at 09:17:42PM +0200, Santiago Vila wrote: > On Thu, 24 Jun 2004 [EMAIL PROTECTED] wrote: > > I am packaging source which builds two binary packages; however, each > > package has different build dependancies. In fact, the packages' build > > dependancies conflict. > > > > I don't think the dpkg tools have the facility to build one binary but > > not the other. Nor do I think one can specify different build > > dependancies for two binaries built from the same source. > > > > Could someone please refer me to any discussion of these issues, and > > any solutions? > > I would create two different source packages. Build-dependencies are > certainly not supposed to be installed or removed by debian/rules in > the middle of the build. Yeah. Note that you don't have to chop up the upstream source to do this; in the name of pristine .orig.tar.gz files, you can just upload the full upstream tarball but only build part of it. -- Colin Watson [EMAIL PROTECTED]
Re: One Source with Different Build Dependancies?
On Thu, Jun 24, 2004 at 09:17:42PM +0200, Santiago Vila wrote: > On Thu, 24 Jun 2004 [EMAIL PROTECTED] wrote: > > I am packaging source which builds two binary packages; however, each > > package has different build dependancies. In fact, the packages' build > > dependancies conflict. > > > > I don't think the dpkg tools have the facility to build one binary but > > not the other. Nor do I think one can specify different build > > dependancies for two binaries built from the same source. > > > > Could someone please refer me to any discussion of these issues, and > > any solutions? > > I would create two different source packages. Build-dependencies are > certainly not supposed to be installed or removed by debian/rules in > the middle of the build. Yeah. Note that you don't have to chop up the upstream source to do this; in the name of pristine .orig.tar.gz files, you can just upload the full upstream tarball but only build part of it. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Excluding some architectures
On Wed, Jun 23, 2004 at 11:05:44PM -0400, Kevin B. McCarty wrote: > On Wed, 23 Jun 2004, Frank Lichtenheld wrote: > > The list is > > http://cvs.debian.org/srcdep/Packages-arch-specific?rev=HEAD&cvsroot=dak&content-type=text/vnd.viewcvs-markup > > > > Further instructions are included there. > > Thank you, I've followed them. > > By the way (just out of curiosity), why is such a list necessary when it > just duplicates information already in packages' control files? Historically, packages' control files have been egregiously wrong. "Architecture: i386" was needlessly common at one point. -- Colin Watson [EMAIL PROTECTED]
Re: Excluding some architectures
On Wed, Jun 23, 2004 at 11:05:44PM -0400, Kevin B. McCarty wrote: > On Wed, 23 Jun 2004, Frank Lichtenheld wrote: > > The list is > > http://cvs.debian.org/srcdep/Packages-arch-specific?rev=HEAD&cvsroot=dak&content-type=text/vnd.viewcvs-markup > > > > Further instructions are included there. > > Thank you, I've followed them. > > By the way (just out of curiosity), why is such a list necessary when it > just duplicates information already in packages' control files? Historically, packages' control files have been egregiously wrong. "Architecture: i386" was needlessly common at one point. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Mon, Jun 21, 2004 at 01:05:18PM +0200, Mattia Dongili wrote: > I'm trying to contact ftpmaters asking them to add > xfree86-driver-synaptics to Packages-arch-specific with an '!s390' entry > (as xsever-xfree86 has the same entry there) and to remove the s390 > binary. > > I haven't submitted a bug since this is not a 'complete' removal (as > read on devel-ref 5.9.2) but I wrote to them directly ([EMAIL PROTECTED]). > Am I wrong wrt to this procedure? The file itself (http://buildd.debian.org/quinn-diff/Packages-arch-specific) lists a contact procedure at the top. -- Colin Watson [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Mon, Jun 21, 2004 at 12:32:05PM +0200, Andreas Metzler wrote: > On 2004-06-07 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: > > > On 2004-05-11 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > > > Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 > [...] > > > Personally I'd immediately change the architecture field and change it > > > back once there is a xserver for s390. - You'll probably have to > > > pester ftp-master to remove the old s390 binary, otherwise > > > xfree86-driver-synaptics will be blocked by "out of date on s390". > > > I finally opted for this solution. > [...] > > Hello, > May I ask for status update? > > You have uploaded 0.13.3-1 yesterday with still "Architecture: any" > and it has therefore built and been uploaed by s390 *again*. It doesn't matter what the source package says anyway. In order to get s390 to stop building it, you need to get it added to Packages-arch-specific. -- Colin Watson [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Mon, Jun 21, 2004 at 01:05:18PM +0200, Mattia Dongili wrote: > I'm trying to contact ftpmaters asking them to add > xfree86-driver-synaptics to Packages-arch-specific with an '!s390' entry > (as xsever-xfree86 has the same entry there) and to remove the s390 > binary. > > I haven't submitted a bug since this is not a 'complete' removal (as > read on devel-ref 5.9.2) but I wrote to them directly ([EMAIL PROTECTED]). > Am I wrong wrt to this procedure? The file itself (http://buildd.debian.org/quinn-diff/Packages-arch-specific) lists a contact procedure at the top. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xfree86-driver-synaptics blocked by xserver-xfree86 on s390
On Mon, Jun 21, 2004 at 12:32:05PM +0200, Andreas Metzler wrote: > On 2004-06-07 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > On Tue, May 11, 2004 at 10:03:04AM +0200, Andreas Metzler wrote: > > > On 2004-05-11 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > > > Subject: xfree86-driver-synaptics blocked by xserver-xfree86 on s390 > [...] > > > Personally I'd immediately change the architecture field and change it > > > back once there is a xserver for s390. - You'll probably have to > > > pester ftp-master to remove the old s390 binary, otherwise > > > xfree86-driver-synaptics will be blocked by "out of date on s390". > > > I finally opted for this solution. > [...] > > Hello, > May I ask for status update? > > You have uploaded 0.13.3-1 yesterday with still "Architecture: any" > and it has therefore built and been uploaed by s390 *again*. It doesn't matter what the source package says anyway. In order to get s390 to stop building it, you need to get it added to Packages-arch-specific. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-firebird-general] Request for comments for ibwebadmin package
On Tue, Jun 08, 2004 at 09:16:52AM -0400, Grzegorz B. Prokopski wrote: > On Mon, 2004-06-07 at 19:12, Remco Seesink wrote: > > I am looking for comments about my packaging of ibwebadmin. > > Testers are also welcome. > > Hi Remco, > > Technically I looked fine for me. I have not tested it at runtime > though. In the non-technical part - I see troubles with the > copyright/licensing stuff. > > 1. Why do *you* add the exception that permits for linking w/ some > GPL-incompatible program > a) in a debian-specific diff? The exception has to be granted by > upstream and they have to release a version that has this exception. > You must not add it yourself! > b) at the top of LICENSE file, which is otherwise pure GPL? This > exception seems to fit more into a file that would be called i.e. > COPYING, where the copying informations would be held and which > would contain the "exception" and reference to the pure GPL in LICENSE > file. > > I saw you already contacted upstream about it, but *they* should release > a version that contains the new COPYING rules. I haven't looked at this particular case, but it should be just fine to say "the copyright owner gave permission to do this" (as long as it's not specific to Debian, etc.), without necessarily having to wait for a new upstream release. Of course, I'd be inclined to include the full text of the e-mail in question. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-firebird-general] Request for comments for ibwebadmin package
On Tue, Jun 08, 2004 at 09:16:52AM -0400, Grzegorz B. Prokopski wrote: > On Mon, 2004-06-07 at 19:12, Remco Seesink wrote: > > I am looking for comments about my packaging of ibwebadmin. > > Testers are also welcome. > > Hi Remco, > > Technically I looked fine for me. I have not tested it at runtime > though. In the non-technical part - I see troubles with the > copyright/licensing stuff. > > 1. Why do *you* add the exception that permits for linking w/ some > GPL-incompatible program > a) in a debian-specific diff? The exception has to be granted by > upstream and they have to release a version that has this exception. > You must not add it yourself! > b) at the top of LICENSE file, which is otherwise pure GPL? This > exception seems to fit more into a file that would be called i.e. > COPYING, where the copying informations would be held and which > would contain the "exception" and reference to the pure GPL in LICENSE > file. > > I saw you already contacted upstream about it, but *they* should release > a version that contains the new COPYING rules. I haven't looked at this particular case, but it should be just fine to say "the copyright owner gave permission to do this" (as long as it's not specific to Debian, etc.), without necessarily having to wait for a new upstream release. Of course, I'd be inclined to include the full text of the e-mail in question. -- Colin Watson [EMAIL PROTECTED]
Re: What format package for debian test phase?
On Sat, May 15, 2004 at 09:49:13AM -0700, Halim Boukaram wrote: > I've finished making the rpm for my package. > > Should i convert it to a 'deb' file (using alien) > before trying to get it uploaded to debian test folder > or should it be rpm or tarred. aliened packages won't be accepted into the Debian archive. You need to create a proper Debian source package; there's documentation in the "Developers' Corner" section of the Debian web site. -- Colin Watson [EMAIL PROTECTED]
Re: What format package for debian test phase?
On Sat, May 15, 2004 at 09:49:13AM -0700, Halim Boukaram wrote: > I've finished making the rpm for my package. > > Should i convert it to a 'deb' file (using alien) > before trying to get it uploaded to debian test folder > or should it be rpm or tarred. aliened packages won't be accepted into the Debian archive. You need to create a proper Debian source package; there's documentation in the "Developers' Corner" section of the Debian web site. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pearpc
On Thu, May 13, 2004 at 09:23:33AM +0200, Marcin Orlowski wrote: > I've just uploaded PearPC (pearpc) package to mentors.debian.net and now > look for sponsor for this package. According to the program manual: > > PearPC is an architecture independent PowerPC platform emulator > capable of running most PowerPC operating systems It's kind of disappointing that this hasn't been ported to powerpc itself. :( (Take a look at src/cpu_generic/ppc_tools.h for starters.) Since ppc_tools.h currently hardcodes HOST_IS_X86, I suspect this release will only build on i386. -- Colin Watson [EMAIL PROTECTED]
Re: RFS: pearpc
On Thu, May 13, 2004 at 09:23:33AM +0200, Marcin Orlowski wrote: > I've just uploaded PearPC (pearpc) package to mentors.debian.net and now > look for sponsor for this package. According to the program manual: > > PearPC is an architecture independent PowerPC platform emulator > capable of running most PowerPC operating systems It's kind of disappointing that this hasn't been ported to powerpc itself. :( (Take a look at src/cpu_generic/ppc_tools.h for starters.) Since ppc_tools.h currently hardcodes HOST_IS_X86, I suspect this release will only build on i386. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I've got a orphaned package.
On Sun, May 09, 2004 at 05:34:50PM +0200, Frank Küster wrote: > Matthijs Mohlmann <[EMAIL PROTECTED]> schrieb: > > The package contains, what i think, a serious bug. Do i need to set it > > to critical ? > > If you think that the package should not be released into stable with > this bug, you should. Any of serious, grave, or critical will do. > It seems to me that you should be somewhat slower and more careful with > your maintainer tasks. In the changelog of your latest packages you > write: > > , > | * Changed to debhelper program (Closes #240384) > ` > > I said previously that this is a bad changelog entry, because one > doesn't know which change exactly was made, and how this closes the > bug. But now it seems that you think that this doesn't fix the bug at > all, and need more testing. Furthermore it won't actually close the bug as apparently desired. See the policy manual for the syntax of "closes". -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I've got a orphaned package.
On Sun, May 09, 2004 at 05:34:50PM +0200, Frank Küster wrote: > Matthijs Mohlmann <[EMAIL PROTECTED]> schrieb: > > The package contains, what i think, a serious bug. Do i need to set it > > to critical ? > > If you think that the package should not be released into stable with > this bug, you should. Any of serious, grave, or critical will do. > It seems to me that you should be somewhat slower and more careful with > your maintainer tasks. In the changelog of your latest packages you > write: > > , > | * Changed to debhelper program (Closes #240384) > ` > > I said previously that this is a bad changelog entry, because one > doesn't know which change exactly was made, and how this closes the > bug. But now it seems that you think that this doesn't fix the bug at > all, and need more testing. Furthermore it won't actually close the bug as apparently desired. See the policy manual for the syntax of "closes". -- Colin Watson [EMAIL PROTECTED]
Re: Attending a RFP
On Wed, May 05, 2004 at 09:26:20PM +0200, Robert Lemmen wrote: > On Wed, May 05, 2004 at 12:16:40PM -0700, Matt Brubeck wrote: > > The WNPP page (linked above, and from the Developer's Reference) says: > > > > RFP: If you are going to package this, retitle the bug report to > > replace 'RFP' with 'ITP', in order for other people to know the > > program is already being packaged, and set yourself as the owner of > > the bug. > > ok, so we wrote it down and still tell people who ask (like me) > different things... I evidently missed the previous discussion, but I correct misconceptions where I can. -- Colin Watson [EMAIL PROTECTED]
Re: Attending a RFP
On Wed, May 05, 2004 at 09:31:10PM +0200, Andreas Barth wrote: > * Robert Lemmen ([EMAIL PROTECTED]) [040505 21:25]: > > On Wed, May 05, 2004 at 07:29:27PM +0100, Colin Watson wrote: > > > No, don't change the submitter; change the owner instead. See > > > http://www.debian.org/devel/wnpp/ for instructions. > > > owner makes way more sense. but i think we should definitely write down > > these things somewhere. i have been told to change the submitter of an > > itp i was about to take over ~ 2 weeks ago right here > > "owner" is quite new. Before that, it was to change the submitter. "Quite new" is relative, of course: revision 1.21 date: 2003/09/23 00:10:06; author: cjwatson; state: Exp; lines: +11 -7 Add setting the bug owner to WNPP instructions. -- Colin Watson [EMAIL PROTECTED]
Re: Attending a RFP
On Wed, May 05, 2004 at 09:26:20PM +0200, Robert Lemmen wrote: > On Wed, May 05, 2004 at 12:16:40PM -0700, Matt Brubeck wrote: > > The WNPP page (linked above, and from the Developer's Reference) says: > > > > RFP: If you are going to package this, retitle the bug report to > > replace 'RFP' with 'ITP', in order for other people to know the > > program is already being packaged, and set yourself as the owner of > > the bug. > > ok, so we wrote it down and still tell people who ask (like me) > different things... I evidently missed the previous discussion, but I correct misconceptions where I can. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attending a RFP
On Wed, May 05, 2004 at 09:31:10PM +0200, Andreas Barth wrote: > * Robert Lemmen ([EMAIL PROTECTED]) [040505 21:25]: > > On Wed, May 05, 2004 at 07:29:27PM +0100, Colin Watson wrote: > > > No, don't change the submitter; change the owner instead. See > > > http://www.debian.org/devel/wnpp/ for instructions. > > > owner makes way more sense. but i think we should definitely write down > > these things somewhere. i have been told to change the submitter of an > > itp i was about to take over ~ 2 weeks ago right here > > "owner" is quite new. Before that, it was to change the submitter. "Quite new" is relative, of course: revision 1.21 date: 2003/09/23 00:10:06; author: cjwatson; state: Exp; lines: +11 -7 Add setting the bug owner to WNPP instructions. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Attending a RFP
On Wed, May 05, 2004 at 08:20:23PM +0200, Robert Lemmen wrote: > On Wed, May 05, 2004 at 08:06:37PM +0200, David López Moreno wrote: > > Currently, there is a RFP for the package (Bug #227525). How should I > > proceed?. Do I directly fill an ITP? Will that remove Bug #227525? Or it > > doesn't matter if they co-exist? > > i think the correct way is to retitle the RFP to ITP and change the > submitter to yourself No, don't change the submitter; change the owner instead. See http://www.debian.org/devel/wnpp/ for instructions. -- Colin Watson [EMAIL PROTECTED]
Re: Attending a RFP
On Wed, May 05, 2004 at 08:20:23PM +0200, Robert Lemmen wrote: > On Wed, May 05, 2004 at 08:06:37PM +0200, David López Moreno wrote: > > Currently, there is a RFP for the package (Bug #227525). How should I > > proceed?. Do I directly fill an ITP? Will that remove Bug #227525? Or it > > doesn't matter if they co-exist? > > i think the correct way is to retitle the RFP to ITP and change the > submitter to yourself No, don't change the submitter; change the owner instead. See http://www.debian.org/devel/wnpp/ for instructions. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
