Re: to use upstream scons or not
On Sat, Jul 21, 2007 at 03:18:23AM +0200, Carl Fürstenberg wrote: When you have a upstream package that are using scons, is there a good way to incorperate that into a debian package, or should a new build script be written? The Second Life viewer uses scons to build, but I'm using dh_install to move the produced binaries from their build-location into a filesystem tree, rather than relying on any install rule in the SConstruct file. I haven't hit any other problems that are scons-specific, although the SConstruct file Linden Labs are using seems a bit atypical to my limited scons knowledge. I do have some patches to the SConstruct file in my dpatch patch list, and that seems to work fine, since they're applied before I call scons. -- --- Paul TBBle Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpMmpWx0Rh8U.pgp Description: PGP signature
Re: Auto-building many manpages: redundant work for the buildds ?
2007/7/21, Charles Plessy [EMAIL PROTECTED]: Le Fri, Jul 20, 2007 at 03:05:45PM +0200, Daniel Leidert a écrit : This would violate the Debian Policy section 12.1, reading [..] Each program, utility, and function should have an associated manual page included in the same package. [..]. Hi Daniel, Since it is not a MUST, but just a SHOULD, would it mean that it would be acceptable to ship the manpages with the doc anyway ? If emboss Recommends: emboss-doc, aptitude will install them together by default. Or, alternatively, create an emboss-manpages package (arch: all) to Depend on (as I already stated). That would ensure that every manpage in emboss is shipped (it just violates the in the same package clause -- but it's a SHOULD, as Charles already pointed out), it would reduce the load on buildds, and doesn't require to install the whole documentation package if I only want the naked thing -- binaries and manpages. EMBOSS is a big suite which deals with biological sequences databases, which typically will take at lot of disk space. I think that there would be no inconvenience for the user to install emboss-doc. But that wouldn't guarantee flexibility. Again, I think that an emboss-manpages package would suit best. Have a nice day, Kindly, David -- . ''`. Debian packager! | http://snipurl.com/gofoxygo/ : :' : User #334216 | http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://www.debianizzati.org/ `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
SOLVED: Re: Strange problem with upstream sources (needing to repackage?)
Hi, Adeodato. Thank you very much for the instructions. On Jul 17 2007, Adeodato Simó wrote: * 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. Ok. 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 My fear was that the package, which unpacks by default in a directory named diskdev_cmds-332 were created. Fortunately, I solved this problem with the use of dpkg-source -x and a proper .dsc file, so, now, everything is pristine upstream, with just the tarball being renamed and nothing else. Thanks to Gerfried for helping me with this. The other changes were done by patches with quilt (which is an impressive tool). (Assuming that the version number is 332). Yes, it is, but I discovered, the package with version 332.14 from upstream. Also, you have to name your source package diskdev-cmds (or some other Policy-compliant name), not diskdev_cmds, that is not possible. I named the package hfsprogs. I hope that this is acceptable. HTH, good luck. Thank you very much, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: adonthell (updated package)
Hi Anthony! * Joseph Nahmias [EMAIL PROTECTED] [070628 23:18]: I am looking for a sponsor for the new version 0.3.4.release-1 of my packages adonthell and adonthell-data, which build these binary packages: [snip] I don't see this new version on the mentors site. All that's there is version 0.3.4.cvs.20050813-4. Any news regarding that package? Or should the one available on mentors be sponsored? Also, I would call the game data wastesedge -- similar to the way upstream does, and have it provide a virtual adonthell-game or somesuch. AIUI, wastesedge will be only one of many future games that will be created as the engine matures. Yes, especially, since you seem to need to know, what game data you've installed to play the game. Perhaps it would even be a good idea, to ship a wrapper script calling adontell wastesedge? Yours sincerely, Alexander -- http://learn.to/quote/ http://www.catb.org/~esr/faqs/smart-questions.html signature.asc Description: Digital signature
Re: Auto-building many manpages: redundant work for the buildds ?
Am Samstag, den 21.07.2007, 10:14 +0200 schrieb David Paleino: 2007/7/21, Charles Plessy [EMAIL PROTECTED]: Le Fri, Jul 20, 2007 at 03:05:45PM +0200, Daniel Leidert a écrit : This would violate the Debian Policy section 12.1, reading [..] Each program, utility, and function should have an associated manual page included in the same package. [..]. Hi Daniel, Since it is not a MUST, but just a SHOULD, would it mean that it would be acceptable to ship the manpages with the doc anyway ? I don't see any advantage in this effort. If emboss Recommends: emboss-doc, aptitude will install them together by default. aptitude is not the only package installation tool and this behaviour can be turned off for aptitude too. Or, alternatively, create an emboss-manpages package (arch: all) to Depend on (as I already stated). Where is the advantage of such an effort? There is none. You would have to install two packages instead of simply one and you don't save any space nor bandwith. IMHO shipping manpages and programs separately but depend on each other is a senseless effort. But that's of course my personal opinion. That would ensure that every manpage in emboss is shipped (it just violates the in the same package clause -- but it's a SHOULD, as Charles already pointed out), it would reduce the load on buildds, If the manpages are already prepared, I don't think, you reduce the load of a buildd. Only the question, if the manpages should be prepared during build time IMHO has a valuable effect on the buildd loads. [snip the rest] Regards, Daniel
Re: Auto-building many manpages: redundant work for the buildds ?
On Saturday 21 July 2007, Daniel Leidert wrote: --cut-- Or, alternatively, create an emboss-manpages package (arch: all) to Depend on (as I already stated). Where is the advantage of such an effort? There is none. You would have to install two packages instead of simply one and you don't save any space nor bandwith. IMHO shipping manpages and programs separately but depend on each other is a senseless effort. But that's of course my personal opinion. Of course, this saves space at mirror's side, since large arch independent data are to be found only once in the archive, rather placed in each arch dependent part. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gimmie
Thierry Randrianiriana schrieb: On 7/20/07, Michael Biebl [EMAIL PROTECTED] wrote: [..] Just tested it. Seems, Recommends is not enough for python-dbus and python-gmenu. Gimmie crashes, when either python-gmenu or python-dbus are not installed: [..] So, both should be added to Depends. We need to fix that before the upload. fixed and package updated Thanks, uploaded your package. For future releases, you can contact me directly via PM, if you want. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
RFS/RFC: dictconv
Hi, I've made a dictconv deb, It builds these binary packages: dictconv - Dictconv convert a dictionay file type in another dictionary file The package is not finished, debian/changelog is incomplete, because I've not opened the ITP bug, first I wish to have your commnents and a mentor interest in sponsoring the package... I think that I've too many ITP bugs opened so before opening a newest one I would like to be sure that the package is of interest for someone. Package name: dictconv Version : 0.2-1 Upstream Author : Raul Fernandes [EMAIL PROTECTED] URL : http://ktranslator.sourceforge.net/ License : GPL Section : utils The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/dictconv - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dictconv/dictconv_0.2-1.dsc Cheers, francesco -- Francesco Namuri francesco(at)namuri(dot)it http://namuri.it/ id gpg key: 21A4702A [EMAIL PROTECTED] signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: Nagios version
On Sat, Jul 21, 2007 at 12:01:20AM +0200, Magnus Holmgren wrote: On Friday 20 July 2007 22:53, Christoph Haas wrote: David, please use your real email address. workaround.org is a domain hosted by myself and I'm pretty positive I didn't give you a freedotfr hostname in that domain. Dudu obviously sent a mail with an unqualified address in the From: field, which your mail server (and mine) qualified with the local domain. Oh, funny. Actually I intended my mail server to not do that. Been bitten by my own ignorance. :) Christoph -- Peer review means that you can feel better because someone else missed the problem, too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dpatch or quilt? in maintainer guide
On Tue, Mar 20, 2007 at 11:31:06AM -0700, Brandon Philips wrote: On 10:24 Tue 20 Mar 2007, Pierre Habouzit wrote: On Tue, Mar 20, 2007 at 01:07:00AM -0700, Brandon Philips wrote: On 18:35 Sun 18 Mar 2007, Pierre Habouzit wrote: On Tue, Feb 27, 2007 at 03:08:17PM -0800, Brandon Philips wrote: I am looking for a sponsor for my package guilt. The package works but I still need to write man pages. I moved to debian/patches with dpatch. Is this a reasonable solution? use what you like. I usually find quilt simpler, but really, I care much about you beeing comfortable with it than me. You may want to read[0]. Yes, it is reasonable for a package quilt for git to use quilt itself :-) Wow, quilt is much easier to use. The new maintainer guide recommended dpatch but it sort of sucked, good thing I asked :) I do not think I recommended dpatch over quilt. Please be careful. Quoting pertinent section I wrote -- Several methods for the patch set maintenance have been proposed and are in use with Debian packages. The dpatch system is one of the simplest of such patch maintenance system proposed. Other ones are dbs, cdbs, etc. FYI: At the time of writing, quilt was not much (or not at all) used in Debian. dpatch was the only actively used simple multi-patch system thus I chose to describe dpatch. dpatch is debian packaging specific, quilt is not. I hear quilt has more user friendly UI but these 2 are practically the same thing for me. Just personal taste differences. dpatch-edit-patch is supposed to be dpatch's UI which matches quilt's UI. (I never use it seriously, I tend to create patches by hand. Thus I touch on this lightly there.) (There are some corner case finction differences like CPP.) I personally do not like the use of cdbs for a simple package which obscures what exactly is going on. 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.) Your input is welcome. I uploaded a new version that uses quilt instead. Good for you. Osamu signature.asc Description: Digital signature
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: quilt, cdbs, dpatch, but is there even simpler ?
Hi,
On Wed, Mar 21, 2007 at 10:40:26AM +, Jörg Sommer wrote:
Hi Charles,
Charles Plessy [EMAIL PROTECTED] wrote:
Le Tue, Mar 20, 2007 at 11:31:06AM -0700, Brandon Philips a écrit :
I moved to debian/patches with dpatch. Is this a reasonable solution?
use what you like. I usually find quilt simpler, but really, I care
much about you beeing comfortable with it than me. You may want to
read[0].
Wow, quilt is much easier to use. The new maintainer guide recommended
dpatch but it sort of sucked, good thing I asked :)
For the moment I use dpatch, but is is a slight work overhead since it
is needed to convert patches to dpatches,
Are you sure, this is necessary? AFAIK the comments and shell commands
are optional.
Comments are optional but the first line is needed now as:
#! /bin/sh /usr/share/dpatch/dpatch-run
I had the same impression as yours.
I guess changing following 2 lines should fix situation.
line 416: test -x ${patch} || chmod +x ${patch}
line 434: if eval ${patch} -patch ${wd} ${redir} ${stamp}.new 21; then
I guess drop 416 and run dpatch-run in 434.
Probably, deapply needs fix too.
I do not know this is caused by some design decision or not. (CCing to current
active maintaner)
Osamu
Re: dpatch or quilt? in maintainer guide
On Sun, Jul 22, 2007 at 05:59:20AM +0900, Osamu Aoki wrote: If someone makes checking on the archive how many packages build depends on dpatch and quit $ grep-dctrl -FBuild-Depends dpatch -sPackage /var/lib/apt/lists/ftp.mx.debian.org_debian_dists_unstable_main_source_Sources|wc -l 1461 $ grep-dctrl -FBuild-Depends quilt -sPackage /var/lib/apt/lists/ftp.mx.debian.org_debian_dists_unstable_main_source_Sources|wc -l 574 signature.asc Description: Digital signature
Re: dpatch or quilt? in maintainer guide
On Sat, Jul 21, 2007 at 11:38:55PM +0200, Adeodato Simó wrote: * 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. OK. Thanks. I quoted this and filed bug report to maint-guide myself. Let's continue there to nail down the best text for the update. My thought is not to go into detail for quilt yet since it is still 1/3 of dpatch. I welcome your thought to be posted to the BTS of maint-guide.
Re: quilt, cdbs, dpatch, but is there even simpler ?
Hi,
I moved to debian/patches with dpatch. Is this a reasonable
solution?
use what you like. I usually find quilt simpler, but really, I care
much about you beeing comfortable with it than me. You may want to
read[0].
Wow, quilt is much easier to use. The new maintainer guide recommended
dpatch but it sort of sucked, good thing I asked :)
For the moment I use dpatch, but is is a slight work overhead since it
is needed to convert patches to dpatches,
Are you sure, this is necessary? AFAIK the comments and shell commands
are optional.
Comments are optional but the first line is needed now as:
#! /bin/sh /usr/share/dpatch/dpatch-run
I had the same impression as yours.
I guess changing following 2 lines should fix situation.
line 416: test -x ${patch} || chmod +x ${patch}
line 434: if eval ${patch} -patch ${wd} ${redir} ${stamp}.new 21; then
I guess drop 416 and run dpatch-run in 434.
Probably, deapply needs fix too.
I do not know this is caused by some design decision or not. (CCing to
current
active maintainer)
Yeah, I guess it was a design decision. If I follow your advise, I
will break those tools that do not run dpatch-run. Most of the
original dpatch scriptlets contained shell scripts which
applied/deapplied themselves.
I read the manual, and apparently there is a simple way to create
dpatch scriptlets (man dpatch):
Creating dpatch scriptlets
There are many ways to create dpatch scriptlets. They are
simple, executable files, which follow a standardised calling
convention (documented in dpatch(7)).
You can fire up your $EDITOR, or use dpatch-edit-patch, and you
should be all set.
For most cases, where the dpatch file is only to apply a simple
patch, there is an even easier way:
dpatch patch-template -p 01_some_patch A random patch \
random.diff debian/patches/01_some_patch.dpatch
regards,
junichi
--
[EMAIL PROTECTED],netfort.gr.jp} Debian Project
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Auto-building many manpages: redundant work for the buildds ?
On Sat, 21 Jul 2007 14:14:17 +0900, Charles Plessy [EMAIL PROTECTED] said: Le Fri, Jul 20, 2007 at 03:05:45PM +0200, Daniel Leidert a écrit : This would violate the Debian Policy section 12.1, reading [..] Each program, utility, and function should have an associated manual page included in the same package. [..]. Hi Daniel, Since it is not a MUST, but just a SHOULD, would it mean that it would be acceptable to ship the manpages with the doc anyway ? Violations of SHOULD rules are still bugs (unless you can demonstrate it is policy that is buggy), even if they are not RC bugs. manoj -- I got rid of my husband. The cat was allergic. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: quilt, cdbs, dpatch, but is there even simpler ?
Hi,
I was unclear.
On Sun, Jul 22, 2007 at 12:59:44PM +0900, Junichi Uekawa wrote:
Hi,
I moved to debian/patches with dpatch. Is this a reasonable
solution?
use what you like. I usually find quilt simpler, but really, I care
much about you beeing comfortable with it than me. You may want to
read[0].
Wow, quilt is much easier to use. The new maintainer guide recommended
dpatch but it sort of sucked, good thing I asked :)
For the moment I use dpatch, but is is a slight work overhead since it
is needed to convert patches to dpatches,
Are you sure, this is necessary? AFAIK the comments and shell commands
are optional.
Comments are optional but the first line is needed now as:
#! /bin/sh /usr/share/dpatch/dpatch-run
I had the same impression as yours.
This was wrong impression of mine.
I should have said after this as:
If we ever want to make dpatch to function like quilt, I guess, changing
following 2 lines should fix situation. But I have no idea how this
affects other parts of dpatch.
I guess changing following 2 lines should fix situation.
line 416: test -x ${patch} || chmod +x ${patch}
line 434: if eval ${patch} -patch ${wd} ${redir} ${stamp}.new 21; then
I guess drop 416 and run dpatch-run in 434.
Probably, deapply needs fix too.
So I am not so interested to change it.
I do not know this is caused by some design decision or not. (CCing to
current
active maintainer)
Yeah, I guess it was a design decision. If I follow your advise, I
will break those tools that do not run dpatch-run. Most of the
original dpatch scriptlets contained shell scripts which
applied/deapplied themselves.
Thanks.
dpatch patch-template -p 01_some_patch A random patch \
random.diff debian/patches/01_some_patch.dpatch
Yes of cource.
I guess the original poster (not me) felt even doing this simple task
was more than just cp andom.diff ebian/patches/01_some_patch.dpatch.
I like dpatch approach to lead people to add description since it
documents patch well.
At the same time, first line seems redundant. So if you can devise
means to check this diff file style, we may have one without executable
as the third variant.
1. Old long script header executable.
2. New Short 1 line script.
3. No executable (a file not started with #!)
For 1 and 2, execute as now.
For 3, just assume to apply as -p1 patch like 2.
Well, this is super low priority wish list.
Osamu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: quilt, cdbs, dpatch, but is there even simpler ?
Le Sun, Jul 22, 2007 at 01:50:11PM +0900, Osamu Aoki a écrit : I guess the original poster (not me) felt even doing this simple task was more than just cp andom.diff ebian/patches/01_some_patch.dpatch. I like dpatch approach to lead people to add description since it documents patch well. Hi everybody, In April, I sent a patch on this list to get feedback before opening a wishlist bug on the new mainainers's guide. http://lists.debian.org/debian-mentors/2007/04/msg00086.html However, I forgot about it in the meantime... I think that dpatch and quilt can be used in very similar ways when one does not try to take full advantage of their specificities (arch-specific patches for dpatch, powerful command line interface for quilt). Both of them allow comments, by the way. I discovered that quilt is easy to use during one meeting of the Tokyo area debian study group ; I really think that it would desserve to advertised side to side with dpatch in the new maintainers's guide. As you said in your message, its main advantage for beginners is that it allows to drop patches in debian/patches without having to dig a manpage to understand how to properly reformat the patch. I just sent my patch to the sgml source of the guide on bug #434156 Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
OK, let's build the manpages offline.
Le Sat, Jul 21, 2007 at 03:14:15PM +0200, Daniel Leidert a écrit : Hi Daniel, Since it is not a MUST, but just a SHOULD, would it mean that it would be acceptable to ship the manpages with the doc anyway ? Where is the advantage of such an effort? There is none. You would have to install two packages instead of simply one and you don't save any space nor bandwith. IMHO shipping manpages and programs separately but depend on each other is a senseless effort. But that's of course my personal opinion. Well, at the beginning I thought that there was a choice to be made between loading the buildds, having a heavy diff.gz, or finding an in-between solution with an arch:all package (taking granted that in the future buildds will not build arch:all packages when they have been produced by faster buildds). Since nobody objected against having many manpages in the diff.gz, we will build them before source package upload. Many thanks everybody for your input ! Have a nice weekend, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
