Re: RFS: gift-gnutella (updated package)
Your message is encrypted, please don't send encrypted mail to mailing lists. :-) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A conclusion is simply the place where someone got tired of thinking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to correctly handle different lib trunks
* Salvatore Ansani [Tue, 08 Apr 2008 11:28:30 +0200]: > For example, package lastfm depends on libqt4. > If I use kde 4.0.2 environment my qt4 version is 4.3.x. > When I upgrade to KDE 4.0.6x my qt4 version become 4.4.x so lastfm > package breaks and need to be deleted. > If I recompile lastfm from sources on new libqt4.4-x environment all was > ok and my new lastfm .deb package now correctly depends on libqtcore4 (>= > 4.4.0~beta1). Salvatore, there was an issue in the qt4 beta1 packages in experimental. Long story short (¹), try with 4.4.0~rc1, which was uploaded to experimental today (for amd64; packages for i386 should be there in a couple days). That will solve your problem. As always, thanks to Neil Williams for his always-to-the-point comments. (¹) libqt4-core was renamed to libqtcore4 because of a rearrangement in the package structure; now a meta-package has been put in place, after determining that there was no ABI breakage on mipsen. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Russian roulette in bash: ((RANDOM%6)) || rm -rf ~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: building package with different libs
* Thorsten Alteholz [Fri, 17 Oct 2008 20:06:09 +0200]:
> Hi,
Hello,
> I need some advice on building packages with different libs.
> Assuming that I have software S which needs to be linked against library L.
> For whatever reason there are several implementations (L1, L2, L3) of
> this library available. Each of them has its advantages and it would be
> fine
> to build three packages SL1, SL2 and SL3.
> Unfortunately L1, L2 and L3 conflict each other. So what would be the
> best way to build all three packages from one source package? Is this
> possible at all?
> To make this a bit more realistic: It is about package meep-mpi.
> Currently it uses libhdf5-serial and there is a requet to build it with
> libhdf5-mpich and libhdf5-openmpi. So my Build-Depends: in the source section
> needs to contain either libhdf5-serial-dev, libhdf5-mpich-dev or
> libhdf5-openmpi-dev. Is it still possible to build package
> meep-mpi-hdf5serial,
> meep-mpi-hdf5mpich and meep-mpi-hdf5openmpi at the same time?
If the different implementations conflict among them, I don't think you
can build all three SL{1,2,3} binary packages from the same source
package.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
A hacker does for love what other would not do for money.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: building package with different libs
* Peter Pentchev [Wed, 29 Oct 2008 18:09:07 +0200]:
> > If the different implementations conflict among them, I don't think you
> > can build all three SL{1,2,3} binary packages from the same source
> > package.
> Well, actually, you can - just look at the various apache2 packages.
> However, the build mechanism has to be a bit complicated...
Care to ellaborate? I don't think in that case the build-dependencies
conflict, OR they are built from the same source package.
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Man is certainly stark mad; he cannot make a flea, yet he makes gods by the
dozens.
-- Michel de Montaigne
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bzr-diffstat
* martin f krafft [Thu, 30 Oct 2008 11:07:28 +0100]: > also sprach David Futcher <[EMAIL PROTECTED]> [2008.10.30.1044 +0100]: > > This is mainly an ease of use/usability thing. Ubuntu is trying to > > move to using bzr (and only bzr) for managing packages. Part of > > our freeze exception process requires a diffstat of the patch, so > > the idea was to make creating diffstats from bzr branches as easy > > (and as integrated) as possible. > Doesn't bzr have aliases? Wouldn't it be better to recommend > patchutils and use its diffstat with a pipe? I don't think bzr has support for shelling out in aliases, a-la-git. > Part of the packaging process is to make those decisions, even if > others disagree. I am by no means an authority, but I do think that > this could be solved in a more Unix-y fashion. I hope you'll find > some time to consider it and make the right decision. I think packaging involves some similar decicions, in particular one should try to avoid packaging crap. As for non Unix-y stuff, it should be up to packages who care, IMHO. :-) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Pasión Vega - La canción del pirata -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Different suggests/recomends according to architecture
* Julien Valroff [Fri, 31 Oct 2008 17:53:43 +0100]: > Hi, > I am the maintainer of the ajaxterm package. > I have been provided a patch to allow use of psyco in ajaxterm only if > available. > I would like to ajaxterm to recommend or suggest this package, which is > only available for i386, whereas ajaxterm is an arch:all package. > Is there any way to specify this? > Should I leave psyco anyway, and rely on apt to not try and install it > on architectures where it is not available? > Should I change my package to be arch:any (I guess no, just asking)? I think Recommending or, particularly, Suggesting packages that don't exist in certain arches is ok for arch:all packages, the story being that nobody notices that it doesn't get installed. If it was a Depends, and arch:all package would depend on "psyco | not+i386", which would pull in type-handling on all !i386 arches. There is no point at all in doing that for Recommends, though: you want psyco just not installed, not random crap pulled in. :-) HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org In my opinion, the most fruitful and natural play of the mind is in conversation. I find it sweeter than any other action in life; and if I were forced to choose, I think I would rather lose my sight than my hearing and voice. -- Michel de Montaigne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: fex (2nd attempt)
* Giuseppe Iuculano [Tue, 04 Nov 2008 19:02:33 +0100]: > I installed this service about a month ago, and feedbacks from my users are > extremely positive. Anyway I respect your (authoritative) point of view and so > I'm going to drop my ITP. I don't think the opinion of a single DD qualifies as "authoritative" unless they're speaking with some hat relevant to the case at hand on, which is not the case. If several DDs started telling you this package is not appropriate, that'd be something different. I only hear one voice against this package, so I'd urge you not to let yourself get demotivated because of it. For extra points, you can ask other DDs you already know for their opinion, and work with that. Good luck, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - Oh my God, you're pimping me out for a new roof? - And windows! -- Andrew and Bree Van De Kamp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question regarding package dependance
* Stefanos Harhalakis [Sat, 08 Nov 2008 12:10:49 +0200]:
> Dear mentors,
> I've come up to a situation that I'm not sure how to handle. A package that
> I created and packaged, named 'vbackup', is included in debian unstable [1]
> under the sponsoring of Vincent Bernat (hi Vincent). After getting it from
> the unstable repository I realised that it doesn't work as expected. vbackup
> is a set of shell scripts that use external programs like mdadm, xfsdump,
> tar, etc to perform backups. Since it uses a number of programs that may not
> be already installed I made the configure script auto-detect them.
> For debian I declare those packages as suggested:
> Suggests: xfsdump, mdadm, lvm2, postgresql-client, mysql-client, rpm
> I did this because there is no need to force a user to have postgresql,
> mysql, mdadm, etc installed when they're not used. It seems that the debian
> builder builds this package without providing the 'suggested' packages as
> well. This makes the configure script to fail to detect the proper paths of
> mdadm, psql, mysql, rpm, etc. Since those paths as stored inside a
> compile-time generated script (common.sh) those paths stay empty.
> I find the configure program detection very convenient since it allows
> vbackup to be run under other OSes like IRIX where the gnu tar is installed
> in a different location (which is specified by a --with-tar=... parameter to
> configure).
> So what do you suggest to do with it? I currently consider the following as
> possible solutions:
> a) Make the detection run-time (not good)
> b) Add run-time detection when configure-time detection failed (Working on
> this)
> c) Add a configuration file to hold program locations (Bad - I don't like
> asking for configuration that can be automated)
> d) Make other programs a "Depends" instead of "Suggests" (Not a good idea.
> Right?)
> e) Fill a bug report asking that the builder (pbuild?) also include
> the "Suggests" packages when making a package
> f) Add all 'Suggests' packages as Build-Depends too (is it a good idea?
> ${Suggests} ?)
In my opinion, you should just invoke the configure script with the
paths of all programs as they are found in Debian, eg.:
% ./configure --with-tar=/bin/tar --with-postgresql=/foo
However, I have one question: why does the build process hard-code the
paths found in the build system? Why don't the scripts invoke the
programs without specifying a full path, as it is normally done in
scripts? With your way, people could not install a local version of tar
in eg. /usr/local/bin.
If what worries you is knowing whether the binary is available or not,
that's what "which" is for. IMHO this all belongs to runtime...
> Also, how can I force vbackup to stay in unstable even after lenny is
> released when such bugs are found? (It makes the package mostly unusable). Is
> there a relevant how to? I've looked in maintainer's guide and in developer's
> reference but I didn't find anything related.
Packages stay in unstable by default, unless somebody takes action to
remove them. Does that answer your question?
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Family - El bello verano
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question regarding package dependance
* Stefanos Harhalakis [Sat, 08 Nov 2008 13:51:28 +0200]: > On Saturday 08 November 2008, Adeodato Simó wrote: > > In my opinion, you should just invoke the configure script with the > > paths of all programs as they are found in Debian, eg.: > > % ./configure --with-tar=/bin/tar --with-postgresql=/foo > After accepting the parameters it verifies their validity (program exists, > perhaps the version, etc...) which will not work. That's too bad: if the user gives a path, it should be interpreted that they want that as a compile-time default. > > > Also, how can I force vbackup to stay in unstable even after lenny is > > > released when such bugs are found? (It makes the package mostly > > > unusable). Is there a relevant how to? I've looked in maintainer's guide > > > and in developer's reference but I didn't find anything related. > > Packages stay in unstable by default, unless somebody takes action to > > remove them. Does that answer your question? > I thought that after 10 days the're moved to testing, unless there is a > reason > not to do so. That's what I was referring to. Sorry, I understood your "force backup to stay in unstable" wrong, ironically I didn't think what you wanted to prevent was migration to testing. In order to prevent migration to testing, you should file a bug against your package at severity "serious" explaining the problem that makes the package unsuitable for migration to testing. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Ella Baila Sola - El tiempo de mi felicidad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPG Keys
* Boyd Stephen Smith Jr. [Mon, 10 Nov 2008 03:14:53 -0600]: > I have two GPG keys, one for my laptop and one for my desktop. I've probably > got a third for my VPS, but I don't thinkn that's on the public keyservers > yet and I only use it so my local apt repository is signed. But, I digress. > mentors.d.n seems to want a single GPG key. I imagine that becoming a DD > would probably entail reducing my keys down to one (1) as well. > Unfortunately, I haven't found a good method for accessing a single private > key from the multiple computers I work in front of regularly. > Any suggestions on the best way to do that? In particular I've considered a > USB key, but I'd like it to be automatically mounted in a consistent location > so my always-running-when-I'm-there gnupg-agent (and kgpg) can find it. One option is to copy the .gnupg directory around, as Sandro mentioned (but only to secure systems; a VPS does not qualify). Another option is to use subkeys (http://fortytwo.ch/gpg/subkeys). This way you only have one main key, but portions of it live in different computers. Signatures made with the subparts (subkeys) are equally valid than if they'd be done with the main key. It is true that AFAIK you won't be able to put more than key in the Debian keyring, should you become a DD or a DM. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Johnny Cash - We'll Meet Again -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf questions
* Andreas Tscharner [Mon, 10 Nov 2008 11:31:42 +0100]: > If I execute the .config file, the expected screen (it's a note) is shown Hm, I thought you're not supposed to use debconf to display notes, and that NEWS.Debian is preferred. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Death Cab For Cutie - Marching Bands of Manhattan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libmsn
* Pau Garcia i Quiles [Tue, 18 Nov 2008 18:27:09 +0100]: > On Sun, Nov 16, 2008 at 9:08 PM, Miriam Ruiz wrote: > > 2008/11/15 Pau Garcia i Quiles : > >> It builds these binary packages: > >> libmsn - high-level C++ library for MSN Messenger [runtime] > >> libmsn-dbg - high-level C++ library for MSN Messenger [debug] > >> libmsn-dev - high-level C++ library for MSN Messenger [devel] > > Some quick comments: > > You shouldn't call your runtime library just libmsn, see [1]. You > > definitely shouldn't get rid of that lintian's message with an > > override. > I have renamed the package to 'libmsn0.1'. > Upstream is planning some changes that might affect the API and might > require soversion changes. I used just 'libmsn' not to flood the > archive with 'libmsn0.1', 'libmsn0.2', etc packages in the near > future. In that case, maybe you should only package the static library until the ABI stabilizes. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Any life, no matter how long and complex it may be, is made up of a single moment: the moment in which a man finds out, once and for all, who he is. -- Jorge Luis Borges -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libmsn
* Pau Garcia i Quiles [Tue, 18 Nov 2008 18:39:45 +0100]: > Should I rename the directory in the .orig.tar and make > tamper-checking more difficult, or not rename the directory in the > .orig.tar and make tamper-checking easier? You should not, dpkg-source copes well enough. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Will you just stand still? -- Luke Danes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: repackaged .orig.tar.gz (was: RFS: libmsn)
* gregor herrmann [Tue, 18 Nov 2008 23:15:07 +0100]: > On Tue, 18 Nov 2008 19:01:30 +0100, Adeodato Simó wrote: > > > Should I rename the directory in the .orig.tar and make > > > tamper-checking more difficult, or not rename the directory in the > > > .orig.tar and make tamper-checking easier? > > You should not, dpkg-source copes well enough. > True, on the other hand the Developer's Reference suggests in > 6.7.8.2: > A repackaged .orig.tar.gz > [..] > 4. should use -.orig as the name > of the top-level directory in its tarball. This makes it possible > to distinguish pristine tarballs from repackaged ones. > Is this recommendation moot? No, not really. Note that in this case we were not talking about a repackaged tarball, but just one with the "bunzip & gzip" dance. Incidentally, the version in Debian was to be 4.0~beta1 instead of the upstream 4.0-beta1, and Pau wondered if *this* needed a repacking, which it did not. Hope that was clear enough. :-) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Dar Williams - In Love But Not At Peace -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: repackaged .orig.tar.gz (was: RFS: libmsn)
* Pau Garcia i Quiles [Wed, 19 Nov 2008 00:11:44 +0100]: > >> True, on the other hand the Developer's Reference suggests in > >> 6.7.8.2: > >> A repackaged .orig.tar.gz > >> [..] > >> 4. should use -.orig as the name > >> of the top-level directory in its tarball. This makes it possible > >> to distinguish pristine tarballs from repackaged ones. > >> Is this recommendation moot? > > No, not really. Note that in this case we were not talking about a > > repackaged tarball, but just one with the "bunzip & gzip" dance. > > Incidentally, the version in Debian was to be 4.0~beta1 instead of the > > upstream 4.0-beta1, and Pau wondered if *this* needed a repacking, which > > it did not. > > Hope that was clear enough. :-) > To further clarify: > What Adeodato says would be accurate in case the packagename matches > the directory name, which is not the case here. > To actually match the package name, I would need to repackage because > the original tarball uncompresses to "libmsn-4.0-beta" but it should > uncompress to "libmsn0.1-4.0~beta1". If I am to abide by rule 6.7.8.2, > renaming "libmsn" -> "libmsn0.1" should be done, and therefore this > package is no longer just a bunzip & gzip case. No, that is not correct. You should not repackage just to rename the top level directory, period. No matter if what doesn't match is the version part, the name part, or both. Said that, your source package name should still be "libmsn" even if the binary package is named "libmsn0.1", bacause when you bump the binary package to "libmsn0.2", we want the source package name to remain constant. Please fix that. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Dar Williams - After All -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libmetalink
* Michal Čihař [Wed, 19 Nov 2008 15:56:47 +0100]: > - Vcs-Bzr: lp:libmetalink ... is this standard way of specifying bzr > repositories? It is Launchpad-specific but, alas, the launchpad plugin is included in bzr core, so anybody who does `bzr branch lp:libmetalink`, it will work. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Everything you read in newspapers is absolutely true, except for that rare story of which you happen to have first-hand knowledge. -- Erwin Knoll -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: taglib-rusxmms, librcc, librcd
* ivan [Fri, 21 Nov 2008 03:41:34 +0300]: > Dear mentors, > I am looking for a sponsor for my > packages "taglib-rusxmms", "librcc", "librcd". > * Package name: taglib-rusxmms > Version : 1.5-3.1 > Upstream Author : Suren A. Chilingaryan <[EMAIL PROTECTED]> > * URL : http://rusxmms.sourceforge.net/ > * License : GPL > Section : libs Hello ivan. Please remove me from the Uploaders field of this package, I keep receiving mail about uploads to mentors.debian.net. Many thanks in advance, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The true teacher defends his pupils against his own personal influence. -- Amos Bronson Alcott -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFH: How to get latest moc into Lenny (Bug#489804)
* Elimar Riesebieter [Wed, 31 Dec 2008 14:33:23 +0100]: > What do I have to do, to get latest moc entering Lenny? You should send a mail to debian-rele...@lists.debian.org asking if the fix is suitable for inclusion in lenny. However, I've taken a look now, and I've unblocked it, so you need not mail -release this one time. Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Javier Álvarez - Septiembre -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: remote-hellanzb-gui
* Arnaud Fontaine [Fri, 02 Jan 2009 16:09:46 +0100]: > You could get rid [...] of debian/docs as cdbs already installs the > files listed. «Explicit is better than implicit.» (Maybe not on -mentors, but surely on -python. ;-) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Anjani - No One After You -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Introducing spurious revisions during sponsorship considered harmful (by some of us)
Hello. Hopefully I'm not beating a completely dead horse here, but since some of the proponents of this "bump revision with each iteration" scheme are very vocal, I thought I could be very vocal too. I will (hopefully) not beat this horse again in the near future. The (in my opinion) most important reason why we shouldn't ask for bumping the debian version on each iteration to our sponsorees is a peculiar one: it's classist, because (in my view of thins) sponsorees should get to work as closely to as developers work as possible. Do you, as a developer, bump the debian revision each time you build a package, are ready to upload it, and discover one final problem with it? Do you, under that scenario, write in the changelog a new bullet point "Oh, I botched the rules file writing `rm -rf $(CURDIR) /usr/lib`, fixed now", or rather just fix it silently? Why should sponsored pepole not get to do the same? It is my belief that stealing them from the opportunity of preparing changelog entries in equal conditions is not right. Now let examine the other arguments, in increasing order of importance: * sponsor convenience: undoubtedly, it's easier to manage files with different names than different files named the same. I've never had any problems, though (I just do `rm -rf old; mkdir old; mv * old` prior to downloading the next iteration), and neither do many other sponsors. And I can't see how that is more inconvenient than having to always pass -v when sponsoring packages. And you can get different file names without adding a newly created changelog version each time. I've said it in the past, and I'll repeat it again: if you really care about different file names, ask your sponsorees to work like this; first iteration: package (1.2-3~mentors1) unstable; urgency=low * Foo. * Bar. * Baz. package (1.2-2) unstable; urgency=low * This is the previous uploaded version. Second iteration: package (1.2-3~mentors2) unstable; urgency=low * Foo. * Bar. * Baz, taking into account the corner case Moo. (Thanks, Boris Sponsor.) * Quux. package (1.2-2) unstable; urgency=low * This is the previous uploaded version. --- And so on. And the sponsor always s/~mentorsX// in the changelog prior to uploading. * history: I haven't seen this argument fly be in (this and other instances of) this discussion, but the answer is that the proper place to record that you had an extra and fatal space in your rules file is your VCS. (And FWIW, I think much of this discussion would go away if sponsorship was VCS-based rather than dsc+diff.gz based.) * uniformity of packages in the archive: this scheme not only introduces classes of people as mentioned above, it also introduces classes of packages. Suddenly, you systematically have in the archive entries for uploads that were never done to Debian... marked as having been uploaded to unstable! If you're going to do this, please ensure they're properly signaled as UNRELEASED (or "mentors", or whatever) as Piotr Ożarowski suggested. So, I get that we have developers that really fancy this scheme. Okay, we have more worrysome differences within Debian. But it would be more okay if these developers would reckon (in their daily doings) that many (?) of us don't agree this should be, by any means, standard practice in Debian, and that better alternatives exist. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org I promise you. Once I enter into an exclusive relationship, I sleep with very few people. -- Denny Crane -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Introducing spurious revisions during sponsorship considered harmful (by some of us)
> Do you, as a developer, bump the debian revision each time you build a > package, are ready to upload it, and discover one final problem with it? > Do you, under that scenario, write in the changelog a new bullet point > "Oh, I botched the rules file writing `rm -rf $(CURDIR) /usr/lib`, fixed > now", or rather just fix it silently? ^^ In case there were any doubts, with "under that scenario" I meant to imply that such botching of debian/rules had been introduced in the current version, not in an already uploaded one. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - You look beaten. - I just caught Tara laughing with another man. - Are you sure they weren't just... kissing or something? - No, they were laughing. -- Denny Crane and Alan Shore -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Introducing spurious revisions during sponsorship considered harmful (by some of us)
* Martin Meredith [Tue, 20 Jan 2009 22:05:11 +]: Hey Martin, > On Mon, Jan 19, 2009 at 02:29:10PM +0100, Adeodato Simó wrote: > > * history: I haven't seen this argument fly be in (this and other > > instances of) this discussion, but the answer is that the proper > > place to record that you had an extra and fatal space in your rules > > file is your VCS. (And FWIW, I think much of this discussion would > > go away if sponsorship was VCS-based rather than dsc+diff.gz based.) > That actually sounds like an interesting project. Something I might start > hacking on. Uhm, what needs hacking, exactly? The sponsoree just says "Repo for the package is at $URL", no? Or do you mean some kind of integration with mentors.debian.net? Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Man is certainly stark mad; he cannot make a flea, yet he makes gods by the dozens. -- Michel de Montaigne -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bypassing mentors http/ftp area durng sponsorship (was: Re: Introducing spurious revisions ... )
* George Danchev [Wed, 21 Jan 2009 16:11:46 +0200]: > cp orig.tar.gz from sid/ > * yes, I know of pristine-tar, but there is no way for it to preserve the > timestamps inside the tarball, i.e. hashsums will not much with these on the > upstream site, unless I'm awfully mistaken) (This is a bit off-topic on this thread, but pristine-tar is precisely about that: giving you the extra bits needed to ensure that the reconstructed tarball will be bit-by-bit identical to the original one.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Any life, no matter how long and complex it may be, is made up of a single moment: the moment in which a man finds out, once and for all, who he is. -- Jorge Luis Borges -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: What to do if the original tarball contains a debian subdirectory
I recommend that you repack your tarball, renaming the "debian" directory inside it to "debian-upstream" or something similar. And you should check with upstream if they'd be willing to stop shipping debian/* in their next releases. (The recommendation above is my opinion, and there are other DDs who think different. Me, I believe having a readable diff.gz is motivation enough as to repack the tarball.) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Leonard Cohen - Alexandra leaving -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can I simulate a weak conflict?
* Ben Finney [Tue, 26 Jul 2005 11:03:51 +1000]: > > "Recommends: udev (>= 0.060-1)". > How does this not express what you want to say? It recommends a > minimum version of the package, and allows for no installation of the > package. But does not prevent a lower version from being co-installed. Which is what you'd get with Conflicts: <<, and if you don't want that, then Recommends: >= is as close as you'll get. Putting a note in the README.Debian sounds sensible, too. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 I don't want to achieve immortality through my work. I want to achieve immortality through not dying. -- Woody Allen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can I simulate a weak conflict?
* Nicolas Boullis [Wed, 27 Jul 2005 00:27:07 +0200]: > And conflicting with udev (<< 0.060-1) isn't satisfactory either, since > some people may be happy with an old udev. (They only would have devices > files attributed to the root group rather than the video group, unless > they are able to configure udev themselves...) Then I recommend that you go with "Recommends: udev (>= 0.060-1)" and put a note explaining exactly that in the README.Debian file. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 There may be no I in TEAM, but a M and an E. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kdar -- Backup and Restore Utility for KDE (the KDE Disk archiver)
* Andrew T. Bennett [Tue, 09 Aug 2005 22:42:08 -0400]: > Hello Mentors, Hello Andrew, thanks for your interest in getting the kdar package into Debian. > Request for sponsor and/or mentor for the package "kdar". Uhm, there seems to be a (perhaps outdated) ITP for it, #221258. Andrew, are you familiar with the RFP/ITP mechanism in Debian? Can you ping the owner of the ITP? Thanks, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 I don't want to achieve immortality through my work. I want to achieve immortality through not dying. -- Woody Allen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kdar -- Backup and Restore Utility for KDE (the KDE Disk archiver)
* Andrew T. Bennett [Wed, 10 Aug 2005 17:00:38 -0400]: > On Wednesday 10 August 2005 4:08 am, Adeodato Simó wrote: > > > Request for sponsor and/or mentor for the package "kdar". > > Uhm, there seems to be a (perhaps outdated) ITP for it, #221258. > > Andrew, are you familiar with the RFP/ITP mechanism in Debian? Can you > > ping the owner of the ITP? > I was unaware of the RFP/ITP policy in Debian. After reading a little on it, > I'm still slightly confused on what must be done. > I e-mailed the owner of the ITP #221258, Roman Kreisel <[EMAIL PROTECTED]>, > but received a "Mailzustellung fehlgeschlagen / Mail delivery failed". I > tried searching for other e-mail addresses associated with his name, but > could not find anything. Well, he's certainly acctive and the account should work (see e.g. [1], from today). I'm CC'ing him to make him aware of this. [1] http://lists.debian.org/debian-kde/2005/08/msg00109.html > If the package is presumably orphaned and no contact can be made with the > owner of the ITP, what is the next step? Does someone with authority examine > the situation and mark the package as "Orphaned", or is nothing done until > contact can be made with the owner? Or am I missing the boat completely and > I need to do more reading on Debian's policies? > Sorry for all of the questions. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Let us not be ashamed to speak what we shame not to think. -- Michel de Montaigne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linker and transition questions...
* Romain Beauxis [Sat, 03 Sep 2005 13:21:28 +0200]: > Hi all! > I'm making a new package for kshutdown, and I've got the following linda > report: > W: kshutdown; Shared object /usr/bin/kshutdown is linked with version 6 and 5 > of libstdc++. Are you compling it with gcc4? Look at the version of your gcc and g++ packages... > Also, it is not clear for me wether I should upload it now or later. Now, as per: http://lists.debian.org/debian-devel-announce/2005/09/msg0.html > But my sponsor for this package does not seem to agree. Pierre? Really? -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Listening to: Jewel - Near you always Don't ask the barber whether you need a haircut. -- Daniel S. Greenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linker and transition questions...
* Romain Beauxis [Sat, 03 Sep 2005 15:15:36 +0200]: > So, if I understand it well, I should upload it, right? After you diagnose & solve the double libstd++ problem, yes. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Listening to: Jewel - You were meant for me A hacker does for love what other would not do for money. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] grace6: An XY plotting tool
* Steve Langasek [Wed, 07 Sep 2005 01:13:59 -0700]: > On Wed, Sep 07, 2005 at 05:15:14PM +1000, Ben Finney wrote: > > The bug report that you submitted says "I request an adopter for the > > grace6 package". While it would be polite for prospective adopters to > > coordinate with the existing maintainer, it's not a breach of > > ettiquette to fail to do this. > Hmm, I'm afraid I have to disagree; I understand this to be a major > difference between an RFA and an O, in that a maintainer submitting an > RFA reserves the right to choose a successor. I'm surprised to hear > that there's documentation which suggests otherwise. This has always been my understanding as well. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Don't be irreplaceable, if you can't be replaced, you can't be promoted. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Renaming the package and other things
* Justin Pryzby [Mon, 12 Sep 2005 01:52:32 -0400]: > On Sun, Sep 11, 2005 at 10:31:06PM -0300, Nelson A. de Oliveira wrote: > > I am planning to rename the source package to "biofox" only, instead > > mozilla-firefox-biofox. > > May I do this? How can I do this? Is it there some policy saying about > > renaming a source package? > Yes; its going to be a new package, that has to go through the NEW > queue (right?) Its going to happen to be from the same upstream > project as a soon-to-be old and removed package, though. NEW queue is for binary packages only, afaik. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Don't ask the barber whether you need a haircut. -- Daniel S. Greenberg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] qterm: BBS client for X Window System written in Qt
* Steve Langasek [Mon, 12 Sep 2005 23:02:55 -0700]: > On Tue, Sep 13, 2005 at 01:27:22PM +0800, LI Daobing wrote: > > > * debian/rules: > > > DEB_AUTO_UPDATE_DEBIAN_CONTROL := yes > > > This sucks, the generated control file is ugly as hell (it does > > > build-depend on build-essential, etc.). Please fix that. > > I don't agree, at least it works. > No, it doesn't. Packages have ended up with RC bugs before as a result > of cdbs changing the build-dependencies of the package in one of the > standard debian/rules targets, and I strongly discourage maintainers > from using this misfeature of cdbs. And ftpmasters will now actively discourage its use, by rejecting packages that use it. As per [1]. [1] http://lists.debian.org/debian-devel-announce/2005/08/msg00011.html -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Military justice is to justice what military music is to music. -- Groucho Marx -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Kat -- Desktop Search Enviroment for KDE
* Jonas Genannt [Fri, 23 Sep 2005 21:14:55 +0200]: > Hello, > I'm searching for a sponsor for Kat. Uhm. Can you explain what's going on with the ITP? 2005-05-14: #309068 - ITP: kat, by Jean-Remy Falleri 2005-09-16: #328610 - RFP: kat, by Nicolas DEGAND 2005-09-22: you retitle #328610 to ITP 2005-09-22, one hour later: you merge #328610 with #309068, without mention whether you've contacted Jean-Remy or not. Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Listening to: Paco de Lucía - María de la O [Tangos] In Italy, for 30 years under the Borgias they had warfare, terror, murder, bloodshed, but they produced Michelangelo, Leonardo da Vinci, and the Renaissance. In Switzerland they had brotherly love - they had 500 years of democracy and peace, and what did that produce? The cuckoo clock. -- Harry Lime in “The Third Man” -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: handling of duplicate bts entries
* Justin Pryzby [Fri, 21 Oct 2005 22:44:20 -0400]: > I can't see any reason not to close one > of them (probably with a message: "closing one of duplicate bugs; #x, > #y", to be parsed by the submitter). If you merge them, both submitters will get the "fixed in version x.y" mail. If you close one, you leave one of the submitters having to poll the BTS to see if it's fixed, or to learn about bug subscription (which, if he managed to submit a duplicate bug report in the first place, is quite unlikely to happen). Cheers, -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Nobody can be exactly like me. Sometimes even I have trouble doing it. -- Tallulah Bankhead -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PGP and GPG keys...
* Daniel Widenfalk [Sat, 12 Nov 2005 12:19:09 +0100]: > I have, and use, PGP 8.1 from PGP Corporation and have a key(s) > there which I use to encrypt and/or sign email with. Can I use > this key in the debian project, or do I have to create a new > GPG key? After asking around a bit on IRC, I got: - from http://www.debian.org/devel/join/nm-step2, "Each Applicant must provide an OpenPGP version 4 public key with encryption capabilities." - somebody mentioning that "a PGP5 key would be fine". Searching in keyservers, I see several keys for "Daniel Widenfalk", but the e-mail address do not match yours, and they seem standard 1024 bit DSA keys. Perhaps if you post your keyid somebody can take a look and tell you whether it's fine or not? Cheers, -- Adeodato Simó EM: dato (at) the-barrel.org | PK: DA6AE621 Listening to: Alanis Morissette - All I Really Want Arguing with an engineer is like wrestling with a pig in mud: after a while, you realize the pig is enjoying it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: sysinfo -- simple GNU/Linux program that displays computer/system information
* Laszlo Boszormenyi [Wed, 07 Dec 2005 17:23:36 +0100]: > I think the changelog is important, so do not delete it. But the epoch > should go IMHO for the initial Debian package release, you can use > Conflicts/Replaces to help upgrading. The package name is the same, so Conflicts/Replaces cannot help. If there's a epoch and you remove it, users should somehow be informed that they should force the downgrade by hand. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Truth is the most valuable thing we have, so let's economize it. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#342381: qterm - FTBFS: error: unknown escape sequence '\='
* LI Daobing [Thu, 08 Dec 2005 07:58:40 +0800]: Hi, > On 12/8/05, Bastian Blank <[EMAIL PROTECTED]> wrote: > > Package: qterm > > Version: 0.4.0pre3-2+b1 > > Severity: serious > > There was an error while trying to autobuild your package: > I have prepared a version to fix this problem, but I need a > sponsor[1], can you help me: > http://lists.debian.org/debian-mentors/2005/12/msg00031.html[1] > qterm (0.4.0pre3-3) unstable; urgency=low > * libstdc++ allocator transition: > - debian/control: build depends on libarts1-dev (>= 1.4.3-2) > * new patches/03-unknown_escape_sequence.dpatch: > - the newest g++ treat "\=" as an error instead of warning. > * bug 333101 in libssl-dev have been closed: > - debian/control: build depends on libssl-dev (>= 0.9.8a-4) > - delete patches/02-openssl.dpatch > * update patches/00list FWIW, this failure is caused only by g++_4.0.2-4. If you closely watch a build of 0.4.0pre3-2 with g++_4.0.2-5, the same warning about \= is emitted, but the build succeeds. So, this upload is really not necessary: qterm will get rescheduled to build when all buildds have g++_4.0.2-5 installed. But you may as well proceed: it really seems it builds fine with -4 and the patch applied. (Odd.) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Pet shop boys - Metamorphosis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFX: Gajim, a Jabber client
* Martin Zobel-Helas [Thu, 12 Jan 2006 20:13:53 +0100]: > it would help if you would mention who your normal sponsor is. % who-uploads gajim 0.9.1-2 Goedson Teixeira Paixao <[EMAIL PROTECTED]> 0.9.1-1 Goedson Teixeira Paixao <[EMAIL PROTECTED]> 0.8.2-1 Goedson Teixeira Paixao <[EMAIL PROTECTED]> (http://people.debian.org/~adeodato/tmp/2006-01-12/who-uploads) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org If there is a sin against life, it consists perhaps not so much in despairing of life as in hoping for another life and in eluding the implacable grandeur of this life. -- Albert Camus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: relibtoolizing when necessary (was: RFS: knmap -- Kde interface to nmap [uploaded])
* Florian Ernst [Fri, 13 Jan 2006 21:52:26 +0100]: > I gave some pointers on relibtoolizing to my sponsees after vorlon > called for improved library handling as mentioned in > <http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html>. > Especially KDE applications seem to be prone to depend on a plethora > of packages they don't really need for functioning due to the admin/ > subdir as shipped by kdevelop, so relibtoolizing can save a great deal > here. Are these instructions in a form suitable to make them public? :) Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Acaba de... Acaba de una vez... Acaba de una vez conmigo -- Astrud, Masaje -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpatch vs. quilt [was: Re: RFS: proxycheck -- link]
* Kevin B. McCarty [Sun, 29 Jan 2006 11:39:17 -0500]: > Frank Küster wrote: > > There are also other alternatives to dpatch; one is Debian-specific and > > i keep forgetting its name, and there's quilt. The main advantage of > > quilt IMHO is that it doesn't duplicate the whole tree when editing and > > updating the patch, which can be time- and disk-consuming in large > > projects. Instead it keeps a list of files for the patch one is editing > > and only keeps copies of these. That (speed), together with `quilt refresh` to get rid of fuzzyness (perhaps dpatch has it as well, I don't know) have made me a fan of quilt recently. Plus other goodies, like --no-timestamps. With respect to speed, it must be that most people use it in small trees, 'cause the couple times I've tried to use for some package of mine, the source was not small and it was unbearable. I also found out that the dpatch author was not quite well aware of this, since he has /tmp in RAM, or so he said. But when prompted about the problem on IRC, he said he'd consider copying the tree with hardlinks, which should help. > Out of curiosity, does quilt have a mechanism similar to dpatch that > allows you to treat shell scripts as "patches"? My inability to find > such a feature was the main reason I opted for dpatch over quilt in the > Cernlib package -- I needed to move a bunch of files around within the > source, and doing so with a pure patch system will result in huge and > fragile diff files (two copies of each file to be moved, which breaks if > upstream changes any of them!). No, in quilt patches are patches, not scripts. :) Why don't you move files around in debian/rules, anyway? Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: María del Monte - Que también es de Sevilla -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpatch vs. quilt [was: Re: RFS: proxycheck -- link]
* Adeodato Simó [Mon, 30 Jan 2006 04:08:52 +0100]: > With respect to speed, (Er, sorry; this paragraph refers to dpatch, which isn't immediately clear.) > it must be that most people use it in small > trees, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: María del Monte - Fue tu querer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debug packages?
* Paul Wise [Mon, 30 Jan 2006 22:18:07 +0800]:
> Hi all,
> I'm packaging a C++ app that has packages like this:
> foo - binary using the library
> libfoo0 - the library itself
> libfoo0-dev - headers and so on
> libfoo0-doc - docs for the library
> I'd like to add a package for debug information, since the app crashes
> occasionally. Should I add a libfoo0-dbg or foo-dbg package containing
> debug info for the lib and the app? or should I create separate
> libfoo0-dbg and foo-dbg packages? I'm inclined to think that creating
> just libfoo0-dbg with debug info for both the binary and is the right
> way to go, since there is also a gui in another package, which uses the
> library, therefore more people will just have the library than normal.
As long as it's only one -dbg package, I'd say that both names are ok.
Though now that, thanks to debhelper v5, it's easy to create -dbg
packages with symbols from multiple binary packages, I'd favour
${source}-dbg for those. Remember to make it Prio: extra, Section:
libdevel.
> Secondly, is dh_strip -k the right way to do this?
By my reading of the manpage, this will keep debug symbols, and ship
them in the _same_ package. I think what you want is:
% echo 5 >debian/compat
% dh_strip --dbg-package=foo-dbg
HTH,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
I try to keep an open mind, but not so open that my brains fall out.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re-libtooling + automake
* Martin Meredith [Mon, 30 Jan 2006 12:04:45 +]: > lsdiff --strip 1 debian/patches/10_update_libtool.diff | xargs touch -r > configure.in.in > However I've just stumbled across a package where this doesnt work. Then, if you insist on using touch-fu (I myself prefer it), you should investigate what the right order of the arguments to touch is. For this, running `make -d` and seeing why things are getting regenerated helps. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org If there is a sin against life, it consists perhaps not so much in despairing of life as in hoping for another life and in eluding the implacable grandeur of this life. -- Albert Camus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: treeline and treeline-i18n
* Miriam Ruiz [Thu, 02 Feb 2006 09:31:22 +0100]:
Hi,
> My packages can temporarily be found at: http://baby.yi.org/packages/treeline/
The packages look good. I can upload them, these are my only concerns:
(1) As per upstream's require.html, the spell checker is not an
absolute dependency, and aspell is normally preferred. What about
this?:
-Depends: python, python-qt3, ispell, ${misc:Depends}
+Depends: python, python-qt3, ${misc:Depends}
+Recommends: aspell | ispell
(2) [minor suggestion, I don't mind leaving it as is] I'd personally
leave the end of this sentence out of the Debian description.
TreeLine is written in Python and uses the PyQt bindings to the Qt
- toolkit, which makes it very portable.
+ toolkit.
(3)
> Package: treeline-i18n
> Description: translation files for treeline data manager
Despite upstream shipping these two in separate tarballs, two separate
binaries _and_ source seems an overkill to me. Perhaps other -mentors
readers will disagree, but I'd look into shipping the translations in
the treeline package itself (most packages do ship translations
themselves, don't they?). This would mean repackaging, though.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Lighthouse Family - Let it all change
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More on touch-fu (was Re: Re-libtooling + automake)
* Zak B. Elep [Sun, 05 Feb 2006 18:24:14 +0800]: > Hi Adeodato! :) Hi! > On 1/31/06, Adeodato Simó <[EMAIL PROTECTED]> wrote: > > Then, if you insist on using touch-fu (I myself prefer it), you should > > investigate what the right order of the arguments to touch is. For > > this, running `make -d` and seeing why things are getting regenerated > > helps. > Hmmm, I found out that `make -d` can be done _after_ the call to ./configure > . However, at reading the good doc at /usr/share/doc/autotools-dev/ , it > seems that the touch-fu has to be done _before_ the configure call (as the > doc example shows touching ./configure itself.) Is this correct, or is > there some other way? You do this: invoke ./configure so that Makefile gets generated. Then, if you'd invoke `make`, you'd see how autotools get rerun. So, you run `make -d` instead, catch its output, and find out why they're being rerun. Then you put the appropriate touch statement in debian/rules, clean, and rebuilt. Rinse, repeat. Alternatively, you can look in the docs the interdependencies between autotools files, and touch them in the correct order. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Placebo - Special Needs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to dpatch a file inside a tarball inside an .orig.tar.gz?
* Marc Haber [Sun, 12 Feb 2006 20:01:58 +0100]: > (3) > Modify debian/rules to first unpack, second patch, third build? I'd personally go with this one, similarly to this: configure: patch foo patch: unpack bar unpack: baz Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Alejandro Sanz - Cuando nadie me ve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/rules build/build-indep/build-arch
* Kevin B. McCarty [Mon, 20 Feb 2006 09:50:27 -0500]: Hi, > So you may get a Policy bug filed for ignoring this recommendation of > section 4.8, but from my reading you are free to tag it "wontfix". In > any case, I've used the solution you suggest in some of my packages. No > Policy bugs filed against them yet (not that this means anything). > > Is this the correct work-around for this problem? or should I put the > > Build-Depends-Indep packages into Build-Depends and let the autobuilders > > build the docs, but not make them into packages (seems like this is a > > bad thing to do, since it increases build times and seems wasteful)? > This is of course the other possible workaround, which is technically > more Policy-compliant. I've used it in others of my packages. If your > documents' build is CPU-intensive, I think the waste of effort to > compile them on every arch outweighs the dubious benefit of technically > being more Policy-compliant this way. Another option worth mentioning would be to do nothing in build-indep if the necessary build-depends-indep are not installed. build-indep: if [ -x /usr/bin/foo ] && [ -x /usr/bin/bar ]; then \ foo; \ bar; \ fi Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A conclusion is simply the place where someone got tired of thinking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Doing a proper package split (cream)
* Christoph Haas [Fri, 10 Mar 2006 14:33:35 +0100]: > Evening... Hi, (uhm, I was replying to this, but I see that the split is already in the archive. Executive summary: please remove the conflicts; I'd personally not split the package, but is your call; current status good, except for the conflicts.) > one thing I never really dealt with before are package splits. And since I > couldn't find any clear policy on how to define the dependencies properly > I'd like to get a second (and even third) opinion on this. I'd reinstate Simon's advice, and drop the Conflicts. The Replaces should be enough, specially with modern dpkg versions that can cope with the old version of cream (0.33) being re-instalated (it would barf on that in the past). > 'cream' is a package with a lot of documentation. Until version 0.33 I had > all the files in a single package. Now in 0.34 I want to split off the > documentation so i have cream (main) and cream-doc (documentation). Following up to Simon's considerations about size and arch:all packages, let's peek at the debs: Package: cream Version: 0.33.1-1 Installed-Size: 2904 Package: cream Version: 0.34-2 Installed-Size: 2380 Package: cream-doc Version: 0.34-2 Installed-Size: 884 With these numbers, the split seems like largely unjustified, IMHO. But well, your call. [snip] > Now when I install cream-doc (0.34) it looks like this: > $> dpkg -i cream-doc_0.34-2_all.deb > Selecting previously deselected package cream-doc. > dpkg: considering removing cream in favour of cream-doc ... > dpkg: yes, will remove cream in favour of cream-doc. > (Reading database ... 173915 files and directories currently installed.) > Unpacking cream-doc (from cream-doc_0.34-2_all.deb) ... > Setting up cream-doc (0.34-2) ... > Then the situation would look like this: > ic cream 0.33.1-1 > ii cream-doc 0.34-2 > The old cream package is still installed (shouldn't it be "rc"?). Desired = Install | Status=Config-files |/ || ++ ic You get a package into 'rc' when a dpkg --remove is issued (eg., by apt); if it's dpkg itself who removes the package due to a conflict, dpkg still things that the package was wanted installed. > While this is sane for APT it's a bit weird for the user because the > documentation now doesn't fit the main package any more. Note, as per your lines above, if you do `dpkg -i cream-doc` when cream 0.33 is installed, you end up with cream-doc installed, and cream removed. But this is irrelevant, 'cause it's a very unlikely situation. > I would like to install both new versions when either new package is > installed. Apt et al. will give you this, as said elsewhere. * Christoph Haas [Fri, 10 Mar 2006 17:21:12 +0100]: > I wonder if my proposal causes any bad things to happen. It would be very > unlikely that a user just installed the new 'cream-doc' package without > upgrading the 'cream' package. And since 'cream' and 'cream-doc' wouldn't > have any hard dependencies (like "Depends:" instead of "Suggests:") in the > future either there may well be situations where the documentation package > could have another version than the main package. If you care much about this, you could make the Suggests versioned; not that any tools would take it into account afaik, but it can act as a bit of documentation. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Capitalism is the extraordinary belief that the nastiest of men, for the nastiest of reasons, will somehow work for the benefit of us all. -- John Maynard Keynes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package in new queue needs update
* gregor herrmann [Wed, 15 Mar 2006 14:17:17 +0100]: > One of my packages is in the new queue, and now it needs a tiny > change (a library it build-depends on changes it's package name). > Can I use the same Debian revision for the updated package or do I > have to bump the revision number (or is there anything else to do > this)? Bump. You can only use the same one if it's been rejected, afaik. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Any life, no matter how long and complex it may be, is made up of a single moment: the moment in which a man finds out, once and for all, who he is. -- Jorge Luis Borges -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: W: A binary links against a library it does not use symbols from
* Steve Langasek [Tue, 18 Apr 2006 16:57:41 -0700]: > But it was established a few weeks ago that linda's check used ldd by > mistake, and I haven't heard that it's been fixed yet. Yeah, it was. Only, it yields lots of false positives, because of the algorithm used to map soname to package name (a simple regex, I think). I believe Steve Kowalik plans on removing this check. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Acaba de... Acaba de una vez... Acaba de una vez conmigo -- Astrud, Masaje -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: executable name collision
* Carlo Segre [Thu, 08 Jun 2006 18:14:39 -0500]: > Hello All: Hey Carlo. > The only way I can see to handle this is to make our package (called > mx1.2) conflict with the "motor" package This is not allowed by policy. > or just ignore the entire thing and let the last package installed > with a --force-overwrite win. And let's, uhm, forget you even mentioned this. > Since this executable is in use in a number of places, I really can't > change its name in the Debian package. Well, either you agree to rename it, or you convince the motor maintainer to rename. If you don't get to an agreement, you both rename. This procedure is described in the first paragraph of Policy §10.1. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Amon Tobin - Dream Sequence -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about linux-wlan-ng-firmware in main
tag 368857 patch
thanks
* Enrico Tassi [Sun, 28 May 2006 13:44:57 +0200]:
Hello Enrico (and Victor),
> Could you please examine this bts entry and give me suggestions.
> Please CC me, since I'm not subscribed.
So there was a 20-message long thread in -mentors, but you were dropped
from CC when the interesting bits came. In particular, two messages from
Frank Küster (kudos) that:
- first, pointed out that the downloading script was in a separate
binary package already, linux-wlan-ng-firmware [1]
- secondly, demonstrated that it is possible for a source package in
main to ship a binary package in contrib [2]
[1] http://lists.debian.org/debian-mentors/2006/05/msg00324.html
[2] http://lists.debian.org/debian-mentors/2006/06/msg00135.html
So I think the conclusion is that:
- the discussion of what happens if the script is shipped in the same
package as the free firmware is one that could expand itself beyond
imaginable limits, but it is _NOT_ the case here
- the linux-wlan-ng-firmware binary package is a "downloader package"
which should be in contrib without a doubt
- because of [2] above, and barring any input from the ftpmaster team,
the attached patch should be enough to fix RC Bug#368857
HTH,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Amon Tobin - Mission
diff -u linux-wlan-ng-0.2.4+svn20060414/debian/changelog
linux-wlan-ng-0.2.4+svn20060414/debian/changelog
--- linux-wlan-ng-0.2.4+svn20060414/debian/changelog
+++ linux-wlan-ng-0.2.4+svn20060414/debian/changelog
@@ -1,3 +1,10 @@
+linux-wlan-ng (0.2.4+svn20060414-3.1) unstable; urgency=low
+
+ * NMU.
+ * Move linux-wlan-ng-firmware to contrib. (Closes: #368857)
+
+ -- Adeodato Simó <[EMAIL PROTECTED]> Fri, 9 Jun 2006 01:55:57 +0200
+
linux-wlan-ng (0.2.4+svn20060414-3) unstable; urgency=low
* shared.prism2 is back (Closes: #365553)
diff -u linux-wlan-ng-0.2.4+svn20060414/debian/control
linux-wlan-ng-0.2.4+svn20060414/debian/control
--- linux-wlan-ng-0.2.4+svn20060414/debian/control
+++ linux-wlan-ng-0.2.4+svn20060414/debian/control
@@ -56,6 +56,7 @@
Package: linux-wlan-ng-firmware
Architecture: all
+Section: contrib/admin
Depends: linux-wlan-ng (= ${Source-Version}), build-essential, debhelper,
subversion, fakeroot
Description: firmware files used by the linux-wlan-ng driver
linux-wlan-ng is a set of drivers and utilities that is intended to
signature.asc
Description: Digital signature
Re: [RFS] museek+: file-sharing application for the SoulSeek peer-to-peer network
* Margarita Manterola [Sat, 10 Jun 2006 19:22:49 -0300]: > I noticed this because I can't build your package with my pbuilder if > I don't install the build-dependencies OUTSIDE the pbuilder. I hadn't > encountered such behaviour in any other package. Next time, try doing it without debhelper installed outside the pbuilder. ;-) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org When all is summed up, a man never speaks of himself without loss; his accusations of himself are always believed; his praises never. -- Michel de Montaigne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: quilt-el
* Satoru Takeuchi [Sun, 02 Jul 2006 23:18:39 +0900]: > 1. package stable release version > 2. package developing version and don't apply any extra patches > 3. package developing version and apply bug fix patch > 4. wait for upstream to apply bug fix patch and release stable release > 5. something else... Option (3) is the way to go if you think you're know what are doing and others don't disagree. ;-) It can get messy if further bugs are discovered by users, though, but chances are slimmer if the maintainer is a regulgar user of the package. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Que no te vendan amor sin espinas -- Joaquín Sabina, Noches de boda -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Procedure for adopting a package?
* Ryan Coyner [Sun, 02 Jul 2006 12:11:36 -0400]: > However I must admit that I'll think twice about packaging software in > the future if there is indeed a policy where a DD can simply take over > maintainence of a package without even sending me a courtesy email. No, there isn't such policy. To all effects, the calcurse 1.4-1 upload was an unannounced hijack, which are not allowed in Debian at all (dev-ref 5.9.5). I can certainly understand the feelings of a DD who cares for a package if they think that the maintainer (particularly if not DD) is not doing a good job at it. However, I've always dealt with this situation by offering help to the original maintainer, in whichever way was appropriate (eg. co-maintainership if the maintainer just lacks time sometimes, or mentoring and sponsoring if the package is not in well form). I would expect the rest of DDs to do the same. > But like I said, I thought there was a process regarding adoption. Confirmed. And thanks for bringing this to our attention in such a polite manner. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org And don't get me wrong - I don't mind getting proven wrong. I change my opinions the way some people change underwear. And I think that's ok. -- Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: quilt-el
* Jari Aalto+mail.linux [Mon, 03 Jul 2006 23:30:55 +0300]: > I wouldn't use quilt alone, because it is stack based and I mostly try > to make all patches completely separate from each other. This is nonsense. Either two patches touch the same group of lines in a file, or they don't, period. If they don't, they're independent, and it does not matter the order in which you apply them, but both quilt and dpatch need you to tell them the order. (Other systems can eg. randomize the order of patches that have no dependencies.) And if they do touch the same group of lines, yet being two separate fixes, you can either: - diff change1 against plain upstream, and change2 against plain upstream, which gives you two patches suitable for submission to upstream, but which will be unapplicable one after another (in either order) in your build tree - decide which one goes first, and have the second not be directly sendable to upstream, since it won't apply cleanly without the first one applied; but you need to do this in order to have a buildable debian package I fail to see what dpatch can do better about this with respect to quilt. > at all costs I try to avoid this, because it makes hard to drop > specific patch if upstream accepts the patched feature. Uh? In the case above, you have no problems if upstream accepts either change1 or change2. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Mecano - El 7 de septiembre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do when a package fails to build on one arch ?
* Charles Plessy [Sun, 16 Jul 2006 00:33:51 +0900]: Hi, > I have two packages which fail to build on m68k. The reason for this is > obviously a bug in a math library. > http://people.debian.org/~igloo/status.php?email=debian-med-packaging%40lists.alioth.debian.org > http://bugs.debian.org/340871 > I think that what I will do is open a bug for each package in which I > explain that I will not do anything until 340871 is fixed, and block > them with by 340871. > If I understand correctly, failing to build from source is a > release-critical severity. However, the packages are meant to do some > scientific computations, and I would be really astonished to hear that > somebody would use them on m68k. So if the bug in the math library is > not fixed by the freeze of testing, shall I drop m68k support for those > two packages ? Who shall I consult before doing this? Given that m68k is not a release arch so it won't affect the migration of your packages to testing, and that #340871 seems on its way to being fixed, I'd say that you need not do anything at all about this, and just let the m68k porters mark your packages for rebuild once #340871 is fixed. Only, in case they provide a workaround for the bug (eg., "build with -O0 instead of -O2"), you may consider applying it for m68k only. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org When all is summed up, a man never speaks of himself without loss; his accusations of himself are always believed; his praises never. -- Michel de Montaigne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pgplot5 binary package
* Carlo Segre [Mon, 17 Jul 2006 23:43:40 -0500]: > Hello All: Hi! > I have started to help maintain pgplot5. It is in non-free but is, > unfortunately, the only option for many Fortran programs which need to > plot to and interact with X. The upstream source is very stable and does > not change often at all but because of the X.org transition and other > changes from sarge to etch, it is badly broken and in need of an update. > I have uploaded a new version for i386 which is pbuilder and lintian clean > and I have even tested the build on a mips machine that I have in my lab. > I would like to have the new pgplot5 installed for all architectures but I > don't the proper protocol. Do I: Since nowadays non-free is supposed to be autobuilt, I think the reasonable thing to do befor #1 or #2 would be to contact the maintainers of this buildd network to see if pgplot5 needs some manual pushing so that is "seen" by these autobuildders. See http://buildd.net/. > 1. request a build and upload on the ports lists? > 2. build the binary packages myself on the developer-access machines and >then upload only the binaries? > #1 is the easiest but since the package is non-free, I hesitate to ask > others to do the work. > If #2 is the right thing to do then I need to find the documentation for > using the chroots on these machines. I have looked around in the Debian > web site for information on this topic but as far as I can see, there is > no information readily available on how to do this. Any pointers would be > appreciated. There is this tiny bit of information: http://www.debian.org/doc/developers-reference/ch-resources.en.html#s-dchroot When you need some packages installed (eg., build-dependencies of your package), you normally mail "[EMAIL PROTECTED]" saying which packages you need, and on which machines and chroots (eg., "g77 in unstable chroot of vore and merulo"). (Btw, this could be a nice addition to that section of dev-ref, feel free to file a wishlist bug.) But this is normally for debugging problems, and for uploads, the non-free buildd network, or porter uploads (#1), are preferred. > I have found the pages on porting and using the -B option in > dpkg-buildpackage but then is it OK to just use dput as usual to upload? Yes, taking into account my previous paragraph. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org There may be no I in TEAM, but a M and an E. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: s390 build box?
* Tyler MacDonald [Tue, 18 Jul 2006 11:37:09 -0700]: Hi Tyler, let's see if I can give an useful answer to your questions and concerns. > Please see: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378375 > I would like to test this bug fix on a s390 box before uploading it. Except > I don't have access to an s390 box. :-/ I asked Bastian if he would be > willing to test this before I get my sponsor to upload, but he hasn't > replied. > What's the Debian way of handling this? I know that if I upload the new > package to unstable, it will at least be no worse than the previous version, > but it also seems like a waste of time to upload it if it just has more > problems under the s390 arch. Should I continue attempting to find an s390 > box, is there something somebody out there can do to help, or should I just > have my new packages uploaded and hope for the best? First, and most important: what makes you think that the failure is s390-specific? The fact that you only got a FTBFS report from the s390 autobuilder just means that (a) it failed there, (b) the buildd admin looked at the log, check that the FTBFS was not already reported, and submitted a bug against your package. But this says nothing about the package building in other architectures, specially because (a) you won't normally get duplicate bugs for the same FTBFS, even if in different arches, and (b) our s390 buildd admin, Bastian Blank, is normally the one that gets to the logs first, or so it seems, because a big part of FTBFS bugs come from him. ;-) Enough for verbosity already. If you check this page: http://buildd.debian.org/build.php?&pkg=mod-bt You'll see that it failed in five more architectures (mips powerpc sparc hppa m68k). In this case in particular, seems like all the big endian ones. :-) So with respect Bastian not replying above, well, I guess porters normally will want to spend their (probably scarce) free time helping with problems _really_ specific to their architecture. * Tyler MacDonald [Tue, 18 Jul 2006 12:14:55 -0700]: > My question was really geared to "any architecture" though... when > it's an arch you don't have access to; > 1) If you "think" you've fixed the problem, should you upload a new > package that "Closes:" the bug? Well, your first initial reaction, wanting to test it in one of the affected architectures, is particularly thoughtful. However, this is not always easy, so there are circumstances when one just directly uploads: e.g. the fix is trivial and one is confident it'll work, or the patch was directly provided by one of the porters. (Of course the above only applies when it is completely impossible to reproduce the problem in one's own architecture.) > 2) How long should you let a FTBFS bug stick around for on account > of lack of testability before you give up and just upload it anyway and hope > for the best? My opinion: not very long, unless it's a very very big package, and provided you have certain assurance that the fix will work (IOW, not just "ok, let's try this and see if it works"). I think this bug is one of those where one can get to the "fairly confident it'll work" stage. (OTOH, your solution seems a bit fragile for a source package that wants to get compiled with -Werror. The two apache2 and php5 files that define WORDS_BIGENDIAN, also share 23 other macro definitions; as it happens, to the same value, which does not trigger an error. But that's up to you, I guess.) > 3) Is there any sort of (organized or disorganized) effort / method > for obtaining builds of your package on architecture X before they're > uploaded to debian? Not really. Either a DD does it in some project machine, or you ask in a porter list. > Is experimental good for this? Not really intended to test if packages build, but if packages work. :-P > 3a) Is experimental good for anything? Eg; if I have a test package > uploaded to "experimental", with a "Closes:" line in the changelog, will it > close the bug? It'll mark it as fixed-in-experimental (or close it with the appropriate version number, in the future). > Will it typically get autobuilt? Supposedly. (http://experimental.ftbfs.de) > Can I upload the exact same > package to unstable later if it turns out that the bug is indeed fixed? With an extra changelog entry, yes. > The dev. reference says "the experimental packages are automatically > removed once you upload the package in unstable with a higher version > number"... which seems to imply that it's not a *true* staging area, > since I can't promote a package that's byte-for-byte the same. Right, not byte for byte, since an extra
Re: changelog.Debian.gz as a symbolic link
* Eddy Petrisor [Sat, 22 Jul 2006 15:07:17 +0300]:
> If both packages come from the same source (as they should), you should
^
^
^
and one depends on the other with (= ${Source-Version}) --|
> symlink the /usr/share/doc/libpac-dev to the /usr/share/doc/libpac.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Proper treatment will cure a cold in seven days, but left to itself, a
cold will hang on for a week.
-- Darrell Huff
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: changelog.Debian.gz as a symbolic link
* Russ Allbery [Sat, 22 Jul 2006 09:13:01 -0700]:
> I'm not sure if it's allowed (my reading of Policy 12.3 says that you can
> symlink the whole directory, but I don't see anything that says you can
> symlink individual files with Debian significance such as copyright or
> changelog.Debian), but regardless I wish you wouldn't do it. lintian (and
> other similar package checking programs) can only check files contained in
> the package, and not having the changelog file present in the package
> means that various things (NMU consistency, for instance) can't be
> checked.
Agreed. I see little point on linking individual files: either link the
whole doc directory if there's a strict (= ${Source-Version}) dependency
(and lintian can indeed check this case), or duplicate the files.
> The additional space used by installing a copy of the changelog
> with each binary package isn't large.
I should also mention that the main benefit I see from linking the doc
directories is not space savings, but making it easier for users to
access documentation: whichever directory they enter, it's all there.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Under capitalism, man exploits man.
Under communism, it's just the opposite.
-- J.K. Galbraith
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request for Review: libnmap-parser-perl (Already have a sponsor)
* Joshua D. Abraham [Wed, 02 Aug 2006 21:53:37 -0400]: > he has requested that someone review it first. Out of interest, why? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org One of my most productive days was throwing away 1000 lines of code. -- Ken Thompson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: feedparser -- Universal Feed Parser for Python
* Carlos Galisteo [Thu, 03 Aug 2006 11:32:50 +0200]: > Jonathan McDowell (previous mantainer) (JFTR, Joe Wreschnig.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Executing tests during package building?
* Kari Pahula [Mon, 28 Aug 2006 20:13:30 +0300]: > On Mon, Aug 28, 2006 at 11:58:21PM +0900, Charles Plessy wrote: > > Le Mon, Aug 28, 2006 at 05:04:40PM +0300, Kari Pahula a écrit : > > > I don't know about a general policy, but I've myself set gecode to run > > > its test suite in debian/rules, excluding some of the slower buildds. > > Good idea, how do you do this? > DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) > ... > -if echo $(DEB_HOST_GNU_TYPE) | grep -vcE '^(arm|m68k|s390)' ; then > $(MAKE) test && LD_LIBRARY_PATH=. test/test ; fi Please use DEB_HOST_ARCH_CPU instead. Also, in case somebody cares about doing it without shell: -8<-- DEB_HOST_ARCH_CPU ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_CPU) SKIP_TEST_CPUS := arm m68k s390 test: ifeq (,$(filter $(DEB_HOST_ARCH_CPU),$(SKIP_TEST_CPUS))) test else @echo "Slow-cpu arch detected, skipping test" endif -----8<-- Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The first step on the road to wisdom is the admission of ignorance. The second step is realizing that you don't have to blab it to the world. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ed2k-shutdown
* David Paleino [Sat, 21 Apr 2007 16:35:06 +0200]: > Dear mentors, Hi, > I am looking for a sponsor for my package "ed2k-shutdown". Please create a single source/binary package ed2k-tools that contains both ed2k-shutdown and ed2k-hash (and any other utilities that the ed2k-tools.sf.net project may add in the future). Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org If you think nobody cares if you're alive, try missing a couple of car payments. -- Earl Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ed2k-shutdown
* David Paleino [Sat, 21 Apr 2007 17:22:12 +0200]: > Adeodato Simó ha scritto: > > Hi, > Hi, (Please reply to the list.) > > Please create a single source/binary package ed2k-tools that contains > > both ed2k-shutdown and ed2k-hash (and any other utilities that the > > ed2k-tools.sf.net project may add in the future). > I thought that as well. But then I realized I could create a > meta-package, called "ed2k-tools", which Depended on all these binaries. > The main "problem" is, in fact, that I should create "from scratch" a > new package. ed2k-tools, in fact, ships the binaries as single ones, and > I found it was simpler to create different packages. > I'll follow your suggestion though, and I'll try to make a whole package > containing everything. Thanks. > P.S.: in any case, what's the procedure to create a meta-package? I > thought one should create only a ./debian/ directory, with the usual > files there, and then build it. Is this the right way? Yes, something like that. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org When you don't know what to do, walk fast and look worried. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: proda
* Charles Plessy [Wed, 25 Apr 2007 13:18:30 +0900]: > About debian/rules: > - The configure rule is mandatory I've never heard such a thing, where does this affirmation come from? Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org There is no man so good who, were he to submit all his thoughts to the laws, would not deserve hanging ten times in his life. -- Michel de Montaigne -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pdebuild, pycentral and gpg
* Gudjon I. Gudjonsson [Fri, 27 Apr 2007 20:04:04 +0200]: > At last I made a silly mistake with my gpg. I put some silly sentence to some > field i thought was for remembering my password (has nothing to do with the > password). But now my name is in the GPG key > Gudjon I. Gudjonsson (sillysentence) > Is there any way of removing the silly sentence? Since I have only used the > key for the two mentor packages, can I revoke it and make a new one. No, you can't remove the silly sentence (what GPG calls the 'comment'), since it's part of the UID, and UIDs can't be removed, only revoked. Unless your key has not been uploaded to a public keyserver, you can't get rid of the comment by any other means than making a new key. If it hasn't been uploaded to a public keyserver, you can remove the UID. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A conclusion is simply the place where someone got tired of thinking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pdebuild, pycentral and gpg
* Gudjon I. Gudjonsson [Sat, 28 Apr 2007 18:02:31 +0200]: > Hi Adeodato Hi. (Please remember to reply on list.) >Thanks for the answer. I have used the key on the Debian mentor homepage > and to sign the two programs I have uploaded but have not gone into the > distribution. I don't know if this means a public server. I don't know what mentors.debian.net does (eg. if they store the key, etc.), but FYI a search for "Gudjonsson" on a couple of public servers does not yield any results matching your name. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Jewel - You were meant for me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lastfm (updated package)
* John Stamp [Sun, 22 Apr 2007 09:57:33 -0700]: > I am looking for a sponsor for the new version 1:1.1.3.0-1 of the > package "lastfm". I am taking over maintainership of the package > with the current maintainer's permission. Hi John. I had a look at your lastfm package. In general looks good, and I can uploaded after you've addressed a couple of issues. > This version incorporates the msk patchset which Alberto Garcia and I > have been working on here: > http://mehercule.net/staticpages/index.php/lastfm > It uses a new alsa plugin with dmix support, and incorporates various > bugfixes and features. Upstream plans to use several of these in a > future version of the client. This is the first issue: the package contains a lots of patches. I'm glad to hear that you're somehow in contact with upstream about including them, and I'm not going to suggest to wait until then: you two seem to know what you're doing. However, I'd recommend that you include at the end of the description of the package something like: This package includes the msk patchset from http://mehercule.net/staticpages/index.php/lastfm. Secondly, the way your packaging files under /etc is not correct. Policy forbids that such files are overwritten on upgrades, which you do; and are to be removed on purge (which is different from removal), which you also do. Is there a reason to generate them in postinst? If not, I recommend that you simply install them as regular files, under all possible directories, and that'll make dpkg give you policy-compliant behavior by default. Finally, some minor remarks: * in lastfm.mozilla, please use "$@" (quotes included) instead of $*. * when upstream only provides a tar.bz2 file, one normally does: bunzip2 file.tar.bz2 gzip --best file.tar Instead of repacking it completely. (It is not important the name of the directory the file uncompresses to, dpkg-source is smart and handles it.) Please change that (or I can do it for you when uploading). * the install target in rules could be very simplified with a debian/last.fm file. I don't mind uploading in the current form, but I suggest you give it a go. P.S.: > - URL: http://mentors.debian.net/debian/pool/main/l/lastfm > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/l/lastfm/lastfm_1:1.1.3.0-1.dsc ^^ I've seen stanzas like this in most RFS. Are they autogenerated in some way? If so, the code needs to be teached to strip the epoch from the dsc. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Enya - River -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lastfm (updated package)
* John Stamp [Tue, 01 May 2007 15:33:30 -0700]: Hi again, John. I've uploaded the package. For the next upload, there are some minor issues I'd like you to consider: * remove "This file will be overwritten on upgrade" from lastfm.js * install lastfm.desktop to /usr/share/applications instead of /usr/share/applications/kde. I believe this way lastfm will appear in the GNOME menu as well. * since lastfm.mozilla is not meant to be called directly by the user, put it under /usr/lib/lastfm, and adjust lastfm.js accordingly, and remove lastfm.mozilla.1. This is recommended/mandated by Policy. * maybe s/unstable/UNRELEASED/ in those changelog entries that never got uploaded to the official archive. > Actually, this brings up a related question. The source is labelled > 1.1.3 but Help|About reports version 1.1.3.0. I decided to follow > the version number that Help|About reports. Does that seem correct > to you? Yeah; either would be fine, IMO. > > * the install target in rules could be very simplified with a > > debian/last.fm file. I don't mind uploading in the current > > form, but I suggest you give it a go. > Can you point me to a description of that? I'm not sure how it would > work in this situation. The canonical reference would be dh_install(1), and you can check any package in the archive: most use dh_install. As a brief summary, a debian/$package.install file contains a number of lines, each with a file to install (or a wildcard), followed by an optional destination of the file. The single thing dh_install can't do is renaming file. So, for example: ---8<- debian/lastfm.mozilla /usr/bin bin/libLastFMTools.so.1*/usr/lib bin/extensions /usr/lib/lastfm bin/services/usr/lib/lastfm i18n/*.qm /usr/lib/lastfm/i18n bin/data/about_generic.png /usr/share/pixmaps/lastfm ... --->8- With that, also the debian/dirs is mostly unnecessary, since needed directories are created by dh_install. HTH, cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Te has enfadado conmigo / porque te dejo / Es injusto No quieres volver a verme / porque no quiero / que estemos juntos Estás siendo egoísta / no has penseado que me quedo / solo yo también -- Astrud, Caridad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lastfm (updated package)
* John Stamp [Wed, 02 May 2007 08:50:03 -0700]: > When -2 is ready should I upload to mentors and ping you? Or would > you prefer something different? Yeah, pinging me is fine. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Beauty, brains, availability, personality: pick any two. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation path changes in -dev package
* Ming Hua [Tue, 08 May 2007 03:06:09 -0500]: > Dear mentors, Hi there, > I am asking you if I handled this change properly, if I missed any > procedure, and anything I can do better next time in a similar > situation. I had a look at the messages and bug you linked, and I think you handled the situation very well. I wish more library maintainers took so much care in warning their fellow maintainers about the changes ahead. Very well, too, the point about binNMUability. I'd change "Optional" to "Optional but highly desirable". ;-) Finally, if you're sure all affected maintainers read the list, what you did is ok. If not, custom practice is to CC them, just in case. Good job! -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org - I'm sorry for laughing. I'd explain if I could. - It's a double entendre. I've been in this country 20 years. I get things. -- Mrs. Kim and Lorelai Gilmore -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rebuilding the whole archive.
* Joe Smith [Fri, 18 May 2007 15:34:56 -0400]: > It really seems absurd that such critical parts of the infrustruture are not > available as debian packages. It seems like that would simplify the lives of > the DSA team, for example. > What am I missing? They exist as debian packages; only, not in the normal Debian repositories because (I assume) they're not regarded as useful for non-debian.org machines. They're publicly available as well, albeit in a sort of hidden repository. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Don't worry about what anybody else is going to do. The best way to predict the future is to invent it. -- Alan Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pastebinit
* David Paleino [Wed, 30 May 2007 09:11:41 +0200]: > I already posted a similar RFS some time ago: the version was 0.8, and > I took the sources from Ubuntu repositories. Now this package uses the > upstream sources (as someone asked), even if they are version 0.7. The source seems to be kept at [1], which has indeed 0.8. My guess is that Ubuntu packaging is tightly integrated to upstream development, and the Ubuntu tarball can be considered the official source. [1] https://code.launchpad.net/~pastebinit-developers/pastebinit/trunk However, Thijs' comments in [2] about contacting the Ubuntu maintainer about maintaining only one package for both distributions still apply. [2] http://lists.debian.org/debian-mentors/2007/05/msg00281.html Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Najwa Nimri - Le tien, le mien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: enblend
* Sebastian Harl [Wed, 30 May 2007 00:15:03 +0200]: > - The files under src/win32helpers are released under the 4-clause BSD > license which is incompatible with the GPL. Thus distributing them as > part > of a GPL'ed program is illegal - the .orig.tar.gz should be repackaged > to > not include those files (they are only needed under Windows anyway) and > '+dfsg' should be added to the version number. Two issues here: - works under a 4-clause BSD license where the copyright holder is the University of California are effectively under a 3-clause BSD license, as per ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change. - even then, it is perfectly fine to *distribute* in a same tarball these incompatible works, as long as they are not linked together (and since they're under win32helpers, I assume they're not on Unix systems). (If they link together, what you can't distribute is the resulting binary; for that, the copyright holder of the GPL part of the source would have to provide an exception allowing for such linkage.) HTH, and thanks to Jacobo Tarrío for confirming that my ideas about this were correct. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Testing can show the presence of bugs, but not their absence. -- Dijkstra -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Kernel module and dpkg-divert
* "Adam Cécile (Le_Vert)" [Wed, 27 Jun 2007 15:41:31 +0200]: > I looked at ipw2x00 packages to make mine, however dpkg fails to install > fuse-module-xxx because it overwrites fuse.ko shipped with kernel package. > If you looked at preinst script, fuse.ko is diverted before installation > buit dpkg fails. It works fine with ipw2x00 packages. The problem is this: fuse-2.6.5% grep dpkg-divert debian/p*.modules.in debian/postrm.modules.in: dpkg-divert --package [EMAIL PROTECTED]@ --remove --rename --divert /lib/modules/@KERNEL@/kernel/fs/fuse/fuse.ko.linux /lib/modules/@KERNEL@/kernel/fs/fuse/fuse.ko ^ ^ ^ debian/preinst.modules.in: dpkg-divert --package [EMAIL PROTECTED]@ --add --rename --divert /lib/modules/@KERNEL@/kernel/fs/fuse/fuse.ko.linux /lib/modules/@KERNEL@/kernel/fs/fuse/fuse.ko ^ ^ ^ You are giving a wrong package name. It should be '[EMAIL PROTECTED]@', not fuse-modules. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org When the only tool you have is a hammer, every problem starts to look like a nail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: include aoTuV patch
* Rogério Brito [Sat, 07 Jul 2007 07:00:56 -0300]:
> I have already packaged a private version of libvorbis with the aotuv
> patch (which applies cleanly) and I also fixed some lintian warnings.
> If some mentors are interested in what I did so far, I put the sources
> on my homepage:
> http://www.ime.usp.br/~rbrito/libvorbis/libvorbis_1.1.2.dfsg-2.0+aotuv5.dsc
> Please, note that they are almost in a point to be uploaded to, say,
> experimental, but there are some cosmetic documentation facts that need
> some more attention (any comments are *QUITE* welcome).
I can't believe you're looking for a sponsor for an NMU of these
characteristics, even if targetted at experimental (but the changelog
entry says 'unstable', btw).
You don't, ever, do things like that, particularly not before mailing
the bug report asking what the status of the bug is, whether the
maintainer has an opinion on it, and expressing your wish to see the
patch applied in an experimental version.
We all appreciate enthusiasm and work put onto improving Debian, yours
in this case, but sometimes enthusiasm can, by ignorance or else, go off
the correct path, and this is not desirable. Consider this a friendly
note pointing out that what you're trying to do here is not quite correct.
Said that, and now with my libvorbis maintainer hat on, feel free to
mail the bug report again as hinted above, and we can discuss things.
Other options besides uploading to experimental would be uploading the
patch in a separate source package, or create a separate binary package
with the patch from the libvorbis source package, given that the ABI is
maintained.
Cheers,
(
> + * debian/README.Source: fix typo;
> + * debian/control: changed the ${Source-Version} substvar to
> ${binary:Version}
Just for the record, these two were fixed in the Bazaar branch a week ago:
http://bzr.debian.org/pkg-xiph/libvorbis
> +It also makes the package binNMU'able.
This is not true, it already was.
)
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
I went to the race track once and bet on a horse that was so good that
it took seven others to beat him!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: include aoTuV patch
* Rogério Brito [Sat, 07 Jul 2007 19:55:52 -0300]: > Besides that, what do you mean with "these characteristics"? That it is > an "intrusive" patch? Intrusive, wishlist. > > Just for the record, these two were fixed in the Bazaar branch a week ago: > > http://bzr.debian.org/pkg-xiph/libvorbis > I get a blank page with just a link to the parent package. It's a Bazaar branch, so you have to retrieve it with: % bzr get http://bzr.debian.org/pkg-xiph/libvorbis Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" (I found it!) but "That's funny..." -- Isaac Asimov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Change in my sponsorship requirements
I have not read this thread, only the initial message. So sorry if what I propose has already been said. If you want different debian revisions per mentor upload, I think the most reasonable think to do so is to have the mentoree upload: package_1.2.3-4~sp1 (sp == sponsor) package_1.2.3-4~sp2 etc. With so many iterations as needed, and with only one changelog entry for -4 (that is, no dch -i, just replacing the version in the first line of the changelog). Then all the sponsor has to do before uploading, is removing 4 characters from the first line of the changelog. This way you get different revisions as to work easily with them, but there are no lost debian revisions, which would seem undesirable for me. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Lhasa - La marée haute -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange problem with upstream sources (needing to repackage?)
* Rogério Brito [Mon, 16 Jul 2007 04:15:02 -0300]: > Should I maintain it in disagreement with the Debian > Policy? You really can't do that, nothing will work. > So, again my question: should I repackage the upstream sources? And if > so, how should that be done, You should not repacakge the tarball, but just rename it: % mv diskdev_cmds-332.tar.gz diskdev-cmds_332.orig.tar.gz (Assuming that the version number is 332). Also, you have to name your source package "diskdev-cmds" (or some other Policy-compliant name), not "diskdev_cmds", that is not possible. HTH, good luck. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Lhasa - Abro la ventana -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpatch or quilt? in maintainer guide
* Osamu Aoki [Sun, 22 Jul 2007 05:59:20 +0900]: > If someone makes checking on the archive "how many packages build > depends on dpatch and quit", and tell me quilt is getting enough > popularity, I may consider changing text there to mention quit may be > used as an alternative to dpatch. (I thoght about it but I did not > want to overload this guide too much thus kept quiet on quilt.) Here are the numbers: dist | quilt | dpatch ---| sarge |11 |485 ---|---| etch | 338 | 1185 ---|---| lenny | 515 | 1393 ---|---| sid | 598 | 1505 I believe it's very appropriate to at least mention quilt in the new maintainer guide. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org And how do you tell an extroverted mathematician? He looks at *your* shoes while he's talking to you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: harvestman (updated package)
* Kumar Appaiah [Mon, 30 Jul 2007 19:17:20 +0530]: > On Mon, Jul 30, 2007 at 01:56:09PM +0200, Piotr Ozarowski wrote: > > * please add python-xml to Depends (HarvestMan/xmlparser.py, line 2) > Done, although it was working for me without python-xml. Because Python itself provides a XML implementation, in this case /usr/lib/python2.4/xml/parsers/expat.py. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Uploaded (Re: RFS: qterm)
* LI Daobing [Wed, 01 Aug 2007 11:46:22 +0800]: > Dear mentors, Hello, > I am looking for a sponsor for the new version 1:0.4.0-5 > of my package "qterm". I've uploaded this package. It'd be great if you could fix the following in the next upload: * remove unneeded debian/docs and debian/menu, and debian/*.ex * update debian/compat to 5 * change " Home Page" in debian/control to " Homepage" It would've been good to mention in debian/changelog the addition of XS-Vcs-Svn to debian/control. No need to modify the changelog in future uploads, though. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org — George, they're missing. — Splendid, splendid. -- Mrs and Mr Banks in “Mary Poppins” -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
* Christoph Biedl [Tue, 11 Sep 2007 15:34:49 +0200]: > Hello, > Currently I am packaging a daemon. I used dh-make (0.43, Debian > lenny) and did some small adjustments afterwards. Now came across two > problems where I am not sure how they should solved properly, in other > words: What is best practise? > Given the following situation: The daemon was stopped manually. Now I > want to install a new build, using "dpkg -i". This invokes (among > other) /var/lib/dpkg/info/.prerm which contains only a few lines > "Automatically added by dh_installinit". They include a call of > "invoke-rc.d stop || exit $?", > this is basically a wrapper for "/etc/init.d/ stop" which > calls start-stop-daemon. This program returns non-zero since the > daemon is not running, that value is passed back through the chain and > finally causes a dpkg error. dpkg tries the script from the new > package instead which fails for the same reason. > To deal with that mess I could modify /etc/init.d/ and add the > --oknodo to start-stop-daemon, or "|| true". If this is the best way > to do, why does not dh-make create the init script in such a way by > default? > An alternative approach was to ship my own version of prerm thus > overriding dh_installinit. Not a good idea IMHO. > Is there a better solution? Your init.d script should *not* exit with status non-zero if the daemon was already stopped. You can do that either by passing --oknodo to start-stop-daemon, or by checking by hand if the return status is 1. *Not*, in any case, by appending "|| true", since that would hide the case when a real errors occurs and the daemon can't be stopped. If you wrote your init.d script from some template that advocates returning directly the exit status of start-stop-daemon without --oknodo, that template needs fixing. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Hooverphonic - Heartbeat (Remix) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: qterm (updated package)
* LI Daobing [Wed, 10 Oct 2007 06:36:15 +0800]: > Dear mentors, > I am looking for a sponsor for the new version 1:0.4.0-6 > of my package "qterm". Package looks good, I uploaded it. Sorry for the delay. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Don't be irreplaceable, if you can't be replaced, you can't be promoted. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: alpine_0.999999+dfsg-2_i386.changes REJECTED
* Asheesh Laroia [Sat, 15 Dec 2007 12:31:49 -0800]: >> I believe that the latest alpine in unstable (namely 0.99+dfsg-1) >> has me as the maintainer, me listed as the Maintainer:, and >> DM-Upload-Allowed: yes in the source section of the control file. The DM-Upload-Allowed field must be first introduced by a version uploaded by a DD. That is, you'll need 0.99+dfsg-1 sponsored, and then you'll be able to upload regularly. Make sure you use XS-DM-Upload-Allowed in debian/control, and not just DM-Upload-Allowed. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Javier Álvarez - No se asombren -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: alpine_0.999999+dfsg-2_i386.changes REJECTED
* Neil Williams [Sat, 15 Dec 2007 20:58:50 +]: > $ gpg --list-key 70096AD1 > pub 1024D/70096AD1 2005-12-28 > uid Asheesh Laroia <[EMAIL PROTECTED]> > uid Asheesh Laroia <[EMAIL PROTECTED]> > uid Asheesh Laroia <[EMAIL PROTECTED]> > sub 2048g/3214EBED 2005-12-28 > You need to edit your key so that the UID that you use is the primary > UID. GnuPG may simply be using whichever UID was created first. Please, pretty please, consider refraining from giving advice when you're not positive you're correct. (Hint: you don't sign with UIDs, so dak could not care less about what the primary UID is.) Have a nice day, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Javier Álvarez - No se asombren -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: alpine_0.999999+dfsg-2_i386.changes REJECTED
* Asheesh Laroia [Sat, 15 Dec 2007 13:07:25 -0800]: > Where is XS-DM-Upload-Allowed documented? I only see DM-Upload-Allowed > documented at http://www.debian.org/vote/2007/vote_003 . If you have a look at #453400 and Policy 5.7, and you should get the picture. :) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Javier Álvarez - Pero mira -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: exception and RFS: unionfs-fuse - fix RC bug
* Bernd Schubert [Sat, 31 Jan 2009 18:53:34 +0100]: > Dear release team, > as I already wrote to the mentors list, there is a critical bug in unionfs- > fuse, see below. So far nobody uploaded the package, maybe due to possible > security implications? Or maybe since I also included two other changes? Unblocked by Luk. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org I promise you. Once I enter into an exclusive relationship, I sleep with very few people. -- Denny Crane -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 3.0 Quilt packages
* Andreas Hoenen [Tue, 03 Mar 2009 20:21:18 +0100]: > This link might be of interest to you: http://bugs.debian.org/457345 > Looks like it will need some more time :-( Take a look again by reloading it in your browser. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Elton John - Daniel -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: 3.0 Quilt packages
* Andreas Hoenen [Wed, 04 Mar 2009 17:46:52 +0100]: > BTW, the time delays are interesting. When I wrote my last mail > yesterday evening (CET), #60 was not visible in BTS. Also the BTS mail > to me (I'm subscribed to the report) did not arrive here yesterday > evening. Thus the Date: line in (#60) is somewhat misleading. Raphael's message was initially sent to debian-...@lists.debian.org, and later bounced to the bug report. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org «¡Pero si es tan español que debe de tener el cerebro en forma de botijo, con pitorro y todo!» -- Javier Cercas, “La velocidad de la luz” -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: best practice for updating inetd.conf with a user-chosen port?
* Giacomo A. Catenazzi [Wed, 11 Mar 2009 16:56:20 +0100]: > how to had new services in /etc/services database? By filing a bug like #353835 (against netbase). -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Which package cacher to use?
I’d recommend approx. > * Is it able to cope with multiple architectures? > * Can it support multiple distributions? Supporting Debian, Ubuntu and > other non-official repositories would be really handy. > * Does it keep a directory hierarchy neatly organized like the Debian > archive? Yes, yes, and yes. Additionally, I think this question is not completely OT here, since (and Rogério confirmed it was for this purpose) a package cacher is an essential tool in the life of every maintainer (or, at least, for the intersection between those who care about building in a clean environment, and those who can’t afford a local mirror). Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian/control
* Jaromír Mikeš [Sun, 15 Mar 2009 13:57:40 +0100]: > Hello, > I am not sure what to fill to "Section" in control file for my new package I > am building. > Program is small easy CLI utility generating sound (pink and white noise) Section: sound sounds appropriate to me. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Genericly-named debian.net domains for private use (was Re: Point to semi-official backported packages?)
* Paul Wise [Sat, 28 Mar 2009 12:35:44 +0900]: > On Fri, Mar 27, 2009 at 8:28 PM, Peter Pentchev wrote: > > (And yes, I know about backports.d.n; maybe I'll get 'round to submitting > > or maintaining stuff there at some point, but for the present it is > > a bit easier for me to keep it all in a single repo :) > I think you mean backports.org, backports.debian.net is not what you > think it is. Despite its name, backports.d.n is a personal backports > archive for Daniel Bauman. I really don’t get why it’s appropriate for a developer to use such generic names for their personal stuff. git.debian.net seems to be Daniel’s too. Wouldn’t it be just better to point those domains to the respective project-wide efforts? I’d appreciate opinions on the matter. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: override a package dependency (without rebuilding package)
* Jérémy Lal [Thu, 26 Mar 2009 13:52:49 +0100]: > Hi, > is there a way to change a package dependency without rebuilding it ? > For example, gimp2.6 depends on libwebkit-1.0.1, and i want latest > libwebkit-1.0.2 > installed. I don't really care to break that dependency since gimp will work > without libwebkit (although some stuff will be broken, but i don't mind). > Of course i force installed libwebkit-1.0.2, still i don't want aptitude to > complain > about gimp being broken. And i don't feel like fixing and rebuilding gimp, nor > i want to remove it ! > Any way ? Yes, deb-reversion(1) from the devscripts package. Not sure if this question was on-topic for -mentors, though; I don’t think so. -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
* Goswin von Brederlow [Mon, 30 Mar 2009 14:33:32 +0200]: Hello, [-mentors only Bcc'ed to drop it from the discussion] Executive summary: concerns about ia32-apt-get raised, lesser hack proposed for comments. > before Lenny ftpmaster asked us (ia32-libs maintainers) to do > something about the mess that is ia32-libs. Specifically that it is a > HUGE source duplication and a security nightmare. Unfortunaetly there > wasn't enough time before the release to get a new solution > (ia32-apt-get) into a stable state. Now that Lenny is out the problem > can be attacked again. The major remaining problems are how to > transition from ia32-libs to ia32-apt-get and how packages can depend > on 32bit libs then. (Which actualy hinge on the same problem.) Has there been any public discussions about ia32-apt-get, and consensus that it is an acceptable solution? To be honest, I’m not sure at all it is actually a better solution than the 500 MB source package. For the benefit of others, so that they can comment, I’ll mention how it works. Mainly, ia32-apt-get dpkg-divert’s /usr/bin/apt-get and /usr/bin/dpkg-deb. For apt-get, it intercepts the “update” operation, calling apt-get.real first in an alternative root for the host arch (/var/lib/apt/native), then calling apt-get.real again for the foreign arch (/var/lib/apt/foreign), and then doing gross sed'ing over those to morph them into acceptable package lists for the host arch. Which are later available because the postinst goes ahead and duplicates all entries in sources.list. For dpkg-deb, it intercepts “--control” and “--fsys-tarfile”. The latter does all sorts of pretty things including moving files around (to /usr/lib32, eg.), changing the Architecture field, and amending the Depends field. I realize quite a lot of effort has been put into writing this and to make sure it works, but as said above, I’m unsure it’s an acceptable solution to this problem. As an amd64 user, I’d be disgusted to see such a hack forced down on my system, and disappointed in Debian for sanctioning such solution. > The problem I see here is that ia32-libattr1, ia32-libx86-1, > ia32-libpam0g, ... are not in main as far as DAK is concerned. They > are not known at all in the Debian archive. As such I think [packages > depending on ia32-lib*] could never transition from unstable to > testing on [their] own. Actually they can, because britney can be told that some packages are available even if they are not in the Packages lists. However, and given my opinion above, I will refuse to do that unless there’s clear consensus among the active developers that this is an acceptable solution. Because of that, opinions welcome. I’d also be interested in hearing from ftpmaster their thoughts on the matter. Maybe a less fugly hack can be devised if the need to address the current ia32-libs mess is really strong. Mark Hymers has talked about providing a mechanism to ensure source packages stay on the pool when other stuff has been built from them (eg. kernel module packages). With this, ia32-libs could become a small source package containing scripts that would download the necessary binary packages at build time, and would encode in a header the employed versions; then, source for those versions would not be removed from the pool. And ia32-libs could be easily Bin-NMUed regularly, in order to pick up the latest libraries from testing. I know downloading stuff in the build process is not something we want to do, but we have packages with special needs that do it by design (eg. the installer). Thoughts? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "out of date on mips: siege (from 2.66-2)"
* Tristan Greaves [Sat, 04 Apr 2009 09:53:53 +0100]: > Hi all, > Could someone please explain the above Excuse for me? (I understand the > _what_ but not the _why_ in this instance). > https://buildd.debian.org/pkg.cgi?pkg=siege > My package has successfully built on the other architectures, but the > process does not seem to have run on mips. There are no click-through > logs to look at in order to see if there was a specific problem here, or > whether the build just has not kicked off for some reason. Sometimes a build gets lost or something similar. I’ve scheduled a rebuild. The correct contact address would be debian-wb-t...@lists.d.o. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
