[12:37] <siretart> just find a student to do that! :)
[12:37] <sistpoty> hehe :)
[12:38] <sistpoty> there is already a huge "diploma thesis are offered" sign at the posting of our chair ;)
[12:39] <sistpoty> s/posting/something properly translated into english which means "aushang"/
[12:40] <bddebian> sistpoty: Aye, working on that
[12:40] <sistpoty> bddebian: you're kidding, are you?
[12:40] <pkern> SDL error: Couldn't find matching GLX visual
[12:41] <sistpoty> pkern: trigger?
[12:41] <pkern> Aye.
[12:41] <bddebian> sistpoty: Aye, should I not be?
[12:41] <sistpoty> pkern: any shell output? (I know the code quite well, but OTOH I'm starting to get drunk right now)
[12:42] <siretart> bddebian: you have experience with vnc and/or rdp?
[12:42] <bddebian> little bit with rdp with MS term servers
[12:42] <pkern> sistpoty: http://rafb.net/p/Rdujvx68.html
[12:42] <siretart> like in, programming a client for them that implement a pattern matcher in it so that we can remote control the session?
[12:42] <sistpoty> bddebian: sure, it's actually only two maps from fuddl that I added, but I guess I'd have sneaked these into the debian package by other means and then hint at upstream svn
[12:42] <siretart> like in, say www mechanize?
[12:43] <bddebian> sistpoty: Oh, you need a new tarball?
[12:44] <sistpoty> bddebian: yes, but as I wrote, I'd rather sneak it in via uuencode or s.th., as the change isn't worth it
[12:45] <pkern> lost in translation
[12:45] <sistpoty> bddebian: hehe, I meant that I'd (finally) update trigger svn on sourceforge with two maps added from fuddl (both in the data subdirectory)
[12:46] <sistpoty> pkern: line 8 is strange for the new version in games svn (it should be /usr/share/games...)
[12:46] <pkern> sistpoty: That's the gutsy one.
[12:46] <sistpoty> pkern: nonetheless I believe that the real error comes somewhere from either your graphic driver or from
[12:47] <pkern> Good point.
[12:47] <sistpoty> + ~/.trigger/trigger.config (let me check which options)
[12:49] <sistpoty> pkern: basically required[anything]  might be worth fiddling with, but I remember a bug report for ati, which I passed on in the past. For nvidia it should work (and does for me)
[12:49] <sistpoty> the ati thingy of course didn't get fixed *g*
[12:49] <bddebian> OK darn it, what do you want me to do ? :-)
[12:50] <bddebian> Actually because of the package rename, they'll all hit NEW anyway won't they?
[12:51] <lamont> siretart: aspectc++ was being special on hppa (looping in launchpad).  So I did a no-change upload to make hppa quit looping (seemed the easiest way to tickle launchpad).  so now instead of having feisty bits current in gutsy, it's out of date and ftbfs everywhere
[12:51] <norsetto> oh well ... bed is in order
[12:52] <sistpoty> bddebian: well, if you want to not draw negative attention from EddyP, I guess you should create a tarball for trigger-rally-data from the svn. If you want to keep it simple, just have it uploaded as is (and eventually write to fuddl to add his two maps which are now in upstream svn to the package himself))
[12:52] <siretart> lamont: how could that loop happen?
[12:53] <bddebian> And if EddyP is Debian, I pretty much only get negative attention from them :-)
[12:53] <lamont> siretart: I rather expect it was a bug in launchpad... dunno
[12:54] <lamont> siretart: lacking source, I didn't debug it. :-)
[12:54] <siretart> k
[12:54] <sistpoty> bddebian: EddyP is (afaik) still waiting for DAM approval, but he used to comment on any strange commit in the past. fuddl is a friend of mine and siretart who's also in the games team (but no DD yet) and cares about nexuiz and friends. He sent me the two maps to add upstream wise
[12:55] <siretart> I didn't work on aspectc++ lately since upstream (my former supervisor) keeps on promising a new release RSN. since over half a year now :/
[12:55] <sistpoty> siretart: over a half year? that's nothing compared to FAUmachine :P
[12:55] <lamont> siretart: and I didn't actually change the source, just bumped the version in debian/changelog and uploaded...
[12:55] <lamont> so it'd fail in rebuild testing as well
[12:56] <sistpoty> lol
[12:56] <siretart> lamont: I think aspectc++'s testsuite failed on hppa anyway, so *shrug*
[12:58] <sistpoty> siretart: greet fuddl from me and tell him that his trigger maps are upstream now and he should import them himself for the games team to spare bddebian ;)
[01:00] <bddebian> How do I just pull the data dir with svn ?
[01:01] <bddebian> Just co http://foo/bar bar/data ?
[01:01] <sistpoty> bddebian: not too sure, but iirc you can just export a subdirectory
[01:01] <bddebian> yeah, that worked :-)
[01:02] <bddebian> Oh, no it didn't
[01:02] <bddebian> It pulled everything
[01:05] <sistpoty> hm... I must admit that I also didn't look if the zip file for the data doesn't diverge from svn, so I guess just getting in a new upstream for now is also fine enough. (and it wouldn't fix the bug about new maps anyway since the reporter didn't send me any :()
[01:06] <sistpoty> bddebian: oh, just saw it: co http://foo/bar/subdir ...
[01:06] <sistpoty> bddebian: it's not cvs ;)
[01:07] <bddebian> Uhm, it doesn't look anything like the existing tarball for trigger-data :-(
[01:08] <sistpoty> well, nevermind then :(
[01:09] <sistpoty> not too sure how keiko built the tarball then
[01:09] <bddebian> OK, nevermind..  However I don't know where crap.obj, README.txt and README-stereo.txt came from :-)
[01:09] <bddebian> I especially like crap.obj
[01:10] <sistpoty> crap.obj is crap as the name said... wanted to remove that anyways. README* should be in trigger-rally though, coming from doc/ ?
[01:11] <bddebian> No, in the current orig.tar.gz for trigger-data
[01:12] <sistpoty> damn, well it's zip files as orig-sources after all, must have been any "windows magic" to get it right then *g*
[01:12] <sistpoty> (which I guess is sorting out by hand=
[01:13] <bddebian> Heh.  Well README and README-stereo are in /doc in the other package so probably not necessary?
[01:14] <bddebian> Or should I just stop even trying?
[01:14] <sistpoty> bddebian: hehe, if you feel like it, go ahead, but don't waste too much time with it, I'd say
[01:14] <bddebian> I'm happy to do stuff I just don't need anyone getting pissed at me :)
[01:15] <bddebian> Heya persia
[01:15] <persia> hey bddebian
[01:16] <sistpoty> haha, well I guess I should rather feel ashamed, since I should have done this stuff some time ago, but -ENOTIME (and currently -ENOBANDWITH and no remaining knowledge about games team packaging) hinder me quite a bit ;')
[01:16] <sistpoty> hi persia
[01:17] <persia> hi sistpoty
[01:18] <bddebian> Someone just tell me what HAS to be in the orig.tar.gz.  Do I need a license file?
[01:18] <sistpoty> bddebian: yes, always
[01:19] <sistpoty> (so copy in gpl from top svn, if there's none in the subdir
[01:19] <sistpoty> )+)
[01:19] <bddebian> Actually, why is it a seperate tarball anyhow?
[01:19] <persia> bddebian: You need: code for every binary (although some .png, .gif, and .jpeg are acceptable), licenses for everything (including data), and copyright attribution on at least a project-wide basis, if not for every file.
[01:20] <pkern> For Debian it's every file.
[01:20] <persia> bddebian: The md5sum or orig.tar.gz is supposed to match the md5sum on the upstream source, so that people who don't trust Debian/Ubuntu/MEPIS/etc. can verify we didn't change the code.
[01:21] <sistpoty> bddebian: that's what it used to be, just zip-files, no svn and nothing more. And then the project moved to sourceforge after I contacted upstream (but not on my request though), which meant having the stuff in svn
[01:21] <persia> pkern: Debian insists on copyright attribution for every file?  I've never seen copyright assertion for .png files in a Debian orig.tar.gz.
[01:21] <sistpoty> so I guess its just the usual sign of a grown project ;)
[01:21] <bddebian> persia: Well that's broken already
[01:21] <bddebian> sistpoty: :)
[01:22] <persia> bddebian: When repacking, ideally you include instructions (perhaps in the get-orig-source rule) that allow someone to reproduce without the orig.tar.gz.
[01:24] <pkern> persia: Every source file. Now PNG aren't exactly the preferred form for modification neither.
[01:24] <sistpoty> persia: when pulling from svn, you cannot match md5sums. and in debian it's not too bad to mangle the orig-tar-gz (in here it's a zip-file anyways)
[01:25] <sistpoty> btw.: if I (as an upstream) would need to attribute *every* source file, I'd tell you to go to hell and learn about pointers first :P (readme -> license of my files)
[01:25] <persia> sistpoty: My understanding was that when repacking, it was best practice to include an orig.tar.gz rule, and put the md5sums of the .zip file (or whatever) in debian/copyright, just to maintain the cryptographic trail.  I believe this all to be from Debian, rather than any Ubuntu policy.
[01:26] <bddebian> This is craziness then
[01:27] <ScottK> What pitti, Mithrandir, and Riddell have told me is that while minor copyright holders aren't essential to be listed in debian/copyright, ALL licenses used in the package must be.
[01:27] <persia> pkern: Find me a debian package with every .svg in the orig.tar.gz containing license and copyright attribution then.  I'll be surprised.
[01:27] <sistpoty> persia: when repacking, the original trail won't help you match (as it won't tell you what changed), however and get-orig-source to build a tarball from a zip-file would (but not if the new tarball came from svn though ;)
[01:28] <sistpoty> ScottK: that's right, but doesn't mean that I need to put a "this is GPL..." in every header
[01:28] <bddebian> Well you guys have successfully scared me away from touching this :-)
[01:28] <sistpoty> damnit *G*
[01:29] <persia> sistpoty: I use `svn export -D $(DATE)` in get-orig-source when packaging a snapshot, just so that others can reproduce.  I suspect `svn export -r $(revision)` would also be acceptable.
[01:29] <bddebian> sistpoty: Good idea :-)
[01:30] <slangasek> pkern: um, no, there's no requirement of individual per-file copyright statements in Debian
[01:30] <bddebian> Hmm, there is shit, not even a README.Debian in the current trigger-data package.  Of course it had a real tarball
[01:31] <sistpoty> persia: sure, that's good practice (I guess using the revision would be better though), but you can also tell this via debian/copyright, or debian/changelog. It *should* be verifyible then.
[01:32] <persia> bddebian: Sometimes that gets put in debian/copyright.  From what I understand, putting it in README.Debian is now deprecated.
[01:33] <mneptok> excuse me for a mo'
[01:33] <mneptok> !ops
[01:33] <ubotu> Help! Hobbsee, Riddell, sladen, fbond or PriceChild
[01:33] <persia> sistpoty: "*should* be verifyable" is really enough.  It's not like the truly diligent doesn't have a decent chance of replacing upstream .tar.gz files with modified versions anyway.
[01:34] <persia> mneptok: Unless you're channel-specific, you might do as well with a /msg to ubotu
[01:35] <mneptok> persia: yes, i know. but thanks. :)
[01:43] <sistpoty> persia: sure, though I've often enough been diffing between svn checkouts and the "orig.tar.gz" though ;)
[01:43] <persia> sistpoty: Well, not everyone follows best practice...
[01:44] <bddebian> Nooo ;-)
[01:44] <sistpoty> persia: right, I didn't write that I did it everytime ;)
[01:44] <bddebian> Oh nice, he sent me a new adanaxis tarball
[01:46] <sistpoty> well, I rather spoke about reviewing packages... for trigger(-rally) I can commit as upstream, so it's easy enough to follow for me. And in code changes I'm most interested because that means for trigger that my patches got cleaned up *g*
[01:48] <persia> sistpoty: You mean pulling back things from an upstream perspective?  People adding random unattributed patches to orig.tar.gz's just seems wrong for that use case.
[01:50] <sistpoty> persia: not too sure what you mean by "pulling back" here, but if you mean to add changes to the orig.tar.gz, yes. however that of course shouldn't work w.o. notice
[01:51] <sistpoty> (as it would be a new orig.tar.gz anyways then)
[01:52] <persia> sistpoty: Ideally.  I think we agree, and are just confusing each other: I'm stopping now :)
[01:52] <sistpoty> hehe, most probably ;)
[01:55] <sistpoty> sorry, got to go to bed now, (actually 2 hours ago *g*)
[01:56] <sistpoty> maybe tomorrow, if I find the time
[01:56] <sistpoty> gn8 everyone
[01:56] <persia> sistpoty: sleep well
[01:56] <sistpoty> thx
[02:03] <danm> Hello, I've accidentally uploaded a package to upload.ubuntu.com. It's called 'xca'. I forgot to specify my ppa account. Is it possible to remove it there?
[02:04] <imbrandon> danm: are you a MOTU
[02:04] <persia> danm: You should soon get a mail saying that the upload was Rejected (unless you're a member of ubuntu-dev).
[02:04] <imbrandon> exactly
[02:04] <imbrandon> sometimes they silently die, but still
[02:04] <danm> ok. I'm not a MOTU.
[02:05] <persia> danm: Don't worry about it then.  There'll be a log showing your attempt to upload, but there's nothing you need to do to clean up.
[02:06] <danm> ah thanks.
[02:10] <bddebian> pkern: You should join the games team *nudge* *nudge*
[02:23] <pochu_> good night folks
[02:26] <persia> Does anyone use clive?  I can't get it to work at all, regardless of whether I add the recommended RC patch.
[04:06] <leonel> WHAT ????  icedtea  on gutsy universe ???
[04:07] <persia> leonel: Why not?
[04:08] <leonel> no no  this is GREAT !!!!!!
[04:08] <leonel> didn't expected  till hardy
[04:08] <leonel> WHOO HOO \o/
[04:09] <persia> leonel: don't get too excited.  We're not supposed to do anything with it until the hardy cycle.  Consider it part of the build chain :)
[04:09] <leonel> persia: right
[04:09] <leonel> but .. this is  great news ..
[04:09] <leonel> thank you all ..
[04:10] <leonel> been waiting for java to be gpl  since ..  years ...
[04:17] <pwnguin> icedtea?
[04:17] <pwnguin> is that a codename for java7?
[04:18] <minghua> It's the code name for the GPL'ed java from Sun added with various other parts that Sun didn't release under GPL.
[04:18] <minghua> I _think_ it's java 6.
[04:19] <superm1> it says java7 in the package names in universe
[04:21] <persia> I believe it's currently a pre-7 version: 7 API, but not complete (beta 2?)  See http://iced-tea.org/wiki/Main_Page
[04:45] <persia> Glah!  Anyone have thoughts on the feasibility of a snort package split including NEW processing to support bug #149341?
[04:45] <ubotu> Launchpad bug 149341 in snort "Snort is not starting in amd64 - gutsy" [Undecided,New]  https://launchpad.net/bugs/149341
[04:56] <minghua> persia: Why is a package split needed?
[04:57] <persia> minghua: The plugins are Architecture: all, so they don't work for !i386
[04:59] <slangasek> you mean the plugins are Arch: all when they shouldn't be?
[04:59] <persia> slangasek: Yep.  See Debian bug #429642 for discussion
[04:59] <ubotu> Debian bug 429642 in cjk "please update libkpathsea4-dev build-dependency" [Normal,Fixed]  http://bugs.debian.org/429642
[05:00] <persia> Um.  Debian bug #439642
[05:00] <minghua> persia: Yeah, reading the Debian bug now, got it.
[05:00] <ubotu> Debian bug 439642 in snort "Snort does not work on amd64, tries to load 32-bit libraries" [Grave,Fixed]  http://bugs.debian.org/439642
[05:00] <minghua> The Debian maintainer put those modules in snort-libraries.
[05:01] <slangasek> "snort-libraries"?
[05:02] <persia> slangasek: A NEW package.  That's why I ask: otherwise it's just an RC sync request.
[05:02] <slangasek> snort-common-libraries, in Debian?
[05:02] <minghua> slangasek: Yes, snort-common-libraries.  I was reading the debian/changelog, and it got the binary package name wrong.
[05:03] <slangasek> ah, heh
[05:05] <persia> Builds fine on our toolchain anyway.  I'll open the sync request, expecting rejection if NEW is not getting processed again before release.
[05:09] <slangasek> time allowing, it seems like an obvious fix to accept
[05:09] <slangasek> if the diff is sane
[05:11] <ubotu> Launchpad bug 152205 in snort "Please sync snort 2.7.0-6 (universe) from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/152205
[05:19] <bddebian> go persia, go persia :-)
[05:21] <persia> bddebian: I've got two that completely stumped me.  One depends on Youtube and Google Video, and the other on eBay, which dependencies I've having issues with.  Wanna help?
[05:22] <bddebian> I can try but man that sounds bogus :-)
[05:23] <persia> bddebian: Debian bug #430433 and Debian bug #442369
[05:23] <ubotu> Debian bug 430433 in clive "no longer works for Google video" [Grave,Fixed]  http://bugs.debian.org/430433
[05:23] <ubotu> Debian bug 442369 in esniper "esniper: unable to find auction --> solved in CVS" [Grave,Fixed]  http://bugs.debian.org/442369
[05:24] <persia> clive is a UVFe, but I've not been able to get either the gutsy or sid packages to work enough to complete the test report part.  I haven't dug into esniper.
[05:26] <bddebian> So what do you want me to do?  Look at esniper or help with clive?
[05:26] <persia> bddebian: I'm not going to make any progress with either of those, and there's all the "Serious" bugs to go...  Take your pick.  If you choose clive, I can comment about the patch.
[05:29] <bddebian> Has the clive UVFe already been filed?
[05:29] <persia> bddebian: No.  I only file the requests if I can test: otherwise it's just another bug :)
[05:30] <bddebian> Hmm, doesn't look like it
[05:30] <persia> Any xen people around?
[05:33] <ubotu> Debian bug 444784 in xenman "xenman doesn't run at all" [Grave,Fixed]  http://bugs.debian.org/444784
[05:49] <bddebian> Hmm, with clive I keep getting type 'exceptions.TypeError'>
[05:50] <persia> bddebian: That was my problem.  I wonder if it's due to other Debian<->Ubuntu issues (e.g. python)
[05:51] <persia> The annoying bit is that it's hard to test against the previous release of YouTube, to see if that error comes from the YouTube update or the clive change.
[05:52] <bddebian> Does Debian still not do python2.5?  Maybe it's a 2.5 vs 2.4 issue?
[05:53] <minghua> bddebian: Debian has 2.4.
[05:53] <persia> bddebian: Does it work if you force python2.4?
[05:53] <minghua> If it's really important, I can test on Debian unstable here.
[05:54] <bddebian> It not important to me :-)
[05:54] <persia> minghua: That'd be great.  We're comparing clive 0.2.0-1.1 and 0.2.1-1
[05:54] <minghua> Okay.
[05:54] <persia> bddebian: Bah.  It should be.  It's our new shiny release ;)
[05:55] <bddebian> Here is the traceback I get:  http://pastebin.com/m4598fdc0
[05:55] <minghua> Nah, it's universe.  ;-)
[05:56] <bddebian> maybe a urllib2 issue?
[05:56] <persia> minghua: Right.  Therefore noblesse oblige applies for MOTUs (in regards to packages)
[05:57] <minghua> persia: clive 0.2.1-1 in Debian unstable works fine for a Google video here.
[05:57] <persia> minghua: And clive 0.2.0-1.1 breaks?
[05:57] <minghua> persia: Not tested yet.
[05:59] <minghua> I don't see why 0.2.0-1.1 could work, though.
[06:01] <persia> minghua: I'm expecting it not to work, but verifying the patch means it's just a python2.4 => python2.5 port, rather than also chasing the "cannot get the video" issue.
[06:03] <minghua> persia: Sure, I'll test soon.  The video I'm downloading is a bit big, and I want to keep it. :-)
[06:03] <bddebian> heh
[06:04] <persia> minghua: No rush.  I'm not cool enough with python to port it anyway (or at least my facsimile of python probably shouldn't be uploaded this close to release)
[06:04] <bddebian> Heh, me either
[06:06] <minghua> Err...
[06:07] <minghua> Three blind people trying to get a map, it looks like.
[06:08] <persia> minghua: Sure, but if we get the info, we can create a meaningful bug, and maybe someone will fix it :)
[06:12] <persia> Any asterisk users around?
[06:14] <bddebian> hah, asterisk is a pig.  I fixed rate-engine at one point and I think it's broken again
[06:16] <persia> bddebian: asterisk-oh323 FTBFS.  The fix appears to be a CVS snapshot, which doesn't seem sane.  Do you feel like testing, or digging out the useful patch?
[06:16] <minghua> Poor bddebian.
[06:16] <bddebian> I'm going to have to go to bed very soon :-(
[06:16] <persia> minghua: You want a couple?
[06:16] <bddebian> heh
[06:17] <ubotu> Debian bug 367745 in battery-stats "battery-stats: must use invoke-rc.d" [Serious,Fixed]  http://bugs.debian.org/367745
[06:17] <minghua> persia: No, thanks. :-)
[06:17] <persia> heh
[06:18] <persia> minghua: Do you use anything on http://django.ajmitch.net.nz/rcbugs ?
[06:18] <bddebian> How the fluck am I going to test esniper.  I'm not bidding on anything
[06:18] <persia> bddebian: That was my issue :)
[06:19] <minghua> And you need to bid on something that ends auction before the freeze deadline, I suppose? :-)
[06:20] <persia> minghua: Enough before that there is time to find, merge, and upload the patch too.
[06:20] <persia> ajmitch: Can we have comment deletion?  Also, comments per-bug, rather than per-package?
[06:21] <bddebian> ajmitch: Just fix all the bugs and you won't need it ;-P
[06:21] <ajmitch> persia: I did have comment deletion, but it didn't work so well
[06:21] <ajmitch> and I am changing it to per-bug
[06:21] <minghua> persia: Hmm, I use gbdfed.
[06:21] <ajmitch> since too many people have asked for that
[06:21] <persia> ajmitch: Didn't work technically, or didn't work socially?
[06:22] <persia> minghua: Great.  Thanks.  #444530 is all yours :)
[06:22] <ajmitch> persia: 'delete' being done by HTTP GET is a Bad Thing :)
[06:22] <minghua> persia: But Debian bug 444530 is already fixed in 1.2-3ubuntu1.
[06:22] <ubotu> Debian bug 444530 in gbdfed "gbdfed: FTBFS: error: 'GtkFileSelection' undeclared" [Serious,Fixed]  http://bugs.debian.org/444530
[06:22] <ajmitch> persia: so I turned that off for now..
[06:22] <minghua> persia: One down.  What next?  ;-)
[06:22] <persia> ajmitch: HTTP POST maybe?
[06:23] <ajmitch> that would work, but I didn't have time to care about it, and noone really cared too much
[06:23] <persia> minghua: Add a comment saying it's fixed, and hunt another one.  I find about 75% of them are already fixed.
[06:24] <persia> ajmitch: Understood.  This is much preferable to the version I was looking at immediately post auto-sync freeze.
[06:25] <ajmitch> which was?
[06:26] <persia> ajmitch: closer to http://ajmitch.net.nz/~ajmitch/missing-fixes-rc.html, but the CSS was different.
[06:26] <ajmitch> right
[06:27] <persia> And even that was better than the feisty release version: the grab links are very helpful.
[06:28] <bddebian> ajax is cool
[06:28] <ajmitch> when used properly
[06:28] <bddebian> Like anything :-)
[06:28] <imbrandon> man i dont think i've written this much php code in years
[06:29] <ajmitch> imbrandon: have pity on people like me to do it every day
[06:29] <persia> Could be nifty, but that's a lot of traffic.  For AJAX, I'd much prefer POST delete, and behind-the-scenes comment update so I didn't get bumped back to the top of the page.
[06:29] <imbrandon> ajmitch: hehe yea i used to , kinda wish i kept that job at times
[06:29] <ajmitch> persia: the comments thing was the only part I'd intended to do
[06:29] <minghua> persia: clive 0.2.0-1.1 is confirmed NOT able to download Google video, but seems to be working otherwise.
[06:30] <ajmitch> fetching bugs would be interesting, but not that useful
[06:30] <persia> minghua: Excellent.  Thanks for testing.
[06:30] <minghua> persia: (i.e.: I got a curses dialog window saying it can't download the video.)
[06:30] <imbrandon> ajmitch: dunno if you ever looked at wordpress it is quite nice code wise though
[06:30] <imbrandon> even though i spent the last 6 hours hacking on it
[06:30] <imbrandon> heh
[06:31] <minghua> bddebian: It's quite hard to write cool code in Fortran 77.  I heard about COBOL as well. :-)
[06:31] <imbrandon> cobol is nice for system bios's
[06:31] <imbrandon> so i hear
[06:32] <ajmitch> no, that's forth
[06:32] <bddebian> heh
[06:32] <imbrandon> serouisly ? i was always told it was cobol mostly for like pheonix and ami etc
[06:32] <bddebian> I doubt that
[06:32] <bddebian> It was a Business language
[06:33] <bddebian> Common Business Object Language or some bullshit like that
[06:33] <ajmitch> forth is used for open firmware
[06:33] <imbrandon> no idea, i never used anything prior to C on x86 ( and only BASIC on the Atari 800, APPLE //e and C64 before that )
[06:33] <persia> Actually, about clive, is there any reason not to force it to use python2.4?
[06:35] <imbrandon> wow i would have thought it would be a asm/c mixture ajmitch
[06:35] <imbrandon> shows what i know ;)
[06:35] <bddebian> persia: If we knew that worked I suppose
[06:36] <imbrandon> one simple question though someone in here is likely to know, is inline ASM part of plain ( ANSI ?? ) c ?
[06:36] <persia> bddebian: It worked for minghua.  Do I need to do anything other than adjust XS-Python-Version: in debian/control?
[06:37] <bddebian> Depends on the package but ideally that should work
[06:38] <minghua> imbrandon: I think it is.  I have C reference manual handy, let me check.
[06:39] <imbrandon> minghua: sweet, thanks
[06:40] <minghua> imbrandon: No it's not.  "asm" is listed as "C++ reserved words" (for compatibility reasons, with word such as class) in the manual.
[06:40] <imbrandon> hrm okie
[06:42] <persia> Hrm.  Now I get http://paste.ubuntu-nl.org/40493/.
[06:43] <persia> Nevermind.  I fixed it.  Thanks bddebian, minghua.
[06:44] <bddebian> Well what was it man?
[06:44] <persia> Down to 2 (two) grave bugs!
[06:44] <persia> bddebian: #!/usr/bin/python -> #!/usr/bin/python2.4
[06:44] <bddebian> Rockin'.  esniper and what else?
[06:44] <persia> bddebian: xenman
[06:44] <bddebian> Ah, that's hideous
[06:44] <ajmitch> persia: good work
[06:45] <bddebian> Oh I wouldn't touch xen stuff with a 20 foot pole :-)
[06:45] <bddebian> Poke zul, he's the only xen master I know of
[06:45] <persia> ajmitch: It's mostly been research: most of it is fine, just not reported.
[06:45] <minghua> bddebian: Go set up an auction so that persia can test bidding on it using esniper. :-)
[06:45] <persia> bddebian: I think it's fixed, but it's a matter of comparing zul's work to upstream/debian.  If xenman launches, there's no bug.  I just can't seem to get enough of xen happy enough to do anything.
[06:46] <persia> bddebian: What do you have that I want to buy?
[06:46] <ajmitch> persia: so, should the next revision of this page give some way to mark a bug as done, in some css style?
[06:46] <persia> minghua: We'd have to register, no?
[06:46] <minghua> persia: I suppose yes.
[06:46] <ajmitch> that way you'd be able to see quickly what needs checked
[06:47] <bddebian> I have shitloads of programming books I've never gotten through ;-)
[06:47] <persia> ajmitch: That'd be great.  There's a lot of comments indicating that someone requested a sync, or is working on it, but the followup isn't automatic.  It'd be extra nice if we could enter LP bugs or revision candidate versions, and have it track the status of those.
[06:48] <bddebian> I have the whole TaoCP set and I can barely get through the first few chapters :-(
[06:48] <persia> minghua: Do you have an ebay account?
[06:48] <ajmitch> persia: that would be trickier, but possible, I guess
[06:48] <minghua> persia: Yes I do.
[06:49] <persia> ajmitch: Depends on how much time / thought you have.  Just a flag would be nice (although it likely won't impact gutsy much).
[06:49] <persia> minghua: Could you please sell bddebian a used, and somewhat tarnished copy of TaoCP?
[06:49] <minghua> I think we are trying too hard to fix esinper, though.
[06:49] <persia> minghua: Too hard?  Why?
[06:49] <bddebian> hah, tarnished copy :-)
[06:50] <minghua> persia: I don't have a TaoCP copy.
[06:50] <persia> minghua: That's find, bddebian will gladly donate his to the auction :)
[06:50] <persia> s/find/fine/
[06:50] <bddebian> heh
[06:50] <minghua> persia: I was really joking when I suggested bddebian to set up an auction...
[06:50] <bddebian> Frickin' set cost me like $400 and I'm too stupid to even get through them :'-(
[06:51] <minghua> bddebian: You sure you want to do this?  I've never sold anything before.
[06:51] <persia> minghua: It's a great way to test.  I can't think of another one that works.  Although, perhaps selling something of less general interest might be better, as TaoCP might get lots of other bids, raising the price of the commission for the experiment.
[06:52] <bddebian> Got some shiny keychain? :-)
[06:52] <ajmitch> bddebian: give up the hurd & start reading
[06:52] <minghua> What about a gutsy CD?
[06:52] <bddebian> I haven't done much of squat for the Hurd in a while :-(
[06:52] <minghua> bddebian: Don't expect my really sending the item to you...
[06:53] <persia> minghua: Just specify electronic delivery.
[06:53] <bddebian> No way, I want it!! :)
[06:53] <minghua> electronic delivery for a keychain?  or a CD?
[06:53] <minghua> Hmm, what about gutsy ISO image file? :-P
[06:54] <minghua> And a pre-order at that.
[06:54] <bddebian> Whatever but if we are going to try it, lets do it, I have to get my old arse to bed.. :-)
[06:55] <persia> bddebian: Just to make sure, you have an Ubuntu compilation with the esniper fixes ready, right?
[06:55] <minghua> Okay.  But maybe it'll take me a while to set up an auction...
[06:56] <bddebian> persia: I took the Debian package.  It has the fixes, no?
[06:56] <persia> bddebian: Should, but it's a snapshot.  Is there a tighter patch that doesn't need UVFe?
[06:57] <bddebian> I didn't go that far since I didn't know how to test it
[06:58] <persia> I think it's safe to assume the debian version works (the maintainer should have tested).  I don't think a snapshot is a problem, but it might be extra work to get it approved (vs. pulling a patch).
[06:58] <imbrandon> wow i just realized this release will mark 3 years of ubuntu for me :)
[06:59] <ajmitch> imbrandon: you're old
[06:59] <imbrandon> err i guess starting 3 year, so 2.5
[06:59] <imbrandon> i guess
[06:59] <imbrandon> ajmitch: heh
[06:59] <persia> imbrandon: Warty start?
[06:59] <imbrandon> end of warty
[07:00] <imbrandon> very end
[07:01] <persia> That was my start also.  Around when I discovered that bddebian would upload all the fixes I wanted to see in Debian without waiting for the maintainer to have an opinion :)
[07:01] <imbrandon> heh
[07:02] <imbrandon> i went from SuSE to this new fanagled "ubuntu" thing from a slashdot post about kbfx and someone had it packaged so i installed to try it, and then started fixing bugs in it from almost day one ( kbfx ) , only 6 months to almost a year later did i even look at debian ;)
[07:02] <minghua> Argh.  Ebay wants to charge me $0.20 for listing.
[07:03] <imbrandon> minghua: craigslist ftw, i LOVE craigslist ( and its free )
[07:03] <persia> imbrandon: craigslist doesn't help us test esniper :(
[07:03] <imbrandon> ahhh ok
[07:03] <minghua> imbrandon: Yeah... if you can test esniper on craigslist...
[07:03] <imbrandon> heh i thought you were selling something
[07:04] <persia> imbrandon: Do you have a better suggestion for testing?  That's the best we could develop.
[07:04] <imbrandon> hrm
[07:04] <persia> (selling an Ubuntu CD)
[07:04] <imbrandon> put ebay.com in your host file and look at the http requests ?
[07:05] <minghua> persia, bddebian: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=140167990751
[07:05] <imbrandon> hehe that would take a bunch of mockup work though
[07:05] <bddebian> persia: heh
[07:05] <StevenK> Or tcpdump
[07:05] <minghua> bid away.
[07:05] <StevenK> Hah. "I'll e-mail you an ISO when Gutsy is released."
[07:05] <minghua> I'm selling an ISO file by the way, to make sure I can deliver...
[07:05] <StevenK> (Basically)
[07:06] <imbrandon> hahah
[07:06] <StevenK> persia: Sign in, Place bid
[07:07] <imbrandon> i just made a .50 bid ( holtsclawb )
[07:08] <persia> bddebian: Are you sniping yet?
[07:09] <minghua> I suspect you can only snipe just before the auction ends...
[07:11] <minghua> Thanks for the business, imbrandon. :-)
[07:11] <bddebian> Do you have to use an auction file?  I don't see any way to specify the auction # otherwise??
[07:18] <bddebian> Sorry gang, I have family coming over tomorrow, I have got to get to bed.  Good luck.
[07:22] <persia> In the clive source, there is a ./scripts/clive with #!/usr/bin/env python at the top.  When I build, this generates /usr/bin/clive with #!/usr/bin/python at the top.  I tried changing the source to #!/usr/bin/python2.4, but the result was still #!/usr/bin/python in /usr/bin.  Any suggestions on how to block this apparent auto-adjustment?
[07:51] <minghua> persia: So I'll just leave the auction there (it ends in 22 hours).  Good luck fixing esniper.
[07:52] <persia> minghua: Thanks for hosting.  I'm hoping for another volunteer before then, but I'll give it a shot there's not a solution in a while.
[07:53] <ubotu> Debian bug 442369 in esniper "esniper: unable to find auction --> solved in CVS" [Grave,Fixed]  http://bugs.debian.org/442369
[07:56] <minghua> I still think we are trying too hard to fix this bug, but I appreciate persia's perseverance.
[07:57] <persia> minghua: There's only three left.  I'm chasing one, zul is the only person qualifies to have an opinion on another, and esniper is the last.
[07:58] <minghua> persia: Why only three?  I see plenty on ajmitch's list.
[07:58] <minghua> Or are we talking about only "grave" status?
[07:59] <persia> minghua: Three "Grave".  I went through the "serious" ones quickly yesterday, it most of them look like FTBFS issues, most of which have been addressed.  I'm expecting to finish commenting them, and determining which needs to get fixed today.
[07:59] <persia> s/which needs/which need/
[09:06] <persia> Any python packagers around?
[09:07] <Fujitsu> persia: I've done a bit of it in the past, but am not at all an expert.
[09:10] <persia> Fujitsu: I'm trying to force python2.4 for clive (which doesn't work with 2.5).  I've set XS-Python-Version: 2.4 in debian/control, Build-Depends: on python2.4-dev, and set PYVERS=2.4 in debian/rules.  The source scripts/clive starts with a header of "#!/usr/bin/env python" which is replaced by the build system to "#!/usr/bin/python".  I'd prefer it was "#!/usr/bin/python2.4", but manually changing this in the source doesn't seem to affect the bi
[09:11] <StevenK> persia: "doesn't seem to affect the ..."
[09:11] <Fujitsu> binaries, I presume.
[09:11] <StevenK> I'm guessing the build system changes it with a patch
[09:12] <persia> StevenK: debian/patches is empty, and there's no patch rule.  Also, there's no complaint about fuzz if I change the line manually.
[09:12] <persia> Fujitsu: I'm working from http://http.us.debian.org/debian/pool/main/c/clive/clive_0.2.1-1.dsc
[09:13] <Fujitsu> persia: Ah, I've only got 0.2.0-1.1.
[09:13] <persia> Fujitsu: I'm fairly sure it has the same problem, so that should be fine.
[09:13] <persia> (at least the error message when launching is the same)
[09:14] <Fujitsu> persia: Yeah, it does override it somehow.
[09:14] <persia> Fujitsu: Thanks.  Let me know if you can get a working debdiff: I want to request a UVFe :)
[09:17] <Fujitsu> persia: It must be something in setuptools, but I haven't dealt with that much.
[09:18] <imbrandon> there hopefully i have rid myself off joins/parts/quits etc
[09:21] <Fujitsu> persia: Running setup.py from a clean tarball still overrides it, so it must be some setuptools magic.
[09:21] <persia> Fujitsu: That's what I thought (and why I'm confused(
[09:21] <persia> Thanks for the confirmation.  I'll dig into it a bit more.
[09:22] <imbrandon> ugh, when will people stop refering to Microsoft as M$ of Microshaft or similar, it just makes them look ..... well not good imho
[09:22] <highvoltage> imbrandon: indeed
[09:23] <highvoltage> what's ironic is, it's the type of people that would call me a linux zealot and call me fanatical who would use such words
[09:23] <highvoltage> it just discredits them completely
[09:23] <imbrandon> :)
[09:24] <imbrandon> we need a "homer" for ubuntu that acts like "clippy" for win95
[09:24] <imbrandon> ;)
[09:49] <imbrandon> highvoltage: check out my last post http://www.imbrandon.com/
[10:17] <highvoltage> imbrandon: I don't think you're completely right though
[10:18] <highvoltage> imbrandon: calling Microsoft name isn't a characteristic of the Ubuntu community, it's only a small, loud percentage of people who do that
[10:19] <ajmitch> usually a very vocal minority
[10:19] <highvoltage> indeed
[10:20] <highvoltage> but I think it's a bit unfair to label the Ubuntu community as namecallers, especially when the vast majority of people are *very* decent.
[10:24] <DarkMageZ> but the problem is that because of those who do, it makes the majority look bad as well.
[10:25] <highvoltage> DarkMageZ: yes, although that doesn't make it right to generalise the entire community
[10:26] <highvoltage> then you could just as well say that the entire ubuntu community is racist, sexist, elitist, etc, just because there's been some isolated cases that's been thrown out of proportion
[10:30] <DarkMageZ> he wasn't saying everyone was guilty tho. he was saying that there are people.
[10:30] <highvoltage> yeah
[10:34] <DarkMageZ> i'd like to see the name calling & propaganda (from both sides) to stop. it's like smoke, and the sooner it clears completely then the sooner everyone can get to fighting on a pure product quality level.
[12:05] <RainCT> Hi
[12:34] <persia> I'm trying to get a package to use python2.4 instead of python2.5.  My last problem is that distutils is installing a script, and performing the standard interpreter magic during installation, changing "#!/usr/bin/python2.4" to "#!/usr/bin/python".  I understand that distutils can take an option --executable to modify the magic, but I've been unable to determine how this should be represented in setup.py (or debian/rules).  Does anyone have a sug
[12:36] <Fujitsu> persia: Your message was truncated again.
[12:36] <persia> Fujitsu: Thanks.
[12:37] <persia> Basically, distutils has a script function, which will install the named files in $target/bin, and update the interpreter to be the interpreter running at installation time.
[12:37] <Fujitsu> Ah.
[12:38] <persia> There is an argument "--executable" which can control which executable is used when adjusting the interpreter for the script.
[12:38] <persia> I can stuff that into setup.py (but don't know how), or I can ignore python, and just install the file.
[12:49] <ajmitch> persia: DEB_PYTHON_INSTALL_ARGS_ALL += --executable
[12:49] <ajmitch> if it's cdbs :)
[12:49] <ajmitch> I don't understand what you're asking about stuffing things into setup.py
[12:50] <pochu> wow soren, I wanna a piece of cake :-)
[12:52] <persia> ajmitch: Excellent.  Thank you.  It's not CDBS, but I can extract from there.  (I thought I needed to stuff setup.py because setup.py appears to be calling distutils, but my knowledge of python packaging is particularly weak).
[12:52] <Fujitsu> ajmitch: Sticking --executable on the end of setup.py's build or install targets doesn't seem to be working.
[12:53] <ajmitch> Fujitsu: that's unfortunate - is setup.py being called with python2.4?
[12:53] <Fujitsu> Ah, wait, I think that worked...
[12:54] <Fujitsu> Why would it only work in 2.4!?
[12:54] <ajmitch> because it's picking up the python version to use from the version used to run setup.py?
[12:55] <Fujitsu> Oh, you stupid distutils. It won't rebuild it if the destination doesn't exist.
[12:55] <Fujitsu> So adding --executable does work.
[12:55] <ajmitch> :)
[12:56] <persia> Just to make sure I understand (in case I ever encounter this again), arguments passed to distutils should be added to setup.py in debian/rules, but distutils tries to be extra smart, and checks to make sure you really mean it when you provide them?
[12:57] <ajmitch> distutils is pretty special
[02:42] <rick_h> anyone around? Wondering if my package I'm trying to do only has /usr/share files in it if it points to a messed up rules file?
[02:53] <persia> rick_h: It can be a lot of different things.  How to you build your package?
[02:56] <rick_h> I did the manual process of creating the debian dir and the main files of control/etc in a newly downloaded source
[02:56] <rick_h> I'm just thinking I cheated by grabbing a control from a similiar package
[02:57] <rick_h> it's a pidgin plugin my friend asked if I could do
[02:57] <persia> rick_h: No, that's not a bad thing.  One just has to be careful.  When you build the binary, do you use debuild locally, or a build system?
[02:57] <rick_h> I did dpkg-buildpackage -rfakeroot
[02:58] <rick_h> but when I view the file listing of the resulting .deb it only use /usr/share/Changelog and such
[02:58] <persia> rick_h: That's what debuild does :)  While generally I'll recommend you'd get more reproducible results with sbuild or pbuilder, the way you've done it makes hunting down the issue much easier.
[02:59] <persia> In debian rules, are you using debhelper, cdbs, or just a raw makefile?
[03:00] <rick_h> I think I'm getting something. I decided to try to go the debhelper path and it won't build with errors I didn't get doing it manually
[03:00] <rick_h> the rules file was just a makefile I believe
[03:01] <persia> rick_h: A rules file is always a makefile, but many packages use debhelper rules files, where most of the rules call debhelper helpers in different ways, and some packages use CDBS, which does extra make magic.
[03:02] <persia> For any debian/rules file, the rule that actually prepares for the .deb is the install: rule.  For debhelper, the two interesting commands are usually $build-system install and dh_install.
[03:03] <persia> So, you can test to see what it's doing by running `debian/rules install` from the package directory.  You'll want to have to put things in either debian/tmp/usr/... or debian/packagename/usr/...
[03:03] <rick_h> ok, I see that. The one I copied from is a debbuilder rules file
[03:04] <rick_h> ok, that's good to know and makes sense
[03:05] <persia> So, if you call the install: rule, what does your package do?
[03:09] <rick_h> well, I get a bunch of output
[03:10] <rick_h> I'll try to pastebin it
[03:11] <rick_h> http://paste.avwsystems.com/paste/48
[03:14] <persia> rick_h: line 20 appears to be installing things in /home/rharding/packaging/musictracker/musictracker-0.4.1_manual/debian/pidgin-musictracker/usr/lib/pidgin/.  Do you see files there?
[03:14] <persia> umm..  rather home/rharding/packaging/musictracker/musictracker-0.4.1_manual/debian/pidgin-musictracker/ (sorry)
[03:16] <rick_h> ok, yea, the files are there
[03:17] <rick_h> but when I look at the .deb and the files included and they're not there
[03:18] <persia> That's OK.  We're not done looking yet :)  At this point, you can be certain that 1) your upstream build system is doing the right thing, and 2) Your debian/install file is taking care of the missing bits.
[03:19] <persia> I'm presuming this is an architecture-dependent package.  Please correct me if I'm wrong.
[03:19] <rick_h> yea, it is
[03:19] <persia> The next place to look is the binary-arch rule.  This should contain information about actually creating the deb.  When you call that, does it show what's happening?
[03:23] <rick_h> ok, in over my head. "binary-arch" rule? do you mean this section of the rules file? http://paste.avwsystems.com/paste/49
[03:24] <persia> rick_h: No worries.  it looks deep, but there's lots of rocks :)  That's the rule.
[03:25] <rick_h> ok, so how am I "calling" that part of the rule to check it?
[03:26] <persia> You mentioned that you had the changelog, so dh_installchangelogs ChangeLog probably did the right thing.  Try calling the rule, and seeing what happens.  At a first guess, I suspect that this rule is installing to debian/tmp/
[03:26] <rick_h> Yea, the changelog I created from scratch with dch --create
[03:27] <rick_h> what I'm missing is that I ran the ./debian/rules install and have that output. Now you're saying to "call this rule"
[03:27] <rick_h> is that different from what I did before?
[03:28] <rick_h> oh duh, I see...each of those is a runtime option
[03:29] <persia> rick_h: Sorry.  `debian/rules binary-arch`
[03:31] <rick_h> I follow ya, so there's this line in the output which seems to explain why the files are in the package structure
[03:31] <rick_h> test -z "/usr/lib/pidgin" || mkdir -p -- "/home/rharding/packaging/musictracker/musictracker-0.4.1_manual/debian/pidgin-
[03:31] <rick_h> musictracker/usr/lib/pidgin"
[03:31] <rick_h> then again, /usr/lib/pidgin is ls-able from my chroot
[03:32] <rick_h> http://paste.avwsystems.com/paste/50
[03:32] <rick_h> that's the output of binary-arch
[03:32] <lamego> rick_h, are you working on a musictracker piding plugin ?
[03:33] <persia> This looks like line 20 of the install: rule from before.  Is it different?  Also, the -z test is whether the string is empty, so -z "/usr/bin/pidgin" is always false.  I suspect it was originally written as -z $(which pidgin) just to verify that pidgin was available.
[03:33] <rick_h> packaging it
[03:33] <lamego> rick_h, have you checked http://www.getdeb.net/app.php?name=pidgin-musictracker ?
[03:33] <rick_h> of course my friend saw I've been trying to learn to package and hit me up
[03:33] <lamego> ok :)
[03:33] <persia> lamego: Is source available from there?
[03:33] <rick_h> heh, no...I didn't look
[03:34] <lamego> persia, yes, it was packaged by me, all getdeb packages have the source available
[03:34] <persia> lamego: I just don't see a link from that page.  How do I download it?
[03:34] <lamego> http://www.getdeb.net/release.php?id=1562, Developers: Source, Diff
[03:35] <lamego> I need to add the source and diff links to the app entry page
[03:35] <rick_h> I see src/diff links on the page
[03:35] <lamego> it is, on the release, not on the app entry :)
[03:35] <rick_h> oic
[03:35] <persia> Ah.  I had thought that the links to 1562 and 1563 would give me downloads :)
[03:36] <persia> lamego: I like your debian/rules :)
[03:36] <lamego> well, I like clean cdbs rules, something that you can read on a few lines ;)
[03:37] <persia> rick_h: You've a choice.  You can grab lamego's debian rules, or keep investigating your build issue.  Which would you like?
[03:37] <rick_h> well, my point is to learn so I'll keep playing
[03:37] <rick_h> where did you find his rules?
[03:37] <lamego> http://www.getdeb.net/archive/pi/pidgin-musictracker_0.4.1-1~getdeb1.diff.gz
[03:38] <lamego> debian/rules
[03:38] <rick_h> ok, in the debdiff
[03:38] <persia> Actually, in the diff.gz.  A diff.gz represents the distribution variance from upstream.  A debdiff represents the differences between two distribution revisions.
[03:39] <rick_h> ok
[03:39] <rick_h> so those what, 7ish lines are the rules file?
[03:40] <persia> rick_h: Yes.  That's an example of a CDBS rules file.  When they work, they are very small.  When they don't work, the investigation requires a deep understanding of make.
[03:40] <rick_h> ah, ok
[03:40] <rick_h> I haven't gotten to trying out anything with cdbs yet
[03:40] <lamego> they should be 4 lines, forgot to remove the template extra lines :P
[03:42] <rick_h> ok, so I can't really use this one to help me figure out what I'm doing wrong then
[03:42] <persia> rick_h: Nope.  If you want to get it packaged quickly, using lamego's code will help.  If you want to understand what went wrong, troubleshooting yours is probably better.
[03:43] <rick_h> ok, I'll keep at mine then
[03:43] <rick_h> nothing like beating your head on the wall doing things the hard way to tech you :-)
[03:44] <persia> So, looking at your ouput, it runs the install rule (the beginning is very similar to what we saw before), and then it runs all the debhelper stuff (from around line 70)
[03:45] <rick_h> ok
[03:45] <rick_h> so the files required are put in that long subdir and debhelper isn't picking them up?
[03:45] <persia> It's safe to ignore the first bit, as you already reviewed to make sure the files were being put where you wanted them.  Most of the debhelper lines are reporting "Compatibility levels before 4 are deprecated.".  Do you have a debian/compat file?
[03:45] <persia> rick_h: Right.
[03:46] <rick_h> so where *should* the files be going that debhelper likes to see them?
[03:47] <rick_h> there's a make rule in the rules file: $(MAKE) install DESTDIR=$(CURDIR)/debian/pidgin-musictracker
[03:47] <persia> rick_h: You've put them in a fine place: many packages do it that way :)
[03:47] <rick_h> ah, ok
[03:48] <persia> Now the ChangeLog was installed in your deb, so you'll want to hunt in the debian/ directory to see where that was installed.
[03:48] <lamego> rick_h, what I found strange, is that, this particular software uses a standard autoconf build rule, if you used the default templates even using debhelper it should work "out of the box"
[03:48] <lamego> erm, find
[03:48] <rick_h> ok, the files that made it to the package are in the debian/tmp dir
[03:49] <rick_h> while the files I NEED are in debian/$package/...
[03:50] <persia> rick_h: Great.  Now, you have a couple choices.  I'll recommend you man debhelper, and read the "Package build directories" section for some background.
[03:50] <rick_h> ok
[03:51] <persia> Essentially, you want to verify that the binary package name in debian/control is pidgin-musictracker, and if so, you can either reset DESTDIR (or just delete the line), or add -p to all the rules that you want to apply to your package specifically.
[03:53] <rick_h> ok, thanks. I'll check that out
[03:54] <rick_h> the only thing in debian/control I guessed at is that I made both the source and package names pidgin-musictracker even though I downloaded the source as just musictracker
[03:54] <rick_h> does that matter at all?
[03:55] <persia> rick_h: Ideally you want the source package name to match upstream (and to match the base directory).  The binary packages can be whatever you want, although there are guidelines for some things (such as libraries begin with lib, etc.)
[03:57] <rick_h> ok
[03:57] <rick_h> thanks for the time/help
[03:57] <persia> rick_h: No problem.  Good luck, and come back here if you have other questions.
[04:28] <lucas> ajmitch: are you still active? your Debian packages seem to need a lot of love
[04:33] <Hobbsee> lucas: he'll be sleeping atm
[04:37] <Nafallo> https://launchpad.net/bugs/152333 < worthy of freeze exception?
[04:37] <ubotu> Launchpad bug 152333 in dbus-glib "gajim suggests dbus-glib which is not available" [Undecided,New] 
[04:38] <Hobbsee> Nafallo: should be fine.
[04:38] <pochu> Nafallo: looks sane to me, but I'm noone :)
[04:38] <Hobbsee> Nafallo: all unmet deps stuff should be fine
[04:38] <Hobbsee> assumign ti doesnt require mass changes.
[04:38] <Nafallo> kewl. I'll work on it then.
[04:38] <soren> pochu: It's pretty darn good, actually :)
[04:38] <Nafallo> if I can find what the package is called now ;-)
[05:31] <TheHobbit> I found a little dependace problem in mmm-mode package (and in others as well...) I *think* to have solved it and I posted a debdiff together with the bug, could someone review it? (bug is #152348)
[05:32] <persia> bug #152348
[05:32] <ubotu> Launchpad bug 152348 in mmm-mode "on feisty, the mmm-mode package forces installing emacs21 instead of emacs22" [Undecided,New]  https://launchpad.net/bugs/152348
[05:33] <Hobbsee> persia: i've let thru a whole bunch of your uploads, btw
[05:33] <TheHobbit> persia, I was surprised it wasn't
[05:33] <persia> Hobbsee: Excellent.  More to come :)
[05:34] <persia> Hobbsee: Can you do sync requests as well?
[05:34] <Hobbsee> nope
[05:34] <Hobbsee> heh, i knew someone would be asking that reallys oon now :P
[05:34] <persia> Hobbsee: congrats, btw.
[05:34] <Hobbsee> thanks
[05:35] <TheHobbit> persia, but I was happy it wasn't, giving me a bite size bug to fix ;)
[05:35] <persia> TheHobbit: That looks sane.  There's a couple administrative things you'll want to do:
[05:35] <persia> 1)  Link the bug to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433691
[05:35] <ubotu> Debian bug 433691 in mmm-mode "Update to support emacs22" [Minor,Open] 
[05:36] <persia> 2) subscribe the ubuntu-universe-sponsors group to request sponsored upload
[05:36] <persia> 3) Set the importance and status as appropriate
[05:37] <TheHobbit> will do
[05:37] <TheHobbit> thank you persia
[05:37] <persia> 4) modify the target distribution in the changelog to point to the current devlopment distribution ("gutsy")
[05:38] <TheHobbit> ok, lets start....
[05:38] <persia> Also, I'm not sure about depending on xemacs21-basesupport (>= 2003.11.13-1) if you want to use emacs > emacs21, but I don't really know much about emacs packaging.
[05:39] <persia> That's all I see.
[05:39] <TheHobbit> I do not use xemasc, so I'm not sure
[05:39] <TheHobbit> but xemacs does not furnish 'emacsen' as emacs?? packages do
[05:40] <persia> TheHobbit: It might be correct: I don't see an xemacs22, but ideally you'd want to test your new candidate also against xemacs, just to be sure.
[05:40] <TheHobbit> ok persia
[05:45] <TheHobbit> persia, I cannot see how to change bug importance... Is marked as read-only in the edit form
[05:45] <persia> TheHobbit: My apologies, but I found one more thing.  On the overview page for mmm-mode (https://launchpad.net/ubuntu/+source/mmm-mode/) it shows a 0.4.8-4, so you might want to look at that.
[05:45] <persia> If you can't change bug importance, don't worry about it now.
[05:54] <TheHobbit> persia, the error is still there
[05:54] <TheHobbit> Il do the patching on 0.4.8-4, then follow your advice on the other points
[05:56] <persia> TheHobbit: That's best.  If you prepare a 0.4.8-4ubuntu1, there's a (small) chance it may be accepted for gutsy.  Given that the RC is out, it may be that you'll need to respin for hardy.
[06:04] <TheHobbit> persia, a stupid question, may be.... but wich bug number must I write in control? debian bug # or ubuntu?
[06:05] <persia> You'll want to put the LP number, and make sure your syntax matches "(LP: #nnnnnn)"\
[06:06] <TheHobbit> LP?
[06:06] <pochu> LP == Launchpad
[06:06] <persia> TheHobbit: LaunchPad
[06:06] <TheHobbit> ok, so Close LP: #xxxx)?
[06:07] <TheHobbit> or (LP: ...)?
[06:07] <pochu> 'LP: #nnnn' is enough. But you can add Closes or brackets...
[06:08] <persia> pochu: You don't need parentheses?
[06:09] <pochu> persia: nope.
[06:09] <pochu> And 'LP: #nnnn, #nnnn, #nnnn' is allowed too.
[06:09] <persia> Cool!  My keyboard will last longer.
[06:12] <pochu> persia: this one is funny :) https://bugs.edge.launchpad.net/ubuntu/+source/tracker/+bug/138778/comments/7
[06:12] <ubotu> Launchpad bug 138778 in tracker "tracker doesn't find results for email address" [Low,Fix released] 
[06:12] <persia> pochu: And that worked for all those bugs?
[06:13] <pochu> yep
[06:15] <ubotu> Off-by-one error in the do_login_loop function in libwzd-core/wzd_login.c in wzdftpd 0.8.2 and earlier allows remote attackers to cause a denial of service (daemon crash) via a long USER command that triggers a stack-based buffer overflow.  NOTE: some of these details are obtained from third party information. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5300)
[06:21] <Hobbsee> there is
[06:21] <Hobbsee> in fact, there are 2.
[06:21] <Hobbsee> persia: same as teh new queue, but unnaproved, isntead of new
[06:21] <persia> Hobbsee: URL?  I want to see if wzdftpd 0.8.2-2ubuntu2 is waiting...
[06:22] <ScottK> persia: The actual regex is for LP: #nnnn so I think pochu's example was too abreviated, but the () is definitely not required technically.
[06:22] <Hobbsee> persia: https://edge.launchpad.net/ubuntu/gutsy/+queue?batch=500 is the new queue
[06:22] <Hobbsee> select the one you awnt in the dropdown
[06:23] <persia> Is it queue_state=1?  If so, I get an access denied error.
[06:23] <Hobbsee> persia: same url, but batch 500 shows all 500 of them :)
[06:23] <Hobbsee> yes, it is
[06:23] <persia> Ah.  batch shows all states?  Thanks.
[06:24] <Hobbsee> no, it doesnt
[06:24] <Hobbsee> it just shows more than the first 25
[06:24] <StevenK> No, batch shows everything on one page, not all states
[06:24] <Hobbsee> no, dont time out on me launchpad.
[06:24] <persia> Hrm.  I think there's still a permission thing.  https://launchpad.net/ubuntu/gutsy/+queue?batch=500 shows empty for me.
[06:25] <persia> ScottK: Thanks for the confirmation.
[06:27] <Hobbsee> persia: https://edge.launchpad.net/ubuntu/gutsy/+queue?queue_state=1&queue_text= ?
[06:27] <Hobbsee> oh, it might only be on edge.
[06:27] <superm1> Hobbsee, i'm on edge and i'm denied to that page too
[06:27] <Hobbsee> oh, i wonder if that's still non-public.
[06:27] <Hobbsee> persia: superm1 the other link (not updated quite as regularly) is http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/unapproved/
[06:28] <superm1> Hobbsee, probably.  I get "Sorry, you don't have permission to access this page. You are logged in as Mario Limonciello."
[06:28] <persia> "Not allowed here", "Sorry, you don't have permission to access this page.".  Oh well, perhaps I miss a couple, or send some dups.  No worries.
[06:28] <Hobbsee> superm1: odd.
[06:28] <Hobbsee> persia: i *think* that's updated every 5 min, but i'm uncertain on that piont
[06:28] <Hobbsee> i thought i remembered being able to view that page before tonight, maybe it was only new, and i didnt try unnaproved..
[06:30] <persia> Hobbsee: You were in certain teams before tonight...
[06:30] <Hobbsee> persia: it shouldnt require release to view, and admin to accept, surely...
[06:30] <Hobbsee> i would have expected it to be release for both
[06:30] <persia> Also, thanks.  5 minute resolution is surely enough.
[06:31] <Hobbsee> sorry, admin fro both
[06:37] <TheHobbit> ok, everithing is done except requiring "sponsored upload"
[06:37] <persia> TheHobbit: So, you've cleaned up the debdiff, retargeted to gutsy, and tested against xemacs?
[06:38] <blueyed> StevenK: do you think bug 152376 is sane?
[06:38] <ubotu> Launchpad bug 152376 in virtualbox-ose-modules "Load kernel driver (vboxdrv) during boot" [Undecided,New]  https://launchpad.net/bugs/152376
[06:39] <TheHobbit> except I can not be sure about the >= 2003.11.13-1 part for xemacs
[06:39] <persia> TheHobbit: That's fine.  If you tested against current, and it worked, leaving the versioned dependency is the safe thing to do (especially as you're only touching the packaging).
[06:40] <TheHobbit> also, I do not know packaging enough to know if I couldn't suppress emacs21 and emacs-snapshot, as they corresponds to virtual package emacsen
[06:41] <persia> TheHobbit: So, now you'll want to subscribe ubuntu-universe-sponsors.  You can see the current queue from https://bugs.launchpad.net/~ubuntu-universe-sponsors/, and a sponsor will upload if the have time before the release, and believe your change needs to be in gutsy.  Don't be discouraged if it doesn't get in: we're extra careful this close to release.
[06:43] <TheHobbit> persia, I choosen ubuntu, among other consideration, exactly because you are that carefull
[06:47] <TheHobbit> by "subscribe to" you mean join the team at https://launchpad.net/~ubuntu-universe-sponsors ?
[06:47] <pwnguin> uh
[06:47] <Hobbsee> no
[06:47] <Hobbsee> subscribe the team to the bug
[06:47] <Hobbsee> the team tells you not to join it if you're not a MOTU yourself.
[06:47] <Hobbsee> as will i, in my rejection email, if you do decide to try.
[06:48] <persia> TheHobbit: On the upper left in the bug window, there should be a link "Subscribe someone else".
[06:48] <Hobbsee> that must be why a whole lot of people are trying to join
[06:48] <Hobbsee> i've always wondered why, but assumed it's just from curiousity, and wanting to be a part of more teams.
[06:49] <TheHobbit> ah.... now I understand :) Sorry,
[06:49] <Hobbsee> even with the warnings on the page being blatantly obvious.
[06:49] <Hobbsee> perhaps its' just badly worded.
[06:49] <TheHobbit> Hobbsee, the warn is obvious, that's why I didn't and asked again instead:)
[06:49] <Hobbsee> TheHobbit: :)
[06:50] <Hobbsee> TheHobbit: obviously it's unclear enough for people to be asking in the first place though
[06:50] <TheHobbit> Hobbsee, what's new in that?
[06:50] <Hobbsee> new in which, sorry?
[06:51] <TheHobbit> no, sorry
[06:52] <TheHobbit> I didn't understand your remark at first reading
[06:52] <Hobbsee> ahh
[06:52] <TheHobbit> to much foreing languages at the same time do not help
[06:52] <Hobbsee> disclaimer:  i'm one of the admins of the sponsorship team
[06:53] <Hobbsee> hehe :)
[06:53] <persia> me suggests "This team offers sponsoring for the 'universe' component of the archive,  Please subscribe ubuntu-universe-sponsors to any bugs for which you wish to request sponsorship.  If you have been advised you need to join a team to assist with Ubuntu development, please investigate ubuntu-universe-contributors.  This team is restricted to developers: if you have questions, please ask in #ubuntu-motu on IRC or ubuntu-motu@lists.ubuntu.com.  M
[06:53] <persia> Blah.  Sorry.  I'll pastebin.
[06:56] <Hobbsee> persia: thanks
[06:56] <persia> Hobbsee: If you can figure out how to make "ubuntu-universe-contributors" a link to that team page, it would be even better.
[06:57] <TheHobbit> luckly enough, since I teached CS for 11 years in french:D
[06:57] <Hobbsee> hm, might work via wiki-style
[06:57] <Hobbsee> will have to look later
[06:59] <TheHobbit> see you
[07:01] <ScottK> StevenK, soren, or zul: Around?
[07:02] <Hobbsee> stevenk's long asleep, no idea on the others
[07:03] <ScottK> Well I think we need to discuss Universe freezes again and so was hoping to see who else was about.
[07:03] <persia> Should I stop pushing things?
[07:03] <ScottK> persia: No.
[07:03] <ScottK> persia: I'm discussing now so we don't suprise people on Monday.
[07:03] <persia> ScottK: Ah.  Good.
[07:04] <ScottK> Hobbsee: How much longer are you going to be up?
[07:04] <Hobbsee> not long
[07:05] <lamego> there is too much discussion about freezes on such a release critical period, those things should be properly defined at the release cycle beginning :P
[07:05] <Hobbsee> lamego: yeah, well
[07:05] <ScottK> Hobbsee: They've had 5 minutes. so I guess let's discuss...
[07:06] <ScottK> Hobbsee: I think we need to assume (based on the incomplete information we have) that the RM freeze is also the final freeze for Universe and we don't get extra time.  Make sense?
[07:07] <jpatrick> ScottK: I'll jot this down for the pack-guide
[07:08] <ScottK> persia: I just acked your clive uvfe.
[07:08] <persia> ScottK: Thanks.  Am I still waiting, or should I upload?
[07:09] <ScottK> persia: I was just reading the bugmail.  Did another motu-uvf ack?
[07:09] <persia> ScottK: No idea.  I'll check later, and wait for two.
[07:09] <ScottK> jpatrick: I think the freeze exception proccess wiki page is fine.  This is just about timing for Gutsy.
[07:09] <jpatrick> right
[07:09] <ScottK> persia: Looks to me like ktoon might be another candidate for a UVFe if you have time.
[07:10] <persia> ScottK: It's on my list (but at the lower of the priorities)
[07:10] <ScottK> persia: Sounds reasonable.
[07:11] <Hobbsee> ScottK: probably - but i would have expected slangasek to be around at some point
[07:12] <ScottK> Hobbsee: OK.  How about this...
[07:14] <ScottK> Hobbsee: I'll give it ~ 8 - 10 hours and if I don't have clarification that we do in fact have after Monday for last minute uploads, I'll change the hard freeze to Monday 0001 UTC with motu-uvf approved exceptions to 1000 UTC.
[07:14] <ScottK> If later we find out we have more time, no one is going to complain.
[07:15] <ScottK> persia: nixternal is going to look at ktoon.
[07:16] <ScottK> persia: It seems to me like you've got plenty on your plate.
[07:16] <persia> ScottK: Could you remind him to add the bug number on the rcbugs list when he does - saves me trying to remember.
[07:16] <nixternal> persia: link me and I will do :)
[07:16] <persia> nixternal: http://django.ajmitch.net.nz/rcbugs
[07:16] <persia> Hobbsee: A wrapper script
[07:16] <nixternal> oh...OK, I am installing the ubuntu one now to test it, and building the debian one to test
[07:17] <ScottK> nixternal: Sounds great.
[07:17] <nixternal> yup, KToon definately bombs from Ubuntu
[07:17] <persia> nixternal: Right.  Read the bug.  Verify the bug.  Verify the fix.  Either extract the patch, or request sync/UVFe.  repeat :)
[07:18] <nixternal> ya, a sync would be close since the debian package incorporated all but 1 of our patches
[07:19] <persia> Urf.  The merges are the hardest :(
[07:19] <ScottK> Hobbsee: Are you good with my proposal above^^^?
[07:19] <Hobbsee> persia: oh, i think i've found it
[07:19] <persia> Or maybe not :)  http://merges.ubuntu.com/k/ktoon/REPORT
[07:20] <persia> Hobbsee: Which?
[07:21] <ScottK> Hobbsee: You might also want to ack Bug 152288 if you have a moment before sleeping.
[07:21] <ubotu> Launchpad bug 152288 in clive "clive does not work with python2.5, and cannot access Google Video or YouTube" [Undecided,New]  https://launchpad.net/bugs/152288
[07:22] <Hobbsee> persia: how to block global shortcuts working whenever blender is running
[07:22] <Hobbsee> ScottK: consider this my verbal irc ack
[07:22] <persia> Hobbsee: Ah.  Great.
[07:22] <Hobbsee> ScottK: sounds sane
[07:22] <Hobbsee> persia: give it a name, click "detect window settings", select blendre, pick the options you want.
[07:23] <ScottK> Hobbsee: Thanks.
[07:23] <persia> ScottK: Would you mind glancing at the debdiff to make sure I didn't miss anything with the python 2.5 ~> 2.4 transition?
[07:23] <ScottK> persia: Will do.
[07:23] <persia> Hobbsee: Neat.  That opens entirely new realms of action-specific input processing.  Perhaps I should reconsider KDE.
[07:24] <persia> ScottK: Thanks.
[07:25] <Hobbsee> persia: indeed.  this is one of the things that i like about KDE>
[07:26] <Hobbsee> i can say "force this application to do this, no matter what everything else does
[07:26] <Hobbsee> useful for programs which have odd shortcuts
[07:28] <persia> Is it safe for a package to use debconf without depending on debconf in Ubuntu?
[07:28] <ScottK> persia: The only think I see is in your python dependency versioning.  python2.4-dev (>= 2.3.5-11) doens't make sense to me.
[07:29] <ScottK> persia: I believe you can rely on XS-Python-Version: and leave the depends/build-dep unversioned.
[07:29] <persia> ScottK: That's leftovers.  I'll drop it.  Thanks.  Just FYI, the other thing wrong is that it should be "XSBC-Original-Maintainer" rather than "XSBC-Maintainer" :)
[07:30] <ScottK> Other than that it looks fine (and what you have should actually work).
[07:30] <persia> ScottK: The issue is that distutils likes to set #!/usr/bin/python at the top - when I left python2.5 in the build-deps (or just called python in rules), it didn't keep my preferred interpreter.
[07:30] <Hobbsee> persia: something tells me that if you try to do that in gnome, you're utterly screwed.
[07:31] <ScottK> Right.  The rules changes you made should be fine
[07:31] <persia> Hobbsee: You write a wrapper script.  it turns everything off, runs blender, and turns everything on.  You turn them on and off through gconf2 calls.  It's annoying when you get a SIGSEGV.
[07:32] <Hobbsee> persia: ew.
[07:32] <ScottK> persia: AFAIK, with pysupport/central it'll handle the 2.4 only bits even if it says #!/usr/bin/python at the top.
[07:32] <persia> (note that that also works for KDE, or any other windowing environment, saving replacement of gconf2 with the appropriate tool)
[07:32] <Hobbsee> yeah
[07:32] <persia> ScottK: Packaging-wise, yes, but /usr/bin/clive crashes if it has #!/usr/bin/python at the top.  Perhaps a special case.
[07:32] <ScottK> Ah.
[07:33] <persia> I think you're allowed to have version-specific modules, but version-specific scripts for the non-default version cause issues.
[07:33] <ScottK> Hmmm.  It might.  Very odd.
[07:34] <persia> There's a special note about the workaround in the distutils documentation about scripts, but it completely fails to give any examples as to how to apply the workaround.
[07:35] <ScottK> persia: Maybe we could ask in #debian-python on OFTC.
[07:36] <persia> ScottK: You could, but I'm not sure it's important enough - there's plenty else to do, and we don't have many clive users, or someone would have reported a bug that it didn't work in feisty.
[07:36] <ScottK> OK.  Let me see if I can find you an example.
[07:37] <ScottK> persia: Could you give me a link to the distutils docmentation on the workaround (or a hint where to find it).
[07:37] <persia> ScottK: http://docs.python.org/dist/node11.html
[07:38] <ScottK> persia: Thanks.
[08:01] <POX__> ScottK, persia: where can I download lates sources?
[08:01] <POX__> (link to .dsc file)
[08:01] <persia> POX__: For which?
[08:02] <ScottK> POX__: If you get the current clive version from Sid and apply the debdiff in the bug I showed you, that'll be it.
[08:02] <POX__> clive
[08:02] <persia> POX__: Also, towards what?
[08:02] <ScottK> persia: POX__ is here to try to help with your python2.4 problem with clive
[08:03] <persia> POX__: http://http.us.debian.org/debian/pool/main/c/clive/clive_0.2.1-1.dsc + http://launchpadlibrarian.net/9966751/clive_0.2.1-1ubuntu1.debdiff
[08:04] <slangasek> ScottK: no, the point of freezing universe at the same time is so that setup for -security and -updates can be done during the period when main has to be locked down for CDs anyway
[08:04] <persia> POX__: What I've done works, but it's not very elegant :(
[08:04] <ScottK> slangasek: Thanks for the confirmation.  We'll adjust our schedule accordingly.
[08:05] <ScottK> slangasek: Would you please accept tinyerp-server (if you haven't already).
[08:05] <persia> slangasek: If you're accepting things: I've a list of them that close RC bugs :)
[08:07] <POX__> persia: just changeling XS-Python-Version to 2.4 should be enough
[08:07] <ScottK> persia: Hobbsee pushed a bunch of stuff through before she went to bed, but due to the fact (we think) that she was using a web UI to do it, accepted mails didn't go out.
[08:07] <ScottK> So a bunch of your stuff may have already been accepted and you don't know unless you look for it in LP to see if it's been published.
[08:08] <persia> POX__: That's what I thought.  Unfortunately, setup.py defines scripts/clive as a script, and disutils replaces the shebang line with the current interpreter (#!/usr/bin/python), which is 2.5 for Ubuntu, so /usr/bin/clive doesn't run after installation.
[08:08] <persia> ScottK: I saw that, but she can't do what I wanted: syncs.
[08:09] <ScottK> Ah.
[08:09] <POX__> what is the problem then?
[08:10] <persia> POX__: I don't know there is a problem, but I don't know there isn't, and ScottK suggested that we get another opinion on this method of forcing interpretation with /usr/bin/python2.4
[08:11] <POX__> your way looks good to me, with this shebang python2.4 will be used for sure
[08:11] <persia> POX__: Thanks for the confirmation.
[08:12] <POX__> np, btw: I just saw that ubuntu still has griffith 0.9.4, I gues it's too late for new upstream, right?
[08:13] <POX__> so what should I do to have it in -updates?
[08:13] <POX__> what is the procedure?
[08:14] <persia> POX__: We only very rarely accept new upstreams as -updates.  -backports is a possibility.  Does it close an RC bug?
[08:15] <ScottK> POX__: Procedure (at this point) is to wait for the Harfy repos to open and get it in there and then backport it.
[08:15] <persia> !backports
[08:15] <ubotu> If new updated Ubuntu packages are built for an application, then they go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
[08:15] <POX__> RC, I guess not, but it has few annoying bugs, let me generate some diffstts...
[08:16] <ScottK> POX__: If you can extract bug patches and give us a debdiff, we can definitely get those in today or tomorrow.
[08:17] <POX__> I'll do
[08:18] <ScottK> POX__: You can ping me if I'm around, but I won't be around much tomorrow.
[08:18] <POX__> ok, thanks
[08:27] <slangasek> persia: can't be too long of a list, the list of stuff in unaccepted is very short?
[08:28] <slangasek> persia: oh, syncs; right, feel free to throw them at me, I won't be able to get to them for a few hours yet though
[08:30] <persia> slangasek: most of the gutsy targeted from https://bugs.launchpad.net/~ubuntu-archive/ appears useful to me.  My own only incude cecilia, gxmms, snort, and zeroc-icee-java so far, but I've several dozen more build-tests to run in the next few hours.
[08:31] <ScottK> Updated Universe freeze is in /topic.  Details on the MOTU mailing list.
[08:55] <slangasek> persia: bug #118964 doesn't look like a sync request to me, and only mentions versions older than the one currently in gutsy, I'm not sure what's meant to happen there?
[08:55] <ubotu> Launchpad bug 118964 in cecilia "Please drop csound & cecilia from ia64 and amd64" [Wishlist,Confirmed]  https://launchpad.net/bugs/118964
[08:57] <ScottK> persia: ^^^ is your bug.  Would you please discuss with slangasek.
[08:58] <ScottK> slangasek: are the cecilia | 2.0.5-2ubuntu2 | amd64, ia64 binaries present?
[09:03] <minghua> ScottK: There isn't a rmadison-equivalent in Ubuntu?
[09:03] <ScottK> minghua: There is (IIRC), but I don't know how to operate it.
[09:04] <minghua> Hmm.  So rmadison doesn't work in Ubuntu?  Pity.
[09:04] <mlind> ScottK, StevenK: would fixing bug #147748 still be possible for gutsy?
[09:04] <ubotu> Launchpad bug 147748 in eclipse "eclipse from repository and ant don't work" [Undecided,New]  https://launchpad.net/bugs/147748
[09:04] <ScottK> mlind: Is there a fix available?
[09:05] <mlind> ScottK: in Debian sid yes, I've not tested it yet. I though asking first.
[09:06] <ScottK> mlind: OK.  We have about ~29 hours left before hard freeze for uploads.
[09:06] <ScottK> minghua: I'm pretty sure rmadison does work, I
[09:06] <sladen> minghua: what is rmadison, why doesn't it work?
[09:06] <ScottK> I've just never used it.
[09:07] <ScottK> sladen: He's made an assumption that my ignorance == doesn't exist that I believe is incorrect.
[09:07] <mlind> ScottK: okay, so it would be still doable. I'll get back to you.
[09:08] <ScottK> mlind: Yes, but at this point we want the least invasive way to solve the problem.  You'll also need to find a MOTU (I'm assuming your not one, but don't actually know) who has both time and a suitable machine to build/test it on (I've neither).
[09:08] <sladen> B<dak ls> was formerly called B<madison>.
[09:08] <sladen> apparently
[09:09] <sladen> http://qa.debian.org/madison.php
[09:09] <ScottK> Would a MOTU please look at Bug #139143.  Comments to the contrary not withstanding, it appears not to have actually been uploaded.
[09:09] <ubotu> Launchpad bug 139143 in apt-listchanges "apt-listchanges crashes after python upgrade" [Undecided,Confirmed]  https://launchpad.net/bugs/139143
[09:11] <mlind> ScottK: yeah, I just wanted to check that universe hasn't frozen yet.
[09:11] <sladen> minghua: if you think the functionality would be useful, please file a bug request into launchpad---for launchpad itself as it sounds like the information means
[09:12] <sladen> funny, the only place I could find a copy of rmadison was in the google cache from Hobsee's website
[09:12] <ScottK> mlind: OK.  I'm being verbose to reduce risk on mis-communication this close to the freeze.
[09:13] <slangasek> ScottK: no; there's an arch: all cecilia_2.0.5-2ubuntu2 in gutsy which I have no clue at all about, but that doesn't seem related to this bug
[09:14] <ScottK> slangasek: Odd.  I guess we have to wait for persia to resurface then.
[09:14] <ScottK> slangasek: Are you just pushing Universe uploads or do I need to bug you about ones that are particularly important?
[09:15] <slangasek> ScottK: I was starting by looking at the ones persia had brought to my attention, and that's the first one on the list, and now I'm off shopping for a bit :)
[09:15] <slangasek> ScottK: if you have ones of particular importance, flagging them to me is probably a good idea
[09:17] <ScottK> slangasek: mergeant is the one on my mind currently.
[09:17] <minghua> sladen: rmadison is a tool in the devscripts package, it should exist in Ubuntu, it's just a matter if it works or not.  I don't have it installed on my Ubuntu do didn't test.
[09:18] <nixternal> ScottK: we can just synch the ktoon thing with debians
[09:18] <nixternal> we can drop the 50_dactionmanager_retval patch
[09:19] <nixternal> the debian version though is a new upstream release
[09:19] <ScottK> nixternal: Please file a sync request then.
[09:19] <ScottK> But subscribe motu-uvf instead of the archive.
[09:19] <nixternal> in progress of doing so now
[09:19] <ScottK> Great.
[09:19] <ScottK> nixternal: I'll ack it immediately, so please ping me here when it's done.
[09:19] <nixternal> yup
[09:23] <sladen> minghua: http://packages.ubuntu.com/gutsy/devel/devscripts | grep rmadison
[09:23] <sladen> minghua: do you have example command line that you would use?
[09:24] <sladen> minghua: $ rmadison devscripts
[09:24] <sladen> devscripts |     2.8.14 |     oldstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
[09:24] <sladen> and 5 other lines
[09:24] <sladen> from that, I assume it works
[09:25] <minghua> sladen: Then it seems it just checks the Debian archive (as the rmadison in Debian does), so I won't call it "working"...
[09:25] <minghua> sladen: I would expect it to check Ubuntu archive.
[09:26] <sladen> minghua: rmadison -u ubuntu devscripts   ahhh, that works
[09:26] <minghua> sladen: Good to know.
[09:26] <sladen> which internally uses http://people.ubuntu.com/~ubuntu-archive/madison.cgi
[09:26] <ScottK> Yes.  Good to know.  Thanks minghua
[09:26] <ScottK> and sladen
[09:27] <sladen> so there's a possible bug that rmadison should default to 'ubuntu' when running under ubuntu
[09:27] <minghua> sladen: Yeah, I just misunderstood ScottK's reply about rmadison.
[09:28] <minghua> It was "ScottK doesn't know how to use it" instead of "it doesn't work in Ubuntu". :-P
[09:28] <ScottK> And now I do thanks to both of you.
[09:29] <minghua> Yay, rmadison -u ubuntu works in Debian, too.
[09:30] <nixternal> ScottK: bug 152423 is ready
[09:30] <ubotu> Launchpad bug 152423 in ktoon "[Gutsy Sync]  Please sync KToon (0.8.1-1) from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/152423
[09:31] <ScottK> nixternal: Thanks.
[09:31] <nixternal> yup
[09:31] <ScottK> soren or zul: would you please ack ^^^ - It fixes "package won't work" problems.
[09:32] <ScottK> The rest of motu-uvf is known to be asleep.
[09:32] <sladen> minghua: ScottK: I've filed http://launchpad.net/bugs/152424 FWIW
[09:32] <ubotu> Launchpad bug 152424 in devscripts "rmadision should default to 'ubuntu' URL when under Ubuntu." [Wishlist,New] 
[09:33] <ScottK> sladen: You might discuss it with StevenK.  He works on devscripts both in Ubuntu and Debian.
[09:41] <sladen> minghua: btw, in general, the core Ubuntu and Debian developers are the same people;  so if a tool was written because it was useful, it like likely be available for both  (see packages.*.*  and similar
[09:43] <minghua> sladen: Thanks.
[10:04] <ScottK> \sh_away: If you get a chance, would you look at Bug #152433.  I don't know if this is a problem on that person's box or something we need to get fixed in the next ~28 hours?
[10:04] <ubotu> Launchpad bug 152433 in wine "No internet in wine after feisty to gusty upgrade in kubuntu" [Undecided,New]  https://launchpad.net/bugs/152433
[10:04] <jussi01> hmmm, cant seem to figure this out. its complaining it needs libSDL-1.2.so.0 but which libsdl package do I install?
[10:12] <bddebian> Heya gang
[10:12] <ScottK> heya bddebian
[10:13] <bddebian> Heya ScottK
[10:13] <norsetto> Press Release: Ubuntu developers are busy with the last minute cut and paste of changes: http://people.ubuntu.com/~scott/uds-planning-pics/IMG_0036.JPG
[10:17] <etank> nixternal: your blog post is inspiring :)
[10:19] <norsetto> hey bddebian, looking for something to do?
[10:21] <bddebian> Heya norsetto.  Depends on what it is.  I have to head to the ariport in about 40 minutes
[10:22] <norsetto> bddebian: review of a package in REVU?
[10:24] <norsetto> jussi01: could it be this: libsdl1.2debian-all?
[10:25] <jussi01> norsetto: yeah, I think so. thanks alot :)
[10:27] <norsetto> jussi01: it depends on what the program will do with it, that one is a sure bet, but you could use one of the specialised versions too (if you know what it is needed for).
[10:28] <jussi01> norsetto: heh, I think it might be the alsa variant...
[10:28] <jussi01> then again, I could use the -all ... :P
[10:31] <norsetto> what package is it for? Could be an overkill (
[10:31] <norsetto> X11, aalib, and ggi graphics
[10:31] <norsetto>  drivers and oss, esound, alsa, arts, and nas sound drivers.
[10:31] <bddebian> norsetto: Which package?
[10:32] <norsetto> sorry about the flooding, it wasn't intentional
[10:33] <norsetto> bddebian: this: http://revu.tauware.de/details.py?upid=358 or this: http://revu.tauware.de/details.py?upid=373
[10:33] <norsetto> bddebian: but don't worry if you have no time, I appreciate it anyhow
[10:34] <slangasek> ScottK: wow, mergeant has really been outstanding since 2005?
[10:34] <ScottK> Yeah.
[10:34] <ScottK> It seemed a shame to leave a 4 digit bug open when we could close it.  Debian finally caught up with upstream.
[10:35] <ScottK> heh.  Hello norsetto.
[10:35] <ScottK> slangasek: Looks like Mithrandir just accepted it.
[10:36] <ScottK> norsetto: Would you please have a look at https://launchpad.net/bugs/152438 and see if it's a general problem and if it's something we can fix before release?
[10:36] <ubotu> Launchpad bug 152438 in viewvc "ViewVC doesn't work after dist-upgrade from viewcvs in feisty" [Undecided,New] 
[10:38] <norsetto> scottK: it could be a leftover configuration file, let me check
[10:39] <ScottK> Dunno.
[10:39] <ScottK> Please do.
[10:52] <bddebian> norsetto: I assume these are not for gutsy?
[10:53] <norsetto> bddebian: right
[11:06] <ScottK> norsetto: You might also look at bug 139143 is you have time.  Looks to me like it didn't get uploaded.  I don't have an opinion on if it should or not.
[11:06] <ubotu> Launchpad bug 139143 in apt-listchanges "apt-listchanges crashes after python upgrade" [Undecided,Confirmed]  https://launchpad.net/bugs/139143
[11:10] <bddebian> norsetto: Unfortuanetly I don't think I'm going to get to them now.  I have them open though so I'll try to hit them when I get back from the airport
[11:13] <norsetto> scottK: bug 152438 seems a genuine one, since the file locations were changed to comply with the FHS, but apparently the path in the config file is still relative, so it is looking in the wrong dir (/usr/lib/ instead of /etc/viewvc)
[11:13] <ubotu> Launchpad bug 152438 in viewvc "ViewVC doesn't work after dist-upgrade from viewcvs in feisty" [Undecided,New]  https://launchpad.net/bugs/152438
[11:13] <norsetto> bddebian: thanks barry, appreciate it a lot
[11:13] <ScottK> norsetto: Can you fix it?
[11:13] <norsetto> ScottK: not in half an hour
[11:13] <ScottK> norsetto: We have ~27 hours
[11:14] <norsetto> ScottK: not me, I'm away most of the day tomorrow
[11:14] <ScottK> Ah.  OK.
[11:15] <norsetto> scottK: it could also be a problem of the migration, since there is a fancy script that moves templates from viewcvs to viewvc, have to check deeper
[11:16] <ScottK> I'm reading the Debian bug now and there's lots of discussion.
[11:18] <ScottK> norsetto: There's a patch at the end of the Debian bug that might be worth looking into.
[11:19] <norsetto> ScottK: 409864?
[11:19] <ScottK> norsetto: Yes.
[11:23] <slangasek> persia: the scripts available to me don't work for syncing snort, because gutsy currently has an ubuntu diff; this apparently wants to be a merge
[12:18] <mlind> any universe-sponsors around to take a look at Bug #147748 ?
[12:18] <ubotu> Launchpad bug 147748 in eclipse "eclipse from repository and ant don't work" [Undecided,New]  https://launchpad.net/bugs/147748
[12:31] <norsetto> g'night all, see you scottK
[12:32] <ScottK> man-di: Do you have an opinion on the proposed revisions in Bug #147748?
[12:32] <ubotu> Launchpad bug 147748 in eclipse "eclipse from repository and ant don't work" [Undecided,New]  https://launchpad.net/bugs/147748
[12:35] <man-di> ScottK: I proposed to doko to apply the small patch to Ubuntu yesterday
[12:36] <ScottK> man-di: What did doko say?
[12:36] <man-di> ScottK: no time
[12:36] <man-di> doko: its in the bug report
[12:36] <man-di> doko: as I said, I have not much time myself
[12:36] <ScottK> doko: http://launchpadlibrarian.net/9973602/debdiff_small.txt