[00:13] <jgoppert> RAOF: I've been pounding away at this but can't figure it out. Can you explain how I should use uupdate, i'm getting the same error with it, if i go to the old source tree and do uupdate ../new-tarball.tar.gz
[00:14] <RAOF> jgoppert: The simple fallback is: unpack the new tarball, and simply copy the debian/ directory from the old package to the new directory.
[00:14] <jgoppert> ok, i'll give that a shot
[00:31] <jgoppert> ok so gdal 1.5 conflicts with gdal 1.6, can i just install the header files to /usr/include/gdal-1.6/* or something instead?
[00:35] <superm1> hm requestsync doesn't work for syncing from contrib does it?
[00:35] <superm1> (for a NEW package)
[00:36] <RAOF> jgoppert: Probably not, although this depends on the precise situation.  Generally you don't want parallel installable -dev packages (which is where the headers go).
[00:37] <jgoppert> ok, well i want to package delta3d which depends on gdal1.6, so should i just install the so's?
[00:38] <jgoppert> RAOF: i guess maybe i could force a statically linked build of gdal and build delta3d against that?
[00:40] <jgoppert> like just put the gdal source under a 3rd party folder on delta3d, might get kind of ugly though
[00:41] <Laney> superm1: should do, with the -n flag
[00:41] <superm1> Laney, i tried with the -n flag and it still didn't even find it in contrib
[00:42] <Laney> sounds like a bug
[00:42] <superm1> Laney, test@dell-desktop:~$ requestsync -d sid -n --lp libvdpau lucid
[00:42] <superm1> E: The package 'libvdpau' does not exist in the Debian primary archive in 'sid'
[00:43] <superm1> http://packages.debian.org/search?keywords=libvdpau&searchon=names&suite=all&section=all
[00:44] <RAOF> jgoppert: Is there any particular reason why you wouldn't want to simply replace libgda's existing -dev package?
[00:45] <Laney> superm1: interesting, seems to be a bug in the lp import
[00:45] <Laney> works without --lp
[00:45] <Laney> (https://launchpad.net/debian/+source/libvdpau/+publishinghistory shows nothing)
[00:46] <Laney> or its just lagging
[00:46] <superm1> awesome
[00:46] <superm1> well as i look closer we need to have a delta to it anyway
[00:47] <superm1> at least for now
[00:47] <superm1> so maybe i'll just upload it to NEW myself with that delta
[00:47] <Laney> fun
[00:48] <superm1> it's stupid stuff too.  the maintainer doesn't want to drop a depends on something that is in contrib (for debian) / restricted (for ubuntu) because the package isn't useful without it he says
[00:48] <superm1> blah
[00:48] <superm1> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558464
[01:04] <superm1> wait what? Rejected:
[01:04] <superm1> libvdpau_0.3-1ubuntu1.dsc: Format is not 1.0. This is incompatible with dpkg-source.
[01:04] <superm1> how do i upload this to launchpad then?  it's format 1.8
[01:06] <ScottK> superm1: Whine at #laundchpad-dev until they fix it.
[01:06] <superm1> gah
[01:07] <ScottK> Although I didn't know about a 1.8
[01:07] <lifeless> 1.8?!wtf
[01:07]  * ScottK thought it was 1.0 or 3.0 as valid choices
[01:07] <lifeless> anyhow
[01:07] <lifeless> 3.0 support is coming
[01:07] <lifeless> wgrant has been working on it
[01:07] <lifeless> but its not 'flick a switch' - its more complicated than that
[01:08] <superm1> oh it is 3.0, just it says 1.8 in .changes
[01:08] <superm1> debian/source/format says 3.0
[01:09] <superm1> lifeless, so is there an ETA then?   does this means it's gonna fail just as hard on PPAs too?
[01:09] <ajmitch> it'll fail hard everywhere in LP until all the bits are in place
[01:10] <superm1> maybe for now so i can get this package in i should just revert it back to the old format for the ubuntu delta then
[01:10] <superm1> and hopefully whenever it gets merged and/or synced in the future launchpad will support it by then
[01:11] <ScottK> superm1: Will you have orig.tar.gz md5sum problems later if you do that now?
[01:11]  * ScottK doesn't know enough about the new formats to know.
[01:11] <superm1> well luckily enough dont need to change the orig.tar.gz at all
[01:11] <superm1> so i dont expect so
[01:11] <ajmitch> .orig.tar.gz should still be the same, but there'll be a diff.gz again instead of .debian.tar.gz
[01:12] <ajmitch> the main things to watch will be if it uses patches
[01:12] <superm1> not at this point
[01:13] <ajmitch> then you may get away with uploading it as 1.0 format
[01:23] <superm1> yay. looks like i did get away with it as 1.0 format
[01:23] <superm1> so i'll just hope for now that by next time merging or syncing is necessary this is sorted out
[01:24] <superm1> oh this is probably why it didn't show up in the LP import yet too then
[01:29] <ajmitch> quite likely :)
[01:29] <ajmitch> one of those few times that you wish that debian wouldn't move so fast
[01:34] <JontheEchidna> it's not like the changes haven't been being discussed for long enough :s
[01:35] <ajmitch> lots of things get discussed & implemented several months/years later :)
[01:35] <JontheEchidna> I guess Debian moving at a normal rate is considered relatively fast? :P
[01:36] <ajmitch> Debian moves when & where it will
[02:24] <nigel_nb> maco: ping
[02:25] <maco> nigel_nb: i cant talk right now. i just did a nice clean install of karmic on mum's computer and now it won't bot
[02:25] <maco> *boot
[02:25] <nigel_nb> maco: kewl, some other day then :)
[02:25]  * maco throws pointy objects at GRUB
[02:26]  * nigel_nb stands in GRUB's defence
[02:32] <jgoppert> RAOF: if i replace libgdal 1.5 with libgdal 1.6 won't that break a lot of dependencies in karmic?
[02:34] <jgoppert> can anyone help, i want to package delta3d, but it depends on lib gdal 1.6, but karmic has lib gdal 1.5, whats the best course of action?
[02:43] <ScottK> jgoppert: Package it for lucid
[02:44] <jgoppert> ScottK: lucid is still at libgdal 1.5, and i'm getting better at packaging but i'm not a pro yet, do i need a sponsor or something to do that
[02:44] <ScottK> jgoppert: Yes, you will, but if we're going to switch, now's the time to do the transition in Lucid.
[02:45] <jgoppert> do i need to contact the debian maintainer? its got no ubuntu revision
[02:46] <ScottK> jgoppert: That would be smart.  We want to have the same versions in Squeeze and Lucid as much as we can.
[02:46]  * jdong grumbles about clock accuracy with handbrake fetch stamps
[02:46] <jdong> it wouldn't have killed them to use md5sums as a decision maker for whether or not to refetch
[02:47] <jdong> ok, build #8 of the evening. gym time while that chugs away
[02:49] <jgoppert> ScottK: If i am trying to deploy delta3d for a small network is there anyway around moving them all to lucid after the package has been updated?
[02:49] <ScottK> jgoppert: You could backport the needed packages into a PPA
[02:49] <jgoppert> ScottK: Ok that should work.
[02:50] <jgoppert> ScottK: thanks
[02:50] <ScottK> You're welcome
[03:06] <jgoppert> ScottK: There are like 3 other libraries that delta3d depends on that aren't in ubuntu, should we just add them to lucid?
[03:07] <ScottK> jgoppert: Yes.  That would have to come first.
[03:07] <jgoppert> ScottK: Can I recruit help somewhere, or a mentor to double check me and approve my packages?
[03:08] <maco> all sponsors are responsible for checking and approving package changes
[03:08] <ScottK> jgoppert: That's what we do here.  You can ask questions here anytime.  No need for a formal mentor to be assigned (although there is such a program)
[03:08] <ajmitch> the debian gmaes team might be helpful as well
[03:09] <ScottK> jgoppert: ajmitch has a good point.  It's called the Debian Games Team, but it's really Debian/Ubuntu.
[03:09] <jgoppert> should i package through debian first?
[03:09] <ScottK> Ideally.
[03:09] <ScottK> bddebian: Are you still doing Debian Games stuff?
[03:10] <bddebian> Not as much as I should be but yes
[03:10] <wgrant> superm1: My 3.0 branch is approved. It just needs to be merged, which means I need to get a new dpkg everywhere, and blah blah blah urrrrghhhh messy.
[03:10] <wgrant> superm1: So it should be ready in a couple of days.
[03:10] <ajmitch> wgrant: that soon? excellent
[03:10] <ScottK> bddebian: jgoppert is interested in getting a game packaged for Lucid (and potentially Squeeze)
[03:11] <ScottK> bddebian: He's new, so be gentle.
[03:11] <jgoppert> thanks ScottK
[03:11] <bddebian> Heh
[03:11] <wgrant> ajmitch: LP 3.1.11 is meant to be happening on Wed 2200UTC, I believe.
[03:12] <wgrant> But I need to check with $CANONICAL_PERSON how the dpkg upgrade on cocoplum is going.
[03:12] <ajmitch> hopefully without any problems or random segfaults
[03:13]  * ScottK is struggling to maintain silence on the topic.
[03:13] <ScottK> "If you can't say anything nice, don't say anything at all" is an interesting theory, but really hard sometimes.
[03:14] <ajmitch> ScottK: I've heard of problems with backporting dpkg in the past, it's nothing specific to LP
[03:14] <ScottK> ajmitch: No, my struggle is more about how unprepared LP is for this and my thoughts about how reasonable it is they didn't prepare.
[03:15] <ScottK> I might also have some thoughts about how this reflects where distro support falls in their priorities, but I'm staying silent.
[03:15] <ajmitch> no, you're really not
[03:15] <wgrant> ScottK: Well, I don't think anybody expected Debian to do it for many years.
[03:16] <wgrant> (however I agree with your distro support comment)
[03:17] <ajmitch> the priorities seem to be enabling new & shiny ways to play with package branches at the moment
[03:18] <lifeless> debian didn't expect to do it for years :)
[03:18] <StevenK> So ScottK's problem is that LP people can't predict the future?
[03:18] <ScottK> It's a release goal for Squeeze
[03:18] <ajmitch> lifeless: and of course there's the backlash against the change on d-d :)
[03:19] <wgrant> ScottK: And release goals are always met...
[03:19] <StevenK> ScottK: Hah. Strawman
[03:19] <ScottK> Of course they aren't always met.
[03:19] <ScottK> OTOH, it shouldn't have been a great suprise someone worked on it.
[03:20]  * maco ^5 StevenK
[03:20] <ajmitch> it was a surprise that there's already talk of switching the default format already
[03:20] <StevenK> Really, this is Debian's fault for getting 4 ftpmasters in the same room for a weekend
[03:21] <StevenK> maco: Heh, for which bit?
[03:21] <maco> StevenK: cant predict the future
[03:21] <wgrant> It took all of not very long at all to implement it.
[03:21] <ajmitch> wgrant: main problem being that dpkg-source is run outside the chroot?
[03:22] <wgrant> ajmitch: That's the buildd side of things, yes.
[03:22] <wgrant> But that's lamont's problem lalalala.
[03:22] <ajmitch> lucky lamont
[03:24]  * ajmitch would like try & get at least something landed into LP in the next release cycle
[03:25] <StevenK> ajmitch: Ubuntu or Launchpad's? :-)
[03:25] <ajmitch> heh
[03:25] <ajmitch> LP, I've got stuff ready to upload to ubuntu when I get time :)
[03:26] <ajmitch> in other news, loggerhead hates me when I try & open 10 tabs of individual revisions
[03:27] <wgrant> ajmitch: They have a contractor working on that.
[03:28] <ajmitch> good
[04:06] <superm1> wgrant, spectacular, thanks
[04:12] <pace_t_zulu> anyone want to help with a debian sync request?
[04:12] <pace_t_zulu> or should i file a bug
[04:13] <StevenK> pace_t_zulu: File a bug
[04:13] <pace_t_zulu> StevenK, ty
[04:21] <pace_t_zulu> virtualbox-ose
[04:21] <pace_t_zulu> https://bugs.launchpad.net/ubuntu/+source/virtualbox-ose/+bug/490193
[05:09] <superm1> can someone else take a peek at this buildlog?  I must be going crazy. i don't see why it wouldn't be able to find the freetype library: http://launchpadlibrarian.net/36246886/buildlog_ubuntu-lucid-i386.mythplugins_0.22.0%2Bfixes22924-0ubuntu0%2Bmythbuntu4_FAILEDTOBUILD.txt.gz
[05:20] <jmarsden> superm1: That does look odd.  Does it build OK locally (in your pbuilder chroot or similar)
[05:21] <superm1> well the same source builds nicely on the PPA for intrepid, jaunty, and karmic daily.  i'm just setting up a lucid pbuilder locally to see
[05:22] <jmarsden> OK.  So you might have found a bug in the libfreetype6 package for Lucid, or something along those lines.
[05:22] <superm1> there's a very small diff from the karmic to lucid freetype
[05:22] <superm1> but i wouldnt expect it to cause this kind of problem
[05:22] <superm1> http://launchpadlibrarian.net/35143239/freetype_2.3.9-5_2.3.11-1.diff.gz
[05:23] <superm1> oh it's a new version too
[05:23] <superm1> so that's gotta be where the problems are lying then
[05:37] <superm1> jmarsden, yeah it was a freetype bug.  amazing what a misplaced period does. http://pastebin.com/f29be441d
[05:37] <superm1> i'll upload that to lucid and send a patch to debian
[05:39] <jmarsden> :)  OK, glad you found it.   Seems slightly odd that debian/libfreetype6.files needed to be hand edited for the new release at all, really...
[05:40] <jmarsden> I can see maybe adding some new lines for new files... but why edit that one?
[05:46] <LucidFox> Ugh... The copyright for so many of these files is written in French.
[05:46] <LucidFox> (2mandvd data files)
[05:48] <LucidFox> Ugh, the license terms for photo-libre.fr are:
[05:48] <LucidFox> "These photos are totally free and copyright free, but they can not be resold or used in any medium for commercial purposes."
[05:48] <LucidFox> How does "copyright free" mesh with "non-commercial"?
[05:48]  * LucidFox deletes these files
[05:56] <LucidFox> ...Gosh, this upstream needs to be educated what "free" as in free software means.
[05:57] <maco> hahaha
[05:57] <LucidFox> license.txt for .png files: "All these events have been found on the internet and was under a free license allowing a free non-commercial redistribution. Other came from tuxpaint project (http://www.tuxpaint.org). If you own one or more images and you do not want it to be in this package you can write me at: gibault.stephane@wanadoo.fr and I will remove them."
[05:58] <maco> i assume they mean gratis all over that
[05:58] <maco> sounds like multiverse
[05:58] <LucidFox> Well, it depends on multiverse packages so it will go to multiverse anyway, but not before I clean up this copyright mess from "non-commercial" or unattributed image files.
[05:59] <LucidFox> The software itself is GPL2+.
[06:00] <maco> wait a...does it... "i dont have the right to redistribute these, but lets pretend i do and that im giving you the right to do so"?
[06:10] <LucidFox> maco> I think the author just assumed that "non-commercial" is good enough to bundle with GPL software.
[06:10] <maco> yeah
[06:11] <maco> that the GPL is a non-commercial license is a common misconception too
[06:13] <Flannel> LucidFox: How does "totally free" mesh with "but you can do X"
[06:13] <LucidFox> Flannel> Ask the author of photo-libre.fr, I'm confused.
[06:14] <LucidFox> So... 9 themes distributed under a French-language free license, 9 from a non-commercial "free" photo site, 25 completely unattributed.
[06:14] <LucidFox> In short, I had to delete 34 out of 43 themes.
[06:15] <maco> ouchies
[07:11] <hyperair> sounds fun
[07:24] <LucidFox> Okay, 2mandvd uploaded to REVU.
[07:47] <LucidFox> Is there a way to subscribe to REVU package uploads by mail or RSS?
[08:09] <nigel_nb> maco: got the computer working?
[08:09] <maco> i think so
[08:09] <nigel_nb> great :)
[08:11] <nigel_nb> how many pointy things did u throw at it :P ?
[08:17] <nigel_nb> maco: will you have the time to mentor me through MOTU?
[08:54] <akheron> LucidFox: got any spare time? http://revu.ubuntuwire.com/p/jansson :)
[08:55] <LucidFox> akheron> Just looked at it, was waiting for you to come back. :)
[08:55] <akheron> heh :)
[08:56] <LucidFox> Why is the -dev package so strangely declared? Contains soname number in the package name, and has Provides and Conflicts for libjansson-dev...
[08:56] <LucidFox> Why not just name the package libjansson-dev?
[08:57] <akheron> I mimiced it from somewhere
[08:57] <LucidFox> ^_^
[08:57] <akheron> from some random debian documentation, I guess
[08:57] <akheron> I don't really know what's the best practice
[08:58] <akheron> the library package has the SONAME in it's name, so why the -dev package doesn't have
[08:58] <LucidFox> You'll only need Provides/Replaces for transitions. It's better to name the package libjansson-dev and drop the Provides and Conflicts lines.
[08:58] <akheron> ok
[08:59] <akheron> also, I wasn't sure about the document ID for doc-base
[08:59] <akheron> is "libjansson" ok, or does it even matter as long as it's unique
[09:00] <LucidFox> Doesn't, really. libjansson or jansson will do.
[09:00] <akheron> ok, good
[09:02] <akheron> Any other notes? I'll upload a new one shortly
[09:09] <LucidFox> akheron> Nothing else I can think of.
[09:38] <akheron> LucidFox: done
[09:38] <LucidFox> Thanks, looking...
[09:38] <akheron> It seems that my "shortly" equals over half an hour :)
[09:41] <LucidFox> akheron> The -dev.install file is still named libjansson0-dev.install.
[09:41] <LucidFox> It helps to build the package after making changes. ;)
[09:41] <akheron> argh
[09:42] <akheron> I did but didn't quite check it
[09:53] <akheron> LucidFox: fixed
[09:53] <akheron> :F
[09:55]  * LucidFox downloads and builds
[10:04] <LucidFox> akheron> Advocated!
[10:13] <\sh> moins
[10:24] <akheron> LucidFox: thanks a lot! :)
[10:46] <alkisg> Hi, I'm using dh_installexamples, and on postinst I'd like to gunzip one of the examples to /etc/my-package. But I've noticed that when the example is small, dh_installexamples doesn't gzip it! Is that true? Is there any standard way to uncompress/view a package's examples?
[10:49] <LucidFox> alkisg> gzip is done in dh_compress rather than dh_installexamples, so you can call dh_compress -Xfilename to ensure that the file in question is never compressed.
[10:49] <alkisg> Thanks, looking...
[11:02] <alkisg> Ah, I see where's the limit: "...files in usr/share/doc that are larger than 4k in size..."
[11:33] <LucidFox> ScottK, I'm going to migrate quassel to dh 7 and --with=kde, and eventually add support for double builds. Would it be better to file both in one debdiff, or wait until the dh 7 version is uploaded and only then work on double builds?
[11:35] <ScottK> LucidFox: I'd prefer to see them as separate patches.  Also Quassel in git has switched to gettext from translations.  Next on my list was to switch to a gettextified quassel.  If you could look at that with the dh7 stuff it'd be much appreciated.
[11:55] <LucidFox> http://revu.ubuntuwire.com/p/linux-libre <-- Wow, that's a slightly oversized diff.gz.
[11:56] <ScottK> LucidFox: I think the package is pretty much unsuitable for the archive in any case.
[11:56]  * LucidFox nods
[12:00]  * ScottK just left a comment to that effect on REVU.
[12:02] <directhex> LucidFox, OOo's is bigger!
[12:02] <LucidFox> Seriously? What is in there, tons of big patches?
[12:02] <directhex> LucidFox, OOo is... complicated
[12:02] <directhex> LucidFox, in short, "yes"
[12:03] <directhex> openoffice.org_3.1.1.orig.tar.gz 	394,144.4 kB
[12:03] <directhex> openoffice.org_3.1.1-5ubuntu1.diff.gz 	96,076.5 kB
[12:03] <LucidFox> It's a shame that the best free office suite out there in something so out of touch with both GNOME and the Unix philosophy.
[12:03] <LucidFox> s/in/is/
[12:04] <directhex> if memory serves, orig is a tar-in-tar of upstream sun OOo (actually 15 upstream tarballs)
[12:04] <LucidFox> O_O
[12:04]  * LucidFox headdesks.
[12:05] <directhex> the patch set is a 214 meg diff
[12:05] <directhex> including a uuencoded copy of an entire icon set
[12:05] <directhex> ( ooo-build/src/ooo_oxygen_images-2009-06-17.tar.gz.uu                                            |317713 +++++++++)
[12:06] <directhex> the diff is basically the entire go-oo patchset, including (e.g.) 334,000 lines of VBA test scripts
[12:08] <directhex> LucidFox, building OOo takes about 101 gig of space and 10 hours of core2duo
[12:08]  * LucidFox O_O
[12:08] <directhex> bah
[12:08] <directhex> 10 not 101
[12:09] <directhex> oh, and lots of RAM too
[12:17] <LucidFox> directhex, if the diff includes the entire go-oo patchset, why not just build off go-oo sources?
[12:18] <directhex> LucidFox, no such thing, go-oo is just a patchset. despite claims by some individuals on some gutter press
[12:18] <directhex> LucidFox, it's just a big honkin' patchset
[12:18] <LucidFox> They do provide a tarbal on go-oo.org, no?
[12:18] <LucidFox> * tarball
[12:19] <directhex> the tarball contains their build system, but not the ooo source
[12:45] <alkisg> On postinst, I'm generating a /etc/my-package/my-package.conf file. Upon uninstallation, when is the correct time to remove it? On prerm when "$1"=="purge"? (I'm worried about the /etc/my-package dir being correctly deleted if empty).
[12:47] <alkisg> Or should I manually check and remove the /etc/my-package dir on postrm if it only contains my-package.conf?
[12:48] <alkisg> Hmmm I don't see prerm called with "$1" == "purge"... Only postrm: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html
[12:51] <Laney> why not postrm?
[12:52] <Laney> that's when conffiles are usually deleted
[12:56] <alkisg> I think when postrm is called, the package files are already removed,
[12:57] <alkisg> so I wanted to delete it beforehand, so that dpkg would remove the directory by itself, if that directory was empty (/etc/my-package)
[12:57] <alkisg> Well I guess I can delete that directory myself, on postrm...
[12:57] <Laney> http://www.marga.com.ar/~marga/debian/diagrams/remove-purge.png
[12:58] <Laney> I don't know if "Conffiles are deleted" is in the right place there...
[12:59] <alkisg> I only want to delete that file on purge, so I guess I don't have much choice... I'll do it on "postrm purge"
[12:59] <alkisg> Thanks for the nice diagram! :)
[13:32] <lfaraone> How can have debuild run "autogen.sh" before running "configure" using CDBS?
[13:34] <lfaraone> Figured it out, thanks.
[13:35] <Laney> you probably want the DEB_AUTO_UPDATE_* stuff instead, lfaraone
[13:35] <Laney> that's the cdbsey way of doing these things
[13:35] <lfaraone> Hm.
[13:37] <lfaraone> Laney: how do I figure out whether I run libtoolize pre or post?
[13:37] <Laney> dunno
[13:37] <Laney> I suck at this stuff
[13:37] <lfaraone> And it looks like the script also runs "gtkdocize" as part of autogen.
[13:37] <Laney> well, it depends why you want to reautogen
[13:38] <lfaraone> Laney: upstream does not believe in shipping configure in git.
[13:38] <Laney> as they should
[13:38] <lfaraone> And their released versions are broken on the most recent version of GTK
[13:38] <Laney> it might be right to just run autogen.sh then - I was thinking you were doing an autoreconf
[13:39] <Laney> alternatively run it before you generate the orig (in your get-orig-source)
[13:39] <lfaraone> Laney: so I could do that with "DEB_CONFIGURE_SCRIPT := ./autogen.sh
[13:39] <Laney> use a full path
[13:40] <Laney> and make sure your clean target deletes the right stuff
[13:41] <lfaraone> Laney: hm. now it builds, but "install" is giving me errors.
[13:41] <lfaraone> Laney: http://paste.ubuntu.com/331694/
[13:47] <Laney> lfaraone: Looks like it repeats some filenames on the install line
[13:47] <Laney> which causes the error
[13:51] <slytherin> ttx: there?
[13:52] <ttx> slytherin: yes
[13:52] <lfaraone> Laney: hm. but it works when I "make install" it locally.
[13:52] <lfaraone> Laney: how would I go about fixing that?
[13:54] <Laney> check the autotools files to find out why it happens ¬_¬
[13:54] <slytherin> ttx: Are you planning to drop -gcj from recommends unconditionally in this cycle? There are no arch now where GCJ is main JDK. Also openjdk seems to work well on all arch.
[13:55] <slytherin> all as in the ones I have tested, i386, amd64 and powerpc
[13:55] <ttx> slytherin: yes, see https://blueprints.launchpad.net/ubuntu/+spec/server-lucid-java-library-fixes
[13:55] <slytherin> great, I will keep an eye
[13:55] <ttx> slytherin: though the change is not acceptable in debian so we need to find the best way of doing it (introduce delta or not)
[13:56] <slytherin> hmm
[13:56] <ttx> slytherin: this is discussed in the spec, I'd welcome your input
[13:56] <ttx> slytherin: see 6.1 in https://wiki.ubuntu.com/LucidJavaCleanupSpec
[13:58] <ttx> slytherin: in all cases we get rid of the arch:any trick
[13:58] <slytherin> ttx: Will check.
[13:58] <ttx> slytherin: thx
[13:59] <slytherin> ttx: By the way, I am not sure how reasonable this request is but in future we should probably have a separate java component in archive reorg. So that we get rid of these dependency problems.
[14:59] <LucidFox> ScottK> bug #490347
[15:06] <ScottK> LucidFox: Diff looks good.  I'll try to get it uploaded tonight.  Thanks.
[15:18] <bddebian> Heya gang
[15:28] <Laney> hi bddebian
[15:52] <bddebian> Hi Laney
[16:40] <shankhs> hi i am learning packaging and I couldnt understand the *.ex files.Can anyone please explain it?Please
[16:41] <Daviey> shankhs: those are example files, generally you want to get rid of them.
[16:41] <shankhs> why?
[16:41] <Daviey> You can use them as a template (if that file is needed)
[16:42] <shankhs> when are templates neccessary?
[16:42] <Daviey> most of them are not required for most packages.
[16:42] <Daviey> they are ex(amples) :)
[16:42] <shankhs> Daviey: thanx i got it
[16:43] <Daviey> great!
[16:45] <shankhs> When i see the changelog of hello file(in https://wiki.ubuntu.com/PackagingGuide/Basic ) i dont see any -0ubuntu1 or ubuntu written anywhere.Did I do anything wrong?Please
[16:46] <shankhs> i am following https://wiki.ubuntu.com/PackagingGuide/Basic
[16:47] <shankhs> My changelog is totally different from this one https://wiki.ubuntu.com/PackagingGuide/Basic
[16:47] <jpds> shankhs: Can you put your changelog's contents on paste.ubuntu.com?
[16:49] <shankhs> jpds: http://paste.ubuntu.com/331820/ i tried dch once
[16:55] <shankhs> hi
[16:58] <jpds> shankhs: It looks like you're suppose to create the -0ubuntu1 entry, simply change the -1 to -0ubuntu1.
[16:58] <shankhs> ok
[16:58] <shankhs> jpds: thanx
[17:47] <jdstrand_> dholbach: hi! my ubuntumembers membership expired while I was on vacation. what is the best way to get it back? (my indirect membership via core-dev doesn't seem to give my cloaking, etc)
[17:49] <dholbach> jdstrand_: that's weird - just send a quick mail to community-council@lists.u.c and I'll unexpire you
[17:50] <jdstrand_> dholbach: ok, thanks
[17:52] <jdstrand_> dholbach: sent
[17:52] <rcbwnka> jdstrand_: Cloakes are just bad. You cannot be recognized after some years.
[17:54] <Pici> rcbwnka: A cloak is the text that replaces a person's hostname on IRC. Ubuntu members qualify for ubuntu/member/$username
[17:55] <rcbwnka> Who cares ?
[17:55] <rcbwnka> I thought the contributions made should be worth something. Not people taking cover ?
[17:56] <rcbwnka> They appeared 2003, right along with Beagle.EXE and other microsoft things
[17:58] <lfaraone> rcbwnka: it's a nice touch.
[17:59] <lfaraone> Do libpam plugins need to be named accoridng to their soname version? (ie libpam-rainbow2 vs libpam-rainbow)
[17:59] <rcbwnka> No, i shouldnt think so
[18:00] <rcbwnka> so name is always "so" though ;)
[18:00] <rcbwnka> so.number
[18:01] <rcbwnka> But, itll make it easy to keep track of. should you not do so your app will never (or should never) see the day of light
[18:02] <rcbwnka> app name: hello-there. Libname1: hello-there.1.x.x
[18:02] <rcbwnka> Or better yet...
[18:03] <rcbwnka> app name: hello-there. Libname1: hello-there-1.1.x.x
[18:03] <rcbwnka> app name: hello-there. Libname2: hello-there-2.1.x.x
[18:03] <rcbwnka> As specific as possible
[18:04] <lfaraone> rcbwnka: I mean should the package be named "libpam-rainbow2" or "libpam-rainbow"?
[18:06] <rcbwnka> well, It seems to be a new version that will diverge enough from the original "rainbow" ?
[18:06] <rcbwnka> To be a mayor version upgrade/release ?
[18:07] <rcbwnka> Otherwise just call it the same.
[18:07] <rcbwnka> Client / server ?
[18:08] <rcbwnka> Then dont change the name, add a min-client-version.
[18:09] <rcbwnka> rainbow six was a bit fun btw
[18:11] <rcbwnka> lfaraone: seems ok to you ?
[18:12] <rcbwnka> Write down what ever scheme you go for.
[18:15] <randomaction> DktrKranz: ping
[18:49] <DktrKranz> randomaction: pong
[18:50] <randomaction> DktrKranz: I'm going to request a sync of xotcl, are you ok with this?
[18:50] <randomaction> bug 399157
[18:53] <DktrKranz> randomaction: sure
[18:53] <randomaction> ok, I'll convert this bug
[20:13] <TLF> hello
[20:20] <TLF> where can I contact the developer of vmware-package package?
[20:35] <TLF> well, anyways
[20:35] <TLF> trying to install vmware-package 0.22 I'm getting: vmware-package:
[20:35] <TLF>  Depends: libstdc++5  but it is not installable
[20:37] <randomaction> TLF: there's a bug filed about it (bug 459286)
[20:37] <TLF> oh, thanks, ubottu
[20:40] <randomaction> anyway, this package was removed from Debian and will likely be removed from the next Ubuntu release
[21:06] <ScottK> TLF: That needs an ancient version of gcc that we aren't supporting anymore. It should have been removed already.
[21:08] <TLF> ScottK: and it is not possible to update the package?
[21:11] <ScottK> TLF: No.  It's not a Free software package, we only have binaries, no source
[21:11] <TLF> ScottK: oh, I though it was a open source program to install the binaries (vmware=
[21:12] <ScottK> Right, but the binaries have to be built against a recent GCC and we don't have that
[21:13] <TLF> oh
[21:13] <TLF> that's ok then :)
[21:14] <ajmitch> from what I can see, vmware-package itself doesn't have the libstdc++5 dependency, which is partly why it didn't get picked up
[21:49] <TLF> bye
[22:08] <dupondje> g
[22:21] <surfzoid> Hi
[22:24] <surfzoid> i'm trying to build a package an have the following error : http://pastebin.com/d7eebf6e1  but my log file is http://pastebin.com/d673c4a7a i really don't see where i do an typo error
[22:24] <surfzoid> someone can give me a clue ?
[22:26] <ajmitch> surfzoid: 1 too many spaces before the date
[22:26] <surfzoid> whoa is it so strict !!
[22:26] <surfzoid> oki
[22:26] <ajmitch> it can be :)
[22:26] <ajmitch> try it, I may be wrong
[22:26] <surfzoid> ajmitch: thanks
[22:27] <ajmitch> the other problem can be using tabs instead of spaces before the *
[22:28] <ajmitch> usually there's a blank line after the line with the version information, though I'm not sure if it's required or not
[22:28] <surfzoid> well, i discover the creasy stric build world :-)
[22:31] <surfzoid> ajmitch: is there a tool or an scite plugin who check debian file syntax or at least colour them ?
[22:33] <ajmitch> there are tools like dch which add the changelog entries, I use emacs however which has some modes for editing changelogs
[22:33] <surfzoid> this is an know format like verylog ?
[22:34] <ajmitch> sorry?
[22:34] <surfzoid> yes debian.changelog use an specif format or this a know one
[22:35] <ajmitch> it's a specific format documented in debian policy
[22:35] <surfzoid> if you take spec file for rpm, you can use shell syntax/format and color
[22:36] <ajmitch> http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog has the details, it's fairly basic
[22:36] <surfzoid> so i will play more with luky :-)
[22:37] <surfzoid> hey seem okay with your few tip, thanks a lot ajmitch :-)
[22:38] <surfzoid> debian world sound like an egg :-)
[22:39] <ajmitch> there are lots of useful tools around for packaging though
[22:40] <surfzoid> yes, using a simple text editor (my favorite) is no easy
[22:42] <surfzoid> bye and again thanks
[23:17] <jjlee> does the ppa build server actually install packages?  I assume not?  If it doesn't, what do you use for testing (install-)Depends?  Just debootstrap + apt?
[23:21] <mannyv> geser, around?
[23:24] <geser> mannyv: yes
[23:26] <mannyv> highvoltage, I have been using requestsync a but lately and I got annoyed at always having to go to launchpad to add a build log as an attachment after filing the sync request. So I modified it a little bit so I could specify a log on the command line.
[23:26] <mannyv> geser ^
[23:27] <mannyv> stupid auto-complete, I always mess it up
[23:27] <mannyv> so then I thought why not try to get it into the package, so I have beenn working on it being able to send an attachment via email as well.
[23:29] <jmarsden|work> jjlee: You could set up a pbuilder chroot and install/test the PPA-built packages in that.
[23:29] <jjlee> yeah, just looking at that -- ISTR another one, can't seem to find it now
[23:29] <jjlee> another tool, I mean
[23:29] <geser> jjlee: or try using puiparts for it
[23:29] <jjlee> other than cowbuilder
[23:29] <jjlee> that was it, thanks
[23:30] <mannyv> geser, that is close to being done. The part I am grappling over is when it prints out a final copy of the email if it should print out, for review, just the body of the messageor include the attachment as well. I thought I would solicit an opinion from you since you wrote it
[23:30] <geser> mannyv: have you something ready to merge/review?
[23:30] <jjlee> so ppa server doesn't install packages?
[23:31] <mannyv> i wanted your thoughts re: my last message first, so I would no where to go with it
[23:32] <jmarsden|work> jjlee: No, the builders are build servers, AFAIK they do not install the stuff they build.
[23:32] <jjlee> jmarsden|work: fair enough
[23:32] <jjlee> would be a nice feature :-)
[23:33] <jmarsden|work> jjlee: Maybe; you're supposed to test locally before submitting to a PPA anyway though :)
[23:33] <jjlee> well, it worked first time anyway :-)
[23:35] <geser> mannyv: the idea behind is to let the user an option to actually see what it send/submitted before it gets done, especially as it gets signed (when mailing)
[23:35] <geser> but I don't have a strong opinion on it
[23:36] <geser> I've have to look up what it did before my recent modifications to requestsync
[23:38] <mannyv> geser, yeah build logs tend to be long and scrolling through a whole log to see the message can be annoying. So i am thinking I will set it so it prints out the body of the email but not the attachment
[23:38] <mannyv> geser, I also rewrote the email part so it uses the email package, you don't have an issue with that do you?
[23:39] <geser> as I didn't had to email attachments to LP till now, do you know which parts of the email need to be signed to let LP accept it? is the "normal" content enough and will LP add the attachment to the bug report?
[23:41] <lifeless> for requestsync
[23:41] <lifeless> is target release optional or not ?
[23:41] <Laney> it should be
[23:41] <Laney> but the flag parser is a bit rudimentary
[23:42] <Laney> so sometimes it is actually not
[23:42] <lifeless> $ requestsync -d unstable python-testtools
[23:42] <lifeless> E: Source package or target release missing. Exiting.
[23:42] <Laney> yep
[23:42] <lifeless> should I file a bug ?
[23:42] <Laney> a patch would be better ;)
[23:42] <Laney> but yeah, file a bug if you like
[23:42] <geser> depends, when using --lp it's optional (it can be looked up with LP API) but for mail it's needed
[23:42] <Laney> well
[23:42] <Laney> I've come across some cases where it's not optional
[23:43] <Laney> we should make it -u [ubuntu release]
[23:43] <lifeless> mm, --lp is happier, so I'll ignore the bug for now
[23:43] <geser> yes, when you omit --lp I don't know a way to look it up without LP API
[23:43] <lifeless> geser: hard code it.
[23:43] <Laney> that would ease the parser
[23:43] <lifeless> geser: each release, update it.
[23:43] <jgoppert> I would like to get gdal from 1.5 to 1.6 in ubuntu. It already is in sid, who do I talk to?
[23:44] <Laney> jgoppert: will they be around in parallel?
[23:44] <Laney> if not, how big is the transition?
[23:44] <jgoppert> well ScottK was saying the other night we should just go to 1.6 for lucid.
[23:44] <Laney> sure
[23:44] <jgoppert> Not too big, I am just about done building 1.6 on my ppa.
[23:44] <Laney> if it's small, you can handle it yourself
[23:44] <geser> lifeless: I thought about it, but then I (or someone) needs to update it short before the release (if we don't want to do a SRU for it)
[23:44] <Laney> otherwise coordinate on the list
[23:45] <jgoppert> Ok, so can someone look over my package on my ppa and commit it to lucid?
[23:46] <jgoppert> I had to back down a couple of dependencies to earlier library versions but it looks like config handled it just fine.
[23:46] <Laney> erm
[23:46] <lifeless> geser: its the same as all our dev tools.
[23:46] <Laney> usually you would get those updated first
[23:46] <lifeless> geser: debootstrap etc need changed too.
[23:47] <jgoppert> yeah... well its just libhdf5-dev, and libhdf4-alt-dev, unless those have more dependencies to fix :-)
[23:49] <geser> yes, but I prefer not to add another package to the list of packages that needs backporting for each new ubuntu release
[23:49] <Laney> let's hope this 'ubuntu-release' tool gets written
[23:50] <jgoppert> what's it supposed to do?
[23:50] <Laney> abstract this problem
[23:51] <mannyv> geser, I just did a test and it only requires the email body be signed not the attachment
[23:52] <geser> mannyv: then IMHO it should be enough to just list the attachments (filename) before sending/submitting
[23:53] <jgoppert> if gdal 1.6 is in sid do i need to attach source tarball on my ppa build for karmic?
[23:53] <Laney> is it a sync?
[23:53] <mannyv> geser, sold =)
[23:53] <Laney> wait
[23:53] <Laney> jgoppert: did you see which version we have in lucid?
[23:54] <jgoppert> Laney: yeah 1.5
[23:54] <Laney> source package gdal?
[23:54] <jgoppert> well where should i look, i went to ubuntu package search
[23:55] <Laney> launchpad or rmadison
[23:55] <Laney> https://launchpad.net/ubuntu/+source/gdal
[23:56] <Laney> jgoppert: however, there is still transitioning to be done
[23:56] <Laney> see http://people.canonical.com/~ubuntu-archive/NBS/libgdal1-1.5.0
[23:57] <jgoppert> ok, nice, so how do i get it on my karmic ppa, pull the source, then build? Or is there a way to backport  from lucid?
[23:57] <Laney> just upload the source package with a ~ppa0 version suffix
[23:57] <jgoppert> ok thanks
[23:58] <Laney> hang on
[23:58] <Laney> https://edge.launchpad.net/ubuntu/+source/gdal/1.6.2-1
[23:58] <Laney> it didn't build yet
[23:58] <Laney> (due to the hdf stuff you mentioned earlier)
[23:59] <jgoppert> oh, well I guess my quick fix will work for my ppa till they clean it up
[23:59] <Laney> why "they"?
[23:59] <Laney> you could do it..........
[23:59] <geser> and who is "they"?
[23:59] <jgoppert> lol, because i'm trying to get like 6 libraries running to package delta3d, :-)
[23:59] <jgoppert> i've got one person helping me though lol