[00:04] <mok0> jdong: in what way, less painful?
[00:04] <StevenK> I suspect the base tarball isn't one any more
[00:05] <jdong> mok0: the base.tgz is much faster to build
[00:05] <jdong> mok0: I find myself doing pbuilder updates quite frequently so that's greatly appreciated
[00:05] <mok0> jdong: hmm, ok
[00:05] <jdong> and the base.tgz size increased abt from 88->110MB
[00:05] <mok0> jdong: I use cowbuilder, so no tarring or compression
[00:05] <jdong> which is noticeable.. .but not too bad
[00:06] <jdong> mok0: if I had LVM set up on this machine....
[00:06]  * StevenK uses sbuild and LVM snapshots
[00:06]  * mok0 plans to set up sbuild & LVM snapshots at some point
[00:07] <LaserJock> hi mok0
[00:07] <mok0> LaserJock: Hi
[00:08] <LaserJock> I haven't quite been convinced yet that sbuild/LVM is much better than pbuilder
[00:08] <LaserJock> seems like you need an aweful lot of disk space for them
[00:09] <mok0> LaserJock: true, but my machine has so many gigabytes of diskspace I don't really need
[00:10] <LaserJock> so what do you gain though?
[00:11] <mok0> LaserJock: As I understand it, with sbuild you can create your own buildd system, that compiles several archs
[00:11] <LaserJock> and you can't do that with pbuilder?
[00:11] <LaserJock> just wondering
[00:12] <mok0> LaserJock: you can use deb-o-matic
[00:13] <LaserJock> deb-o-matic apparently work with pbuilder as well
[00:13] <RAOF> LaserJock: It's a bit faster than pbuilder, and it's an environment closer to what the buildds use.
[00:13] <mok0> yes that's right
[00:13] <LaserJock> RAOF: right
[00:14] <LaserJock> but they seem fairly comparable
[00:16] <LaserJock> when I reinstalled my system I LVM'd it all so I could try it out, but I haven't had a chance to try yet
[00:16] <LaserJock> I don't have a lotta hard drive space so that was my biggest concern
[00:16] <StevenK> You seemed more content to complain about 64 bit issues instead.
[00:17] <LaserJock> heh
[00:17] <LaserJock> I haven't reinstalled it though, I'm still sticking to 64 bit
[00:18] <LaserJock> I've been learning how to work around the issues
[00:20] <LaserJock> I need to figure out how to get a 64 bit skype 2
[00:20] <LaserJock> that's my latest challenge
[00:23]  * RAOF laughs derisively.
[00:26] <RAOF> Actually, that's unfair.  Skype _would_ be easy for me to set up if ALSA wasn't broken.
[00:28]  * LaserJock cringes at reading people trying to deploy Hardy production school servers
[00:29] <RAOF> LaserJock: http://www.skype.com/go/getskype-linux-beta-dynamic seems to work (modulo ALSA problems) for me.
[00:29] <Fujitsu> I've deployed Hardy to a server.
[00:29] <Fujitsu> Though it isn't doing much at the moment other than rebuilding universe.
[00:29] <RAOF> As have I.  But that's because I'm _insane_.
[00:29] <jdong> LaserJock: I've been shocked by how stable hardy has been throughout development...
[00:29] <Fujitsu> jdong: Indeed.
[00:29] <LaserJock> well
[00:29] <jdong> the hiccups have only been minor so far
[00:30] <jdong> there's that pycentral day :)
[00:30] <Fujitsu> Apart from composite on -intel, it hasn't broken.
[00:30] <Fujitsu> And that, yeah.
[00:30] <jdong> and yeah, intel xv from day to day
[00:30] <LaserJock> I'm not afraid of the desktop stuff in general
[00:30] <Fujitsu> And g-p-m a bit lately, but nothing important.
[00:30] <jdong> my biggest trouble area right now is the newest HAL
[00:30] <jdong> i.e proc->sys batteries
[00:30] <LaserJock> but deploying unfinished software to workaround Gutsy bugs seems doomed
[00:30] <RAOF> Yes.
[00:30] <jdong> sysfs batteries do not update properly for me, so I've personally locked my own patched hal to my macbook right now
[00:31] <Fujitsu> jdong: I have 59 hours until my battery is charged.
[00:31] <RAOF> My battery is discharging on AC :)
[00:32] <emgent> eya people
[00:32] <emgent> 59 O_O
[00:32] <emgent> lol Fujitsu
[00:33] <Fujitsu> I had 63 hours of runtime this morning, too.
[00:33] <jdong> my battery only updates when I /etc/init.d/hal restart
[00:33] <jdong> so I love how I have 98% battery for 4 hours
[00:33] <jdong> then my PMU puts the laptop to sleep.
[00:33] <Fujitsu> Same.
[00:33] <mok0> jdong: Just tested lzop, it's about 2x faster than gzip
[00:33] <jdong> hence why I inverted the patch we chose to apply
[00:34] <Fujitsu> I see the flashing red battery light, and note that I have 100% full...
[00:34] <jdong> mok0: it turns the process from CPU bound to IO bound.
[00:34] <Fujitsu> But then the power history graph shows correct discharge...
[00:34] <mok0> jdong: ok
[00:34] <jdong> Fujitsu: and even worse, g-p-m and laptop mode both apply the wrong power saving settings
[00:34] <jdong> mok0: so the more underpowered your CPU is, the more you'll likely save
[00:35] <mok0> jdong: I have a q6600, not exactly underpowered :-)
[00:37] <jdong> mok0: oh PFFT
[00:37] <jdong> mok0: then you'd almost not benefit from the switch
[00:37] <mok0> jdong: 2x
[00:37] <jdong> mok0: you'd probably want to use p7zip's bzip2 backend
[00:37] <jdong> mok0: which can quad-thread bzip2 from stdin
[00:37] <jdong> that might end up faster on your muscle CPU
[00:37] <mok0> jdong: cool
[00:37] <mok0> lzop doesn't delete the original?
[00:38] <jdong> mok0: lzop is identical in behavior to gzip
[00:38] <mok0> jdong: no
[00:39] <mok0> jdong: not for me
[00:39] <mok0> jdong: it leaves the original as well as the compressed file
[00:39] <jdong> mok0: you're right
[00:40]  * mok0 tries p7zip
[00:40] <mok0> definitely slower
[00:41] <jdong> mok0: are you sure you're multithreading bzip2
[00:41] <mok0> jdong: no :-)
[00:41] <jdong> lemme TRY to recall the cmdline
[00:41] <jdong>  | 7z a -tbzip2 -mx=1 -mmt=on -si test.bz2
[00:42] <jdong> that should be the "business end" of your pipe
[00:42] <jdong> it's definitely gonna be 3-4x faster than standard bzip2, and compress better than it.
[00:42] <mok0> jdong: I am testing on an .iso, it doesn't really compress well
[00:42] <jdong> the question is, is it gonna be faster than lzop.....
[00:43] <jdong> mok0: you should probably test on a gunzipped base.tgz
[00:43] <mok0> jdong: you mean gunzipped base.tgz?
[00:44] <jdong> what did I say?
[00:44] <mok0> jdong: kkk
[00:46] <mok0> 7z: 7.77 secs :-)
[00:46] <mok0> lzop: 2.26 sec
[00:47] <jdong> ok, that's what I expected
[00:47] <jdong> though of course the former would be a lot smaller if it were compressible
[00:47] <mok0> Both compress the image to 81M
[00:48] <mok0> bzip2: 19.9 sec
[00:49] <mok0> 81 Mb
[00:49] <Fujitsu> How long does pbuilder usually take overall? sbuild+LVM gives me <25 second builds on lots of things.
[00:50] <mok0> Fujitsu: it take me 3.9 secs to decompress base.tgz
[00:50] <LaserJock> man, pbuilder used to take slightly over 1 min. on my older laptop
[00:51] <Fujitsu> Not bad.
[00:52] <mok0> I use cowbuilder, which does no unpacking/packing
[00:52] <Fujitsu> We seem to have a lot of failures in universe because of the dh_iconcache/dh_icons migration.
[00:53] <mok0> Fujitsu: what's the problem?
[00:53] <Fujitsu> dh_iconcache doesn't exist any more, so the builds fail.
[00:53] <jdong> Fujitsu: unpacking the base.tgz usually takes me 3-4 secs, cleaning takes another 5 secs or so
[00:53] <mok0> Ah.
[00:53] <jdong> so I'd guess at top 15s overhead
[00:53] <LaserJock> Fujitsu: I thought it was transitioning
[00:54] <Fujitsu> LaserJock: My build results say otherwise.
[00:54] <LaserJock> hmm :/
[00:56] <LaserJock> Fujitsu: do you have any idea how many FTBFS we're looking at?
[00:57] <Fujitsu> LaserJock: Total, or just from that?
[00:57] <LaserJock> just from that
[00:58] <Fujitsu> Still grepping for that.
[00:58] <LaserJock> I guess total would be good to know as well ;-)
[00:58] <Fujitsu> ~500 out of the ~8300 that I've built so far have failed. Some of those won't be legit failures (because I forgot to use P-a-s this time), but most will be.
[00:59] <LaserJock> hmm
[00:59] <LaserJock> that's fairly significant
[00:59] <Fujitsu> Yes.
[01:00] <Fujitsu> About 3000 builds still to go, which should take about 36 hours more.
[01:00] <LaserJock> I wonder if they're biased towards Ubuntu packages or if they're a general problem
[01:01] <TheMuso> Fujitsu: I'm guessing this is related to performing universe rebuilds?
[01:01] <Fujitsu> TheMuso: Correct.
[01:01] <TheMuso> Lovely.
[01:01] <slangasek> LaserJock: defining "Ubuntu packages" how?
[01:02] <LaserJock> slangasek: Ubuntu versioned
[01:02] <slangasek> dh_iconcache was never in Debian, so they'll all be Ubuntu-local bits
[01:02] <jdong> pkgname =~ ubuntu?
[01:02] <LaserJock> slangasek: I was speaking about all FTBFS for that part
[01:02] <slangasek> ah, yes
[01:02] <jdong> is there any way of grabbing the changelog between two vers of packages from launchpad?
[01:02] <jdong> or is hitting up changelogs.ubuntu.com the only way?
[01:02] <slangasek> in that case, I'm sure there are plenty of FTBFS that can be blamed on the Debian maintainers ;)
[01:03] <LaserJock> yeah
[01:03] <LaserJock> we often sync at precisely the wrong time ;-)
[01:04] <slangasek> nah, there's no right time to sync that will avoid the fact that a significant number of packages in Debian unstable are poorly maintained
[01:04] <Fujitsu> Hm, pycentral breakage in a build just a few minutes ago.
[01:05] <Fujitsu> During bzr installation. Is that known?
[01:05] <superm1> what actually happened that initiated this pycentral breakage in so many things?
[01:06] <LaserJock> slangasek: I don't mean sync repo wide, just on a per-package basis
[01:07] <LaserJock> anyway, yeah
[01:08] <slangasek> LaserJock: yes, and some packages sit FTBFS in unstable for longer than an Ubuntu release cycle :)
[01:09] <LaserJock> yeah
[01:09] <jdong> Is there some method other than grep-dctrl that I can use to resolve an arbitrary binary package name to its source package?
[01:09] <LaserJock> it's difficult sometimes because Debian seems to have quite variable levels of maintenance
[01:19] <blueyed> Should a package remove obsolete config files when it gets upgraded? They seem to stay in /etc and get listed as "obsolete" in "dpkg -s".
[01:20] <Fujitsu> Erasing modified configs is a Bad Idea.
[01:20] <blueyed> Fujitsu: sure. But they should get removed when they are unmodified, shouldn't they?
[01:22] <crimsun_> jdong: rmadison?  apt-cache madison?
[01:22] <jdong> crimsun_: really? *checks his sanity*
[01:23] <jdong> crimsun_: rmadison on a binary package name doesn't seem to tell me its source package?
[01:23] <jdong> or am I being retardd?
[01:25] <crimsun_> jdong: ah, it's not reliable, true
[01:25] <crimsun_> jdong: it only shows source if the binary pkg name is also the source pkg name
[01:25] <jdong> right
[01:25] <crimsun_> jdong: ("apt-cache madison" should suffice, though)
[01:25] <jdong> I guess I'll just grab the Source.bz2's
[01:26] <jdong> crimsun_: well that makes assumptions about what's in sources.list
[01:26] <crimsun_> true
[01:26] <jdong> if only launchpad were magical...
[01:32] <crimsun_> jdong: PTS has something of that sort
[01:32] <emgent> heya crimsun_ :)
[01:32] <crimsun_> hey emgent
[02:40] <ScottK> \sh_away: If it's bugfix only, no FFe is needed.  Just file a bug to document what you are doing.
[03:43] <LaserJock> hmm
[03:44]  * LaserJock wonders why git-core in fiesty-backports has a ~dapper1 version and is newer than in gutsy
[03:53] <Hobbsee> hm?
[03:53] <Hobbsee> heh
[04:02] <ScottK> LaserJock: Because it was backported from Hardy to Dapper and then Hardy got a newer one that wouldn't backport cleanly past Gutsy so the Dapper one was forward ported to Edgy/Feisty.  Gutsy backport from Hardy is pending.
[04:02] <ScottK> Clear?
[04:02] <LaserJock> ScottK: kinda
[04:03] <ScottK> It'll all work out right in the end.
[04:03] <ScottK> jdong had it all figured out.
[04:03] <LaserJock> I figured
[04:03] <LaserJock> just made me smile as I was backporting
[04:04] <jdong> lol
[04:04] <jdong> yeah lamont uploaded to dapper initially, then I realized we needed to care for everyone else
[04:04] <jdong> I got a FTBFS of the latest hardy to gutsy which I am investigating
[04:04] <jdong> somehow the test for cvs fails in pbuiler
[04:06] <LaserJock> hmm, I'm  currrently trying it
[04:06] <LaserJock> it takes an insane amount of time doing tests
[04:06] <jdong> LaserJock: one of the final test cases failed with can't cd into cwd, IIRC
[04:07] <LaserJock> hmmpf
[04:07] <ScottK2> jdong: Lucky you to have an interested core-dev that might upload a source backport for you.
[04:07] <jdong> ScottK2: yeah, just have to know what to upload ;-)
[04:12] <TheMuso> hrmf. Since when did pycentral start using /usr/share/pyshared?
[04:12]  * TheMuso had to find that one out by building a damn package by hand.
[04:18] <emgent> hello world
[04:24]  * jscinoz is away: I'm busy
[04:25] <RAOF> jscinoz: Thank you for that useful titdit of information :P
[04:25]  * jscinoz is back (gone 00:00:52)
[04:25] <jscinoz> what happened
[04:25] <jscinoz> didnt know that would go out in every channel
[04:25] <jscinoz> >_<
[04:27] <LaserJock> jdong: well, git-core just finished building for me
[04:27] <jdong> LaserJock: no way
[04:27] <jdong> LaserJock: well why did it fail for me :(
[04:27] <jdong> oh well I'll assume it works
[04:27] <ScottK2> jdong: You don't have that special core-dev touch.
[04:28] <jdong> and get a backport going
[04:28] <LaserJock> heh
[04:28] <jdong> ScottK2: lol
[06:09] <LaserJock> hmm, so the icecast of the local police scanner proved useful tonight
[06:10] <LaserJock> "Powered by Ubuntu" ;-)
[06:26] <AstralJava> LaserJock: Could you elaborate, please? Sounds fascinating. :)
[06:27] <LaserJock> well, somebody in my LUG emailed to say they set up an icecast server on an Ubuntu box to stream from his police scanner
[06:27] <LaserJock> tonight "something" happened in our neighborhood
[06:28] <LaserJock> a helicopter kept circling around
[06:28] <LaserJock> so I thought I'd make use of the stream and see what was up
[06:28] <AstralJava> Oh alright. Nice. :)
[06:28] <LaserJock> I'm still a bit shaky on the details, but something definately when down a couple streets away
[06:29] <AstralJava> Right.
[06:29] <LaserJock> I thought it was an interesting use of Ubuntu :-)
[06:33] <AstralJava> Most definitely. :)
[06:49] <jscinoz> ugh this is maddening
[06:49] <jscinoz> package builds fine with dpkg-buildpackage, but if i debuild -S -sa then use pbuilder it fails
[06:51] <RAOF> jscinoz: Missing build-deps?
[06:52] <jscinoz> none afaik
[06:52] <RAOF> jscinoz: Also, logs make for more useful answers :)
[06:52] <jscinoz> sec il lpatebin
[06:52] <superm1> good evening slomo, you around?
[06:53] <slomo> superm1: yes
[06:53] <jscinoz> RAOF, http://pastebin.com/m28dfdc95
[06:54] <superm1> as we had discussed the other day about that patch related to V4L/V4L2, I scrapped it and made one against gst-plugins-good0.10 that just changes the default
[06:54] <slomo> superm1: sounds better
[06:54] <superm1> I talked to an upstream dev about making the change show up upstream as well, and they're going to consider making it a change there too
[06:54] <warp10> Good morning
[06:54] <RAOF> jscinoz: Your /tmp is out of space?
[06:55] <RAOF> jscinoz: That's likely to be a fair sized package, yes?
[06:55] <slomo> superm1: sounds sane anyway... who did you talk to? :)
[06:55] <jscinoz> yes 750mb
[06:55] <jscinoz> RAOF, shouldnt be, i have 1.4gb free
[06:55] <superm1> slomo, er i'd have to look at my logs at my PC in the office.  gentleman in #gstreamer
[06:56] <superm1> he said they'd decide later though, so just to document it on a bug for now
[06:56] <slomo> superm1: ok, so things are taken care of ;) feel free to patch the ubuntu package for now
[06:56] <superm1> slomo, well it's in main
[06:56] <superm1> so i'd need to get sponsorship on it
[06:56] <slomo> oh
[06:56] <slomo> give me a patch then ;)
[06:57] <superm1> the debdiff on the bug is against debian
[06:57] <superm1> bug 195914
[06:57] <ubotu> Launchpad bug 195914 in ekiga "Ekiga & gstreamer inputs default to outdated V4L, and require to be changed to V4L2" [Undecided,In progress] https://launchpad.net/bugs/195914
[06:57] <slomo> superm1: thanks
[06:57] <jscinoz> RAOF, wait i guess you're right, it is running out of space >_<
[06:57] <slomo> superm1: will care for that later, don't worry :)
[06:58] <superm1> slomo, thanks
[06:58] <jscinoz> is it possible to tell pbuilder to use a different temp dir? i have plenty of room on my home partition
[07:03] <AstralJava> jscinoz: Change the APTCACHE and BUILDRESULT config option in your pbuilderrc, I would think.
[07:04] <jscinoz> thanks
[07:04] <AstralJava> jscinoz: Also BASETGZ and BUILDPLACE config options in the same file come to play.
[07:10] <jscinoz> If i get my package in to debian, will it likely be in ubuntu 8.10?
[07:29] <AstralJava> jscinoz: Most probably, yes, unless you manage to sneak it in within the next few days, and then file a FF exception bug, get it reviewed and accepted within the next two weeks or so. I'm not sure about the dates, but it's getting pretty late for 8.04 cycle anyway.
[07:29] <jscinoz> yeah, i was told it'd be better to go for debian unstable and it would get into intrepid anyway
[07:30] <AstralJava> Yeah, during the Intrepid cycle, it's only a matter of a simple sync request.
[07:34] <jscinoz> arent the debian folk rather tight-arsed about what gets included though?
[07:35] <AstralJava> jscinoz: Heheh. :) I guess one could find a more delicate description. :) To answer your question, I don't really know, I haven't tried to upload anything there, but I've been told they have a good tight QA process, which really is a good thing, mind you. :)
[07:35] <jscinoz> yeah
[07:36] <jscinoz> i have one small licensing issue with my package
[07:36] <jscinoz> a single file is under a non-free license
[07:36] <AstralJava> They're strict about licenses, yes.
[07:36] <jscinoz> the Quake 3 SDK EULA, which permits distribution.
[07:36] <jscinoz> >_<
[07:37] <jscinoz> at the moment i have it display the license preinst, then upon acceptance i have it download this one file which is only 1.2mb
[07:37] <AstralJava> Hmm... I have no experience when it comes to such issues.
[07:37] <AstralJava> Right, well unless the upstream agrees to change the policy and license, I'm afraid that's the only approach possible.
[07:40] <jscinoz> well i'll submit it to mentors and see what feedback i get.
[07:40] <jscinoz> although i'd imagine every quake3 based game has this same issues, and they're still in the repos
[07:41] <jscinoz> this data package takes so darn long to build >_<
[07:47] <jscinoz> finally built now to upload the 800mb package >_<
[07:57] <AstralJava> Ouch. :)
[08:00] <jscinoz> 108kbyte upload speed >_<
[08:00] <jscinoz> dput cant do a diff upload can it?
[08:00] <jscinoz> because i have a feeling the first one is gonna be rejectect and i get to uploda the whole thing again >_<
[08:08] <slomo> superm1: uploaded
[08:08] <slomo> superm1: will take the patch to debian too and upload after the previous version went to testing
[08:13] <HighNo> Hi everyone. Is updating a package to a new upstream version a feature freeze exception? and if so how can new upstream versions be included into hardy at all? Or do they only go into intrepid and have to be backported?
[08:14] <nixternal> HighNo: yes. if it fixes bugs, doesn't include new api/abi changes, then filing a feature freeze exception should be easy
[08:15] <nixternal> if it is major changes, then it may be a bit more difficult for it to get included
[08:17] <HighNo> ok, it would be a major update...
[08:19] <nixternal> morning dholbach
[08:19] <dholbach> good morning
[08:19] <dholbach> hey nixternal
[08:25] <\sh> moins
[08:25] <Hobbsee> morning
[08:25] <\sh> who can I bug about UbuntuWeeklyNews?
[08:25] <\sh> Message from Zend: http://andigutmans.blogspot.com/2008/02/zend-framework-to-be-part-of-ubuntu.html
[08:26] <dholbach> \sh: just edit the wiki page :)
[08:28] <\sh> dholbach: this one? https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Ideas <--- looks a bit outdated ;)
[08:28] <HighNo> nixternal: so what about if I want to integrate the new version with hardy and most likely without a ffe?
[08:28] <\sh> oh no...there is something else
[08:28] <dholbach> The next Ubuntu Weekly Newsletter, Issue #80 is due to be released on March 1st 2008.
[08:29] <dholbach> https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue80
[08:29] <dholbach> \sh: ^
[08:29] <\sh> dholbach: yeah found it :)
[09:20] <HighNo> anybody - what is the exact process of releasing a new version of a package already included in hardy - if that new version only has functionality, not bugfixes? Am I getting this right - it is typically not wanted unless using the backport project?
[09:24] <cody-somerville> HighNo, Are you looking to get the new version into Hardy or into an already released version of Ubuntu?
[09:29] <HighNo> cody-somerville: Hardy at this time - though the new version will be released next week
[09:29] <cody-somerville> HighNo, The feature freeze has already passed for Hardy. If you want to upload a new version to Hardy, you'll need to file for an exception.
[09:30] <cody-somerville> HighNo, See https://wiki.ubuntu.com/FreezeExceptionProcess
[09:31] <cody-somerville> HighNo, What package are you thinking of?
[09:32] <pwnguin> neat. someone finally wrote some colorblind simulations for colorfilter
[09:35] <HighNo> cody-somerville: blueproximity
[09:37] <cody-somerville> HighNo, interesting package.
[09:38] <cody-somerville> HighNo, What is the upstream URL?
[09:39] <HighNo> cody-somerville: I am the upstream author and doing some major feature enhancements these days. The version that made it into hardy is very stable and works great but has limited functionality. I was mainly asking to know what to do after I completed those changes and did the testing. If there are ways to get the package with the new funcionality in hardy. (which also implies feisty and gutsy as backporting takes place)
[09:39] <HighNo> cody-somerville: http://blueproximity.sf.net
[09:39] <cody-somerville> HighNo, Is there a risk of regression? How big is the update?
[09:40] <HighNo> anyone: It is ok for MOTUs to accept a package with very low build deps (like debhelper 5). It would make backporting of my package very easy (that is no change at all)
[09:41] <HighNo> cody-somerville: could you explain regression?
[09:42] <cody-somerville> HighNo, Is there a big risk that the package will stop working where it would work before? ie. The risk of regression would be greater if the amount of changes you've made since the last upload is larger than what some might consider "minor"/.
[09:43] <cody-somerville> HighNo, Once you've made the next release, you can make yourself (or ask someone else) to file a Ubuntu Freeze Exception to see if you can get approval to upload your new version. As I already pointed out, the procedure is detailed at https://wiki.ubuntu.com/FreezeExceptionProcess
[09:44] <HighNo> cody-somerville: ahh, ok, no danger of regression then
[09:45] <cody-somerville> HighNo, Okay. Well, once you've made the release, feel free to e-mail me if you need help filing for a freeze exception.
[09:47] <HighNo> cody-somerville: that sounds great
[09:47] <cody-somerville> HighNo, Do you need my e-mail address or will you be able to find it?
[09:47] <HighNo> cody-somerville:  until when can new versions be introduced?
[09:48] <cody-somerville> HighNo, Technically, new versions may not be introduced with an exception approved by the motu release team. The closer we get to the release date, the harder it will be to get approval.
[09:48] <cody-somerville> HighNo, If with the exception request, you could prove that you've tested it for regressions, I'm sure you'll have an easier time getting approval.
[09:50] <cody-somerville> HighNo, OooOoo... I'm just looking at the release schedule now. I dunno how easy it will be able for you to get an exception. The UserIterface freeze passed on the 28th.
[09:51] <cody-somerville> HighNo, If we can't get your new version into the official hardy repository, we can always put it in a PPA :)
[09:51] <cody-somerville> HighNo, And that'll mean it'll be all ready for a quick upload once the repository for the next version (intrepid) opens in a few months.
[09:53] <cody-somerville> HighNo, Do you know what a PPA is?
[09:56] <HighNo> cody-somerville: sorry, have been afk
[09:57] <HighNo> cody-somerville: I've hear of PPA but have not used it until now
[09:58] <cody-somerville> HighNo, It is a personal package archive. It allows you to host debian packages on launchpad easily :)
[09:59] <HighNo> cody-somerville: I'd like to involve launchpad a bit more into development but don't know how. Are You used to that?
[09:59] <cody-somerville> I am.
[09:59] <HighNo> whoohoo
[09:59] <cody-somerville> I'll continue this conversation with you in a private query.
[10:00] <HighNo> ok
[11:11] <proppy> oy
[11:43] <dholbach> soren, geser, nixternal, persia: I won't be able to make it to the MOTU Meeting today (just as a heads-up) - need to prepare some stuff for next week :/
[11:45] <Hobbsee> oh, there's a meeting?
[11:45] <Hobbsee> goody
[11:57] <Iulian> Hi
[12:09] <sistpoty|work> motu meeting in #ubuntu-meeting now
[12:44] <RainCT> Heya
[13:15] <txwikinger> moo
[13:28] <mok0> persia, about the logo, you can see it in https://help.ubuntu.com/community/UbuntuScience
[13:28] <persia> mok0: Ah.  I'm in agreement with you then :)
[13:28] <DaveMorris> I've created a bug, assigned a debdiff for a package thats been included in hardy, and assigned USU to it.  What else do I need to do to get it built and released?
[13:30] <mok0> DaveMorris: you've created a bug? ;-)
[13:30] <DaveMorris> technically I did, I left off some dependencies in the package I created :)
[13:31] <mok0> DaveMorris: The procedure seems correct
[13:31] <DaveMorris> so just a matter of time till it's build, or do I need to change teh status as well?
[13:31] <mok0> DaveMorris: Status = confirmed
[13:31]  * RainCT supposes that DaveMorris means u-u-s and not u-s-u
[13:32] <DaveMorris> Ubuntu sponsors for universe is who I subscribed
[13:32] <RainCT> ok then :)
[13:32]  * mok0 's head just exploded
[13:32] <RainCT> rofl
[13:33]  * RainCT puts mok0 head back together with some glue ;)
[13:33]  * mok0 hugs RainCT
[13:34]  * RainCT hugs mok0 back :)
[13:34] <mok0> DaveMorris: If you click on the Ubuntu Sponsors for Universe string in LP, you can see that your package now appears on their list
[13:35] <emgent> heya
[13:35] <DaveMorris> yeah, I noticed I had only subscribed them, not assigned it to them
[13:35] <RainCT> Hi emgent
[13:35] <mok0> DaveMorris: I don't think you should assign it to them,
[13:35] <mok0> but to yourself, showing that you take responsibility for it
[13:36]  * DaveMorris needs to sort out some backports of the package yet
[13:36] <RainCT> actually, I think it shouldn't be assigned to anybody (so that the reviewer can assing it to himself) :P
[13:36] <RainCT> which bug is it, btw?
[13:36] <DaveMorris> #195433
[13:36] <mok0> RainCT: Ah, is that how it works?
[13:37] <mok0> bug 195433
[13:37] <ubotu> Launchpad bug 195433 in opensg "libopensg-core-dev is missing dependices which are called on in the pkg-config file" [Undecided,Confirmed] https://launchpad.net/bugs/195433
[13:37] <soc> hi
[13:37] <soc> can someone help me?
[13:37] <soc> i worked on bug https://bugs.launchpad.net/ubuntu/+source/blogtk/+bug/196813
[13:37] <ubotu> Launchpad bug 196813 in blogtk "BloGTK doesn't work with Python 2.5 (IOError: unsupported XML-RPC protocol)" [Undecided,New]
[13:37] <soc> and found the fix
[13:38] <soc> i contacted the upstream developer and asked him to include it in a new upstream version
[13:38] <soc> hope that was right?
[13:38] <mok0> RainCT: I am constantly confused by what you are supposed to and not supposed to in LP.
[13:38] <soc> when a new version gets released how can i sync it in ubuntu?
[13:38] <mok0> RainCT: ... and the rules tend to change ever so often
[13:39] <RainCT> soc: yes, contacting upstream is always right :)
[13:40] <RainCT> soc: now what would be good to do (unless the next upstream version is a bugfix only release) is to include the fix in the version that is currently in Ubuntu
[13:40] <RainCT> (s/Ubuntu/Hardy)
[13:40] <RainCT> mok0: heh
[13:40] <soc> RainCT: how can i do that?
[13:41] <RainCT> mok0: I also find them somewhat confusing :).
[13:41] <soc> imo the fix would be very useful because it fixes a) a crasher b) makes BloGTK run with Python 2.5, so the dependency on Python 2.4 can be dropped ...
[13:42] <RainCT> soc: do you have the hardy source repository enabled?
[13:42] <soc> yes
[13:43] <RainCT> mok0: and the answer to your question is yes (well, at least there are some sponsors doing so)
[13:43] <soc> i downloaded the orig.tar.gz and the diff.gz now
[13:43] <RainCT> mok0: it's allways good to subscribe yourself when reviewing something so that other sponsors don't duplicate the work
[13:43] <soc> in my opinion in the diff all the lines with "-#!/usr/bin/env python
[13:43] <soc> +#!/usr/bin/env python2.4"
[13:43] <soc> have to be changed back ...
[13:44] <RainCT> soc: okay. you'll need also the .dsc, and then run:   dpkg-source -x *.dsc   to get an uncompressed directory
[13:44] <soc> but just deleting deleting is not the right to do i gess :-)
[13:44] <soc> ok
[13:44] <mok0> RainCT: Ok, I understand
[13:45] <mok0> RainCT: But subscribing is different than "assigned to"
[13:45] <LucidFox> What should be the version number for a fakesync?
[13:45] <soc> ok, did it ...
[13:46] <RainCT> mok0: Yes. Subscriber's get bug mail (and in the case of u-u-s, the bug is listed in their "bugs the group is subscribed to" list..)
[13:46] <soc> do i have to manually change #!/usr/bin/env python2.4 to #!/usr/bin/env python or is there a way to revert that change?
[13:46] <RainCT> mok0: the Assigner field is to say who is working on the bug, and usualy a field with someone assigned shouldn't be touched (unless he is asking for information on his last message or something, then you should answer if you can :))
[13:47] <RainCT> soc: let me have a look at the source.. :)
[13:47]  * jdong half-loses temper at bug reporters
[13:48] <HighNo> soc: I believe that there should be #!/usr/bin/python and no env anymore
[13:48] <soc> ok
[13:48] <jdong> "Why don't you just upload the package without the launcher and break all the launcher icons? I need this bugfix on hardy NOW"
[13:48] <jdong> *grumble*
[13:48] <Hobbsee> haha
[13:48] <HighNo> hehe
[13:48] <Hobbsee> sounds like a $clueless_user
[13:48] <Hobbsee> apply $lart
[13:48]  * HighNo pours in another cup of coffee for jdong
[13:49] <jdong> HighNo: thanks
[13:49] <soc> RainCT: the last change was basically setting the py interpreter to a fixed version
[13:49]  * Hobbsee takes away the accompanying crack pipe
[13:49] <jdong> Hobbsee: what's even more... he used a *homemade deb* as a threat :D
[13:49] <Hobbsee> haha
[13:49] <HighNo> hehe
[13:50] <HighNo> and he didn't ask for archive upload rights?
[13:50] <jdong> https://bugs.launchpad.net/ubuntu/+source/ktorrent-kde4/+bug/192812/comments/20
[13:50] <ubotu> Launchpad bug 192812 in ktorrent-kde4 "[FF exception] New upstream release ktorrent-kde4 3.0.0 " [Wishlist,Confirmed]
[13:50]  * jdong cries a bit
[13:50] <RainCT> haha
[13:50] <HighNo> hehe, hey at least 'he doesn't want to sound rude'
[13:51] <Hobbsee> silly users.
[13:51] <Hobbsee> remind them about hte idea of patience
[13:51] <RainCT> HighNo: hm.. are you sure? /usr/bin/env allows the user to specify a custom version
[13:51] <jdong> HighNo: whenever a statement is prefixed by that, it almost ALWAYS tends to have the opposite effect
[13:51] <HighNo> jdong: hehe, I know :-)
[13:51] <jdong> Hobbsee: I almost want to reply back "Well if I do that, don't ever expect me to get a feature freeze exception approved again for the next 2 decades"
[13:51] <Hobbsee> haha
[13:52] <Hobbsee> it's not like you would anyway.  you're jdong.
[13:52] <HighNo> RainCT: that's what the MOTUs have told me to change in my package, telling me the env style is 'outdated'
[13:53] <RainCT> HighNo: oh, will have to check this then.
[13:54] <soc> RainCT: still here?
[13:54] <RainCT> soc: yes, 1 moment
[13:54] <jdong> kinit -R
[13:54] <jdong> grumble
[13:54] <soc> afaik /usr/bin/env selects the _first_ python interpreter in the path
[13:54] <jdong> soc: that's correct
[13:54] <soc> i guess this is useful if you develop something, where you have different versions installed
[13:55] <jdong> soc: it's also useful when deploying software to platforms with inconsistent python locations
[13:55] <soc> but for software release /usr/bin/python should be used, because it uses the _system_ interpreter
[13:55] <jdong> i.e. I'm doing that for MIT's intro EECS packages because we must deploy to the network cluster, personal debian/ubuntu, solaris.... etc
[13:55] <soc> so software behaviour doesn't change if you install another python interpreter
[13:55] <RainCT> soc: the change to "python2.4" was done by upstream?
[13:55] <soc> yes
[13:55] <jdong> but for an Ubuntu.Debian package, you should use /usr/bin/python*
[13:56] <jdong> because by policy they are fixed to that location anyway
[13:56] <jdong> and you'd rather NOT get bugreports from people who decided to run it with some other python interpretor in their path
[13:56] <soc> because py2.5 was more strict in some XML-RPC things which made BloGTK crash
[13:56] <RainCT> jdong: and packages should be patched to use usr/bin?
[13:56] <soc> so i think the one before me thought "well, then just use pyx 2.4"
[13:56] <jdong> RainCT: I would personally be inclined to do so
[13:56] <soc> ^py 2.4
[13:57] <RainCT> soc: heh. and you have a patch for those crashes now?
[13:57] <jdong> RainCT: either via gigantic patch or via some sort of make rule in the install target...
[13:57] <soc> i would now make my changes to source ...
[13:57] <soc> yes
[13:57] <RainCT> jdong: I usualy prefer sed in debian/rules for such things :)
[13:57] <soc> my patch verifies that the uri starts with http:// or https://
[13:57] <jdong> RainCT: but big patches are fun ;-)
[13:57] <RainCT> lol
[13:58] <soc> if it not starts, BloGTK will crash on Python 2.5
[13:58] <soc> because Py 2.5 _requires_ http:// or https://, Python 2.4 didn't do that
[13:58]  * jdong tries his newly built ktorrent-kde4
[13:58] <soc> RainCT: i would now make my changes ok?
[13:58] <RainCT> soc: okay. you can do those changes on the source directly here, as the package isn't using any patch system
[13:59] <soc> and then could you tell me how they get into the diff?
[13:59] <soc> or can i just change the last patch?
[13:59] <RainCT> soc: (if it was using one you'd have to create a patch using that system; you can see what patch system is being used by running "what-patch" in the source directory, if you have ubuntu-dev-tools installed)
[13:59] <RainCT> soc: run:  debuild -S
[14:00] <soc> RainCT: before or after my changes?
[14:00] <Amaranth> after
[14:00] <RainCT> soc: after doing your changes and adding a new changelog entry (with "dch -D hardy -i")
[14:00] <soc> ok
[14:00] <soc> can i modify things in the diff?
[14:01] <bobbo> What is the current DH_COMPAT level to use?
[14:01] <RainCT> soc: then cd to the previous directory (where you have the .dsc, .diff.gz and .orig.gz) and run: debdiff <old version>.dsc <new version.dsc> > <new version>.debdiff
[14:01] <Hobbsee> 6
[14:01] <RainCT> bobbo: 4-6
[14:01] <soc> ok
[14:01] <bobbo> Hobbsee, RainCT; thanks
[14:02]  * RainCT prefers the lowest one which isn't deprecated (unless newer features are needed) as it makes backports easier
[14:03]  * HighNo applaudes to RainCT
[14:03] <RainCT> soc: (where <old version> is is blogtk_1.1-2build1, and <new version> blogtk_1.1-2ubuntu1)
[14:03] <soc> ah ok
[14:03]  * RainCT hugs HighNo 
[14:04]  * HighNo feels warm enough, you can let go now :-)
[14:04]  * RainCT unhugs HighNo heh
[14:05] <jdong> vorian: ok I see the problem with ktorrent-kde4
[14:05] <jdong> rather, it's one of those "it's a transition not a bug" things.
[14:05] <HighNo> I always if these jokes only cost precious time one could really spend much more useful or if one does productivity will be lower since you're not motivated...
[14:05] <RainCT> soc: and debdiff will then create a diff from the version that is currently in Hardy to your new one
[14:05] <HighNo> +wonder
[14:05] <jdong> vorian: the /usr/bin/ktorrent-kde4 launcher is nixed, the desktop file just explicitly calls the kde4 version
[14:06] <soc> mhhhh
[14:06] <jdong> Exec=/usr/lib/kde4/bin/ktorrent %i -caption "%c" %u
[14:06] <jdong> anyone think that'll actually work?
[14:06] <soc> RainCT: i'm currently on a gutsy system, but have the hardy package (which is imo the same as the gutsy one)
[14:06] <jdong> we don't need to set any PATHs to contain KDE4?
[14:06] <soc> is that a problem?
[14:07] <soc> how can i drop the dependency on python 2.4?
[14:07] <RainCT> soc: no, same here :)
[14:07] <soc> ok, good
[14:07] <RainCT> soc: the dependency will change automatically
[14:07] <soc> ah, ok
[14:08] <soc> fantastic :-P
[14:08]  * RainCT wonders if HighNo wouldn't be more productive if he wondered less and spend more time working instead
[14:08] <RainCT> :D
[14:08] <soc> sorry, closed the window ...
[14:08] <soc> ok
[14:08] <tonio> hi there
[14:08] <soc> so now i do: dch -D hardy -i
[14:08] <tonio> I'm attempting to package a gnome application, and I must say I'm a bit embarassed with gnome build-deps
[14:08] <soc> then debuild -S?
[14:08] <Hobbsee> RainCT: as everyone knows, the most effective thing to do is whing :P
[14:08] <tonio> for kde, kdelibs4-dev does the trick
[14:09] <tonio> isn't there a gnome-libs meta package for development files ?
[14:09] <jdong> Hobbsee: do you use KDE4? :)
[14:09] <Hobbsee> sometimes
[14:09] <RainCT> soc: yes. dch will open a nano window where you have to explain what you changes (look at the previous entries for reference), and also ensure that the version number is right
[14:09] <jdong> Hobbsee: do you know if a .desktop file just runs /usr/lib/kde4/bin/some_app, whether or not that'll work?
[14:09] <Hobbsee> no idea
[14:10] <soc> ah ok
[14:10] <soc> i see it
[14:10] <jdong> Hobbsee: I thought several environment variables had to be augmented for KDE4 apps to launch
[14:10] <soc> it now says hardy in the changelog
[14:10] <soc> is that a problem for gutsy?
[14:10] <jdong> soc: if you're uploading it into Ubuntu, yes. If you are doing something locally, no.
[14:10] <soc> mhh
[14:11] <RainCT> soc: no, it should say Hardy
[14:11] <soc> i would prefer that the change would get into gutsy and hardy ...
[14:11] <jdong> soc: first, fix it in Hardy
[14:11] <soc> ok
[14:11] <RainCT> soc: you'll have to request a SRU then once it's fixed in Hardy
[14:11] <jdong> soc: the process of fixing it in Gutsy is slightly different (StableReleaseUpdates on the wiki)
[14:11] <soc> ah ok
[14:11] <soc> mhh
[14:11] <soc> my emailadress says "doko@ubuntu.com" is that right?
[14:12] <RainCT> Hobbsee: uhm.. whing isn't in the dictionary :D
[14:12] <Hobbsee> er, whining
[14:12]  * Hobbsee probes RainCT with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! ™
[14:12] <RainCT> soc: in the changelog?
[14:13] <soc> yes
[14:13] <jdong> soc: lol I'm not sure doko_ would be happy with that ;-)
[14:14] <RainCT> soc: you've a bad global variable then
[14:14] <soc> last version was 1.1-2build1, should the new version now be 1.1-2ubuntu0?
[14:14] <soc> should i change it to my adress?
[14:14] <RainCT> soc: ubuntu1
[14:14] <soc> ok good
[14:14] <RainCT> soc: what does "echo $DEBEMAIL" say?
[14:15] <soc> nothing
[14:15] <RainCT> soc: ok, do you have a GPG key?
[14:15] <soc> yes
[14:15] <RainCT> soc: then open ~/.bashrc and at the end add:
[14:16] <RainCT> soc:  export DEBFULLNAME="Your Name (and key comment)"
[14:16] <RainCT> soc:  export DEBEMAIL="your@email"
[14:16] <soc> what's key comment?
[14:17] <RainCT> soc: if you run "gpg --list-secret-keys", do you have (something) after your name?
[14:17] <soc> i have 3 entries ...
[14:17] <soc> 2 mail adresses, one jabber
[14:17] <RainCT> soc: look at that one you have on Launchpad and which you want to use for Ubuntu development
[14:18] <soc> should i choose the email adress from my launchpad account?
[14:18] <soc> ok
[14:18] <RainCT> soc: DEBFULLNAME should be your name exactly like it's listed there (but without the email)
[14:18] <soc> ahh ... ok
[14:19] <RainCT> soc: dch should get it right then. and yes, for now change the email in the changelog (and also the name if it got it wrong too)
[14:19] <soc> so, i should run dch again now?
[14:19] <protonchris> I submitted a FFE.  It was ack'ed twice, approved and marked as confimed.  Do I need to do anyting else other than wait?
[14:20] <RainCT> soc: either change it manually or close nano without saving (ctrl+x n) and run it again then
[14:20] <soc> ok
[14:20] <Amaranth> protonchris: us uus subscribed?
[14:20] <Amaranth> err, is
[14:20] <soc> guess i have to restart gnome-terminal too?
[14:21] <RainCT> soc: eh, yes (or at least get into a new tab).
[14:21] <protonchris> Both uus and MOTU Release team
[14:21] <soc> :-)
[14:21] <RainCT> protonchris: then yes, just wait :)
[14:21] <protonchris> Cool.  Thanks.
[14:21] <soc> know it looks right!
[14:21] <soc> now^
[14:21] <protonchris> I just wanted to make sure I wasn't the hold up :)
[14:22] <soc> parsechangelog/debian: error: badly formatted heading line, at file debian/changelog line 5
[14:22] <soc> dch: fatal error at line 1166:
[14:22] <soc> Problem executing dpkg-parsechangelog:
[14:22] <soc> mhhh
[14:23] <RainCT> soc: copy the changelog to http://paste.ubuntu.com
[14:23] <soc> ok, fixed it ...
[14:23] <RainCT> (or any other site you prefer)
[14:23] <soc> looks like i have to manually align the enumerations ... :-)
[14:23] <soc> *sigh*
[14:23] <RainCT> soc: you can also edit the file with any other text editor
[14:24] <RainCT> soc: geany for example gets the align right automatically (and most other graphical editors probably too) :)
[14:24] <soc> ok
[14:24] <soc> works now
[14:24] <RainCT> soc: just save (Ctrl+O) the document in nano after it shows up and then you can edit it with what you want ;)
[14:25] <soc> i exited nano now ... dch is now finished, right?
[14:25] <RainCT> yes
[14:25] <soc> ok
[14:25] <soc> now debuild -S?
[14:25] <RainCT> right
[14:26] <soc> *sigh* pgp passphrase ....
[14:26]  * RainCT wonders if he is spamming the channel and #ubuntu-classroom would have been better.. :P
[14:26] <soc> ah now ...
[14:26] <soc> ok
[14:26] <soc> ok, signed that now
[14:26] <RainCT> soc: cool, now the debdiff thing
[14:28] <soc> debdiff blogtk_1.1-2build1.dsc blogtk_1.1-2ubuntu1.dsc ????????.debdiff
[14:28]  * RainCT also wonders why he always forgets something when he mentors someone :P
[14:28] <soc> what name should debdiff have?
[14:28] <Hobbsee> packagename.debdiff
[14:28] <RainCT> soc: blogtk_1.1-2ubuntu1.debdiff, and there's a > missing before it
[14:29] <soc> debdiff blogtk_1.1-2build1.dsc blogtk_1.1-2ubuntu1.dsc > blogtk_1.1-2ubuntu1.debdiff
[14:29] <soc> like this?
[14:29] <RainCT> yes
[14:29] <soc> great!
[14:29] <sistpoty|work> persia: thanks for hosting the meeting, and sorry again that I had to leave
[14:29] <RainCT> soc: does the debdiff look good?
[14:30] <soc> Warning: You do not seem to have interdiff (in the patchutils package)
[14:30] <soc> installed; this program would use it if it were available.
[14:30] <soc> gpg: Signatur am Mo 15 Jan 2007 18:58:57 CET mit DSA Schlüssel, ID 0F932C9C, erfolgt
[14:30] <soc> gpg: Unterschrift kann nicht geprüft werden: Öffentlicher Schlüssel nicht gefunden
[14:30] <Hobbsee> install patchutils then
[14:30] <RainCT> soc: install interdiff and ignore the gpg warning
[14:30]  * persia catches up on backscroll, references https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue, and notes that it doesn't appear to change very often (or at least in short bursts).
[14:30] <soc> ok
[14:30] <soc> now it works
[14:30] <RainCT> s/interdiff/patchutils
[14:30] <Hobbsee> RainCT: no, patchutils
[14:30] <Hobbsee> yes :)
[14:30] <RainCT> Hobbsee: yes, thanks :)
[14:30] <soc> RainCT: the GPG warning is gone now too
[14:30] <persia> sistpoty|work: Happy to.  I hope you don't disagree with any of the agreements after you had to run.
[14:31] <soc> ater installing patchutils
[14:31] <RainCT> cool
[14:31] <sistpoty|work> persia: no, I think it was a very productive meeting :)
[14:31] <soc> good
[14:31] <soc> now i have the debdiff
[14:31] <RainCT> soc: okay, now you can create a new one because I forgot something :$
[14:31] <persia> sistpoty|work: I generally find 12:00 UTC meetings the most productive, and sometimes wonder why we have them at different times (aside from fairness).
[14:31] <RainCT> eh, I mean because I didn't explain something yet so that you create it twice and get more practice :D
[14:32] <soc> ok :-)
[14:32] <soc> no problem :-)
[14:32] <RainCT> soc: get back into the source directory, open debian/control and look at the "Maintainer: ..." line there
[14:33] <RainCT> soc: then run update-maintainer (you'll need package ubuntu-dev-tools for that) and notice what changed in debian/control and debian/changelog :)
[14:36] <soc> "You don't have hardy in your source repos."
[14:37] <soc> nothing changed ....
[14:37] <bobbo> Debdiff up for Bug #196870 if anyone has some spare time
[14:37] <ubotu> Launchpad bug 196870 in gpppon "No .desktop file for gpppon" [Undecided,Confirmed] https://launchpad.net/bugs/196870
[14:37] <RainCT> soc: do you have hardy in your source repos?
[14:38] <RainCT> (try "update-maintainer --section=universe" for now)
[14:38] <persia> RainCT: Do you happen to have a plan for chromium?  I've just noticed it FTBFS (although we've still working gutsy binaries)
[14:38] <persia> (update-maintainer issues seem to be the source of the FTBFS)
[14:38]  * RainCT doesn't understand persia's last sentence :S
[14:39] <persia> http://builder.ubuntuwire.qeuni.net:9998/job/7936
[14:40] <RainCT> persia: (about the first questio,) not really. I want to look at the package in debian-games' SVN (and apply our patches there if they aren't in Debian yet), but that's all. I still can't any C/C++ :(
[14:41] <RainCT> oh
[14:41] <persia> RainCT: It's just a packaging issue.  If the C++ really FTBFS, bug me about it.
[14:42] <RainCT> persia: yes I see. I'll fix it now then
[14:42] <persia> Also, I think the new sound files were put in SVN recently, and it might be nice to use them (as they are free, unlike the current sound)
[14:42] <persia> If I'm wrong, it's worth pinging to see if they can be added (they should be ready soon, if not already, and a weekend is coming up)
[14:43] <RainCT> persia: if so what do you thing about bugging some DD in debian-games to release it and then syncing?
[14:44] <persia> RainCT: That works too, but I think D-G is waiting for the new upstream, so I suspect that to be unlikely.
[14:45] <RainCT> persia: ah yes I got some email about that. is there already one or you mean they are waiting until there's one before releasing anything?
[14:45]  * RainCT wonders if soc is still there
[14:46] <RainCT> btw, does artwork freeze apply to universe?
[14:46] <soc> sorry
[14:46] <soc> just made a soup
[14:46] <soc> no, no hardy
[14:46] <soc> i'm running gutsy
[14:46] <RainCT> heh no problem :)
[14:46] <RainCT> soc: yes, but you can still have a deb-src line in /etc/apt/sources.list
[14:47] <soc> "Maintainer changed to Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>"
[14:47] <persia> Yes.  Artwork Freeze / Doc Freeze applies everywhere.  As with any other freeze, if you've a good reason, ask motu-release (but first, have a good reason)
[14:47] <soc> no, i downloaded the hardy package manually
[14:48] <RainCT> soc: if you plan to contribute more often, I recommend adding "deb-src http://archive.ubuntu.com/ubuntu/ hardy main restricted universe multiverse" there so that you can get the sources with "apt-get source package-name" and have a working update-maintainer
[14:48] <persia> Either that, or create a chroot tracking the development version, and do package updates from the chroot.
[14:50] <soc> ah ok
[14:50] <soc> i guess i'll have to decide where i do my developing in the future ...
[14:51] <RainCT> soc: well lets continue.. that change is something you always have to do when you change a package for Ubuntu (it's needed because of https://wiki.ubuntu.com/DebianMaintainerField, if you are interested)
[14:51] <soc> on my laptop with hardy it would be easier ... but my gutsy desktop has a brandnew 24" tft :-P
[14:51] <soc> yes, i know that ...
[14:51] <RainCT> soc: ok, so now you can create the new debdiff ( debuild -S; !debdiff)
[14:51] <RainCT> ok :)
[14:52] <soc> debdiff: fatal error at line 260:
[14:52] <soc> Can't read file: blogtk_1.1-2build1.dsc
[14:52] <RainCT> soc: oops, cd .. first :)
[14:52] <soc> could it be that i have to change dirs between debuild and debdiff?
[14:52] <soc> ok
[14:53] <RainCT> soc: ok, now just check that the debdiff only has the changes that you did (you'll see that sometimes you find strange stuff there), and then attach it to your bug report
[14:54] <soc> mhhh
[14:54] <soc> how do you know that -Maintainer: Diego Andres Sanabria (diegueus9) <diegueus9@gmail.com> is a debian dev and not an ubuntu dev?
[14:54] <RainCT> soc: use "apt-cache madison blogtk" to check that the package is in universe, and then subscribe ubuntu-universe-sponsors to the bug (or in this case, better just give me the URL)
[14:55] <RainCT> soc: because of the version number in his changelog entries
[14:55] <RainCT> soc: but this change is done always anyway
[14:55] <soc> ah ok
[14:55] <soc> mhhh
[14:55] <soc> mhhh
[14:55] <soc> beneth my changes there is something else:
[14:56] <soc> http://ubuntuusers.de/paste/53106/
[14:56] <soc> is that a problem?
[14:56] <RainCT> soc: only Ubuntu Developers (with @ubuntu.com) can decide to leave themselves as the Maintainer in packages they create if they want
[14:57]  * soc thinks that having an @ubuntu.com email adress would look veeeeery cool :-P
[14:57] <soc> but i guess that will take some years :-P
[14:57] <RainCT> soc: heh :D. not really.
[14:58] <soc> isn't it only for canonicals employees?
[14:58] <soc>  isn't it only for cannonical's employees?
[14:58] <persia> soc: Only for Ubuntu members.  Typically takes 3-6 months of solid, linkable contributions to get Membership.  Of course, you ought keep the contributions up at that point :)
[14:58] <soc> ah ok ...
[14:59] <RainCT> soc: no, Canonical guys have @canonical.com; the have to go through the Community Council (or some other Ubuntu council) to get an @ubuntu.com, too
[14:59] <soc> but back to topic ...
[14:59] <RainCT> s/the/they
[14:59] <soc> is that thing http://ubuntuusers.de/paste/53106/ ok?
[14:59] <soc> the last entry looks a bit weird
[15:00] <RainCT> soc: which one?
[15:00] <soc> that one after: blogtk (1.1-2build1) feisty; urgency=low
[15:01] <soc> "only in patch2:
[15:01] <soc> unchanged:"
[15:01] <RainCT> looks strange :S
[15:02] <sistpoty|work> tjaalton: can you attach diffstat/upstream changelog diff to bug #196073 please?
[15:02] <ubotu> Launchpad bug 196073 in libpciaccess "Please sync from libpciaccess from Debian unstable" [Wishlist,Incomplete] https://launchpad.net/bugs/196073
[15:02] <RainCT> patching file src/spellcheck.py
[15:02] <RainCT> patch unexpectedly ends in middle of line
[15:03] <RainCT> Hunk #1 succeeded at 1 with fuzz 1
[15:07] <RainCT> soc: strange.. try rm blogtk_1.1-2ubuntu1*; cd blogtk-1.1/; debuild -S; cd ..; !debdiff
[15:07] <soc> ok
[15:07] <soc> mhh
[15:07] <soc> the same
[15:08] <persia> Anyone interested in a possible security SRU combined with some date checking code?  Bug #196854 seems to cover a few interesting issues.
[15:08] <ubotu> Launchpad bug 196854 in fail2ban "fail2ban doesn't handle leap years" [Undecided,New] https://launchpad.net/bugs/196854
[15:08] <persia> Err s/security SRU/security\/SRU/
[15:09] <soc> http://ubuntuusers.de/paste/53108/
[15:11] <RainCT> soc: that was intending to be run in ~/build/BloGTK
[15:11]  * RainCT wonders how many computers soc has (desktop07..) :P
[15:12]  * RainCT wonders why he is wondering that much today
[15:14]  * DktrKranz wonders about RainCT wonderings
[15:14] <RainCT> debdiff blogtk_1.1-2build1.dsc blogtk_1.1-2ubuntu1.dsc > blogtk_1.1-2ubuntu1.debdiff
[15:15] <RainCT> (oops, sorry)
[15:15] <RainCT> soc: hm.. I get the same thing here
[15:17] <RainCT> soc: well, if you fix the patch manually it works
[15:17] <soc> how?
[15:18] <RainCT> soc: http://paste.ubuntu.com/5141/
[15:20] <soc> mhhh
[15:20] <soc> i think i need the last one, too
[15:21] <RainCT> soc: it's there. I just moved the stuff up to the other src/* changes, removed the -orig from the --- line, add a "diff -u ..." line and remove the "only in..." crap
[15:23] <soc> ahhh now
[15:23] <soc> ok, didn't see that ...
[15:23] <soc> ok
[15:24] <soc> i corrected my debdiff now
[15:24] <RainCT> soc: ok, attach it to the bug report. and normally you would have to subscribe ubuntu-universe-sponsors but don't do this now as I'm already subscribing it
[15:24] <RainCT> s/subscribing/reviewing
[15:26] <RainCT> soc: eh, but before add: (LP: #xxxx) to the 1st or 2nd point in your changelog entry
[15:26] <RainCT> where xxxx is the bug number
[15:26] <RainCT> (rather to the 2nd one)
[15:27] <soc> ok, mom
[15:28] <soc> ok
[15:28] <soc> i'll attach it
[15:28] <persia> soc: Careful.  The acronym "MoM" means something very specific here (merges.ubuntu.com) :)
[15:29] <soc> ah ok :-)
[15:29] <soc> http://launchpadlibrarian.net/12296500/blogtk_1.1-2ubuntu1.debdiff
[15:29] <soc> https://bugs.launchpad.net/ubuntu/+source/blogtk/+bug/196813
[15:29] <ubotu> Launchpad bug 196813 in blogtk "BloGTK doesn't work with Python 2.5 (IOError: unsupported XML-RPC protocol)" [Undecided,New]
[15:29] <HighNo> what is the usual crowd in #launchpad? are those paid people? Somehow they are much less responsive than MOTUs...
[15:30] <persia> HighNo: Mix of paid and unpaid, but the community is smaller (harder to review code).  Generally best to check during CET working hours.
[15:31] <HighNo> persia: but that's the place to ask if something with launchpad (like rosetta) is somewhat broken?
[15:31] <soc> RainCT: what does happen now? (btw, i changed status to Fix Committed, hope that's right
[15:32] <HighNo> Maybe I'll post the question here too: I'm having a strange behaviour with rosetta: I uploaded a translation, get the import mail with the correct number of entries but the translation does not show up in launchpad - it still shows an old version...
[15:32] <RainCT> HighNo: yes, either there, on the Launchpad mailing list or filling a bug
[15:32] <RainCT> soc: was about to complain about that, should be "confirmed" or "triaged" (fix committed means that a MOTU uploaded it) :)
[15:32] <soc> ah ok
[15:32] <persia> HighNo: That's the place, although launchpad-users@ and answers.launchpad.net may also be helpful.
[15:32] <soc> ok, changed
[15:33] <RainCT> soc: uhm, btw, why do you mentor yourself on the bug report? :P
[15:34] <RainCT> soc: I'll upload your changes in some minutes :)
[15:34] <soc> yesterday i thought "ok, if someone fixes it, i can at least review the patch" but today i thought, "well, let's just do it myself"
[15:34] <soc> ^^but i hope by mentoring myself i get extrapoints? :-P
[15:35] <HighNo> hehe
[15:35] <HighNo> did you help yourself much?
[15:35] <soc> that remains to be dicussed between reporter, mentor and asignee :-P
[15:36] <RainCT> lol
[15:37] <soc> uuuhh
[15:37] <soc> btw ...
[15:37] <soc>  gpg --send-key --> which key should i choose?
[15:38] <soc> the "pub" id or the "sub" id?
[15:38] <soc> i just saw that i forgot to import my gpg key into launchpad and didn't sign the code of conduct ...
[15:40] <RainCT> soc: ohhhh, I can't speak to you anymore until you've signed it :D
[15:40] <soc> :-P
[15:40] <soc> just tell me which id i have to use!
[15:40] <RainCT> soc: what do you mean with which?
[15:41] <RainCT> soc: that one you used for the package..
[15:41] <soc> when i do  gpg --list-keys soc@krg-nw.de i get 5 lines ...
[15:41] <soc> first starts with "pub"
[15:41] <soc> then 3 with "uid"
[15:41] <soc> 5th starts with "sub"
[15:41] <soc> and i wonder which id i have to use for  gpg --send-key
[15:42] <RainCT> soc: ah. dunno, mine starts with "sec 1024D/0EADC245 2006-11-04 [expires: 2008-11-03]", where "1024D/0EADC245" is what I've to pass gpg --send-key
[15:42] <soc> (and for gpg --fingerprint)
[15:42] <RainCT> soc: try with gpg --list-secret-keys
[15:42] <soc> now i have one line with sec
[15:42] <soc> 3 with uid
[15:43] <soc> and one with ssb ...
[15:43] <RainCT> soc: see above :)
[15:43] <soc> guess i'll take that one with sec
[15:46] <soc> https://wiki.ubuntu.com/Soc
[15:46] <soc> coooool
[15:46] <soc> that's bad for google's summer of code :-)
[15:47] <sistpoty|work> protonchris, murrayc_: thanks for adding the check-symbols output to bug 190744. Unfortunately the abi is not stable, please see my comment at the bug.
[15:47] <RainCT> heh
[15:47] <ubotu> Launchpad bug 190744 in libgdamm3.0 "Request: Upgrade libgdamm3.0 to upstream version 2.9.81" [Undecided,Confirmed] https://launchpad.net/bugs/190744
[15:47] <RainCT> (if someone is bored, http://paste.ubuntu.com/5144/plain/)
[15:48] <HighNo> doh!
[15:48]  * HighNo feels bored enough to fall for that one...
[15:48] <soc> ouuuch ... that's really brilliant ...
[15:49] <soc> the call the file UbuntuCodeofConduct-1.0.1.txt
[15:49] <soc> but give the line gpg --clearsign UbuntuCodeOfConduct-1.0.1.txt ... of course, that can't work ...
[15:49] <bobbo> soc: they spell it wrong on the site
[15:49] <soc> yes ...
[15:49] <bobbo> try tab completing it
[15:49] <soc> already fixed it ...
[15:50] <protonchris> sistpoty|work: thanks for taking a look.  I was under the impression that symbols starting with an underscore were internal.
[15:50] <bobbo> soc: ah sorry
[15:50] <protonchris> sistpoty|work: admittedly, I am new to all of this.
[15:50] <sistpoty|work> protonchris: nope... that's the c++ mangling (everything starting with _Z is a c++ symbol iirc)
[15:51] <sistpoty|work> protonchris: you can just use echo "c++demangledsymbolname" | c++filt to see the demangled name
[15:51]  * RainCT observes how HighNo loops :P
[15:52] <HighNo> damn, that is a loop?
[15:53] <RainCT> HighNo: do you have a broken parser or what? :D
[15:53] <HighNo> hehe
[15:54] <protonchris> sistpoty|work: Ahh.  Thanks.  I'll see if murrayc_ wants to do a new release with an updated soname.
[15:54] <sistpoty|work> protonchris: thanks!
[15:56] <soc> RainCT: is there anything i can do now?
[15:56] <\sh> grmpf
[15:57] <\sh> can't we patch away the registration dialog box of netbeans?
[15:58] <HighNo> \sh:  why is it bothering you?
[15:58] <\sh> HighNo: it shouldn't be in an app we ship..there is no need to register, so it's useless...
[15:58] <\sh> HighNo: and it's highly annoying
[15:59] <RainCT> soc: fix another bug :)
[16:00] <HighNo> \sh: at least full ack on 2nd one. I am not certain about the first one. If it is in universe and a commercial one - there still is a point in kindly asking the users to register. Knowing about your users is good for commercial development
[16:01] <bobbo> RainCT: you got time to sponsor another debdiff for me?
[16:01] <bobbo> RainCT: this one is actually in universe ;)
[16:01] <HighNo> (hey, it's not even bad for any software)
[16:02] <\sh> HighNo: then it should belong to multiverse but as we build it from source, and as it's opensource now, we should get rid of it
[16:02] <RainCT> soc: (I'll need some time to upload this one as I'm uploading my Hardy chroot and that's damn slow.. feel free to donate me a better connection :P)
[16:02] <RainCT> bobbo: subscribe me and I'll have a look at it later today :)
[16:03] <HighNo> \sh: you are free to do it - but still open source does not conflict with commercial app.
[16:03] <bobbo> RainCT: thanks :)
[16:03] <soc> RainCT: no problem?
[16:03] <soc> is there a way to see which packages still depend on python 2.4 instead on python?
[16:04] <soc> so i can investigate if it's a mistake or if there is something fundamental blocking it from using Python 2.5
[16:04] <RainCT> soc: apt-cache rdepends python2.4   might help
[16:04] <sistpoty|work> soc: apt-cache rdepends python2.4
[16:04] <sistpoty|work> heh
[16:04] <soc> thanks
[16:04] <RainCT> ^^
[16:04] <soc> :-)
[16:04] <\sh> HighNo: well, then we should change the text "you'll receive mail for new version releases blabla" doesn't make sense in a package which will be supported for 3 years...
[16:04] <HighNo> \sh: ok, that does not make sense then
[16:05] <RainCT> hooray, pbuilder finished :)
[16:05] <HighNo> \sh: do you formally ask me to patch that?
[16:05] <HighNo> \sh: I just freed 500mb of disk space :-)
[16:05] <\sh> HighNo: :) disk space is not the problem i have :)
[16:06] <murrayc_> sistpoty|work: I don't update .so names for any of the *mm libraries, and neither does GTK+.
[16:06] <HighNo> \sh: Yes, but it was mine. (<150mb) I meant I have enough space to apt-get source netbeans now :-)
[16:06] <\sh> HighNo: and it would be nice, if we could get rid of this screen...or just make it a simple splash which disappears after 2 or 3 secs ,-)
[16:06] <\sh> the former is my favorite solution :)
[16:07] <HighNo> \sh: I'll have a look.
[16:07] <sistpoty|work> murrayc_: well, you really should, as the abi is broken by the change (that's what the soname is for)
[16:07] <HighNo> \sh: you want me to patch the hardy release, right?
[16:07] <\sh> HighNo: yepp :)
[16:08] <murrayc_> sistpoty|work: It's unstable. It's meant to break. But on the other hand, I don't mind if we change the .so name it for that very reason, so I'd accept a patch. Without a patch I'm not confident that I'd make the right change in configure.ac.
[16:08] <HighNo> \sh: can you give me some short details on when the dialog pops up and what its content is (at least part of it so I can search for that in the source)
[16:09] <sistpoty|work> murrayc_: ok, I'll take a look, once I'm at home (or maybe protonchris would like to do that?)
[16:09] <emgent> jdstrand, ping
[16:09] <\sh> HighNo: directly when you start netbeans the first time
[16:09] <murrayc_> sistpoty|work: Thanks.
[16:10] <sistpoty|work> Thanks for the lib in the first place, murrayc_ ;)
[16:10] <RainCT> btw, nano segfaults when the terminal is too small
[16:11] <soc> RainCT: ok, i'll review balder2d next ...
[16:11] <soc> i'll leave my hands of zope and plone ... and falcon repository builder mentions something about py 2.5 incompatibility ...
[16:13] <RainCT> go soc go! :)
[16:13] <HighNo> \sh: I never used netbeans - how do you start it from the command line?
[16:16] <soc> ^^:-)
[16:19] <\sh> HighNo: netbeans :)
[16:20] <\sh> HighNo: if you have sun-java6 installed somehow, it will crash right before start.
[16:20] <\sh> HighNo: just do this on the CLI:  export LIBXCB_ALLOW_SLOPPY_LOCK=1
[16:20] <\sh> and start netbeans...this is a workaround
[16:21] <soc> weiiird ... since when go executables to /usr/lib?
[16:21] <\sh> HighNo: I'll go home now...and come back in at least 1h30mins :)
[16:21] <\sh> HighNo: if you need help, I can look into the code too :)
[16:21] <\sh> ok...and weekend time now
[16:23] <tjaalton> sistpoty|work: I'm too lazy, I'll just close it as invalid for hardy. it's only really needed when xserver 1.5 is uploaded after hardy.. ;)
[16:23] <sistpoty|work> ok, thanks tjaalton
[16:38] <Iulian> I'm trying to debuild a package after I added .desktop file but I get an error from lintian: desktop-file-but-no-dh_desktop-call
[16:38] <Iulian> I've added dh_installmenu in debian/rules
[16:38] <Iulian> Am I missing something?
[16:38] <RainCT> Iulian: you've to add dh_desktop, not dh_installmenu
[16:38] <RainCT> Iulian: dh_installmenu is for debian/menu files
[16:39] <Iulian> RainCT: Boah!
[16:39] <Iulian> Right
[16:39] <Iulian> Thanks RainCT
[16:39] <RainCT> Iulian: np :)
[16:39] <RainCT> soc: uhm.. blogtk is failing to build
[16:39] <RainCT> soc: both the current version and that one with your changes
[16:40] <bddebian> Heya gang
[16:40] <RainCT> chmod +x debian/blogtk`pkg-config libgnome-2.0 --variable=prefix || echo /usr`/bin/BloGTK
[16:40] <RainCT> chmod: cannot operate on dangling symlink `debian/blogtk/usr/bin/BloGTK'
[16:43] <RainCT> strange.. but running make install manually works
[16:44]  * RainCT thinks that this is a strange package.. :P
[16:47] <RainCT> can someone try to build blogtk on a Hardy chroot?
[16:48] <bobbo> RainCT: i'll give it a go
[16:48] <bobbo> RainCT: vanilla package from Hardy apt-source?
[16:49] <hellboy195> dholbach: around?
[16:49] <dholbach> hellboy195: yes, but quite busy - how can I help you?
[16:50] <hellboy195> dholbach: ah, just wanted to let you now that clean-la thing (libnxml) is *still* necessary. so the uploaded debdiff should be ok. if you want to go ahead ,.. but if you have no time, it 's no problem. just no stress :)
[16:50] <hellboy195> *know
[16:51] <dholbach> hellboy195: OK, best to ask for *somebody* to upload it :)
[16:51] <hellboy195> ^^
[16:52] <hellboy195> MOTUs out there with a little bit of time. Ok in fact I only need '1' ^^. bug 195532 :)
[16:52] <ubotu> Launchpad bug 195532 in libnxml "Merge libnxml 0.18.1-4 from Debian(Unstable)" [Undecided,Confirmed] https://launchpad.net/bugs/195532
[16:52] <Iulian> RainCT: Do you have few seconds to take a look at my debdiff please? http://paste.ubuntu.com/5145/ - it's bug #196871
[16:52] <ubotu> Launchpad bug 196871 in zblast "No .desktop file; here is one" [Undecided,In progress] https://launchpad.net/bugs/196871
[16:52] <bobbo> RainCT: blogtk fails on my end too Error: http://pastebin.ubuntu.com/5146/
[16:54] <soc> RainCT: could it be that the main py-file isn't chmod+x ed?
[16:56] <hellboy195> LucidFox: btw, why are you a subscribed at my beagle merge if you are already in the MOTU Mono Team?
[16:57] <LucidFox> hellboy195> I marked my intention to do it this way
[16:58] <hellboy195> LucidFox: ah k, nice if you would do it. I uploaded the debdiffs a long time ago and you should have noted that already somebody asked about the progess
[16:58] <LucidFox> Indeed :)
[16:58] <LucidFox> (By the way, for some reason I don't receive mail from team subscriptions - none from u-u-s, for example)
[17:00] <hellboy195> LucidFox: :)
[17:12] <RainCT> Iulian: sorry for the wait. the .desktop file won't validate; otherwise it looks good
[17:12] <RainCT> bobbo: thanks
[17:13] <RainCT> bobbo: same error as here
[17:13] <RainCT> but dpkg-buildpackage -rfakeroot works
[17:13] <RainCT> LucidFox: u-u-s mails go to ubuntu-universe-sponsors@lists.ubuntu.com
[17:14] <Iulian> RainCT: No problem, what should I do before submitting the debdiff to the bug report?
[17:14] <RainCT> Iulian: ensure that the .desktop file is clean, using the desktop-file-validate command
[17:15] <RainCT> (it's installed with the default installation)
[17:15] <Iulian> RainCT: Ok, will do that.
[17:16] <RainCT> Iulian: on a first look the Encoding line should be removed, the Application category too, the Icon field should just be "xzb" and the command should start with a verb (desktop-file-validate won't find this last one, but trust me :))
[17:16] <RainCT> ah, and remove the GenericName thing if it's empty
[17:17] <RainCT> perhaps a more descriptive Name would be good, but I don't see many games following this so you might also leave it as it is
[17:19] <RainCT> Iulian: ah, and if you tell me what Comment you're going to use I'll give you one or two translations :)
[17:20] <Iulian> RainCT: Actually I don't know. :-)
[17:21] <Iulian> RainCT: I don't mind if you give me one though
[17:21]  * Iulian smiles
[17:21] <RainCT> igh-speed shoot 'em up game
[17:22] <RainCT> argh
[17:22] <RainCT> Iulian: "Play a high-speed shoot 'em up game" would be the easy one
[17:22] <Iulian> RainCT: Heh, ok, will add that. Thanks
[17:27] <RainCT> Iulian: ok.. I'll give you a translation when I decide how to translate "shoot 'em up" :P
[17:29] <Iulian> RainCT: Okay
[17:32] <jpatrick> sorry about that guys
[17:33] <Iulian> RainCT: I'm still fighting with the .desktop file, can you give me a hint? http://paste.ubuntu.com/5147/
[17:34] <Iulian> jpatrick: You missed one :)
[17:34] <jpatrick> gah
[17:34] <PP|Spydon> Who shall I contact if I want a package reviewed and updated to the repos?
[17:34] <bobbo> Iulian: "Applications;Games;" should just be "Games;" i think
[17:35] <Iulian> bobbo: Let me try.
[17:36] <Iulian> bobbo: Nop, seems that it should start with X-
[17:37]  * bobbo goes to grab gnome-games source to check this out
[17:37] <Iulian> bobbo: Yep, it should start with X-. Now I get only this error: zblast.desktop: warning: key "Encoding" in group "Desktop Entry" is deprecated
[17:38] <bobbo> Iulian: just remove the entire Encoding line and it should work
[17:38] <Iulian> Ok
[17:38] <Iulian> Isn't necessary to have that line?
[17:39] <bobbo> Iulian: Looks like its been deprecated to me
[17:40] <Iulian> That's true...
[17:41] <bobbo> Iulian: is it working now?
[17:42] <Iulian> bobbo: Yes
[17:42] <PP|Spydon> The game X-Moto is version 0.3.2 in the repos and there has been many improvements since that version to the current version (0.4.1) is it possible to get in updated in some way? :P
[17:43] <PP|Spydon> Or this is maybe the wrong place to ask?
[17:43] <bobbo> PP|Spydon: is there a newer version in Debian Sid?
[17:44] <PP|Spydon> bobbo, I don't think so...
[17:44] <stgraber>      xmoto |    0.3.2-1 | gutsy/universe | source, amd64, i386, powerpc
[17:44] <stgraber>      xmoto |    0.4.0-2 | hardy/universe | source, amd64, i386, powerpc
[17:44] <PP|Spydon> ah how nice!
[17:45] <stgraber> so hardy's 0.4.0
[17:45] <bobbo> Debian sid has 0.4.1-1
[17:45] <PP|Spydon> Ah okay, how can I check things like that? :P
[17:45] <sistpoty|work> oh, you don't want to block the release team having to extensively test the newer xmoto from sid? *g*
[17:46] <stgraber> PP|Spydon: I just used : rmadison xmoto that gives you the versions for Ubuntu and there is an extra parameter to check Debian IIRC
[17:46] <PP|Spydon> thx
[17:47] <stgraber> rmadison xmoto -u debian
[17:47] <PP|Spydon> ah this is a really nice app
[17:48] <PP|Spydon> I shall not take more of your time, thx for the information and keep up the good work! :)
[17:48] <PP|Spydon> bb
[17:55]  * sistpoty|work heads home... later folks
[17:58] <jakev> Hello all
[18:01] <Iulian> Hi jakev
[18:02] <Iulian> RainCT: I think it's ready now, can you please take a look at it again? http://paste.ubuntu-nl.org/57847/
[18:27] <hellboy195> \sh: good to see you :) I have a question
[18:28] <hellboy195> \sh: I'm currently mergin gnustep-gui and I have an error I can't avoid. http://pastebin.com/m44f7596a
[18:30] <RainCT> Iulian: why "X-Game"?
[18:30] <\sh> hellboy195: you need to install some of the gnustep -dev packages
[18:31] <\sh> hellboy195: it's a essential build-dep for gnustep stuff, and it needs to be installed on the host where you run debuild -S -sa
[18:31] <\sh> or something similiar
[18:31] <hellboy195> \sh: ah. I'm a dork.
[18:31] <RainCT> Iulian: it's just Game, see http://standards.freedesktop.org/menu-spec/latest/apa.html
[18:31] <hellboy195> \sh: just wondering why the build machines don't have a problem!?
[18:32] <Iulian> RainCT: I changed it because this: zblast.desktop: error: value "Games;" for key "Categories" in group "Desktop Entry" contains an unregistered value "Games"; values extending the format should start with "X-"
[18:32] <RainCT> Iulian: because it's "Game" and not "Games" ;)
[18:33] <Iulian> RainCT: Blah! :)
[18:33] <RainCT> Iulian: using "X-Game" either it won't be displayed or it would create a new category in the menu
[18:33] <Iulian> RainCT: Okay, after that should I attach the debdiff to the bug report and subscribe u-u-s?
[18:33] <RainCT> Iulian: yes
[18:34] <Iulian> RainCT: Thanks!
[18:34] <hellboy195> \sh: but debuild is also very funny. dpkg-source: error: syntax error in ./gnustep-gui-0.12.0/debian/control at line 55: line with unknown format (not field-colon-value)
[18:34] <hellboy195>   http://pastebin.com/m28b8e3fa  ;)
[18:35] <RainCT> does anyone know what "chmod: cannot operate on dangling symlink" means?
[18:35] <RainCT> slangasek?
[18:35] <\sh> hellboy195: that was the rules file
[18:36] <hellboy195> \sh: I'm just wondering what's false at line 55
[18:36] <slangasek> RainCT: it means coreutils has gotten silly in its old age
[18:37] <slangasek> RainCT: that used to fail silently, now coreutils balks when you try to chmod a symlink that's pointing out into nowhere
[18:37] <\sh> hellboy195: but there is something wrong in debian/control not in rules...
[18:37] <hellboy195> \sh: l g
[18:37] <hellboy195> \sh: I mean. OMG. I should stop for today xD
[18:37]  * RainCT decides that slangasek is allmighty :)
[18:38] <RainCT> slangasek: thanks
[18:41] <afflux> there are three bugs in gnome-art for which I have fixes that I'd like to get sponsored. Should I create multiple debdiffs or one big containing all three fixes ?
[18:41] <RainCT> afflux: one
[18:41] <hellboy195> \sh: thanks, thanks, thanks :)
[18:42] <RainCT> slangasek: but the symlink works..
[18:42] <afflux> RainCT: okay. And attach that one to which bug?
[18:43] <hellboy195> wb LucidFox :)
[18:43] <LucidFox> I won't stay for long
[18:43] <LucidFox> going to sleep soon
[18:43] <hellboy195> ^^
[18:43] <RainCT> afflux: create a new bug "Candidate for version XXX"
[18:44] <RainCT> afflux: and post a comment in the other bugs stating that there's a fix available on that other bug
[18:44] <slangasek> RainCT: more context, please?
[18:44] <afflux> RainCT: alright, thank you
[18:44] <RainCT> slangasek: http://paste.ubuntu.com/5146/
[18:45] <RainCT> slangasek: it builds in Gutsy but failds with that error in Hardy chroots
[18:46] <RainCT> slangasek: btw, if you know what that strange "`" is please tell me (it's also there when building on Gutsy)
[18:46] <slangasek> ln -s  debian/blogtk`pkg-config libgnome-2.0 --variable=prefix || echo /usr`/share/blogtk/BloGTK.py debian/blogtk`pkg-config libgnome-2.0 --variable=prefix || echo /usr`/bin/BloGTK
[18:46] <RainCT> s/is/are
[18:46] <slangasek> RainCT: that's not a proper package symlink according to Debian policy; you're supposed to use relative symlinks, where this one is an absolute symlink (which would be invalidated in the actual package, besides)
[18:47] <Iulian> bobbo: Are you working on #196872 ?
[18:48] <slangasek> basically, that line above reduces to ln -s debian/blogtk/usr/share/blogtk/BloGTK.py debian/blogtk/usr/bin/BloGTK
[18:48] <slangasek> and it should be ln -s ../share/blogtk/BloGTK.py debian/blogtk/usr/bin/BloGTK
[18:51] <slangasek> RainCT: so the blogtk Makefile is just not compatible with current coreutils, and also creates a symlink that's wrong; the latter was not an issue for the package because it was overridden by debian/blogtk.links
[18:51] <slangasek> but the former is an issue
[18:53] <RainCT> uhm.. the package has been removed from Debian
[18:53] <LucidFox> Gosh, an iPod is _heavy_.
[18:54] <hellboy195> LucidFox: not if you loose it (like me :( )
[18:56] <bobbo> Iulian: i was thinking about working on #196872 but you can have it if you want
[18:56] <LucidFox> I've compared my dad's iPod video 5G to my iriver clix. The iPod's ONLY advantage is 40x more storage space, 80GB vs 2GB (but, then, it's HDD vs flash). Everything else is worse.
[18:56] <RainCT> slangasek: from popcon  web: position by_vote: 26 blogtk  inst: 1949  vote: 158  old: 1703  recent: 87
[18:57] <RainCT> slangasek: do you think is should be removed or rather adopted in Ubuntu?
[18:57] <LucidFox> Overpriced, heavy, few formats supported, requires special software, etc.
[18:57] <slangasek> RainCT: I'm not familiar with the package and have no opinion
[18:57] <LucidFox> anyway... night all
[18:57] <RainCT> anyone here knows blogtk?
[18:58]  * soc knows it a bit since yesterday ...
[18:58] <soc> :-)
[18:58] <RainCT> heh
[18:59] <RainCT> soc: do you think it's worth being in Hardy?
[18:59] <soc> good question ...
[18:59] <soc> it's the only remotely usable blogging client for gtk ...
[18:59] <soc> afaik
[19:00] <soc> i have absolutely no experience with makefiles, but i can look at it ...
[19:00] <Iulian> bobbo: Ok, I will take a look.
[19:01] <slangasek> I'm not even sure what a "blogging client" is...
[19:01] <slangasek> my blogging client is my editor + my VCS (ikiwiki++ :P)
[19:01] <RainCT> soc: I'm already looking at it
[19:01] <soc> mh ok
[19:01] <soc> at least it would be good to have one program less which depends on python 2.4
[19:02] <soc> so either fix or remove i would say ...
[19:02] <soc> but atm it's not really nice ...
[19:03] <RainCT> well, I think I'll just clean it up a bit for now
[19:05] <\sh> man I'm tired of sckers who steal property, even if it's only an article
[19:07] <\sh> check out "http://www.linuxindex.com/" and tell me what you see...this is ridiculus
[19:09] <jpatrick> \sh: especially when they get money with ads..
[19:10] <RainCT> :/
[19:10] <\sh> jpatrick: and more annoying when they send trackbacks in their name with our content
[19:10] <\sh> http://www.mysqlperformanceblog.com/2008/02/04/finding-out-largest-tables-on-mysql-server/ as he did here
[19:12] <\sh> if you want to send emails to him, all infos are on http://www.sourcecode.de/content/damn-you-thieves :)
[19:13] <\sh> sadly that p.u.cs cronjob isn't running :)
[19:17] <tbf> superm1: revu has an updated version of gnome-lirc-properties
[19:17] <tbf> RainCT: danke! :-D
[19:22] <RainCT> tbf: you're welcome :)
[19:23] <TuxCrafter> hi guys
[19:23] <TuxCrafter> how do I remove all *-dev files
[19:24] <TuxCrafter> packages
[19:24] <fdoving> for example_:
[19:24] <fdoving> dpkg -l '*-dev'|xargs aptitude remove
[19:25] <TuxCrafter> i am working with a driver developer and he needs /usr/include/linux to link to the kernel sources but is this a correct way
[19:25] <fdoving> em, that missed a cruical part. hang on.
[19:26] <TuxCrafter> he needs the compiler.h
[19:26] <fdoving> dpkg -l '*-dev'|awk '{print $2}'|xargs aptitude remove
[19:26] <fdoving> there.
[19:26] <fdoving> that can be used to uninstall all -dev packages.
[19:28] <jpatrick> fdoving: woah... tons of output
[19:29] <slangasek> TuxCrafter: ehm, no, the correct way is for the driver developer to not use /usr/include/linux, which is reserved for userspace headers
[19:29] <fdoving> jpatrick: did you get the one with awk? - the first command i left awk out. which is fun, but it won't work.
[19:30] <jpatrick> fdoving: aptitude is still working the stuff needing removal out..
[19:30] <TuxCrafter> slangasek: it is a special tvtime modivication
[19:31] <TuxCrafter> or am i just missing a important dev package
[19:31] <fdoving> jpatrick: oh, that much :)
[19:31] <TuxCrafter> how can i search apt-cache for  an package that will install the compiler.h header?
[19:31] <TuxCrafter> in the /usr/include/linux dirs
[19:31] <TuxCrafter> i got one in my normal headers
[19:31] <fdoving> TuxCrafter: you can't use apt-cache for that. there is apt-file
[19:31] <fdoving> or you can use packages.ubuntu.com
[19:32] <slangasek> TuxCrafter: it doesn't matter what it is, that's the wrong directory to use when building kernel modules.  you want either /lib/modules/$(uname -r)/build, or a specific path under /usr/src/ depending on the kernel ABI you're building for
[19:33] <slangasek> and compiler.h is not a userspace header, so if you're building something that's /not/ a kernel driver, you shouldn't be using that header
[19:33] <TuxCrafter> slangasek: i agree
[19:33] <TuxCrafter> i am going to talk with him about than
[19:33] <TuxCrafter> i will show you
[19:34] <TuxCrafter> maybe you can give me advice where he sould be looking for his header files
[19:35] <TuxCrafter> slangasek: http://pastebin.ca/923686
[19:37] <TuxCrafter> he is working on some very advanced video and tuner chips for external pctv devices
[19:38] <TuxCrafter> but his dependency checks are driving me crazy so i am doing the documentation for him
[19:38] <slangasek> TuxCrafter: this is userspace code using a kernel-only header.  compiler.h is not vetted for use from userspace; if he wants that definition, he needs to copy it into his own code
[19:38] <TuxCrafter> so nobody else have to go through it agiain
[19:39] <TuxCrafter> slangasek: and if he needs kernel space code because it is interfacing with hardware?
[19:40] <TuxCrafter> that would not be a good idea
[19:40] <TuxCrafter> it would break the API
[19:40] <TuxCrafter> ABI
[19:40] <slangasek> TuxCrafter: false, you only need kernel space code if you're writing kernel code
[19:40] <TuxCrafter> slangasek: yes i see that
[19:40] <slangasek> if you're writing a userspace application, the rule has always been that if it's not a header exported by the kernel, you either can't rely on it at all or you make a local copy
[19:44] <TuxCrafter> slangasek: In file included from videoinput.c:39: videodev2.h:19:46: error: linux/compiler.h: No such file or directory
[19:45] <slangasek> yes
[19:45] <slangasek> linux/compiler.h is not a header intended for userspace
[19:47] <TuxCrafter> so he needs to include that file in his own code?
[19:47] <slangasek> if he thinks he needs to use it, yes
[19:47] <TuxCrafter> or should he do something else?
[19:47] <slangasek> personally, I think the reference to linux/compiler.h ought to be dropped entirely
[19:47] <slangasek> since the only definition he uses from it is __user
[19:48] <TuxCrafter> so relinking /usr/include/linux to my kernel source tree is not correct
[19:48] <slangasek> nope, a userspace app should be buildable without having to do that
[19:54] <TuxCrafter> slangasek: can you please help me explain this issue to the developer at #dvb at freenode.org
[20:02] <TuxCrafter> slangasek: http://packages.debian.org/search?searchon=contents&keywords=compiler.h&mode=exactfilename&suite=stable&arch=any
[20:03] <TuxCrafter> why does debian has a /usr/include/linux/compiler.h and ubuntu does not
[20:03] <slangasek> TuxCrafter: no time to get involved in this discussion on another channel right now, sorry
[20:04] <slangasek> TuxCrafter: Debian no longer has /usr/include/linux/compiler.h either; that information only applies to etch, not to lenny
[20:15] <TuxCrafter> slangasek: also is this normal to do sudo ln -s /usr/src/linux-source-2.6.24 /lib/modules/$(uname -r)/source
[20:16] <TuxCrafter> i had to do that to compile an other piece of his kernel userspace driver
[20:17] <slangasek> TuxCrafter: generally one can use the linux-headers-$(uname-r) package instead
[20:19] <TuxCrafter> yea but the headers the package was needing where not there with only the headers
[20:21] <slangasek> then that code is also broken for relying on headers that aren't part of the interface exported for kernel modules ;)
[20:22] <TuxCrafter> slangasek: pfff
[20:22] <TuxCrafter> i aslo cant get the guy to change his mind
[20:23] <TuxCrafter> seem to be something broken in videodev2.h when i compile it
[20:25] <TuxCrafter> is there some documentation that explains developers where to look for header and source files
[20:30] <TuxCrafter> found the problem
[20:30] <TuxCrafter> this code is just bad
[20:38] <Ubulette> is http://paste.ubuntu.com/ broken only for me ? http://pastebin.mozilla.org/349392
[20:41] <jpatrick> Ubulette: paste.u.c is broken beyond belief, use http://paste.ubuntu-nl.org/ instead
[20:41] <Ubulette> jpatrick, i use paste.u.c a lot and it's the 1st time it dies on me
[20:42] <sistpoty> hi folks
[20:42] <tbf> hey sistpoty :-)
[20:42] <hellboy195> sistpoty: ahoi :)
[20:42] <sistpoty> hi tbf and hellboy195
[20:43] <tbf> sistpoty: hope it wasn't my mail, that brought you back to life! :-D
[20:43] <hellboy195> sistpoty: May I ask you what kind of job you have. You work prettly long
[20:44] <tbf> hellboy195: its in the ubuntu wiki
[20:44] <tbf> it's
[20:44] <sistpoty> tbf: no, I'll take a look later (need to do some things first)
[20:44] <hellboy195> tbf: k
[20:44] <sistpoty> hellboy195: I'm a scientific research (computer science) at the university of erlangen
[20:44] <tbf> sistpoty: of course!
[20:45] <hellboy195> sistpoty: cool :)
[20:45] <sistpoty> hellboy195: and since I pretty much can choose from when and to when I work, as long as I work my 40hrs per week, I tend to arrive later :)
[20:45] <hellboy195> sistpoty: that's nice. lucky one :)
[20:45] <sistpoty> heh, I even develop foss there: www.faumachine.org is the big project of the chair I'm working at
[20:55] <RainCT> soc: ok, I changed the package a little bit (my changelog entry is only 50 lines long) :)
[20:56] <HighNo> sistpoty: hm, latest release 20060310 ?...
[20:57] <sistpoty> HighNo: yeah... everyone is busy adding new features atm *g*
[20:57] <HighNo> seems like there are a lot of germans around here :-)
[20:57] <sistpoty> so, the long awaited new release still needs to wait a little bit longer
[20:57] <sistpoty> heh
[20:57] <HighNo> sistpoty: I see... not exactly the 'open source way' ("release early, release often")
[20:58] <sistpoty> HighNo: well, it's still a university project (and of course there is cvs access) *g*
[20:58] <soc> RainCT: ok, i'll watch out on hardy :-)
[21:06] <hellboy195> Wow. Today is a popential programs for FFE release day :)
[21:24] <zul> hello anyone feeling like patching fail2ban?
[22:08] <sistpoty> anyone, who'd like to proofread meeting minutes? http://paste.ubuntu-nl.org/57883/
[22:09] <RainCT> sistpoty: «such an ACK does "not necessarily whether it's correct or not" [Hobbsee].»
[22:11] <sistpoty> RainCT: fixed, thanks
[22:25] <RainCT> btw, with what keyboard shortcut can I paste in konsole?
[22:27] <nixternal> RainCT: shift + insert
[22:27] <RainCT> thanks nixternal
[22:27] <nixternal> or clicking the middle mouse button
[22:27] <nixternal> no prob
[22:28] <nixternal> I have gotten so used to shift+insert I use it now more than I do ctrl+v
[22:48] <sistpoty> tbf: just looking at gnome-lirc-properties: though I'm not a cdbs expert, I guess the autotools-dev build-dependency is not necessary (at least I didn't find something using it there).
[22:58] <tbf> sistpoty: hmm
[22:59] <tbf> sistpoty: hmm.... the generated makefile contains several autotool invokations...
[22:59] <sistpoty> tbf: also, please make sure to file a new FFe (referring to the needs-packaging bug) and mention that in debian/changelog (otherwise, archive admins might put it back to motu-release)
[22:59] <tbf> ...even if they shouldn't be called normally
[23:00] <sistpoty> tbf: then you'd need to build-depend on auto*conf* (the autotools-dev rather is useful, if upstream config.sub/config.guess is outdated and doesn't support a newer architecture for example)
[23:01] <persia> sistpoty: FFe bug?  Not new package bug?
[23:02] <sistpoty> persia: well, the new package bug is confirmed (rightfully that), an FFe being confirmed would mean that it's accepted
[23:03] <sistpoty> see bug 192368
[23:03] <ubotu> Launchpad bug 192368 in ubuntu "Please add gnome-lirc-properties" [Wishlist,Confirmed] https://launchpad.net/bugs/192368
[23:03] <sistpoty> though I don't mind too much to have only one fulfilling both ;)
[23:04] <sistpoty> but at least one new package feature freeze exception bug should be there *g*
[23:04] <persia> sistpoty: I thought the plan was one filling both, but I suppose that's an implementation detail :)
[23:04] <sistpoty> persia: let's say it evolved in this case *g*
[23:04] <bddebian> persia: !!??!
[23:04] <tbf> i read you shall just subscribe the ffe team
[23:05] <persia> tbf: Good :)
[23:05] <sistpoty> tbf: sure, is ok as well, but please set it back to new or triaged then
[23:05] <sistpoty> tbf: (otherwise motu-release won't look at it *g*)
[23:05] <hellboy195> persia: No one picked wxwidgets so far. So if you want to, just take it :) I'm going to bed now. hf and gn8
[23:05] <tbf> sistpoty: hmm... maybe a new bug is more secure
[23:05] <sistpoty> heh
[23:05] <persia> hellboy195: I can't compile it on my machine.  We'll have to wait for someone else.  Thanks again.
[23:06] <tbf> sistpoty: i am that much lost in procedure already... that i've entered no-risk mode some time ago :-)
[23:06] <hellboy195> np. so gn8
[23:06] <persia> bddebian: Hi.  I've still not tracked down the attal thing, but it's on my list for tomorrow (when I ought have some time).
[23:07] <bddebian> persia: NP.  Actually I was wondering if you saw the newpki-client upload?
[23:07] <tbf> sistpoty: regarding: "and mention that in debian/changelog" --- something like "* Initial upload to Ubuntu (#192368, #xyz)"?
[23:07] <persia> bddebian: I did, and was very happy.  Unfortunately, it appears I deleted the patch that makes ctsim compile and segfault.  I'm thinking about disabling the GUI for hardy, and just shipping the CLI tools.
[23:08] <sistpoty> tbf: s.th. like "feature freeze exception LP: #bugnumber" (to make it more clear, and LP: #bugnumber will also close that bug)
[23:08] <soc> RainCT: did you figure out what caused the problems in BloGTK?
[23:17] <tbf> sistpoty: removed autotools-dev, really doesn't seem to make sense - but crosschecking by uploading to ppa
[23:18] <tbf> sistpoty: what stands "LP" for?
[23:18] <azeem> tbf: "launchpad", usually
[23:19] <tbf> azeem: ah!
[23:23] <sistpoty> tbf: I guess I asked you before, but what is the prerm good for?
[23:31] <sistpoty> tbf: sadly, it doesn't work for me (see revu comment)
[23:33] <sistpoty> tbf: looks like the python-support directory is wrong (/usr/share/python-support/gnome-lirc-properties/*gnome-lirc-properties*/)... though I'm no python packaging expert
[23:38] <tbf> sistpoty: that it doesn't find gnome_lirc_properties for you...
[23:38] <jdong> vorian: poke; you back yet? :)
[23:39] <tbf> sistpoty: for me python-support creates all the symlinks in /var/lib/python-support/python2.5/gnome_lirc_properties/
[23:39] <tbf> all pointing to that odd /usr/share/python-support/gnome-lirc-properties/*gnome-lirc-properties*/ folder
[23:40]  * sistpoty installs again
[23:41] <sistpoty> tbf: looks like it was my fault, didn't see that dpkg bailed out on missing dependencies (closed the shell too early *g*)
[23:42] <tbf> ah... the odd folder name also is right
[23:43] <tbf> it is gnome-dash-lirc-dash-properties/gnome-underscore-lirc-underscore-properties
[23:43] <tbf> the dash variant is the package name....
[23:43] <sistpoty> tbf: still looking at the ui, it seems strange: I couldn't unlock at the first try, and had no chance to unlock for a second time (some error appeared). when I restarted it, somehow it was already unlocked
[23:43] <tbf> ...the underscore variant is the public module name, sistpoty
[23:43] <sistpoty> tbf: ah
[23:44] <sistpoty> tbf: oh, it crashed when clicking on help (note, that I don't have gnome installed)
[23:45] <tbf> sistpoty: hmm... shall i add yelp to the depends list, or shall i make the code calling yelp more robust
[23:46] <sistpoty> tbf: whatever you prefer, I guess
[23:46] <sistpoty> (I guess, if there is a button, I'd like to be able to click it, though yelp as a dependency makes some sense to me)
[23:46] <sistpoty> s/though/so/
[23:47]  * persia notes that robust code might also provide some user feedback to install yelp when clicking an otherwise nonfunctional button, but doesn't intend to sway the decision either way
[23:49] <persia> Anyway feel like reviewing some packages and preparing new candidates for upload?  There are 395 likely candidates available from http://tinyurl.com/create.php, which is likely plenty to share :)
[23:49] <persia> Err.. http://tinyurl.com/2stsyf
[23:49] <persia> s/Anyway/Anyone/
[23:49]  * persia stops, apparently being unable to type
[23:49] <sistpoty> heh
[23:50] <vorian> jdong, in about 30 min
[23:50] <vorian> :)
[23:50]  * sistpoty ponders fixing a configure.ac to bump soname for upstream
[23:50]  * sistpoty also ponders going to bed though
[23:50] <jdong> vorian: :)
[23:51] <vorian> maybe 40
[23:51] <vorian> I just happened to hear my computer talking again :P
[23:51] <jdong> vorian: what are you, the Vista copy dialog?
[23:51] <vorian> hehe
[23:51] <jdong> :)
[23:51] <jdong> (maybe this is a bad joke to make in the Gates building; he might just disassociate me from the AP... AGAIN)
[23:59] <tbf> sistpoty: also have to sleep: had a 700km trip today