Re: Question about packaging a kernel module
Is the current kernel source available as a binary package? Why do you need a binary package? You can always do apt-get source linux-image-version-and-arch - most likely this works for Ubuntu too. Besides there seems to be a binary package for the kernel source in Debian: linux-source-version-and-arch Best regards Ben -- Please do not send any email to [EMAIL PROTECTED] -- all email not originating from the mailing list will be deleted. Use the reply to address instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about packaging a kernel module
On Fri, Mar 10, 2006 at 10:30:34AM +0100, Benjamin Mesing wrote: Is the current kernel source available as a binary package? Why do you need a binary package? You can always do apt-get source linux-image-version-and-arch - most likely this works for Ubuntu too. Besides there seems to be a binary package for the kernel source in Debian: linux-source-version-and-arch Some time ago I wrote a Howto about that topic. Creating a kernel with CTX patch the Debian way. https://dev.njh6.de/wiki/index.php/Doc:Debian-Kernel-CTX It's for Debian/Sarge, and it's german. But the commands should be self-explaining and will give you a general idea. It uses the kernel source package and make-kpkg. It's a very elegant way to produce a Debian package containing your new patched kernel. If someone is really interested in that Howto, I'd translate it to english. Greets, Volker -- Volker Grabsch ---(())--- Administrator NotJustHosting GbR -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Making multiple-version Python packages with debhelper?
On Tue, Mar 07, 2006 at 02:50:12PM +0100, Florian Ragwitz wrote: Hello, I was asked to make my python-selecting package support multiple Python versions. Does somebody know the proper way to achieve that with debhelper (using dh_python in some way perhaps?), or a pointer to such information? Take a look at the [1]rules file for python-bluetooth, prepared by [EMAIL PROTECTED] [1] http://files.perldition.org/python-bluetooth.rules Okay, I now updated the package to build for multiple versions. It seems that python:Depends is clever enough that debian/control need not be updated when the default Python version changes. The new package is available at: http://sange.fi/~atehwa/debian/python-selecting_0.92-2.diff.gz http://sange.fi/~atehwa/debian/python-selecting_0.92-2.dsc http://sange.fi/~atehwa/debian/python-selecting_0.92.orig.tar.gz Panu -- personal contact: [EMAIL PROTECTED], +35841 5323835 technical contact: [EMAIL PROTECTED], http://www.iki.fi/atehwa/ PGP fingerprint:0EA5 9D33 6590 FFD4 921C 5A5F BE85 08F1 3169 70EC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: backports?
Wolfgang Lonien wrote: I'm asked to do some backporting from time to time - would that count as: we require that prospective developers have already contributed – in the form of translations, documentation, sending patches or package maintenance. (from the new maintainers' corner)? No. Backporting is easy, and something completely diffrent than building a package from scratch and/or maintaining a package on your own. And would I send these only to backports.org, or should I also try to find some mentor/sponsor here? If you need a sponsor for backports.org, just write to [EMAIL PROTECTED], and give an URL where the backported package can be reviewed. I, at least, will look at it in a very timely fashion, for sure. -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Doing a proper package split (cream)
Evening... 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. '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). My debian/control file of the new 0.34 package now looks roughly like this: shnip-- Source: cream Section: editors Priority: optional Maintainer: Christoph Haas [EMAIL PROTECTED] Build-Depends-Indep: debhelper (= 4.0.0) Standards-Version: 3.6.2 Package: cream Architecture: all Depends: gvim, ucf Suggests: cream-doc Description: ... ... Package: cream-doc Architecture: all Conflicts: cream(0.34) Replaces: cream(0.34) Recommends: cream Description: ... ... --shnup-- Without the Conflicts+Replaces in the cream-doc part users could install the new cream-doc (0.34) package and get conflicts because the same documentation-related files were formerly in the cream (0.33) package. So I needed to make sure it gets removed before cream-doc (0.34) is installed. 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?). 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. I would like to install both new versions when either new package is installed. What would you propose to do to have a proper upgrade path here? Remove 'cream' in the 'postinst' maintainer script of 'cream-doc' if a 'cream' version of 0.34 was installed? I don't want to make it even dirtier than it's now. Thanks in advance. Christoph -- ~ ~ .signature [Modified] 1 line --100%--1,48 All -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: MinGW cross compiled library packages for Debian
Dear Debian Mentors, thanks a lot for your ideas and opinions. After having thought about it, I try to summarize what I plan to do: I don't think I should ask every Debian maintainer to produce mingw32 binary packages. Instead, I'll build extra Debian packages using the sources of GnuWin32 (http://gnuwin32.sourceforge.net). The libraries libsmpeg, SDL_mixer, ... are not covered by GnuWin32, but they don't have any good MinGW builds anyway. So I think it's better to ask GnuWin32 to support these packages. The only remaining library is SDL which isn't covered by GnuWin32 and has good MinGW builds. But even that package should be included in GnuWin32, because GnuWin32 has a nice installing system (for Windows MinGW). What do you think about it? Is it reasonable? Is it good practice? Is there anything else I should take care of? Greets, Volker -- Volker Grabsch ---(())--- Administrator NotJustHosting GbR -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Doing a proper package split (cream)
On Fri, Mar 10, 2006 at 02:33:35PM +0100, Christoph Haas wrote:
Evening...
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.
'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).
My debian/control file of the new 0.34 package now looks roughly like this:
shnip--
Source: cream
Section: editors
Priority: optional
Maintainer: Christoph Haas [EMAIL PROTECTED]
Build-Depends-Indep: debhelper (= 4.0.0)
Standards-Version: 3.6.2
Package: cream
Architecture: all
Depends: gvim, ucf
Suggests: cream-doc
Description: ...
...
Package: cream-doc
Architecture: all
Conflicts: cream(0.34)
Replaces: cream(0.34)
Recommends: cream
Description: ...
...
--shnup--
Without the Conflicts+Replaces in the cream-doc part users could install
the new cream-doc (0.34) package and get conflicts because the same
documentation-related files were formerly in the cream (0.33) package.
So I needed to make sure it gets removed before cream-doc (0.34) is
installed.
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?). 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. I would like to
install both new versions when either new package is installed.
What would you propose to do to have a proper upgrade path here? Remove
'cream' in the 'postinst' maintainer script of 'cream-doc' if a 'cream'
version of 0.34 was installed? I don't want to make it even dirtier than
it's now.
Certainly not :)
Besides, you can't run 2 dpkg processes at the same time (with the
same $root).
You probably want to make a new dummy package, one which I guess will
have just copyright and changelog files, will be named cream, and
will have Depends: cream-doc, cream-program. This will cause existing
cream installations to have the same things included in them, though
by different packages.
That 'cream' is installed (before the upgrade) will cause apt.. to
want it to be installed after the upgrade, and to upgrade it to the
latest version, also. Upgrading will pull in both of cream-program
(rename to your liking) and cream-doc.
You *could* also make cream-doc Depend: cream (${Source-Version}), but
this really isn't necessary; apt an friends will upgrade both at the
same time, unless the user specifically holds/upgrades exactly one
package.
BTW cream should have a description about being a dummy package; you
should read:
http://lists.debian.org/debian-devel/2005/10/msg01154.html
Also, if cream had conffiles which changed across the upgrade, you
would have to deal specially with them; transferring ownership of
conffiles, see my bugs #345112 and friends..
I'm interested if there are other ways of doing this, though.
Actually, I wonder if this can be done purely with Conflicts+Replaces.
In any case, you can and should always drop the upgrade foo after the
next stable release.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gaim-snapshot (possible) newbie question
Hello, I'm trying to apply to the NM program so this whole email is quite newbie-ish. I've been making some gaim debs for the cvs version lately. It's quite stable and usable by now. Can this be a good candidate for experimental? It Conflict's with gaim so that if you don't want gaim 1.5 removed you can just prevent gaim-snapshot from installing if you don't want it. I made a deb for gaim-libnotify too. Now it's not that featureful but it can be a suitable replacement for guifications. The .deb required some patches in the code and in the configure script (the it.po translation I sent to the maintainer was not included in the configure.ac file), and I don't know if I made some formal mistakes, it seems to work quite well though. Can anybody review (and hopefully upload) those? I have nor sponsors nor advocates, by now. deb http://kuolema.kicks-ass.org/deb ./ deb-src http://kuolema.kicks-ass.org/deb ./ # sources included too :) The names are gaim-snapshot[,-data,-dev,-libnotify] Ciao ~marco signature.asc Description: Questa parte del messaggio è firmata
Re: gaim-snapshot (possible) newbie question
On Fri, Mar 10, 2006 at 05:18:01PM +0100, Marco Cabizza wrote: Hello, Hi. I'm trying to apply to the NM program so this whole email is quite newbie-ish. I've been making some gaim debs for the cvs version lately. It's quite stable and usable by now. Can this be a good candidate for experimental? Uploading such package would be considered as hijacking someone's else package. The current maintainer of gaim (Robert McQueen) should be first person to contact with such idea. So IMHO this is very bad package for starting NM process. [...] regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: gaim-snapshot (possible) newbie question
Hi Marco, On Fri, 2006-03-10 at 17:18 +0100, Marco Cabizza wrote: It's quite stable and usable by now. Can this be a good candidate for experimental? Yes. It Conflict's with gaim so that if you don't want gaim 1.5 removed you can just prevent gaim-snapshot from installing if you don't want it. I don't think this is a good idea. You should remain with the gaim package name, just use a normal package version. So if the CVS version just adds some tweaks use stable_version+cvsdate; if it is a candidate for a new upstream release, use (stabletobe_version-minor)+cvsdate. So if new upstream version is going to 1.5, use 1.49+cvs060310 as a package version. Can anybody review (and hopefully upload) those? I have nor sponsors nor advocates, by now. It may sound rude, but I hope all will say no. I don't think messing with an existing package would be good; ask the gaim maintainer, Robert McQueen [EMAIL PROTECTED] about blessing. OK, we can review your packages, but upload is a no-no, at least by me. Regards, Laszlo/GCS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Doing a proper package split (cream)
Justin, thanks for your reply. On Friday 10 March 2006 16:39, Justin Pryzby wrote: You probably want to make a new dummy package, one which I guess will have just copyright and changelog files, will be named cream, and will have Depends: cream-doc, cream-program. This will cause existing cream installations to have the same things included in them, though by different packages. Yes, that case looks simpler: cream (split)--- cream-main + cream-doc In this case 'cream' would just become a dummy package. To my eyes that's still a bit ugly. If possible I'd wish for: cream (split)--- cream + cream-doc Also, if cream had conffiles which changed across the upgrade, you would have to deal specially with them; transferring ownership of conffiles, see my bugs #345112 and friends.. True. If the latter alternative would somehow work I wouldn't need to transfer the conffiles to a new package because it would remain in 'cream'. In any case, you can and should always drop the upgrade foo after the next stable release. Another issue I would like to avoid because I'll surely forget to remove that cruft. :) A good once and for all solution would make me happier. But it actually looks like the solution you proposed is more common. 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. Doubtingly Christoph -- ~ ~ .signature [Modified] 1 line --100%--1,48 All -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gaim-snapshot (possible) newbie question
On Fri, 2006-03-10 at 17:18 +0100, Marco Cabizza wrote: Can anybody review (and hopefully upload) those? My main concern (apart from the valid hijacking concerns raised) is that it's a Debian native package. That's not right; you should use an orig.tar.gz from upstream; even if you pull from CVS yourself, you need to make a tgz out of that and use that as the orig.tar.gz. The .diff.gz will then contain exactly the packaging and other Debian-specific changes. The package also exhibits some other lintian/linda warnings/errors: W: gaim-snapshot source: maintainer-script-lacks-debhelper-token debian/gaim-snapshot-dev.postinst W: gaim-snapshot source: source-contains-CVS-dir .ssh/CVS E: gaim-snapshot; Uses cdbs and debhelper.mk, but debhelper Build-Depends is too old. The CVS one may be caused by using cvs co instead of cvs export. bye, Thijs signature.asc Description: This is a digitally signed message part
Re: Making multiple-version Python packages with debhelper?
On Fri, Mar 10, 2006 at 02:17:56PM +0200, Panu Kalliokoski wrote: On Tue, Mar 07, 2006 at 02:50:12PM +0100, Florian Ragwitz wrote: Hello, I was asked to make my python-selecting package support multiple Python versions. Does somebody know the proper way to achieve that with debhelper (using dh_python in some way perhaps?), or a pointer to such information? Take a look at the [1]rules file for python-bluetooth, prepared by [EMAIL PROTECTED] [1] http://files.perldition.org/python-bluetooth.rules Okay, I now updated the package to build for multiple versions. It seems that python:Depends is clever enough that debian/control need not be updated when the default Python version changes. The new package is available at: http://sange.fi/~atehwa/debian/python-selecting_0.92-2.diff.gz http://sange.fi/~atehwa/debian/python-selecting_0.92-2.dsc http://sange.fi/~atehwa/debian/python-selecting_0.92.orig.tar.gz You're still shipping /usr/sbin which you probably don't use. You should check the contents of the .deb with dpkg-deb -c ../...deb or if it is installed dpkg -L foo + -$(PY23) setup.py clean + -$(PY24) setup.py clean This is bad for reasons documented by Branden's lintian bug (careless use of make clean). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Doing a proper package split (cream)
Hello, Christoph Haas wrote: '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). That only makes sense when the documentation is large and the package has arch-specific components. Since both packages are arch:all, at least in the control file you posted, I doubt it is worth it. Conflicts: cream(0.34) Replaces: cream(0.34) If there is no functional conflict, you can omit the Conflicts: here, as you are merely replacing files in the old version. This would, however, allow a situation where the new docs and the old programs are installed. Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gaim-snapshot (possible) newbie question
Il giorno ven, 10/03/2006 alle 18.13 +0100, Thijs Kinkhorst ha scritto: On Fri, 2006-03-10 at 17:18 +0100, Marco Cabizza wrote: Can anybody review (and hopefully upload) those? My main concern (apart from the valid hijacking concerns raised) is that it's a Debian native package. That's not right; you should use an orig.tar.gz from upstream; even if you pull from CVS yourself, you need to make a tgz out of that and use that as the orig.tar.gz. The .diff.gz will then contain exactly the packaging and other Debian-specific changes. The package also exhibits some other lintian/linda warnings/errors: W: gaim-snapshot source: maintainer-script-lacks-debhelper-token debian/gaim-snapshot-dev.postinst W: gaim-snapshot source: source-contains-CVS-dir .ssh/CVS E: gaim-snapshot; Uses cdbs and debhelper.mk, but debhelper Build-Depends is too old. The CVS one may be caused by using cvs co instead of cvs export. bye, Thijs Thanks for the replies. I just had to learn something. Anyway, about the hijacking, well, that's why I said candidate. I sent Robert an email and got no reply, I hope I'll get one some day :) (I named it gaim-snapshot because I didn't want by any means mess with gaim). And I don't want it to be uploaded now, I have pretty much 5% experience in packaging .deb's, I just asked for information for a *might*be*candidate* package, and I got some, thank you! Thijs, I am trying to fix the issues now. Marco signature.asc Description: Questa parte del messaggio è firmata
Closing #338657
Ok, new attempt :) I spent the second-to-last 30 minutes scanning wnpp for packages i could debianize and I found this one (buoh, online comic strip viewer) that I actually used some months ago. There was actually an ubuntu .deb already, but it installs into /usr/local and I guess it was done with checkinstall. Anyway, I uploaded it in the mentors' repo - as well as mine. deb http://kuolema.kicks-ass.org/deb ./ The only error i get is binary-without-manpage because the package actually has no manpage. Ciao ~marco signature.asc Description: Questa parte del messaggio è firmata
Re: Closing #338657
On 2006-03-10, Marco Cabizza [EMAIL PROTECTED] wrote: The only error i get is binary-without-manpage because the package actually has no manpage. That task is quite easy to solve ;) Just write a man page ... perhaps help2man can help you /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Closing #338657
Sune Vuorela wrote: On 2006-03-10, Marco Cabizza [EMAIL PROTECTED] wrote: The only error i get is binary-without-manpage because the package actually has no manpage. That task is quite easy to solve ;) Just write a man page ... perhaps help2man can help you Hey! Thank you for that tip Sune, I've never seen that app before and it will help me a lot! /Sune -- 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: Closing #338657
Done. I didn't write one because I thought it wasn't needed, as the program itself had no manpage... but here it is. help2man was a little useless because the whole --help output referred to GNOME specific stuff and the only useful flag was --version :) It helped me to learn the syntax though, and may be useful in the future, thanks. Updated both repositories! Il giorno ven, 10/03/2006 alle 19.08 +, Sune Vuorela ha scritto: That task is quite easy to solve ;) Just write a man page ... perhaps help2man can help you /Sune signature.asc Description: Questa parte del messaggio è firmata
Re: Doing a proper package split (cream)
Am Freitag, 10. März 2006 18:00 schrieb Simon Richter: Christoph Haas wrote: '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). That only makes sense when the documentation is large and the package has arch-specific components. Since both packages are arch:all, at least in the control file you posted, I doubt it is worth it. Sure, the architecture-dependency is one aspect. But the size of the package is what mattered to me: 512552 cream_0.34-2_all.deb 637582 cream-doc_0.34-2_all.deb So separating the documentation would save 640 KB for a normal installation. I thought it would be worth it. Conflicts: cream(0.34) Replaces: cream(0.34) If there is no functional conflict, you can omit the Conflicts: here, as you are merely replacing files in the old version. This would, however, allow a situation where the new docs and the old programs are installed. You are right. But isn't that true for a number of other split packages, too? Christoph -- ~ ~ .signature [Modified] 1 line --100%--1,48 All
Re: Doing a proper package split (cream)
Am Freitag, 10. März 2006 20:36 schrieb Adeodato Simó: (uhm, I was replying to this, but I see that the split is already in the archive. I decided for the split already and then was pointed at problems with 0.34-1 so I was rather looking for a half-decent solution now. Re-joining the package might be sane, too. I could just add a Replaces: cream-doc and forget about the split. Executive summary: please remove the conflicts; I'd personally not split the package, but is your call; current status good, except for the conflicts.) Okay. 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 I incorrectly considered the sizes of the binary package files instead of the actual installed-size. This makes the split even less useful. Rats. Christoph -- ~ ~ .signature [Modified] 1 line --100%--1,48 All
Attempting to adopt two packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For a while now, I've been interested in the checkinstall package. I see that the current maintainer (Matt Hope) is apparently MIA, and that installwatch (which currently is shipped with checkinstall now, anyway) was orphaned recently. So I'd like to adopt these two packages, and have already done some work on them. However, I have some questions: 1) What is the proper way to handle hijacking of packages? I have tried to contact Matt, but so far I haven't received any response (mail was sent on 11/01/06). I do know I have to file an ITA bug to each package, but I haven't yet (I'd rather be sure what to do before doing it). 2) It seems to me that now, since installwatch and checkinstall come bundled and that they are small packages (each package is 23 and 64 KB respectively), it makes sense to merge this two packages. Does it? If it is, how is this to be done? 3) Actually, the source packages need merging anyway. Do the changelogs need merging? How is that done? Any help with this questions is greatly appreciated. - -- Felipe Sateler -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEEeMK19K8LkCXFHcRAsdZAKCfBWXFCH5l1ONWqxkYtnMpkGETzACfRV4n JcZdFe+LSilWc/YmHgr6jmU= =eEK7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Doing a proper package split (cream)
Christoph Haas [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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?). 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. I would like to install both new versions when either new package is installed. For some reason dpkg seems to be getting confused. (or perhaps policy is not clear enough about the way dpkg acts) It appears to be ignoring the conflict line. It installs your documentation package over the other package as the replaces line allows. However your package does not fully replace the other so the other one is not 'dissapeared'. Interestingly dpkg seems to decide that it should remove cream, but does not. I think you should just drop the replaces. Then cream-doc would not install at all if 0.33.1-1 is installed. However it would happily install after cream has been upgarded to a new version. Policy quote: A Conflicts entry should almost never have an earlier than version clause. This would prevent dpkg from upgrading or installing the package which declared such a conflict until the upgrade or removal of the conflicted-with package had been completed. That sounds about right to me. (The above is based on my understanding of how policy claims dpkg should work, but does not nessisarally reflect reality.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about packaging a kernel module
On Fri, Mar 10, 2006 at 07:40:50AM -0800, Martin Kelly wrote: I can try to struggle through it with a translator, but if it's not too much trouble, an English translation would be nice :). Okay. I tried by best: https://dev.njh6.de/wiki/index.php/Doc:Compile_Debian_Kernel_with_CTX Feel free to correct any stylistic, spelling, etc. mistakes. It's a wiki. This howto links to a Debian documentation which you should read, too: http://www.debian.org/doc/manuals/reference/ch-kernel.en.html Thanks all, I will investigate module-assistant and tell you if I have any problems :). I left this quote because you sent that mail accidently just to me instead of the mailing list. Greets, Volker -- Volker Grabsch ---(())--- Administrator NotJustHosting GbR -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC/RFS: beef - a flexible BrainFuck interpreter
Here I am again, mentors. I just released a new version of beef, and created a new Debian package. The package is both lintian and linda clean, and builds correctly using pbuilder. * Package: beef Version: 0.0.4 Upstream author: KiyuKo [EMAIL PROTECTED] * URL: http://www.kiyuko.org/beef/ Licence: GPL Description: flexible BrainFuck interpreter beef is a BrainFuck interpreter written in C. Its behavior is configurable using command-line options, so you can run a lot of BrainFuck programs written for other interpreters/compilers without modifications. beef gets rid of some historical BrainFuck limitations: for example, the length of the memory tape has no limits except for the amount of memory your computer has. beef's aim is not to be incredibly small or optimized, but to be a flexible and pleasant-to-work-with interpreter. The package is available at the following URLs: * http://www.kiyuko.org/debian/beef_0.0.4.orig.tar.gz * http://www.kiyuko.org/debian/beef_0.0.4-1.diff.gz * http://www.kiyuko.org/debian/beef_0.0.4-1.dsc You can also APT my repository by adding deb http://www.kiyuko.org/debian ./ deb-src http://www.kiyuko.org/debian ./ to your sources.list Any comment is welcome. A sponsor, even more. Cheers. -- KiyuKo eof AT kiyuko DOT org Like Russian Rulette with six bullets loaded pgpgb0nAoH11w.pgp Description: PGP signature
Non-Debian packaging practice
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there a document describing software packaging good practices for general use, not specific to Debian, preferably in electronic form? Debian discourages creating Debian-native packages: This type of packaging is only appropriate for the debian-specific packages, which will never be useful in another distribution. [1] But creating it for other distributions requires some knowledge of what those other distributions expect of a package. The current interest here is primarily in packages consisting of shell scripts, as opposed to compilable code, but presumably the question arises in either case. -- [1] /usr/share/doc/maint-guide/maint-guide.en.txt.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 http://mailcrypt.sourceforge.net/ iD8DBQFEEJhRDkU5rhlDCl4RAh1xAJ471EZlxIW2x33VajxdeeZL0xXqEQCdHimL G2Mtgjp4TEjmVTZNwDTdmBI= =yND9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about packaging a kernel module
Thanks for the translation! This will help to build a custom kernel; I will bookmark it. I believe this message is sent only to the mail list this time :P. Martin Volker Grabsch wrote: On Fri, Mar 10, 2006 at 07:40:50AM -0800, Martin Kelly wrote: I can try to struggle through it with a translator, but if it's not too much trouble, an English translation would be nice :). Okay. I tried by best: https://dev.njh6.de/wiki/index.php/Doc:Compile_Debian_Kernel_with_CTX Feel free to correct any stylistic, spelling, etc. mistakes. It's a wiki. This howto links to a Debian documentation which you should read, too: http://www.debian.org/doc/manuals/reference/ch-kernel.en.html Thanks all, I will investigate module-assistant and tell you if I have any problems :). I left this quote because you sent that mail accidently just to me instead of the mailing list. Greets, Volker -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Attempting to adopt two packages
On Fri, Mar 10, 2006 at 05:35:15PM -0300, Felipe Sateler wrote: contact Matt, but so far I haven't received any response (mail was sent on 11/01/06). I do know I have to file an ITA bug to each package, but I In the case of installwatch, you should retitle the 'O'rphan bug instead: http://packages.qa.debian.org/installwatch = #347469 2) It seems to me that now, since installwatch and checkinstall come bundled and that they are small packages (each package is 23 and 64 KB respectively), it makes sense to merge this two packages. Does it? The most important reason/justification for merging the 2 packages is that a single upstream source package now provides both. If it is, how is this to be done? What you want to happen, is that anyone who has either of installwatch or checkinstall now, ends up with the new version of whatever the new packagename will be. Do it by setting Package: foo Replaces: bar Conflicts: bar The overloaded combination of Conflicts+Replaces means this is the new name for package bar, so it will cause files in bar but not foo to be removed. Note that if there were conffiles in bar which you wanted to become owned by package foo, and you wanted to change the contents of that conffile too, you would have to do extra work in preinst (but this doesn't appear to be the case). 3) Actually, the source packages need merging anyway. Do the changelogs need merging? How is that done? Copying the changelog for package bar to a new file changelog-bar-old is probably the cleanest way. You might consider requesting uploads as an NMUs initially, though if it were a QA-owned package this would be a QA upload rather than an NMU. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Non-Debian packaging practice
On Fri, Mar 10, 2006 at 10:35:22PM -, StealthMonger wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there a document describing software packaging good practices for general use, not specific to Debian, preferably in electronic form? I'm not entirely sure I understand what you mean. Debian discourages creating Debian-native packages: This type of packaging is only appropriate for the debian-specific packages, which will never be useful in another distribution. [1] But creating it for other distributions requires some knowledge of what those other distributions expect of a package. Of course Debian doesn't attempt to describe with other distros expect. Since you're talking about stuff that will apparently be used in other distros, you want a non native package anyway, right? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: nmzmail -- indexes and searches email in maildir folders, especially mutt
I am looking for a sponsor for the package 'nmzmail'. This is a great little program that indexes and searchs email in maildir folders. It truly shines when used in combination with mutt, making searches of your email extremely easy and quick. The package is lintian/linda clean and builds cleanly in pbuilder-sid. Thank you in advance for reviewing this package and possibly sponsoring it. Package name: nmzmail Version:1.3-1 Upstream author:Johannes Hofmann [EMAIL PROTECTED] URL:http://www.ecademix.com/JohannesHofmann/#nmzmail License:GPL Description:nmzmail is a tool, primarily to be used with mutt, for indexing and searching maildir folders. Based on the result of a search query using the search engine namazu2, nmzmail generates a maildir folder containing symbolic links to the mail(s) matching the query. A simple mutt macro makes it easy to use nmzmail from within mutt. nmzmail is similar to mairix (another email index/search program), but perhaps easier to use since it uses the query syntax of namazu2. ITP:Closes #325043 Source files: http://mentors.debian.net/debian/pool/main/n/nmzmail/ Listed at http://sponsors.debian.net/ -- Kevin Coyner GnuPG key: 1024D/8CE11941 http://rustybear.com/publickey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nmzmail -- indexes and searches email in maildir folders, especially mutt
On Fri, Mar 10, 2006 at 10:41:44PM -0500, Kevin Coyner wrote:
I am looking for a sponsor for the package 'nmzmail'. This is a
great little program that indexes and searchs email in maildir
folders. It truly shines when used in combination with mutt, making
searches of your email extremely easy and quick.
The package is lintian/linda clean and builds cleanly in
pbuilder-sid.
Thank you in advance for reviewing this package and possibly
sponsoring it.
Package name: nmzmail
Version:1.3-1
Upstream author:Johannes Hofmann [EMAIL PROTECTED]
URL:http://www.ecademix.com/JohannesHofmann/#nmzmail
License:GPL
Description:nmzmail is a tool, primarily to be used with mutt, for
indexing and searching maildir folders. Based on the
result of a search query using the search engine
namazu2, nmzmail generates a maildir folder
containing symbolic links to the mail(s)
matching the query. A simple mutt macro makes
it easy to use nmzmail from within mutt.
nmzmail is similar to mairix (another email
index/search program), but perhaps easier to use
since it uses the query syntax of namazu2.
ITP:Closes #325043
Source files:
http://mentors.debian.net/debian/pool/main/n/nmzmail/
I would suggest to Enhances: mutt, in addition to suggesting it. Also
the homepage field is supposedly supposed to be indented with an extra
space.
+ -$(MAKE) distclean
is evil, see Branden's bug against lintian.
nmzmail-0.1.3.orig/config.{sub,guess} are interesting, they seem to be
introduced entirely by your .diff; does upstream really not ship with
them? Aren't they required? You might consider removing them in
'clean' and copying them from /u/s/autotools-dev/ on configure, and of
course b-dep on autotools-dev.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
