Re: RFS: steam-powered
On Mon, Aug 27, 2007 at 09:53:07PM -0400, Michael Gilbert wrote: > Dear mentors and games team, Heh, more than 9 months old. But I only just came across the ITP. ^_^ > I am looking for a sponsor for my package "steam-powered". > * Package name: steam-powered > Version : 5 > Upstream Author : Michael Gilbert > * URL : no website > * License : gpl > Section : contrib/games I just had a look at your package (version 7) and a few thoughts came to mind. On a multi-user machine, this current setup (sticking stuff in .config/steam-powered) will lead to duplication of some very large files. (GCF files, and the contents of .ncf files) Would it not be better (and I don't know if this is rationally possible) to have a shared installation of Steam? As an outline/suggestion, it'd have to create a new user, which owns /var/lib/games/steam-powered/ say, and has a local wine-prefix in /var/lib/games/steam-powered/.wine and then installs Steam to /var/lib/games/steam-powered/Steam. I don't know however how good Steam is at locking files it's updating, but if it can handle that OK, then that mean that whichever user happens to run Steam and do the updates, all users on the system benefit from it. Steam already has a system for storing login-specific (Steam-login, that is) data, but short of building an appropriate symlink farm, that data will also live in /var/lib/games/steam-powered. (A symlink farm back to user's home directories won't work, because a Steam login might be shared by multiple Debian user accounts...) This also avoids the issue with the current code of playing with the user's .wine/dosdevices folder, and in fact the assumption that .wine exists. It would however require that all potential Steam users are able to gksudo or similar to the relevant user, gaining the appropriate wineprefix on the way. I haven't looked at how feasible that would be. I also haven't tried starting a wine session from a different wine prefix to one that is already running. I don't know if wineservers separate themselves by wine-prefix (good for this solution, bad for cut-and-paste ^_^) or not (bad for this solution, good for cut-and-paste). If they do separate, then that also means that if Steam kills its own wine session, it doesn't affect anything else you're running under your normal wine. With this setup, I'd suggest that the relevant steam folder not be deleted on remove, but on purge (or never...). This would put us a step up on the upstream windows installer, which once blew away my gcf files (expected) and my savegames (unexpected) when I uninstalled Steam. >_< There's also the issue of having multiple users accessing the one wine process as a single user. I imaging Wine (in order to implement the Win32 API) doesn't have a lot of protection within a single wine process from a malicious user. So maybe you have to be in a steam-powered group or something to actually fire up this wineprefix. Having said all this, some parts of the above could probably be generalised and added to the Debian Wine packaging, basically implementing a Debian-specific version of the bottling stuff CrossOver (a Wine-derived commercial product) offers, both for packagers and for users. (ie. users can wine-bottle to quickly create or user a wine-prefix under .wine-bottle, and packagers get a dh_winebottle script to create a wine bottle with appropriate permissions and startup scripts) A couple of other things. Wine now includes a Tahoma-replacement, and I don't recalling having that old 26% bug last time I installed Steam, but that could just be my faulty memory. Also, rather than kill -9, wineserver -k should do what you want there, I believe. (ie. tear down the current Wine session) One last thing, I _do_ very much like the postinst stuff you've done. Off the top of my head, I'm not sure that stuff the postinst scripts create (OK, download, in this case, but the difference is immaterial) should go in /usr/share or in /var/lib. (Or /var/cache? Given that the removal of the downloaded cab file or the extracted license agreement doesn't actually break anything, /var/cache might be safe for those...) Wow. That ended up longer than I expected. If you think this is an interesting idea but don't have the time to play with it yourself, let me know (best to directly CC me, I often forget to read d-mentors...) and I'll try and make the time to prototype such a thing for feasibility. -- --- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year 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
Advice on dpatch vs post-patching?
Basically, I've just converted FreeRADIUS to use dpatch, and that's working nicely. However, the current debian/rules files does a whole bunch of seding against the configuration files after they've been processed by configure and friends. I'm not sure if I should convert these sed calls into dpatches against the source files... (eg. against Make.inc.in, and radius.conf.in) The advantage of the sed file stuff is it's more resiliant to upstream changes. I'm not sure that's a good thing though, I'd like to notice during package build when something's changed interestingly. The advantage of changing to dpatch is that after debian/rules patch is run, you end up with the complete and accurate source tree, in case you're trying to debug a problem. And this means that if upstream changes, the dpatch breaks and I _notice_ that it's happened. At this point I'm leaning towards converting sed to dpatch... Any thoughts from others would be appreciated though. -- ----------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpFwrxdlG6Zf.pgp Description: PGP signature
Re: Advice on dpatch vs post-patching?
On Mon, Jul 11, 2005 at 03:11:51AM -0400, Decklin Foster wrote: > Paul TBBle Hampson writes: >> And this means that if upstream changes, the dpatch breaks and I >> _notice_ that it's happened. > I think this is a clear argument for going with dpatch. It is also much > easier for someone else (say you go on vacation and an NMU is necessary, > or a user wants to help by including a patch with their bug report) to > read the intent of your changes if they are a unified diff, rather than > a sed script. The latter format is not generally solicited by > free-software projects for general bug fixes. :-) The thing is, the sed scripts are for editing the config files, so that I get /var/run/freeradius instead of /var/run/radius for example. As an upstream developer, this all goes into the upstream CVS anyway under the debian/ directory. However, I think I will go with dpatch, although I need to check as I may be seding against generated files rather than the original original source files... (I inherited this code with the package. ^_^) (Sorry for the very late followup, I forgot to mark debian-mentors as a incoming mailbox... I just converted to Maildir and discovered a month's new mail waiting for me. ^_^) -- ----------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgppOyrLyKwx7.pgp Description: PGP signature
Re: question about increasing versionnumbers
On Mon, Aug 08, 2005 at 11:24:54PM +0200, Bastian Venthur wrote: > Hi Mentors, > as I've noticed no one is rightnow interested in sponsoring my > tvbrowser-package. But since, I really want to maintain this package (I use > it for myself) I have a question about future changes I'll make in this > package. > What is the best practice, when making small changes to the package like > fixing typos and stuff? Should I stick to my "initial release" or should i > alter the Versionnumber everytime I make change? > And the next question in a bigger context: What if a new upstream comes out > while my package is not sponsored? Should I pretend to maintain a real > package and alter the changelog and stuff or should the last package which > is not part of debian always be the "initial release"? If your package is available for people other than yourself to download, I would definately suggest pretending it's in the archive, and update versions accordingly. It also gives your eventual sponsor history for the package, providing more evidence as to your commitment and skills, especially over the long term. (Which is important, so that your package does not get sponsored once, then bitrot.) -- ------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpo4aGieO0jm.pgp Description: PGP signature
Re: question about increasing versionnumbers
On Mon, Aug 08, 2005 at 09:10:27PM -0400, Justin Pryzby wrote: > On Tue, Aug 09, 2005 at 08:30:30AM +1000, Paul TBBle Hampson wrote: >> It also gives your eventual sponsor history for the package, >> providing more evidence as to your commitment and skills, >> especially over the long term. (Which is important, so that >> your package does not get sponsored once, then bitrot.) > Yes, I agree here, from experience. > One interesting idea was to use an NMU version scheme for unofficial > packages: > foo_1.2.3-0.1 (supposing it is 1 based) > foo_1.2.3-0.2 > foo_1.2.3-0.3 > ... > foo_1.2.4-0.1 (I guess) > foo_1.2.4-0.2 > ... > Then, I guess you should change the version number and add a changelog > entry when you're sponsored: > foo_1.2.4-1: > * Update version for upload to d.o archive, thanks Sponsor Dude >(Closes: #11) Interesting, but I certainly wouldn't use it. There's nothing wrong with the first version into the Debian archive being -2, -3 or -4, as long as you remember to make it a full-source upload. That's certainly what we did with FreeRADIUS, since at the time upstream was releasing as -1. -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpiTvtshAnpT.pgp Description: PGP signature
Re: [RFS] qterm: BBS client for X Window System written in Qt
On Sat, Aug 13, 2005 at 08:13:34PM +0800, LI Daobing wrote: > Version: 0.4.0pre2.ds.3-2 > Distribution: unstable > Urgency: low > Maintainer: LI Daobing <[EMAIL PROTECTED]> > Changed-By: LI Daobing <[EMAIL PROTECTED]> > Description: > qterm - BBS client for X Window System written in Qt > Changes: > qterm (0.4.0pre2.ds.3-2) unstable; urgency=low > . >* ABI transition >* debian/control: change Standards-Version to 3.6.2 > already uploaded to mentors.debian.net > $ lintian qterm_0.4.0pre2.ds.3-2_i386.changes > W: qterm: binary-without-manpage qterm > $ linda qterm_0.4.0pre2.ds.3-2_i386.changes > E: qterm; No manual page for binary qterm. > W: qterm; The command /usr/bin/qterm" > icon32x32="/usr/share/pixmaps/qterm_32x32.xpm" > icon16x16="/usr/share/pixmaps/qterm_16x16.xpm listed in a menu file > does not exist. > I don't know what's the meaning of the second warning of linda. At a glance, it looks like linda is somehow processing the newlines as part of the command name, and is looking for /usr/bin/qterm"\nicon32x32="/usr/share/pixmaps/qterm_32x32.xpm"\nicon16x16="/usr/share/pixmaps/qterm_16x16.xpm I'd suggest checking your linefeeds in the menu file, and if they're good, look at linda's source to see why it would be doing that. -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgp2pdCbKl55d.pgp Description: PGP signature
Re: rpath problem
On Sun, Aug 14, 2005 at 10:00:49PM +0800, Paul Wise wrote: > Hi all, > I'm packaging lufis[1], which will allow me to package captive ntfs, and > I've come across an issue with lintian/linda complaining about -rpath > Basically, lufis uses shared libraries from lufs, located > in /usr/lib/lufs/ on debian (from the lufs-utils package). When I build > the upstream source, the lufis binary doesn't know where to find these > shared libraries. In order to tell it where to look, I can either use a > wrapper script (and set LD_LIBRARY_PATH), or send the -rpath option to > the linker. > Lintian/linda complain with the following messages: > W: lufis: binary-or-shlib-defines-rpath ./usr/bin/lufis /usr/lib/lufs/ > I'm not sure what to do here[2], should I add an override for this, or > file a bug on lufs-utils? I would vote for an override, since you're already linking against lufs's internal shared libraries, so rpathing yourself is no risker than the current dependancy on them anyway. You can either establish a gentleman's agreement with the lufs maintainer to not move the libs except on soname change, or -- now that they are user by something other than lufs -- see about getting lufs's shared objects moved into a location where the normal Debian protections and promises apply, and you don't need rpath to find the libs. In short, rpathing breaks the ability of ld-linux.so to pick the best matching soname by limiting you to searching for that library in that path. Since you're linking against libraries that ld-linux.so can't see, you have to do _something_ to produce this limitation. Your other choise is an LD_LIBRARY_PATH-setting wrapper script, like mozilla uses. However, I suspect your library usage is more tightly coupled than that, so it would be more effort than is neccessary for the payout. -- --- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpf4c8GLPusU.pgp Description: PGP signature
Re: RFS: ITP: crystalcursors -- X11 mouse theme with the crystal
On Wed, Aug 17, 2005 at 06:19:15PM +0200, Bastian Venthur wrote: > I'm seeking a sponsor for these beautyfull mouse cursors. Alltogether it is > basicly one theme which comes in 20 different flavors (different colors, > left-handed, animated, not-animated). > It is linda-clean but gives a lintian warning like this for every cursor: > W: crystalcursors: packages-installs-file-to-usr-x11r6 > usr/X11R6/lib/X11/icons/crystalwhiteleft_nonanim/ > but I guess it's OK -- because these are cursors and they have to be > installed in this directory. I'd suggest somewhere in /usr/share (and so has someone else here) as I expect the cursor data is arch-independant... Also, it might be worth querying the debian-x list about this, since it looks like there's two conflicting pieces of advice in lintian about this. -- ----------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpP1Y9qPxK1U.pgp Description: PGP signature
Re: RFS: libpam-heimdal -- PAM module for Heimdal Kerberos 5
On Sun, Sep 04, 2005 at 12:42:33PM -0400, Bruno Barrera C. wrote: > On Fri, 2005-09-02 at 16:14 +0200, Matthijs Mohlmann wrote: >> I'm looking for a sponsor for libpam-heimdal. With this module it is >> possible to authenticate against a heimdal kerberos server. It requests >> a ticket for you like the kinit program. >> Download: http://www.cacholong.nl/‾matthijs/debpkg/libpam-heimdal/ > Not Found > The requested URL /‾matthijs/debpkg/libpam-heimdal/ was not found on > this server. You've been through a JIS roundtrip. The ~ in the original URL has become ‾. http://www.cacholong.nl/‾matthijs/debpkg/libpam-heimdal/ and then retype ^ as a tilde, instead of a high-bar. -- ----------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgp3x6pNTmaaI.pgp Description: PGP signature
Re: Reopening Bug#267042, libptp2 and a lintian warning.
On Fri, Sep 30, 2005 at 12:00:43PM +0200, Antonio Ospite wrote: > There is an issue with the package name, lintian says: > W: libptp2: package-name-doesnt-match-sonames libptp2-1 > but libptp2 is not intended to be the second version of libptp, it is a > different thing and so I (and the upstream author) think that the > package should be named libptp2 and not libptp2-SONAMEVERSION as the > library policy would suggest. May I override the lintian warning about > this issue? sonames go in the library package name so that different versions of the library with the same name but different soversions are parallel- installable. libptp2, which you've suggested, is libptp soversion 2. What you said you want is what lintian suggests, libptp2 soversion 1: "libptp2-1" This means you'll get libptp2-dev and libptp2-bin (if you need a -bin) associated packages. -- ----------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgptzt2yFfAsx.pgp Description: PGP signature
Re: Reopening Bug#267042, libptp2 and a lintian warning.
On Sat, Oct 01, 2005 at 09:56:16AM +0200, Antonio Ospite wrote: > On Fri, 30 Sep 2005 23:15:44 +1000 > Paul TBBle Hampson <[EMAIL PROTECTED]> wrote: >> On Fri, Sep 30, 2005 at 12:00:43PM +0200, Antonio Ospite wrote: > >> There is an issue with the package name, lintian says: > >> W: libptp2: package-name-doesnt-match-sonames libptp2-1 > >> but libptp2 is not intended to be the second version of libptp, it > >> is a different thing and so I (and the upstream author) think that > >> the package should be named libptp2 and not libptp2-SONAMEVERSION > >> as the library policy would suggest. May I override the lintian > >> warning about this issue? >> sonames go in the library package name so that different versions of >> the library with the same name but different soversions are parallel- >> installable. >> libptp2, which you've suggested, is libptp soversion 2. What you said >> you want is what lintian suggests, libptp2 soversion 1: "libptp2-1" > well, actually libptp2 is libptp2 soversion 1, the shared object file > is named libptp2.so.1. Not according to Debian's library naming policy. Calling it libptp2 produces an expectation that the package will contain /usr/lib/libptp.so.2.x.y and a symlink from /usr/lib/libptp.so.2, and that any program that works with libptp2 will work with any future libptp2. If upstream promises to _never_ _never_ _never_ remove or change any symbols, but only add new ones, an exception might be made. And it'll have to survive both debian-devel (where you'll be told all this again, but with more force and possibly some direct personal abuse) and ftp-masters. > The upstream asked me to call the package libptp2 and not libptp2-1, > should I follow his request? Not where it conflicts with Debian packaging policy, no. If upstream doesn't like this, point out that there's no libmysqlclient in Debian either. I think upstream is confused about what they want from a Debian package name. The _source_ package name would make sense as libptp2, but there'll be no binary package by that name. >> This means you'll get libptp2-dev and libptp2-bin (if you need a -bin) >> associated packages. > I don't understand here; if the package is called libptp2-1, hasn't the > dev package to be named libptp2-1-dev ? Not neccessarily. The -dev package is generally libraryname-dev, unless there is a good reason to have different -dev pacakges parallel installable for the different soversions... libmysqlclient for example does this, I think partly because the license change between sovers 10 and 12 meant that people needed to be able to link against whichever version was acceptable but mainly because it's such a commonly-linked library and is not symbol-versioned, you need to be careful not to have one program ultimately linked against two different sovers of it. This is prolly a good point to prompt your upstream about symbol versioning. ^_^ Another reason to use libptp2-1-dev is if upstream tends to change the API non-backwards-compatibly. This way working packages won't be broken by a new upload by you. This is done by gtk, for example, who put the API into the package name. The 1.2 series has also gotten by on having no soversion in the package name, because they have made the abovementioned promise to not break backwards compatibility. The 2.0 series of GTK however uses the standard soname versioning, although they're still on -0 so they've yet to need it. ^_^ If upstream is inclined to break API like this, suggest that when they do so that they call it libptp3 instead. ^_^ Keep in mind that having a libptp2-1-dev and a libptp2-2-dev will need to come from seperate source packages or updating libptp2-1-dev will be impossible once libptp2-2-dev hits the archive. And you really don't want to be responsible for something in the archive becoming non-updatable. libmysqlclient for example has the .so.10 version as its own source package (no one wanted to keep mysql3 itself in the system, and mysql3 had the same source package name as mysql 4.0 "mysql-dfsg") while all later versions come from a mysql-dfsg-4.x source package, so can be updated in parallel. However, this is hard work. You don't want to choose to do it lightly. If you go the libptp2-1-dev route, consider having libptp2-1-dev provide and conflict with libptpt2-dev for people who want to develop against libptp2 to be able to find the current -dev package easily. There was a discussion on debian-devel a month or two ago about soversions and API versions you may want to read, but I think the above summarises the ultimate outcome. Either way, packages still should refer to the specific sover -dev package if it exists, under the assumption that the packager of the library knows what they're do
Re: Installation of Type1 fonts
On Mon, Oct 03, 2005 at 08:49:19AM +0200, Norbert Preining wrote: > . dh_installdefoma and $(package).defoma-hints > Hmm, defoma seems to me really a bit out-of-date in the sense that > I don't see any use for it. Activating a font for fontconfig should > be enough to get it working with most applications in Debian, sin't > it? If I recall correctly, the point of defoma is to register your font with fontconfig as well as those applications that don't support fontconfig, so you don't have to care about which applications get to your font and how they get it. So fontconfig may give you "most applications", defoma will give you that set _and_ other applications. -- ----------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgppGBJc8WWhT.pgp Description: PGP signature
Re: [RFC/RFS] adm8211-source - driver for ADMtek wifi card
On Mon, Oct 10, 2005 at 09:42:56PM -0400, Jean-Marc Ranger wrote: > Hi Geert, > Thanks for your feedback. > >There are no signs of an ITP ( Intented To Package ) > >Please file an "ITP bugreport" > I thought it was optional. Fixed anyway, see http://bugs.debian.org/333237 It's optional, in so far as you can upload without it if you're a DD. But you might have trouble finding a sponsor without it. ^_^ -- ----------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpeXwXxIg7y6.pgp Description: PGP signature
Re: Lintian error binary-or-shlib-defines-rpath
On Wed, Oct 12, 2005 at 10:18:56AM +0200, Joost van Baal wrote:
> Hi,
> Op wo 12 okt 2005 om 09:32:55 +0200 schreef Michael Hanke:
>> Joost van Baal schrieb:
> >> Op di 11 okt 2005 om 10:26:50 +0200 schreef Jan C. Nordholz:
> >>
> >>>AFAICT, --disable-rpath is catching all usages of the "rpath" feature
> >>>except
> >>>one: src/Makefile.in, Line 540:
> >>>540 $(CXXLINK) -rpath $(kde_moduledir)
> >>> $(libkbibtexpart_la_LDFLAGS) $(libkbibtexpart_la_OBJECTS)
> >>> $(libkbibtexpart_la_LIBADD) $(LIBS)
> >>>Here -rpath is used unconditionally (and the target in question is
> >>>libkbibtexpart.la, so I think that is the one lintian chokes about).
> >>>I'd suggest you remove the "-rpath $(kde_moduledir)" and try again.
> >> And, of course, report this ignoring --disable-rpath as a bug to
> >> upstream.
>> Of course. I did this even before posting to this list.
>> Simply removing "-rpath $(kde_moduledir)" from the Makefile.in did not
>> make it. It led to an error about missing libkbibtexpart.lai (sorry, I
>> don't have the output here ATM).
I suspect _that_ problem occurred because it's trying to link against a
module built from the same source, which is not yet installed. So it
uses -rpath for libtool to find the .lai, and the .lai (which
is the installed version of a .la with all paths fixed to final
destinations) tells it it's going to be in /usr/lib, so it embedds
/usr/lib into your file, but actually gives "-L $(kde_moduledir)
-lkbibtexpart -rpath $(destination_according_to_.lai_file)" or simiar to gcc.
Or at least I _think_ that's how it goes.
I'd suggest the actual problem is libtool should drop the '-rpath' part
of the gcc call when the value for -rpath is /lib, /usr/lib, or
/usr/local/lib.
Assuming I'm right as to the problem.
>> I don't know the autotools too well, but as Makefile.in is a generated
>> file, shouldn't the root of the error be somewhere else?
Makefile.in is only generated if using automake, in whcih case it is
as follows.
> Yes, probably in Makefile.am in the same directory. If it's not there,
> it might be in configure.{ac,in} in the toplevel directory.
Otherwise, the .in file is not generated, but processed by configure
into a Makefile mainly by variable substitution.
You can tell an automake-generated Makefile.in because it'll make you
cry like a small child if you accidentally view it in a text editor.
^_^
--
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]
"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"
License: http://creativecommons.org/licenses/by/2.1/au/
---
pgpWGCT73h8nd.pgp
Description: PGP signature
Re: [RFC/RFS] adm8211-source - driver for ADMtek wifi card
> Upstream author list hotplug among its requirements. Trying without > hotplug/udev was the first thing I did after reading Paul's comment, > but I didn't managed to get it working (my test setup is cardbus, as > you suspected). It seems faily typical - it's also mandatory for > ipw2100-source, which was my template. If hotplug is mandatory, then it's mandatory for firmware loading, not for actual module installation. ie. modprobe can load the module as easily as hotplug, but modules using firmware_class (which should be all of the drivers that need non-DFSG firmware) call hotplug or some other firmware-loading userland agent to get their firmware udev in unstable can now substitute for hotplug when loading firmware, but looks for the firmware in /lib/firmware, not /usr/lib/hotplug/firmware as hotplug (specifically firmware.agent) does. Happily, udev Provides: hotplug so you don't yet need to worry about that for pacakaging purposes, although if you put the firmware in a .deb file then it _does_ matter. (Or at least so the changelog of udev implied to me) -- ----------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] "No survivors? Then where do the stories come from I wonder?" -- Capt. Jack Sparrow, "Pirates of the Caribbean" License: http://creativecommons.org/licenses/by/2.1/au/ --- pgpEm0u0muM9x.pgp Description: PGP signature
RFS: openjpeg
Dear mentors, I am looking for a sponsor for my package "openjpeg". * Package name: openjpeg Version : 1.1.1-1 Upstream Author : OpenJPEG Team <[EMAIL PROTECTED]> * URL : http://www.openjpeg.org/ * License : BSD (2-clause as per http://www.openjpeg.org/BSDlicense.txt) Section : libs It builds these binary packages: libopenjpeg-dev - JPEG 2000 image compression codec library development files libopenjpeg-tools - JPEG 2000 image compression codec library shared objects libopenjpeg1 - JPEG 2000 image compression codec library shared objects libopenjpeg1-dbg - JPEG 2000 image compression codec library shared objects The package is lintian clean. The upload would fix these bugs: 413987 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/o/openjpeg - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/o/openjpeg/openjpeg_1.1.1-1.dsc I would be glad if someone uploaded this package for me. It is a dependancy of the second-life viewer application, and Bernd Zeimetz intends to package a Gimp plugin that uses it to. [1] [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413987;msg=10 -- ------- 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/ --- pgpQm4T2UC32f.pgp Description: PGP signature
RFS: elfio
Dear mentors, I am looking for a sponsor for my package "elfio". * Package name: elfio Version : 1.0.3-1 Upstream Author : Serge Lamikhov-Center <[EMAIL PROTECTED]> * URL : http://elfio.sourceforge.net/ * License : LGPL Section : libs It builds these binary packages: libelfio-dev - library for reading and generating ELF files The package is lintian clean. The upload would fix these bugs: 413985 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/e/elfio - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/e/elfio/elfio_1.0.3-1.dsc I would be glad if someone uploaded this package for me. I'm packaging it as a dependancy of the second-life viewer, although it has been suggested that it can be built without ELFIO. I'll be looking into that while packaging up slviewer, so unless you know of another use for the library, there's no particular hurry on this one. -- ----------- 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/ --- pgpwL2uZGHUfk.pgp Description: PGP signature
RFS: xmlrpc-epi
Dear mentors, I am looking for a sponsor for my package "xmlrpc-epi". * Package name: xmlrpc-epi Version : 0.51-1 Upstream Author : Dan Libby <[EMAIL PROTECTED]> * URL : http://xmlrpc-epi.sourceforge.net * License : See below (Basically the first clause of the BSD license) Section : libs It builds these binary packages: libxmlrpc-epi-dev - XML-RPC request serialisation/deserialisation library development libxmlrpc-epi0 - XML-RPC request serialisation/deserialisation library shared obje The package is lintian clean. The upload would fix these bugs: 413986 == License 1) The above copyright notice and this permission notice shall be included without modification in all copies or substantial portions of the Software. 2) THE SOFTWARE IS PROVIDED "AS IS", WITHOUT ANY WARRANTY OR CONDITION OF ANY KIND, EXPRESS, IMPLIED OR STATUTORY, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTIES OF ACCURACY, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT. 3) IN NO EVENT SHALL EPINIONS, INC. BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES OR LOST PROFITS ARISING OUT OF OR IN CONNECTION WITH THE SOFTWARE (HOWEVER ARISING, INCLUDING NEGLIGENCE), EVEN IF EPINIONS, INC. IS AWARE OF THE POSSIBILITY OF SUCH DAMAGES. == The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/x/xmlrpc-epi - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/x/xmlrpc-epi/xmlrpc-epi_0.51-1.dsc I would be glad if someone uploaded this package for me. I'm packaging this as a dependancy of the second-life viewer. It happens to be the same library behind the PHP5 xmlrpc extension, and I'm hoping we can start building that PHP5 extension against this library rather than its own, statically-linked copy. [1] The PHP5 version is more recently updated, so I've pulled in whatever changes seemed useful already. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413986;msg=25 -- ----------- 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/ --- pgpbqpg77dXSV.pgp Description: PGP signature
Re: Bug#413985: RFS: elfio
On Tue, Mar 20, 2007 at 01:40:32PM +0100, Thomas Jollans wrote: > On Tuesday 20 March 2007 04:41, Paul TBBle Hampson wrote: >> It builds these binary packages: >> libelfio-dev - library for reading and generating ELF files > This package should be split in a binary package with the library, and an > architecture-independant -dev package with headers and example AFAIK. What would be the benefit of seperating the headers from the static library? I don't see how either is useful on its own. -- Paul "TBBle" Hampson, [EMAIL PROTECTED] Shorter .sig for a more eco-friendly paperless office. pgpDoB08zzf39.pgp Description: PGP signature
Re: Bug#413985: RFS: elfio
On Tue, Mar 20, 2007 at 11:44:00PM +0100, Thomas Jollans wrote: > My mistake, I missed that it's a static library. However, the binary > in /usr/bin - is it useful on its own or just used to configure something > about the library. It's useful on it's own, but IMHO way too trivial to put into a seperate package. That's for a fairly wide-ranging definition of 'useful', too... If it turns out to be an issue, I'd rather drop the binary entirely. In fact, if I can swing it, I'd rather just not package this one, since nothing else uses it (that I know of... someone may have decided to inline the code into their own source tree). However, I won't know that I can drop it for sure until next weekend at the earliest. -- ----------- 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/ --- pgp8m9jS0X6Bc.pgp Description: PGP signature
Re: RFS: openjpeg
On Wed, Mar 21, 2007 at 02:38:44AM +0100, Romain Beauxis wrote:
> Le mardi 20 mars 2007 04:17, Paul TBBle Hampson a écrit :
>> Dear mentors,
> Hi !
>> I am looking for a sponsor for my package "openjpeg".
> Some basic comments:
> * debian/rules: you should remove uneeded call to dh_ stuff. Also the
Fixed, thanks. Thanks.
> ## shared library versions, option 1
>> version=1.0.0
>> major=1
> stuff does not seem right, and version is not the one provided..
The soversion is 1.0.0 in the build I have here... What'd it come up
with for you?
>> ln -s libopenjpeg-${version}.so dist/libopenjpeg.so
> This does not seem right too...
Uh, that's so that the included binaries link against the shared-object.
The link is removed two lines later.
> * debian/control: there is a typo in one description. Also, you should rename
> libjpeg2000-utils to something like jpeg2000-utils since this package does
> not provide any lib..
Hmm. I was going off the example of libgd-utils and libjpeg-tools, as
well as Junichi Uekawa's packaging guide, but I will take openjpeg-tools
under consideration. (Assuming that's what you meant, not that I rename
the entire thing to *jpeg2000*.)
Fixed the cut and paste oversight, thanks.
> * debian/copyright: You repeated copyright for licence, these are different
> sections.. Also download source should be a webpage or a ftp site, but not
> the tarball.
Strange. Policy requires a verbatim copy of the copyright and license,
and that's verbatim from the website.
I've fixed this by removing the "License" seperator and the first set of
copyright statements, so it's now both verbatim and doesn't describe the
copyright holder's list as the license.
As for the upstream URL, the copyright FAQ [1] states that should be the
URL for the upstream source... That could be clearer, they obviously
mean the _other_ "source". Fixed, thanks.
[1] http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
> * In the diff.gz: your modifications to source should be kept as patch and
> applied at build time. This way they'll remain into the debian/ directory.
> Also, you may check wether you could build the package without those
> modifications...
I'm not going to apply dpatch to something so trivial. The number of
DD's who dislike dpatch is significant enough that I don't feel this
package is changed enough to require it, and make someone else's life
harder down the road for the sake of 6 changed lines.
The package _builds_ without those changes, but isn't policy-compliant.
(ie. the stuff in libopenjpeg-tools ends up statically linked, and the
debug version of the library ends up stripped. The 'mv' change will go
away, the preceeding change should be sufficient)
> And... You have a nice FTBFS for amd64:
>> /usr/bin/ld: ./libopenjpeg/bio.o: relocation R_X86_64_32 against `a local
>> symbol' can not be used when making a shared object; recompile with -fPIC
>> ./libopenjpeg/bio.o: ne peut lire les symboles: Mauvaise valeur
> As written in the message, you have to pass the -fPIC option at build time..
The debian/rules file builds it firstly without -fPIC, as Debian policy
requires that .a objects are build without it, and then rebuilds with
-fPIC to generate the .so. I didn't realise it was going to fail to
build in that instance...
I've changed it so it doesn't _try_ to build the .so file the first time
'round.
New package will be uploaded once it's out of pbuilder.
--
---
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/
---
pgpCPSojWA7ol.pgp
Description: PGP signature
Re: RFS: openjpeg
On Wed, Mar 21, 2007 at 12:01:50PM +0100, Romain Beauxis wrote: > Le mercredi 21 mars 2007 09:44, Paul TBBle Hampson a écrit : >> On Wed, Mar 21, 2007 at 02:38:44AM +0100, Romain Beauxis wrote: > >> Le mardi 20 mars 2007 04:17, Paul TBBle Hampson a écrit : > >>> version=1.0.0 > >>> major=1 > >> stuff does not seem right, and version is not the one provided.. >> The soversion is 1.0.0 > BTW, I don't get why you need to define the soversion in the debian/rules. > Isn't this supposed to be defined by upstream ? > Remenber that if defined in rules, you'll have to take care of this for each > upstream release... And a soversion is supposed to be carefully bumped when > making changes to the API/ABI, so you'll then have to do upstream's job on > this... (a) it came with the dh_make template. (b) now that I've gone over the rules file again, it means that I only need to change one or two places when upstream bumps theirs, and if I forget to, it'll fail noisily. I suspect I'll have to do upstream's job anyway. I'm pretty sure the 1.1 -> 1.1.1 change should have bumped the soname (One of the structures which contains arrays has had them grow from MAX_PATH bytes to 4096 bytes and added an enum halfway through the structure) I'll have to email them about that... Old library, new code: all arrays after the enum are in the wrong spot: bad New library, old code: reads random byte from array as enum value: bad Yeah, looks like an ABI bump to me. Beh. I don't even want to think about their handling of the JPWL stuff. The structures gain elements at the end based on a #define the user code is expected to define before including. It's not enabled for now, but once it is, it'll have to stay enabled or it's ABI-bump (and Debian-specific ABI bump at that!) time. > >> * debian/copyright: You repeated copyright for licence, these are > >> different sections.. Also download source should be a webpage or a ftp > >> site, but not the tarball. >> Strange. Policy requires a verbatim copy of the copyright and license, >> and that's verbatim from the website. >> I've fixed this by removing the "License" seperator and the first set of >> copyright statements, so it's now both verbatim and doesn't describe the >> copyright holder's list as the license. > No.. > What I meant is that sentences like "copyright (c) 1492 Christopher Colombus" > are copyright statements, they don't have to be listed in the licence > section.. > You should simply have removed these sentences from the licence section, not > remove the licence section... ;) I removed the heading of the license section. The license itself is still there, and now matches the upstream verbatim. The various FAQs on the matter (and Policy, although it's not exactly explicit here) as well as the couple of random packages I pulled up to check all seem to work the way I've got it now. >> As for the upstream URL, the copyright FAQ [1] states that should be the >> URL for the upstream source... That could be clearer, they obviously >> mean the _other_ "source". Fixed, thanks. > So you would have to update copyright file for each upstream release ? ;) Yeah. I'd have to anyway, in case any new contributors or copyright holders came on board. (As happened between 1.1 and 1.1.1, since one contributor's copyright now includes 2007.) > >> * In the diff.gz: your modifications to source should be kept as patch > >> and applied at build time. This way they'll remain into the debian/ > >> directory. Also, you may check wether you could build the package without > >> those modifications... >> I'm not going to apply dpatch to something so trivial. The number of >> DD's who dislike dpatch is significant enough that I don't feel this >> package is changed enough to require it, and make someone else's life >> harder down the road for the sake of 6 changed lines. >> The package _builds_ without those changes, but isn't policy-compliant. >> (ie. the stuff in libopenjpeg-tools ends up statically linked, and the >> debug version of the library ends up stripped. The 'mv' change will go >> away, the preceeding change should be sufficient) > We'll speak on this later when it will be time for your to update to a newer > upstream version.. > However, as for *my* point I will not sponsor without patch in any way, I > think all modifications on source related to the diff.gz are not a good > practice, to *my* point of course Indeed, I tend to agree. Certainly my larger packages use dpatch by preference. I
Re: RFS: openjpeg
On Wed, Mar 21, 2007 at 01:18:25PM +0100, Romain Beauxis wrote: > I had forgot how painfull it is to build a library without > configure/libtool... > configure/libtool is a pain in the ass for sure, but coming on those subjects > it simply and magicaly handle all those hard stuff alone.. Yeah. xmlrpc-epi uses libtool, and I didn't even have to think about -fPIC. ^_^ > Anyway, do you have a link to the new package, I'll try to have a deeper > review on this.. http://mentors.debian.net/debian/pool/main/o/openjpeg/ > You may also contact upstream an try to explain them that if they want their > project to be easily portable (think of this mess ported to macosX, sunOS > etc...), they really should consider using a good building system, especially > autoconf which is very well oriented toward portability... They provide a Makefile.osx and a .dsp file. Sadly, the included viewer is currently Windows-only... This isn't too bad, I've fought things harder for -fPIC. (libtool 1.4 used to get this really really badly wrong when building modules. In fact, I never solved that one.) The actual library is so small, it's barely worth autotoolising. Hmm. The Makefile.osx uses libtool... It can't be _that_ easy... -- ----------- 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/ --- pgpUTUrN9oKvB.pgp Description: PGP signature
Re: RFS: openjpeg
On Wed, Mar 21, 2007 at 02:25:24PM +0100, Romain Beauxis wrote: > Le mercredi 21 mars 2007 13:46, Paul TBBle Hampson a écrit : > >> Anyway, do you have a link to the new package, I'll try to have a deeper > >> review on this.. >> http://mentors.debian.net/debian/pool/main/o/openjpeg/ > More comments: > * You have lintian warnings about missing manpages. They are required so you > may fix this. Yeah, I discovered help2man today, (from FTP Master REJECT FAQ of all things) I'll use that for my next run. Bleh. help2man's not even vaugely correct. I'll try txt2man instead. > * debian/copyright: add licence section header between copyright part and > licence part.. Policy required it to be verbatim but you may still seperate > what is licence and what is copyright.. OK. How do I describe the statement of copyright and license for the Debian packaging? It's both license and copyright. > * debian/control: still you define a libopenjpeg-tools, and still the typo... Wait, which typo are you talking about? I fixed the short description, and there's a bunch of 'r's in the long description of libopenjpeg1 in my local copy, dunno if they made it to the upload. (My laptop keyboard seems to occasionally insert a whole bunch of 'r's in vim... >_<) I've renamed libopenjpeg-tools to openjepg-tools, but I remain convinced that this is needlessly inconsistent with libjpeg and libjasper's usage, and the libpkg guide. > Seems you have added autotool-dev to the build-dep.. Why is this needed if > autotools are not used ?? Whoops. That was supposed to be added to libxmlrpc-epi... I must have done that on Tuesday, that changelog entry was there when I started applying your comments tonight. Removed, thanks. > * libopenjpeg1: libopenjpeg-1.0.0.so is not the right way to name a shared > object I fear, it should be libsoname.so.soversion. And it seems that > upstream is doing this wrong naming... I can't believe I've missed that _every_ time. >_< I must submit a lintian test for that one. Fixed, thanks. Although I hope there's nothing which depends on that particular whackyness of naming that would cause problems here... The ldconfig symlinks should take care of all that, I expect. -- --- 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/ --- pgpkszpHdJgvb.pgp Description: PGP signature
Re: RFS: openjpeg
On Wed, Mar 21, 2007 at 04:49:42PM +0100, Romain Beauxis wrote: > Le mercredi 21 mars 2007 16:32, Paul TBBle Hampson a écrit : > >> * debian/copyright: add licence section header between copyright part and > >> licence part.. Policy required it to be verbatim but you may still > >> seperate what is licence and what is copyright.. >> OK. How do I describe the statement of copyright and license for the >> Debian packaging? It's both license and copyright. > Well.. As explained before, copyright lists the guys that have worked in the > code, with statements like (c) 2007 Someone > Licence is the part that talks about rights granted on the code from the > above > copyright owners.. > Simply add a Licence: line between copyright and the other part and its ok.. > Also, now that we come to this point, have you checked all file headers ? I > know it is a boring job, but it often gives you some very interesting > results... upstream authors are not always consistent with the licence they > give and some part of code they may take from other sources.. Given that you > have read the REJECT FAQ, I guess you are aware of this point.. Erk. The template in dh_make needs fixing then... Drat, I forgot to check the stuff I wasn't building. >_< There's a couple of copies of a four-clause BSD-licensed getopt.[ch], one attrubution-only type copyright in the jp3d library, and one java file that may be "freely used or adapted". I guess the question is, to reroll without the getopt stuff, or email upstream and try and explain the issue to them, as well as the issue with the sonames. And the jpwl header stuff. And by email I apparently mean 'sourceforge forum'. I've got a bad feeling about this... > >> * debian/control: still you define a libopenjpeg-tools, and still the > >> typo... >> Wait, which typo are you talking about? I fixed the short description, >> and there's a bunch of 'r's in the long description of libopenjpeg1 in >> my local copy, dunno if they made it to the upload. (My laptop keyboard >> seems to occasionally insert a whole bunch of 'r's in vim... >_<) > Yes I mean those r :) OK, fixed. >> I've renamed libopenjpeg-tools to openjepg-tools, but I remain convinced >> that this is needlessly inconsistent with libjpeg and libjasper's usage, >> and the libpkg guide. > Well, those utilities seem to be usefull outside of the library usage. > Take the user point of view, would you understand the a libopenjpeg-utils in > fact contains utilities that have a more general usage than only for testing > the library or whatever is library specific ? > Other formulation would be : why do you think this package name has to be > libopenjpeg specific ? The position I'm in is that if I want to see what came with a library, I'll look for it by package name, so if it starts with 'lib' it'll be in the output of an apt-cache search near the library itself. The short description tells me they're tools for the JPEG 2000 image compression codec, rather than being something library-specific like a *-config (which would be in -dev instead) and the long description even tells me what the tools are and what they do. If I want to find a tool to do something, I'd search on keywords, not names, and find it no matter what it's called. Mind you, in contrast to the below, the upstream project name is openjpeg, not libopenjpeg... Anyway, I've made the change, and I can appreciate both sides of the discussion. I'm not thrilled by the change, as I was of the understanding that without a clear style guide or policy position, such choices were at the descretion of the maintainer. > I can think of mpeg3-utils for instance... Given that there's no such thing as mpeg3, that's an awful example. ^_^ libmpeg3 is the name of the project, and mpeg3-utils has managed to lose the 'lib', so it doesn't look like it belongs to that project, while instead looking like it is a tool to manipulate data according to an imaginary MPEG standard. And the short description claims it's a library, too, since it seems to share the short description with libmpeg3-1 _I'd_ have pulled this up as an example of why I think openjpeg-tools is the wrong name, were I trying to argue that. -- --- 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/ --- pgpROv9CucNzO.pgp Description: PGP signature
Re: RFS: openjpeg
On Fri, Mar 23, 2007 at 12:33:41AM +1100, Paul TBBle Hampson wrote: > On Wed, Mar 21, 2007 at 04:49:42PM +0100, Romain Beauxis wrote: >> Le mercredi 21 mars 2007 16:32, Paul TBBle Hampson a écrit : > >>> * debian/copyright: add licence section header between copyright part and > >>> licence part.. Policy required it to be verbatim but you may still > >>> seperate what is licence and what is copyright.. >>> OK. How do I describe the statement of copyright and license for the >>> Debian packaging? It's both license and copyright. >> Well.. As explained before, copyright lists the guys that have worked in the >> code, with statements like (c) 2007 Someone >> Licence is the part that talks about rights granted on the code from the >> above >> copyright owners.. >> Simply add a Licence: line between copyright and the other part and its ok.. >> Also, now that we come to this point, have you checked all file headers ? I >> know it is a boring job, but it often gives you some very interesting >> results... upstream authors are not always consistent with the licence they >> give and some part of code they may take from other sources.. Given that you >> have read the REJECT FAQ, I guess you are aware of this point.. > Erk. The template in dh_make needs fixing then... > Drat, I forgot to check the stuff I wasn't building. >_< There's a > couple of copies of a four-clause BSD-licensed getopt.[ch], one > attrubution-only type copyright in the jp3d library, and one > java file that may be "freely used or adapted". OK, I've uploaded a new version, with changelog as follows: openjpeg (1.1.1-3) unstable; urgency=low . * Remove build-depend on autotools-dev, there's no autotools use here * Rename libopenjpeg-tools to openjpeg-tools * Correctly install libopenjpeg.so.1.0.0 rather than libopenjpeg-1.0.0.so * Make libopenjpeg1-dbg depend on the same-source version of libopenjpeg1 * Create manpages for image_to_j2k, j2k_to_image and index_create * Update debian/copyright with full details of all contained licenses and copyrights - Thanks again to Romain Beauxis for reviewing I really think this one's ready... (Of course, I thought that about the last two versions too...) ^_^ Now it's not only Lintian-clean, but doesn't even have any warnings. The copyright file is just over a third of the .diff.gz. Bleh... Obviously, I'm still open to any further comments. ^_^ -- --- 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/ --- pgpbAbJKtvLxO.pgp Description: PGP signature
Re: RFS: openjpeg
On Wed, Mar 28, 2007 at 01:31:42PM +0200, Romain Beauxis wrote: > Le mercredi 28 mars 2007 12:46, Paul TBBle Hampson a écrit : >> OK, I've uploaded a new version, with changelog as follows: > Hi Paul ! > Would you please post a link to it for such a lazy guy as me :) Ooops. http://mentors.debian.net/debian/pool/main/o/openjpeg -- ------- 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/ --- pgpi7SQLIPTfv.pgp Description: PGP signature
Re: RFS: openjpeg
On Wed, Mar 28, 2007 at 04:54:52PM +0200, Romain Beauxis wrote: > However, I see you have made significant changes to the makefile system, in > order to create a shared object with the correct name and to link dynamically > the utilities to the shared library, great ! These are not significant changes, they are trivial changes. A significant change would be autotoolising the system. > But, I would advise to put this as patch, and not let it stay into the > diff.gz. There are several reasons for that: > * Upgrading the package to new upstream release will be much more easy, and > if > the patch fails you'll see where etc.. > * Any other user/DD may then see precisly what changes you are doing to > upstream sources. You will also be able to seperate the changes that perform > a different task. Currently, any other user can see what I'm doing by looking at the .diff.gz. Under dpatch, they would have to notice in the .diff.gz that I'm using dpatch, then look at both the double-diffed dpatch and the 00list file, or _apply_ the .diff.gz and then look at the diff in debian/patches I don't consider the above that onerous, but others have expressed the opinion that it is so, and so I prefer to not require it when trivial. > * You may submit the final patch upstream.. I suspect they don't want it. I doubt they've accidentally produced staticly-built utilities, a stripped shared library, and a shared object named as they have. > In your precise case, I would strongly suggest sumbiting this to upstream > since it corrects two facts that are very important (shared object name) and > important (linking utilities to shared objects). Neither of these are global truths or neccessary outside Debian. The shared object name is invisible to the system, ldconfig builds the correct symlinks irrespective of the name. And static binaries are much easier to run from the build directory without installing the whole package. Which is handy if you don't care about libopenjpeg, but need something to convert to or from JP2 files. Interestingly, libblah-soversion.so appears to be how libtool creates private libraries, and it looks like libtool 1.4 may have done that with public libraries too. I probably will suggest to them that they rename the default .so file generated, but that'll be part of the same forum post that explains the risks and perils of soversion mistakes like the 1.1 to 1.1.1 update. > If only upstream would be using any suitable configure tool :) autotools would almost certainly be too large for this project. Maybe if they also rearranged the distribution to build everything together cohesively, there would be some advantage to it. But for just the library, written in what appears to be nice standrd C++ without any other libraries needed, it's overkill. > Then it is also a good training for a new packager to add patch support to > debian/rules. I don't think it will be very difficult for you.. *cough* Uh, I'm not a new packager, nor am I new to dpatch in particular. As I mentioned before, dpatch is my preferred patching infrastructure. That doesn't mean I feel it should be applied to every upstream tarball. I could accomplish the same thing with a little bit of effort in the debian/rules file, but that would produce the (accurate, and more relevant I feel) criticism that the build system used by 'make' is markedly different from that used by 'debian/rules binary' > Sorry to ask for many corrections, but I feel important that this package, > and > others, have a good shape before upload.. I welcome and appreciate the feedback. -- --- 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/ --- pgpOed8Mj0EJW.pgp Description: PGP signature
Re: manpage tools
On Wed, Mar 28, 2007 at 05:01:56PM +0200, Magnus Holmgren wrote: > So what other alternatives are there, not counting help2man and pod2man? I just recently tried txt2man. The manpages were quite easy to produce, but the options in formatting are limited and I'm not convinced it's produced particularly aesthetic manpages. I'll be having a look at some of the other tools mentioned in this thread for future use. txt2man's big advantage is it's just a big awk script, and so doesn't have to pass through any kind of intermediate format. This makes it light enough to be a Build-Depends if that sort of thing suits you. -- ----------- 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/ --- pgpVQwJNXz7TB.pgp Description: PGP signature
Re: RFS: openjpeg
On Thu, Mar 29, 2007 at 07:13:27PM +0900, Charles Plessy wrote: > Le Thu, Mar 29, 2007 at 07:41:40PM +1000, Paul TBBle Hampson a écrit : >> On Wed, Mar 28, 2007 at 04:54:52PM +0200, Romain Beauxis wrote: > >> * Any other user/DD may then see precisly what changes you are doing to > >> upstream sources. You will also be able to seperate the changes that > >> perform > >> a different task. >> Currently, any other user can see what I'm doing by looking at the >> .diff.gz. > just a "me too" word to say that I also feel more comfortable with > clearly labelled patches debian/patches rather than having them in the > diff.gz, which is not the easiest medium. Indeed, I believe this is not uncommon, hence the wig-and-pen source package format which, if I recall correctly, provides the upstream tarball(s), a debian/ tarball, and the patches to apply to the upstream source. Or something like that. Again, I question the idea that a dpatch is _easier_ to parse than the .diff.gz. Particularly, the .diff.gz shows all the changes to a given file in one place, and consumes any intermediate stages, so you don't have changes in an earlier patch breaking changes in a later patch and requiring you to reroll all subsequent patches that touch that file. And of course the contents of debian/patches is immaterial since the file you have to be verifying before upload is the .diff.gz. So if you're having trouble parsing it, dpatch won't solve it. (That's what debdiff is for. Again, debdiff output is much easier to read if you're not using dpatch. interdiff is hard enough to use without having to then parse _two_ layers of diff.) > In addition, in the future it may be more and more frequent to have > the content of the debian directories browsable through a web > interface to a revision system. In this case again, having things in > debian/patches makes life easier to understand the purpose of the > modifications. And again, if I was going to keep the debian/ directory in an external version-control system, dpatch would be the way to go. Since I'm not going to, the Debian archive already has a system for storing such trivial patches, in the .diff.gz. Despite this, and because I'm obviously going to be overruled here again no matter what I say, here's a version using dpatch. At least dpatch use is _easy_ to revert later. http://mentors.debian.net/debian/pool/main/o/openjpeg -- --- 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/ --- pgp3CkrTv6YhH.pgp Description: PGP signature
Re: RFS: openjpeg
On Fri, Mar 30, 2007 at 12:09:12AM +0900, Charles Plessy wrote: > Le Fri, Mar 30, 2007 at 12:18:23AM +1000, Paul TBBle Hampson a écrit : >> Again, I question the idea that a dpatch is _easier_ to parse than the >> .diff.gz. > Actually, I am sorry to critisize general problems of diff.gz in a > discussion about the particular one of your package, without having > looked at it. > It's just that sometimes I have a hard time finding useful information > in the some diff.gz when they have a lot of autoconf gizmo in, or many > manpages, xpm icons, desktop files, or any other "noise". I find the trick with reading a .diff.gz is to ignore anything that's in the debian directory, since that's all created (or at least, you don't really care that much what's changed from upstream), so the existent files are sufficient. I also am used to skipping autoconf-generated files in the .diff.gz, since the changes are never of actual interest, compared to the fact that they have been changed. That should trim the noise out almost entirely. I don't know if this is actually true, deliberate, or just co-incidental, but I believe it's the case that a .diff.gz has the non-debian/ stuff, then the debian/ stuff. > I agree that in the cases of trivial packages with a slim diff.gz, the > discussion becomes quite academic. Indeed, and as I've been saying, had the changes to the upstream tarball been more than trivial, dpatch would have been the first thing I did. -- --- 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/ --- pgpkbXUrITjPE.pgp Description: PGP signature
Re: RFS: openjpeg
On Thu, Mar 29, 2007 at 04:27:41PM +0200, Romain Beauxis wrote: > Le jeudi 29 mars 2007 16:18, Paul TBBle Hampson a écrit : >> And again, if I was going to keep the debian/ directory in an external >> version-control system, dpatch would be the way to go. >> Since I'm not going to, the Debian archive already has a system for >> storing such trivial patches, in the .diff.gz. >> Despite this, and because I'm obviously going to be overruled here again >> no matter what I say, here's a version using dpatch. At least dpatch use >> is _easy_ to revert later. > Paul, we'll talk about this later, when you'll have to update your package to > a new upstream release, when the diff.gz may not apply cleanly and you'll end > up seperating what's for upstream sources to what's for debian/ in the > diff.gz and finally patching new upstream with a new patch... That is > precisely the work I advise you to do in the first place: extracting a > patch.. Hmm. I don't actually blindly apply .diff.gz to new upstream versions. I usually just copy the debian/ directory across from my old one, inspect the .diff.gz for any changes outside the debian/ directory, and consider whether they are still needed, and what form they should take. When dpatch is in the mix, it's the same procedure, except I need to check each dpatch, rather than just running through the entire .diff.gz, and I also need to keep in mind any relevant changes made by earlier dpatches to the same files. And also not get confused by existing dpatches that aren't in 00list. If you're unlucky, you need to reroll a non-applying dpatch. If you're really unlucky, you then have to reroll subsequent dependant (and possibly non-applying) dpatches too. And although I haven't done it in a while, I don't recall dpatch-edit-patch being particularly fun to use on a non-applying patch... Either way, interdiff (via debdiff) then gives me a clue as to whether I've missed anything, and the results are much much easier to use without dpatch. Seriously, interdiff + dpatch means you're diffing diff files, the avoidance of which is the whole point of interdiff. Maybe some kind of dpatch-specialised interdiff wrapper... Hmm, I might look into that. I've also just realised that cowdancer integration would speed up dpatch-edit-patch quite nicely. In my experience, dpatch introduces more complication in the mix. And that complication is not worth it for five lines of changes between two Makefiles. > Sorry for giving you the impression that I overruled your will, but seriously > we'll discuss this later and I'm really convinced that > you may not have the same opinion. We've already established I've not the same opinion. I really don't expect that it'll change at this stage, either. I've presented all my positions on the topic, and the strongest arguement I've heard back was Charles' observation about debian/ directories becoming browseable at some point in the future. -- --- 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/ --- pgpOSZTQoG7nx.pgp Description: PGP signature
Re: RFS: openjpeg
On Fri, Mar 30, 2007 at 12:32:41AM +0200, Romain Beauxis wrote: > Le jeudi 29 mars 2007 18:37, Paul TBBle Hampson a écrit : >> Hmm. I don't actually blindly apply .diff.gz to new upstream versions. I >> usually just copy the debian/ directory across from my old one, inspect >> the .diff.gz for any changes outside the debian/ directory, and consider >> whether they are still needed, and what form they should take. > You have to keep in mind that you will not be the only one to work on your > package. You cannot assume that you'll maintain them forever, and even if it > would be the case, there may have NMUs, or security updates that will need > that another maintainer work on your package. And as I said before, I have seen the opinion expressed by DDs that dpatch makes it harder to do exactly that. And frankly, I can rely on every DD being able to handle the basic Debian packaging system, I don't think I need to expect every DD to grok dpatch, quilt or cdbs (Hell, _I_ don't grok cdbs) in order to make a small change to my package, without good cause. In short, I'm aiming for the lowest common denominator. > According to this, everything that makes your package easier to understand > and > handle for an external maintainer is a good thing, and using patches that > explain what they do, one for each different purpose *is* a good packaging > practice. I agree that it's a good packaging practice. I just don't agree that it needs to be applied to every package. -- --- 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/ --- pgpEzK09Wy8Hi.pgp Description: PGP signature
Re: RFS: openjpeg
On Fri, Mar 30, 2007 at 12:06:26AM +0300, Damyan Ivanov wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > - -=| Paul TBBle Hampson, 29.03.2007 19:37 |=- >> And >> although I haven't done it in a while, I don't recall dpatch-edit-patch >> being particularly fun to use on a non-applying patch... > My experience exactly. This is why I use quilt instead :) I'm going to have to have a look at quilt. I was under the impression that it was a rather complicated patch-management system, used for example by Andrew Morton for managing the -mm tree pre git. -- ----------- 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/ --- pgp4zDeK50hvv.pgp Description: PGP signature
Re: RFS: openjpeg (Sponsor still needed)
On Tue, Mar 20, 2007 at 02:17:06PM +1100, Paul TBBle Hampson wrote: > Dear mentors, > I am looking for a sponsor for my package "openjpeg". > * Package name: openjpeg Version : 1.1.1-4 > Upstream Author : OpenJPEG Team <[EMAIL PROTECTED]> > * URL : http://www.openjpeg.org/ > * License : BSD (2-clause as per > http://www.openjpeg.org/BSDlicense.txt) > Section : libs > It builds these binary packages: > libopenjpeg-dev - JPEG 2000 image compression codec library development files openjpeg-tools - JPEG 2000 image compression codec library shared objects > libopenjpeg1 - JPEG 2000 image compression codec library shared objects > libopenjpeg1-dbg - JPEG 2000 image compression codec library shared objects > The upload would fix these bugs: 413987 > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/o/openjpeg > - Source repository: deb-src http://mentors.debian.net/debian unstable main > contrib non-free - dget http://mentors.debian.net/debian/pool/main/o/openjpeg/openjpeg_1.1.1-4.dsc > It is a dependancy of the second-life viewer application, and Bernd Zeimetz > intends to package a Gimp plugin that uses it to. [1] > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413987;msg=10 (I've dequoted the differences from the original RFS) Romain is no longer taking an interest in this package. So I remain in need of a sponsor. Package still at the above URL, version is now 1.1.1-4, and I am satisfied (to the best of my knowledge) that the packaging is in a fit state for upload, barring a dpkg-buildpackage -v 0 -sa to ensure the ITP bug is closed by the full-source upload. -- --- 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/ --- pgpaoknGHcTho.pgp Description: PGP signature
Re: RFS: openjpeg
On Wed, Apr 04, 2007 at 08:01:19PM +0200, Michelle Konzack wrote: > Hello Romain, > Am 2007-03-21 14:25:24, schrieb Romain Beauxis: >> More comments: >> * You have lintian warnings about missing manpages. They are required so you >> may fix this. > Ehm, a manpage for a executable is clear, but for a LIB? This was in reference to the programs in openjpeg-tools -- ----------- 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/ --- pgpzKu3Cdpmhd.pgp Description: PGP signature
Re: RFS: openjpeg (Sponsor still needed)
On Thu, Apr 26, 2007 at 07:54:40PM +0200, Bernd Zeimetz wrote: >> Package still at the above URL, version is now 1.1.1-4, and I am >> satisfied (to the best of my knowledge) that the packaging is in a fit >> state for upload, barring a dpkg-buildpackage -v 0 -sa to ensure the ITP >> bug is closed by the full-source upload. > are there any news on this? Having openjpeg in Debian would be appreciated. Nope. However, now that the second-life viewer is packaged, with only a license issue keeping it from going from ITP to RFS, I'm pinning my hopes on a DD being keen enough for slviewer to also sponsor its two dependancies into the archive at the time. (I did kind of hope the PHP team would sponsor xmlrpc-epi, but after an initially-interested response from one of the team, I haven't heard back from them, and I wasn't ever successful in convincing pbuilder-uml to build php5 for me, so I don't know if it would even work with PHP as I expect.) -- ----------- 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/ --- pgp7sKjcLoSu3.pgp Description: PGP signature
Re: RFS: openjpeg (Sponsor still needed)
On Wed, May 30, 2007 at 09:22:16PM +1000, Paul TBBle Hampson wrote: > On Thu, Apr 26, 2007 at 07:54:40PM +0200, Bernd Zeimetz wrote: >>> Package still at the above URL, version is now 1.1.1-4, and I am >>> satisfied (to the best of my knowledge) that the packaging is in a fit >>> state for upload, barring a dpkg-buildpackage -v 0 -sa to ensure the ITP >>> bug is closed by the full-source upload. >> are there any news on this? Having openjpeg in Debian would be appreciated. > Nope. I've just uploaded openjpeg 1.2 packaging. Soversion has bumped to 2. http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=openjpeg -- ----------- 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/ --- pgpJkBgBeBNy3.pgp Description: PGP signature
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: List of (un)sponsored packages on Mentors (approximate)
On Mon, Jul 23, 2007 at 06:35:06PM +0200, Bart Martens wrote: > Here's also a list of packages needing a sponsor. > http://people.debian.org/~bartm/borg/needssponsor.html Your title= tagging has unfortunately barfed on my name, due to the "TBBle" in it causing the quoted string to terminate early. (See the openjpeg entry for example) -- ----------- 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/ --- pgplh7EaHrfG5.pgp Description: PGP signature
