[00:15] <blueyed> Where's the source for ubuntu-dev-tools? It says "XS-Vcs-Bzr: https://launchpad.net/ubuntu-dev-tools/", but that's not a branch.
[00:16] <crimsun> there are several branches.
[00:16] <jdong> blueyed: https://code.edge.launchpad.net/ubuntu-dev-tools/
[00:16] <crimsun> https://code.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk
[00:16] <jdong> look under the Code tag
[00:16] <jdong> tab*
[00:17] <Fujitsu> blueyed: That is a branch.
[00:17] <jdong> blueyed: and as Fujitsu said, if you branch that URL you will get the trunk.
[00:17] <blueyed> Fujitsu: "bzr: ERROR: Not a branch: https://launchpad.net/ubuntu-dev-tools/"
[00:18] <Fujitsu> blueyed: That's very off.
[00:18] <blueyed> And I've only looked for the Code tab at https://edge.launchpad.net/ubuntu/+source/ubuntu-dev-tools. Thanks everybody.. :)
[00:18] <Fujitsu> *odd
[00:19] <jdong> No revision control details recorded for trunk.
[00:19] <jdong> hmm is trunk set as the trunk? :D
[00:19] <blueyed> LaserJock: you could also use prism, to handle gmail just like an app. One for you and one for your wife.
[00:20] <blueyed> LaserJock: http://labs.mozilla.com/2007/11/prism-prototype-now-available-on-mac-and-linux/
[00:21] <Fujitsu> jdong: Now it is.
[00:21] <blueyed> But the point is still valid, that the Vcs-Bzr field is wrong, isn't it?
[00:21] <jdong> Fujitsu: nicely done
[00:21] <Fujitsu> blueyed: Try again.
[00:21] <jdong> blueyed: it works now
[00:21] <Fujitsu> I think it should be OK now.
[00:21] <jdong> blueyed: it was an oversight on the product's configuration in LP
[00:21] <Fujitsu> jdong: They're projects now.
[00:21] <blueyed> yes, it works. Thanks.
[00:22] <jdong> Fujitsu: lol stupid nomenclature
[00:23] <jdong> projects, products.... blah.
[00:41] <LaserJock> blueyed: yeah I did think about that
[00:53] <LaserJock> Fujitsu: you did the upstream watch script right?
[00:53] <Fujitsu> LaserJock: Yes.
[00:54] <LaserJock> Fujitsu: I was just thinking that Daniel Liedert wrote a perl script for Debichem to do a weekly watch file check
[00:54] <persia> LaserJock: pong
[00:54] <LaserJock> not sure if you'd find that interesting or not
[00:54] <LaserJock> persia: hi, how did the session go?
[00:54] <Fujitsu> LaserJock: Well, I stole the majority of the code from Debian.
[00:54] <persia> crimsun: I like pulseaudio by default, but please make it easy for jack to not use pulse.
[00:54] <LaserJock> Fujitsu: alright, I just thought about it when I saw the weekly report for Debichem
[00:55] <persia> LaserJock: quiet in the beginning, and very exciting at the end.  Unfortunately, we didn't fix any bugs, but we did get good triage for two of the three we examined.
[00:56] <LaserJock> great
[00:56] <LaserJock> how long did it go/
[00:56] <LaserJock> ?
[00:56] <persia> LaserJock: About two hours
[00:57] <LaserJock> that's what I was guessing
[00:57] <LaserJock> I know I can never get anywhere in 1 hr
[00:58] <persia> Actually, we finished triage on one bug in an hour (which I think it about normal).  And the other two were only ~30 minutes each (but in neither case did we find the actual problem: one was against the wrong package, and the other was very confusing code).
[01:06] <crimsun> persia: pasuspend work is higher priority for me than repromoting jack-audio-connection-kit into Ubuntu main.
[01:08] <pkern> \sh_away: haha.
[01:08] <persia> crimsun: I'm not sure jack belongs in main until ffado (freebob replacement) is more stable.  On the other hand, I use jack (as do others), so I want to make sure that calling `jackd -dalsa -dhw:0` (or similar) won't get trapped by pulseaudio.  (whereas, I'd expect "default" to go into pulse).
[01:10] <persia> So, pcm.default -> pcm.pulse but pcm.hw wouldn't be trapped.
[01:12] <crimsun> persia: I don't intend to push "pulse alsa-lib plugin enabled via soundrc" onto users.
[01:12] <crimsun> asoundrc*
[01:12] <persia> crimsun: Ah.  Nevermind then.  I misunderstood.
[01:13] <crimsun> I outlined in #ubuntu+1 the more conservative approach of polling users to see if a significant userbase on the forums, mailing lists, and irc end up using pcm.pulse, and if so, some hackery will be done to enable that.
[01:14]  * persia reads logs
[01:14] <crimsun> if that, in fact, is the case, we can begin to whitelist apps to pasuspend, like jackd and/or qjackctl
[01:14] <crimsun> (skype being another)
[01:15] <persia> crimsun: A whitelist sounds like the solution I sought: you're way ahead of me.
[01:24]  * pkern is getting sick of LP.  My other clearsigned email without attachments was ignored, too.
[01:29] <Fujitsu> pkern: Are you sending it from a registered email address?
[01:30] <Fujitsu> (attachments will just get dropped - the message will be unaffected)
[01:32] <pkern> pkern@ubuntu.com...
[01:32] <pkern> Which is of course not added... Gah.
[01:33] <pkern> Maybe another one will work...
[01:35] <persia> pkern: You might try just adding it.  Mine didn't work for a very long time until I told LP about it.
[01:35] <pkern> Is `sending it from a registered email address' talking about envelope-from or the from header?
[01:36] <pkern> If it forces me to fake my envelope from that would suck.
[01:36] <pkern> Well now it worked, thank you Fujitsu.
[01:36] <pkern> Yay for the build log in the description.
[01:39] <minghua> I think it's "From:" header.
[01:43] <Fujitsu> It's the From header.
[01:44] <pkern> Now I also get request failures, fine.
[01:46] <Fujitsu> pkern: You need to sign messages if they're changing things.
[01:47] <pkern> Fujitsu: I do now clearsign them, albeit I would normally use PGP/MIME.
[01:47] <pkern> Filing seems to work now.
[01:49]  * pkern passed some rebuilding to his desktop machine this afternoon (http://ka.philkern.de:9998/dist/hardy/arch/i386)
[02:04] <chillywilly> OOo seems to crash for me and I've been searching bugs and I don't see it
[02:04] <chillywilly> how can I tell which repo a package was installed from?
[02:04] <TheSheep> "seems to crash"? how does it look?
[02:05] <chillywilly> it dumps core
[02:06] <chillywilly> danielb@frodo:~$ ooffice
[02:06] <chillywilly> Bus error (core dumped)
[02:06] <chillywilly> ** (process:9746): WARNING **: Unknown error forking main binary / abnormal early exit ...
[02:06] <chillywilly> 2.3 is the version in gutsy, right?
[02:06] <TheSheep> !info openoffice.org
[02:06] <ubotu> openoffice.org: OpenOffice.org Office suite. In component main, is optional. Version 1:2.3.0-1ubuntu5 (gutsy), package size 4 kB, installed size 44 kB
[02:10] <Fujitsu> pkern: Oh dear. You're putting the entire build log in the description?
[02:10] <Fujitsu> Can't you link to it or something?
[02:11] <pkern> Fujitsu: I would have made an attachment, and no I can't, yet.
[02:12] <pkern> But you see... LP would discard attachments.
[02:12] <persia> pkern: You might want to look at python-launchpad-bugs.  Also, attachments are never allowed in the first entry: only in comments.
[02:13] <Fujitsu> LP is useless, right. But what is often done is sticking a link in the description.
[02:13] <Fujitsu> persia: Apport does this sort of thing well, but it is black proprietary specific LP magic.
[02:13] <pkern> Fujitsu: ACK.
[02:14] <persia> Fujitsu: So just copying the apport code isn't sufficient?
[02:14] <Fujitsu> persia: I think the LP implementation is currently apport-specific, but I'll check.
[02:15] <Fujitsu> Er, why is there a Fedora backend implementation in Apport!?
[02:16] <persia> Fujitsu: Why not?  Should apport be distro-specific?
[02:16] <Fujitsu> I hadn't heard anything about it being used elsewhere, and would have thought there would have been a lot of NIH associated with it.
[02:18] <Fujitsu> Hm, looks like the blob storage capability might actually be usable by everyone, just not documented anywhere.
[02:18] <persia>  Fujitsu: regarding NIH, you're forgetting the master plan :)
[02:19] <Fujitsu> persia: Which master plan?
[02:19] <persia> For blob storage, I thought I remember it being general: it's just undocumented.
[02:19] <persia> Fujitsu: Good point.  The LP takes over the world master plan.
[02:19] <Fujitsu> Ah.
[02:20] <Fujitsu> Right, using python-launchpad-bugs you upload a MIME blob (with an inline component being appended to the description, and attachments being attached), and get the URL back. Why isn't this documented anywhere?
[03:06] <LaserJock> persia: thanks
[03:18] <codemaste1> I have just made an Ubuntu package for multiget (to fix bug #163276) and I would like to find a sponsor to check it and help me uploading to ubuntu repository
[03:18] <ubotu> Launchpad bug 163276 in ubuntu "[needs-packaging]multiget " [Wishlist,Triaged] https://launchpad.net/bugs/163276
[03:20] <codemaste1> multiget is a GUI-based multi-thread downloader with publish support.  a good replacement for the broken d4x
[03:20] <codemaste1> and I would really like to see multiget to be the default mass downloader in ubuntu desktop
[03:21] <persia> codemaste1: Thanks for your package.  The next REVU day starts in just short of 7 hours, so this tends to be a quiet time for REVU.  I'd suggest you get the package in for hardy, and write a spec to make it default for hardy+1: fast transitions are hard to manage smoothly.
[03:22] <codemaste1> persia, are you willing to sponser multiget?  If so, may I email the package to you?
[03:23] <persia> codemaste1: I have no idea if I'm willing to sponsor yet.  If it's on REVU, there's a good chance I'll review it during REVU day.  If it already has an advocate when I review it, and I don't encounter any issues, I may well sponsor (but it's a very rare package for which I don't encounter issues).
[03:23] <bddebian> pfft REVU ;-P
[03:23] <bddebian> persia: You're supposed to be fixing scorched3d ;-P
[03:24] <codemaste1> how can I put my package onto REVU?
[03:24] <codemaste1> I already have an account on launchpad.net although I am not yet a member of any teams.
[03:25] <persia> bddebian: That's currently 4th on my list (which is why I'm not REVUing now).
[03:25] <bddebian> heh
[03:26] <persia> codemaste1: You'll need to join the contributors team.  See https://wiki.ubuntu.com/MOTU/Packages/REVU for details, and more generally, look at https://wiki.ubuntu.com/MOTU/Contributing for some guidelines on making sure your package gets through REVU smoothly.
[03:27]  * persia quivers in fear
[03:27] <Hobbsee> Mez: are you actually here?
[03:28] <Hobbsee> persia: now fix the soundfonts bug :)
[03:29]  * Fujitsu cowers in the corner.
[03:29] <persia> Hobbsee: Is that still bug #45852, or did you make a new one?  I can't find it.
[03:29] <ubotu> Launchpad bug 45852 in baltix "Default Ubuntu desktop can't play midi files (not Kubuntu)" [Medium,Confirmed] https://launchpad.net/bugs/45852
[03:29] <Hobbsee> persia: havent made a new one
[03:29]  * jdong tries to figure out what he did now
[03:30] <jdong> aww poor guy
[03:31] <Fujitsu> Haha.
[03:31] <Hobbsee> ban didnt work, i see.
[03:31] <persia> Mez is special
[03:31] <jdong> HAHAHA
[03:32] <jdong> Hobbsee: probably work better if you do him by ircname
[03:32] <Hobbsee> jdong: there's a thought.
[03:32] <Hobbsee> odd.
[03:33] <Hobbsee> weird, it worked on -devel
[03:33] <Fujitsu> Hm, might he have the ban-evasion level here?
[03:33] <jdong> Hobbsee: seems like he is identifying after a few channels are joined
[03:34] <jdong> i.e. his client's flaking/flooding :)
[03:47] <gnomefreak> anyone alive i have a question of lintian error
[03:47] <gnomefreak> W: iceape source: binary-nmu-debian-revision-in-source 1.1.6-1ubuntu0.7.10
[03:48] <gnomefreak> the source package seems to be correct, maybe i should drop debian's -1 since i didnt get anything from debian
[03:48] <gnomefreak> The version number of your source package ends in +b and a number or
[03:48] <gnomefreak> N:   has a Debian revision containing three parts.
[03:48] <gnomefreak> is the really confusing part or warning
[03:49] <persia> gnomefreak: Are you based on Debian 1.1.6-1 ?
[03:49] <gnomefreak> persia: not really i stopped geting stuff from debian a long time ago since mine is normall done first
[03:50] <gnomefreak> but i did it for 1.1.5-1 still not using debian at all
[03:50] <gnomefreak> where is the developers refference guide? it gives me a section on it
[03:51] <Hobbsee> jdong: indeed.
[03:53] <persia> gnomefreak: Well, the revision number looks sane, although I think I'd prefer 1.1.6-0ubuntu0.1 for gutsy-proposed, and 1.1.6-2ubuntu1 for an upload to hardy if you are using Debian input, or 1.1.6-0ubuntu1 if you are not using Debian input.  I suggest the former: even if you don't use the patches, processing as a merge keeps it from showing on the merge list.
[03:54] <gnomefreak> persia: will that get rid of the warning above about binaries?
[03:54]  * persia looks at lintian
[03:56] <gnomefreak> persia: http://revu.tauware.de/revu1-incoming/iceape-0711172100/lintian
[03:57] <persia> gnomefreak: coincidentally, yes.  The check is to see if there are two '.' characters in the revision number.  My suggestion would still trigger it for something like 1.1.6-2.1ubuntu3.2 (2nd SRU of 3rd Ubuntu revision from 1st NMU of 2nd Debian revision).
[03:57] <gnomefreak> last time i got that was with sunbird but was due to wrong orig.tar.gz name i used - instead of _
[03:58] <persia> gnomefreak: The critical part is whether the revision matches the regex /^-[^.-]+\.[^.-]+\./
[03:58] <gnomefreak> persia: not sure what you mean name it iceape_1.1.6-1ubuntu1.7.10
[03:59] <persia> gnomefreak: Don't use foo.7.10 and you don't get so many '.' characters, so it doesn't complain.
[04:00] <gnomefreak> than how would i name it for gutsy? atm 1.1.5-1ubuntu1.7.10 is in gutsy atm i dont remember getting errors on it
[04:00] <LaserJock> persia: the .7.10 versioning seems to be used quite a bit by asac
[04:00] <persia> Also, I'd recommend 1.1.6-0ubuntu0.1 meaning initial Ubuntu packaging (not from Debian) with initial upload for SRU (not previously released).  That way, 1.1.6-0ubuntu1 is larger, so upgrades to hardy go smoothly.
[04:00] <persia> LaserJock: True, but it triggers lintian.  Doesn't really matter.
[04:00] <gnomefreak> iceape wont upgrade to hardy we are using seamonkey in hardy
[04:01] <persia> gnomefreak: OK.  What happens for users that have iceape installed?  Will there not be a transition package?
[04:02] <gnomefreak> persia: we might try to get an upgrade for them but this was against my opinion i wanted to keep iceape until sm2 was released but my thought didnt matter i guess
[04:03] <persia> gnomefreak: I don't know the history, but my opinion is that if there is an iceape package released in 7.10 or 6.06, hardy needs an "iceape" package.  This "iceape" is permitted to be a meta-package depending on something else, but not having anything named "iceape" means users lose support silently.
[04:05] <gnomefreak> persia: again i was against the change but i already spoke up but since the paid maintainer gets final say
[04:06] <persia> gnomefreak: I'm not sure it matters if people get paid or not.  There's no reason there can't be a universe transition package to support a broken upgrade path.  You might also want to touch someone in QA.
[04:06] <gnomefreak> persia: we might make it like that but that is not my concern atm
[04:07] <persia> gnomefreak: OK.  If you just want to shut lintian up, use less '.' characters in your version.
[04:07] <LaserJock> or ignore lintian
[04:07] <persia> Right.
[04:07] <gnomefreak> less ther eis only one -
[04:07] <StevenK> Or complain about MOTU.
[04:07] <StevenK> Oh, wait.
[04:07] <LaserJock> haha
[04:08] <gnomefreak> so taht isnt something that will stop it from being pushed?
[04:08] <gnomefreak> s/taht/that
[04:08] <persia> gnomefreak: Not likely, if it's a good SRU.  There's lots of packages that use that versioning scheme.  The larger issue is that new upstream versions require special exceptions for SRU.
[04:10]  * Fujitsu wonders why this isn't having patches backportee.
[04:10] <Fujitsu> *backported
[04:11] <Fujitsu> Oh, Mozilla. Right.
[04:11] <Fujitsu> Run away!
[04:11] <LaserJock> heh
[04:12] <LaserJock> anybody know if you can just dump a git branch on a web host like you can with bzr?
[04:12] <jdong> Rule 4 for keeping jdong happy: Things should build within an hour on a core 2 duo :)
[04:12] <jdong> LaserJock: I'm pretty sure git can't be served over http?
[04:13] <persia> LaserJock: I believe you can: it's just files.
[04:13] <gnomefreak> well i gave him links so maybe ill get lucky and get them pushed (none of my packages in last month or 2 have been uploaded since noone ever has time to do it and alot of motus are scared of mozilla and dont test it IMHO
[04:13] <jdong> LaserJock: never mind, it works
[04:14] <jdong> it's just really mean to do because it's slower than bzr 0.11  *ducks*
[04:14] <LaserJock> right
[04:14] <persia> LaserJock: http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt might be interesting...
[04:14] <StevenK> Dear.
[04:15] <Fujitsu> jdong: Is that possible?
[04:15] <jdong> Fujitsu: it's an extremely talented achievement, but can be done if Linus puts his mind to it!
[04:16] <Amaranth> slower than bzr?
[04:17] <bddebian> hah
[04:20] <mwolson> LaserJock: yes, it is possible to just dump a git branch on a web host.  i've done it
[04:21] <mwolson> just remember to chmod +x .git/hooks/post-update, and when cloning, use path to .git directory rather than the working directory
[04:24] <jdong> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[04:24] <jdong> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[04:24] <jdong> *SNIFF*
[04:24] <jdong> do the buildd's perform the above check?
[04:25] <Fujitsu> jdong: No.
[04:25] <jdong> backporting mplayer from Hardy -> Feisty, and pdebuild pukes on that
[04:25] <Fujitsu> unset DEBMAIL
[04:25] <persia> Hmm..  schroot seems to have lost my hardy chroot.  It appears in lvs output, but doesn't show in /dev/data00/  Anyone have a pointer to something to check?
[04:25] <Fujitsu> persia: Are there any broken snapshots of it?
[04:25] <persia> Fujitsu: Yes, one.
[04:26] <Fujitsu> persia: Try removing it, and if it doesn't come back `lvchange -a y' it.
[04:27] <persia> Fujitsu: Thanks.  Now, why would a broken snapshot cause the source to be hidden?
[04:28] <Fujitsu> persia: It may decide that it's better not render the snapshot useless.
[04:28] <Fujitsu> Was the snapshot full?
[04:29] <persia> Fujitsu: likely.  It was my working area for testing hardy, and I kept not syncing, while installing lots of packages.  I should probably have created another real chroot for that.
[04:29] <Hobbsee> Fujitsu: they don't?
[04:30] <Fujitsu> Hobbsee: They don't what?
[04:31] <Hobbsee> [15:24] <jdong> do the buildd's perform the above check?
[04:31] <Hobbsee> [15:25] <Fujitsu> jdong: No.
[04:31]  * Hobbsee thought htey did.
[04:31] <Hobbsee> or maybe they turned that off.
[04:31] <Fujitsu> Hobbsee: They don't die if you don't comply.
[04:31] <Hobbsee> ahhh
[04:31] <persia> Hobbsee: They do mangle the maintainer for the binary packages though.
[04:31] <Hobbsee> ah right.
[04:31] <Fujitsu> persia: That would be it, though I thought the kernel would mark the snapshot as broken and useless by default.
[04:31]  * Hobbsee notes that that's really...non-sense making?
[04:31] <LaserJock> it's a warning though?
[04:32] <jdong> LaserJock: on Feisty it's a hard abort
[04:32] <Hobbsee> yeah, it's a warning
[04:32] <Fujitsu> LaserJock: No, it kills the debuild locally.
[04:32] <LaserJock> it's a warning on the buildds, but kills locally?
[04:32] <persia> Hobbsee: Every binary has an Ubuntu maintainer, as it's Ubuntu built, and Ubuntu originated.  We don't mangle source inputs, as that's too much work, but we are supposed to change them for compile.  There's still some packages that haven't been touched in ages that don't comply with the Debian Maintainer Field check.
[04:33] <Hobbsee> persia: which then got rebuilt in gutsy, i thought
[04:33] <persia> Fujitsu: It probably should have done so: I wonder why it let me get away with it for so long.
[04:33] <persia> Hobbsee: No, in gutsy I identified a few hundred packages that failed the test, and didn't see enough changelog entries to indicate they were all fixed.  I haven't run tests for hardy yet.
[04:33] <Hobbsee> ahh
[04:34] <Fujitsu> persia: pitti ran through the remaining modified sources in late Gutsy, updating the maintainer field.
[04:34] <Hobbsee> maybe it was all the packages that we touched somewhere along the point
[04:34] <Hobbsee> yeah, modified would be it
[04:34] <persia> Fujitsu: All of them?
[04:34] <Fujitsu> persia: As far as I know.
[04:36] <persia> Maybe everything in main.  I still see 312 binary packages that don't comply in hardy today.  Looking for source packages now...
[04:37] <Fujitsu> I saw some universe ones.
[04:37] <persia> 285 source packages in main don't meet the test.
[04:37] <Hobbsee> and how many of those are changed by ubuntu at all?
[04:37] <persia> Err..  Nevermind.  I'm testing the wrong thing.  Let me rerun...
[04:38] <persia> OK.  for hardy/i386 102 source packages in main and 258 source packages in universe don't have *ubuntu* in the maintainer field and do have *ubuntu* in the version field.
[04:39] <persia> (right now)
[04:39] <Hobbsee> weird
[04:39] <persia> Hobbsee: Work in progress.
[04:39] <Hobbsee> must be
[04:40] <LaserJock> persia: can you tell if those are just old packages that havent' been uploaded recently?
[04:41] <persia> LaserJock: Not with my current script: I'd need to extract more.
[04:41] <persia> Further, I don't consider it a big issue at this point in the cycle: after DIF, I'd consider them all targets for update, regardless of whether they are new or old.
[04:44]  * Fujitsu convinces LaserJock to do some security stuff.
[04:44] <persia> Fujitsu: Do you think http://people.ubuntu.com/~kees/ubuntu-cve/unfixed.html should be listed as a QA target?
[04:44]  * Hobbsee convinces Fujitsu to fix the world.
[04:47] <Fujitsu> persia: persia You mean ~pitti?
[04:47] <Fujitsu> Oops.
[04:47] <Fujitsu> I can't see that under ~kees...
[04:47] <persia> Fujitsu: This is part of why I ask: I don't know which is correct, and don't want to push the wrong place.
[04:47] <Fujitsu> persia: ~pitti is the authoritative branch.
[04:48] <persia> Fujitsu: OK.  I'll add a link to http://people.ubuntu.com/~pitti/ubuntu-cve/unfixed.html then.  Thanks.
[04:48] <Fujitsu> (I've gone through almost 100 CVEs from that tracker over the past couple of days working out what is actually needed where)
[04:48] <persia> Fujitsu: which tracker?
[04:48] <Fujitsu> persia: ubuntu-cve.
[04:48] <Fujitsu> (see ~pitti/bzr/ubuntu-cve)
[04:49] <keescook> persia: the "unfixed.html" stuff is out of date (since Sep)
[04:49] <Fujitsu> Aha.
[04:49] <keescook> I'll be providing some new stuff to replace it next week (I'm hoping)
[04:49] <Fujitsu> Hi keescook.
[04:50] <keescook> hiya!  (just passing through before dinner...)
[04:50] <Fujitsu> keescook: Isn't it a bit late for dinner?
[04:50] <persia> keescook: Ah.  Great.  I'll wait then.  Please ping me when there's a nice external interface to a list of things that need doing, and I'll add it to the QA list.
[04:50] <LaserJock> Fujitsu: what are you wanting me to do? :-)
[04:50] <keescook> persia: okay, sounds good.  I really should have something by Tue or so
[04:50] <Fujitsu> LaserJock: Erm, work through the 998 or so open universe CVEs.
[04:51] <LaserJock> ah
[04:51] <persia> keescook: No big rush: I'd rather good than fast.  It's still a couple weeks before mass-publicity for the QA stuff.
[04:51] <LaserJock> Fujitsu: I'll put it on my list ;-)
[04:51] <Fujitsu> keescook: Is there a timeframe for moving that branch to LP?
[04:52] <LaserJock> I have a dissertation to do, colloquia presentation on Tuesday to start, gcompris merge to do, then maybe we'll see
[04:52] <Fujitsu> LaserJock: Ouch.
[04:52] <LaserJock> plus it's my birthday tomorrow :-)
[04:52] <Hobbsee> LaserJock: define tomorrow?
[04:52]  * persia takes advantage of timezone skew to wish LaserJock happy birthday today.
[04:52]  * Fujitsu wraps up a block of CVEs for LaserJock.
[04:52] <Hobbsee> okay, happy birthday then!
[04:52] <LaserJock> 18th, today for you
[04:52] <Hobbsee> persia: me too :)
[04:53] <Fujitsu> Slightly preemptive happy birthday!
[04:58] <jdong> do we have any automagical tool for detecting when the API/ABI of a library changes?
[05:00] <LaserJock> that'd be interesting
[05:00] <LaserJock> how would you tell?
[05:00] <persia> jdong: Not really.  It's supposed to be linked to SONAME, but not every upstream complies.
[05:00] <persia> LaserJock: You could export the symbol map from the library, and check for significant changes.
[05:00] <jdong> LaserJock: so far it's been an exaustive try every reverse-depped package thrrouhg all usecases
[05:01] <jdong> LaserJock: I was wondering at least for C library API's if we can scan through their header files for prototype differences
[05:01] <LaserJock> persia: can API/ABI be easily be unintentially broken?
[05:01] <LaserJock> I was wondering how developers know
[05:01] <persia> jdong: At a simple level (read backports), the binary package name is supposed to be updated when the API/ABI changes to support transitions.
[05:01] <persia> LaserJock: Yes: just add a new function, or change a function prototype.
[05:02] <jdong> persia: in practice how often is that done though?
[05:02] <jdong> persia: I recall a libgpod update not bumping solib but causing its rdepends to segfault 2 release cycles ago
[05:02] <jdong> persia: I used to assume that same package name = still compatible...
[05:02] <LaserJock> persia: a new function would count? or changing an existing function?
[05:02] <persia> jdong: I've only seen about 5 cases where it wasn't for normal shared libraries.  Private libraries using wrappers are different.
[05:03] <persia> LaserJock: Both are changes, but only the change is incompatible.  ABI can also change due to changes in the build tools.
[05:04] <persia> Err.  That doesn't parse.  Adding a new function makes a different API/ABI, but it can be a compatible API/ABI.
[05:04] <persia> Changing a function definition usually results in an incompatible API.
[05:04] <jdong> persia: what results in incompatible ABI for C/C++ libraries?
[05:04] <jdong> apart from build tools
[05:05] <LaserJock> persia: ahh, so when you have an incompatible API/ABI you should change the SONAME
[05:05] <persia> jdong: Ignoring build tools, it has to do with how the symbols are exported.  If a symbol name changes, or the same name does a different thing, that's incompatible.  If there are just more symbols, that's compatible.
[05:05] <persia> LaserJock: exactly.
[05:05] <persia> (symbols disappearing is also incompatible)
[05:05] <jdong> persia: ok, cool, that's good to know. Wow today was an educational day :)
[05:06] <LaserJock> persia: so what are symbols again?
[05:07] <persia> jdong: Just to make it more fun, when the ABI changes, but the API is stable, a backport should just work.  If the API changes, the backport should FTBFS.
[05:07] <LaserJock> the list of function?
[05:07] <persia> LaserJock: functions, constants, etc.  Things that the library exports.
[05:07] <LaserJock> ah, so lots of stuff
[05:07] <LaserJock> k
[05:08] <jdong> persia: so if I were bold enough to attempt/evaluate a library backport, what would be a good procedure to assessing compatibility?
[05:08] <jdong> I'm guessing at least a before/after symbol dump
[05:08] <jdong> possibly recompiling all the reverse deps if it seems like symbols got removed?
[05:08] <persia> LaserJock: Right.  Everything that the client application might want to use.  Internal implementations are different.  That's part of why it's a bad idea to write code that works but doesn't match the published public headers: there's no guarantee that it will keep working, even for a "stable" ABI.
[05:09] <persia> jdong: before/after dump with analysis should be enough.  If there is a change, all rdepends need a recompile.
[05:10] <persia> jdong: Remember, you don't just want to make sure the symbols have the same name, but that they mean the same thing.  If the semantics change, the clients may need recompile or porting.
[05:10] <persia> Err.  "...want to just make sure..."
[05:11] <jdong> persia: sounds logical
[05:11] <persia> jdong: On another note, why would you want a library backport?
[05:11] <LaserJock> I've been thinking about doing one
[05:12] <LaserJock> but it's got a lot more deps than I want to take care of
[05:12] <persia> LaserJock: Why?  What new fancy feature does a library provide that would be user-visible?
[05:12] <LaserJock> umm, because the app I want to backport needs newer libs
[05:12] <jdong> persia: usually it would only be for pulling in a backport that requires a newer library
[05:13] <jdong> persia: for pairs like libtorrent/rtorrent where the latter is the only rdep of the former, I usually just let it slide if it's backported in a pair
[05:13] <LaserJock> I want gchemutils and it requires at least the goffice/openbabel versions in gutsy
[05:13] <persia> OK.  If an app being backported requires newer libraries, that's almost certainly a case of ABI incompatibility.  Hardly even need to check.
[05:14] <jdong> persia: would a newer library release that only adds new symbols cause ABI incompatibility?
[05:14] <persia> jdong: Where there's only one client, that makes sense.
[05:15] <persia> jdong: If it's only adding symbols it can be compatible: I guess I'm thinking of the case where the client wants a new package name, and not the case where it just needs a newer version with the same package name.  Nevermind.
[05:15] <LaserJock> persia: yeah, I know, the have different SONAMEs and now in Debian new package names so we can have multiple versions of goffice
[05:16] <LaserJock> that's why I'm not eager to backport it
[05:26] <LaserJock> anybody know if there is a way to do like an apt-get autoclean for pbuilder apt caches?
[05:26] <tonyyarusso> other than rm?
[05:27] <LaserJock> yeah, I want like autoclean
[05:27] <LaserJock> so look at what pbuilder would actually use
[05:27] <tonyyarusso> not pbuilder clean though?
[05:28] <jdong> LaserJock: how do you know what pbuilder would actually use?
[05:28] <LaserJock> from the current pbuilders apt caches
[05:28] <jdong> LaserJock: probably your best bet is to use python or something to look for duplicate package names, then delete the older one
[05:28] <jdong> LaserJock: autoclean simply removes files not referenced in any of your package lists, which would be essentially the same thing
[05:29] <LaserJock> yeah, although if I have a dapper, gutsy, and hardy pbuilders
[05:29] <jdong> oh
[05:29] <LaserJock> right
[05:29] <jdong> that's a lot more complex then
[05:29] <LaserJock> maybe I shouldn't worry about that case
[05:29] <persia> Does anyone have a good suggestion for how to submit a sponsorable diff for a bug when it requires modification of a binary file?  (native package)
[05:29] <jdong> I think some creative use of madison ;-)
[05:29] <LaserJock> hmm
[05:30] <jdong> persia: :-/ I've always just submitted the entire source package
[05:30] <persia> jdong: As a sponsor, I don't like to receive that, but I can see the point.
[05:30] <LaserJock> if it's a  single file I'd take just the file
[05:30] <jdong> persia: well a debdiff cannot represent the change... I guess there's otherways you can coordinate
[05:31] <jdong> this seems like a good one-case exception to receive an entire soruce package with explanation of what changed
[05:32] <persia> LaserJock: There's actually a bunch of other changes as well.  Essentially, this package has tar.gz files for test cases for the test rule, and the test cases need to be altered to match the source changes.
[05:32] <LaserJock> I would probably just do the whole source package
[05:32] <Hobbsee> persia: "uencode it" is coming to mind.  but, i dont know.
[05:32] <jdong> persia: wow, that'd be a pain to review :(
[05:32] <persia> jdong: Perhaps you're right.  I'll try it that way, although I'll also add the patches to make my sponsor's life easy.
[05:32] <Hobbsee> kinda hard to review a binary blob
[05:33] <persia> Hobbsee: Were it not native, I'd agree with uuencode.  In this case, it's a tar.gz in a native package, and uudecoding in debian/rules just seems needless cruft.  Since the package gets tar.gz'd anyway, I'm not sure why the author tar.gz'd the test cases.
[05:34] <jdong> persia: it does seem like a foolish decision of upstream to package this way
[05:34] <persia> jdong: Native - no upstream :)
[05:34] <jdong> persia: can't you slap the guy to repackage his source then?
[05:35] <persia> jdong: No.  He's busy doing lots of other things I want to see done.
[05:35] <jdong> ah
[05:39] <LaserJock> persia: what package?
[05:40] <persia> LaserJock: I won't mention it, as I don't want to shame the maintainer.
[05:44] <Hobbsee> please tell me it's not enigmail
[05:44] <Hobbsee> or something mozilla-related.
[05:44] <Hobbsee> they like doing crack like that.
[05:44] <Fujitsu> Mozilla does all sorts of crack.
[05:45] <persia> Mozilla is crack.  I want more.
[05:55] <LaserJock> dang it, I hate it when printing just stops working
[05:59] <jdong> LaserJock: you have no right to complain about printing to me!
[05:59] <LaserJock> sorry
[05:59] <jdong> LaserJock: you don't have to deal with kerberos authenticated lpr printers!
[05:59] <LaserJock> I just always find it weird with things *did* work and just mysteriously stop
[05:59] <jdong> :)
[06:05] <StevenK> LaserJock: It's what printers do. Their primary function isn't to put ink/toner on dead trees, it's to fail mysteriously and make you spend half a day fixing them
[06:17] <Hobbsee> hum.  blender be broken.
[06:18] <persia> Hobbsee: Generally :)
[06:18]  * Hobbsee does not like blender broken
[06:19] <Hobbsee> oh, it's hte desktop effects stuff
[06:21] <Hobbsee> persia: i take it your a blender hater?
[06:22] <persia> Hobbsee: I'd like to like it, but I find that my AutoCAD knowledge translates poorly, the interface is annoying, and the documentation is weak.  Further, it just hasn't run ~ 40% of the times I've tried it (not that my system is known for stability or anything)
[06:22] <StevenK> I'd try blender, but I have nothing to draw
[06:23] <Hobbsee> persia: yeah....the documentation is crap
[06:23] <Hobbsee> it's not so bad once you actually learn it though - it's the learning part that's the problem!
[06:23] <Hobbsee> works fine on kubuntu.  falls over on ubuntu
[06:24] <persia> Hobbsee: If it weren't for the crashing part, I suspect I'd agree with you :)
[06:24] <Fujitsu> My brother got a bit annoyed that he can't run Blender and Compiz at the same and edit the massive models he often does.
[06:24] <Hobbsee> appears to b ea dri problem
[06:26] <persia> Hobbsee: More specifically, it's a problem with the GUI architecture, we've four different layers, and each application targets differently.  As a result, it's really hard for the rendering drivers to do the right thing.
[06:27] <Hobbsee> tasty.
[06:28] <persia> Same problem as for sound, but at least sound is getting sane: we should be down to three layers soon, and lots of people are looking for a good solution.  With visuals, it's still a matter of each app on their own, although compiz may help with this over time.
[06:38] <Hobbsee> persia: why would a package have 2 soname versions?
[06:38] <Hobbsee> sarah@LongPointyStick:~$ dpkg -S libGL.so.1
[06:38] <Hobbsee> libgl1-mesa-glx: /usr/lib/libGL.so.1
[06:38] <Hobbsee> libgl1-mesa-glx: /usr/lib/libGL.so.1.2
[06:40] <persia> Hobbsee: I believe libGL.so.1 is likely a link to libGL.so.1.2.  This might be to support the swapping about involved in handling the special libGL implementations for different hardware.
[06:40] <Hobbsee> persia: you win.
[06:41] <persia> Hobbsee: What were we playing, and what were the stakes?
[06:42] <Hobbsee> :)
[06:42] <Hobbsee> as in, you're correct
[06:42] <Hobbsee> you win a pony
[06:42]  * Hobbsee pokes LaserJock
[06:42] <StevenK> Ponies!
[06:46] <LaserJock> I got them started
[06:47] <StevenK> How much work to finish them off?
[06:48] <LaserJock> not sure
[06:49] <LaserJock> I'm having a harder time getting into the "creative mood" this time
[06:49] <StevenK> I'm sure somone's Long Pointy Stick could help
[06:50]  * StevenK hides
[06:50] <LaserJock> oh don't worry, that's the first one to be done ;-)
[06:50] <Hobbsee> hehe
[06:50]  * Hobbsee uploads blender, and hopes that it works.
[06:50] <Hobbsee> does on kubuntu, or did last time i checked.
[06:50] <Hobbsee> who needs this gnome thing, anyway?
[06:51] <StevenK> You, actually
[06:51]  * Hobbsee still has a kubuntu cd
[06:52] <persia> Hobbsee: You might also try it with compiz disabled: if fixed, it may well work on top of metacity.
[06:52] <Hobbsee> persia: it doesnt seem to work with metacity - the old version, anyway
[06:53] <persia> Hobbsee: Right then.  How hard is it to make KDE look like Mac OS 9 again?
[06:53] <StevenK> persia: Hard?
[06:53] <Hobbsee> persia: no idea.  probably not that bad.
[06:53] <Hobbsee> easier than gnome, i expect
[06:55] <persia> StevenK: Well, I like my menus at the top, and my icons on the desktop: I've been fully seduced away from twm, but I'm finding I use more and more Qt apps, and would like to use blender, so perhaps I'll shift (as compiz just completely breaks for me)
[06:55] <persia> Hobbsee: Well, for gnome, it's mostly just sticking the menubar on top, and flicking a couple gconf switches.  I'll have to go look at KDE again (haven't tried it since 2001 or so)
[06:56] <Hobbsee> right
[06:57] <LaserJock> I've gotta have a Windows style bar until gnome decides to allow locking of panels
[06:57] <Amaranth> persia: it's easier to make KDE look like OS 9 than GNOME
[06:57] <jdong> TheMuso: can you clarify on your comment on bug #160403? I've definitely seen archive managers sync stuff from debian-multimedia
[06:57] <ubotu> Launchpad bug 160403 in gpac "Please sync gpac 0.4.4-0.3 from debian-multimedia.org unstable" [Undecided,Invalid] https://launchpad.net/bugs/160403
[06:58] <Amaranth> persia: because in KDE you can do the menu-on-panel thing
[06:58] <jdong> and newer gpac is a good idea for Hardy
[06:58] <persia> Amaranth: That sounds better than having the double-menu bit in the upper left.  Thanks.
[06:58] <Amaranth> there is a patch to do it for GTK but it's outdated
[06:58]  * Hobbsee changes her mind, and throws it at a ppa instead.
[06:59] <Amaranth> and the panel applet to go with it was horrid
[07:00] <persia> jdong: It's not automated: an archive admin has to manually download it, and manually upload it, after manually tweaking the .changes file.  There's some support scripts, but they're not all the way yet.  I believe it's currently preferred to treat non-Debian sources as new Ubuntu uploads, rather than sync candidates.
[07:01] <jdong> persia: oh okay, that's fine too. I guess I'll go towards a motumedia PPA -> Hardy approach with it then :)
[07:01] <jdong> persia: tomorrow may be the day of my multimedia burnout :)
[07:02] <persia> jdong: That's likely faster.  You might also check with the archive admins: if they prefer the manual sync to a fresh upload, so as to track Origin properly, then this bug oughtn't be "Invalid".
[07:04] <persia> jdong: Also, are you still working on bug #145508, or is that ready for sponsoring?
[07:04] <ubotu> Launchpad bug 145508 in z88dk "[TEST] z88dk has a test bug open" [Undecided,Fix released] https://launchpad.net/bugs/145508
[07:04] <persia> Err.  Bug #145506
[07:04] <ubotu> Launchpad bug 145506 in gtkpod-aac "gtkpod-aac does not allow adding local tracks, claims iPod is not loaded (gutsy)" [Undecided,In progress] https://launchpad.net/bugs/145506
[07:04] <jdong> persia: ok, I've assigned the bug to myself and asking archive admin is on my todo list
[07:05] <jdong> persia: that debdiff is good for uploading into Hardy
[07:05] <persia> jdong: OK.  Remember to adjust the Status / Assignment next time :)
[07:05] <jdong> persia: okay, do you prefer it assigned to uus? and what status should I use?
[07:06] <persia> jdong: https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue
[07:07] <jdong> persia: ah yes, it's documented in black and light brown. Shame on me for not reading it :)
[07:07] <jdong> I'll use the right statuses from now on
[07:17] <jdong> persia: ah seems like the sync vs upload thing is a nonissue anyway; the package requires some trivial control mangling to match ubuntu build-dep names
[07:20] <persia> jdong: Ah.  Perfect then.  Process as a merge, retitle, and resubmit to the queue.  Which bug again (I lost my log)
[07:20] <jdong> bug #160403
[07:20] <ubotu> Launchpad bug 160403 in gpac "Please sync gpac 0.4.4-0.3 from debian-multimedia.org unstable" [Undecided,New] https://launchpad.net/bugs/160403
[07:20] <persia> jdong: Unsubscribed pending update
[07:22] <jdong> persia: on a merge should I graft in the two previous Ubuntu changelog entries if they are basically frivilous?
[07:23] <persia> jdong: I haven't looked at the package.  The general answer is yes, as the previous people who worked on it deserve credit (until there is a working sync source).
[07:24] <jdong> ok, will do then :)
[07:24] <persia> jdong: If you're not preserving the changes, just report that in your changelog entry.  If you are keeping the changes, then reference them as with any merge.
[07:37] <jdong> ok, build time :)
[07:42] <imbrandon> ok question, how evil is it if i add a maintainer script to install a config file based on if its debian or ubuntu ( and this change would go upstream to debain as i maintain the package there too )
[07:42] <jdong> what specifically would be handled differently?
[07:42] <imbrandon> e.g. have a package.conf.debian and a package.conf.ubuntu in the /debian dir and install it based on lsb-release
[07:43] <StevenK> But why?
[07:43] <jdong> I don't think Debian would be amused about having Ubuntu-specific cruft in their packaging
[07:43] <imbrandon> StevenK: because i'm maintaining two packges ( the conf requires deb lines )
[07:43] <persia> imbrandon: There's a lot of packages that do that now.
[07:43] <imbrandon> err one packeg but a delta
[07:44] <imbrandon> e.g the sid package has deb ftp.debian.org sid main etc and ours i patch to have s/sid/<dev-release>/g
[07:44] <persia> jdong: Depends on the definition of "Debian".  For dual-maintained packages, it's not so bad (i.e. when the Debian maintainer is monitoring Ubuntu)
[07:44] <imbrandon> but i maintain both here and debian
[07:44] <imbrandon> persia: heh well in this case the dore-dev is mentoring debian heheh
[07:44] <imbrandon> core* bleh
[07:45] <jdong> imbrandon: meh that doesn't sound as evil
[07:45] <persia> imbrandon: Don't you want that in a config file anyway?  I'd think it would break for lenny users.
[07:45] <jdong> if desktop wallpaper isn't mostly brown, disable fancy features....
[07:45] <imbrandon> persia: well thats why i was thinking about a lsb release generated config
[07:45] <persia> imbrandon: That's a build-time, no?  You need something that works at run-time.
[07:46] <imbrandon> its apt-mirror , thus the need for deb lines
[07:46] <persia> It doesn't matter so much for Ubuntu, as we rebuild a lot, but for something to reach lenny, you can't rebuild from sid.
[07:46] <imbrandon> persia: i could include all the configs like debootstrap and only install the correct one
[07:46] <imbrandon> is what i was thinking
[07:46] <persia> imbrandon: That works: install all the configurations, and select the right one at run-time.
[07:46] <imbrandon> right
[07:47] <imbrandon> or install time
[07:47] <imbrandon> is more what i was thinking
[07:47] <persia> imbrandon: I don't like install-time, as it will likely be a conffile, and then users who upgrade don't get the upgrade unless you rebuild.
[07:47] <imbrandon> the current apt-mirror conf looks much like sources.list ( intentionaly )
[07:47] <persia> (and they didn't touch it)
[07:48] <imbrandon> persia: alternatives
[07:48] <imbrandon> err i guess thats ment for binarys though
[07:48] <persia> imbrandon: Still, what happens for a hardy user who upgrades to hardy+1 ?
[07:49] <imbrandon> likely after its in service they wont want to change
[07:49] <imbrandon> e.g. it mirrors the archive anyhow so its likely not to be an unedited config
[07:49] <persia> imbrandon: No?  It's a mirror, right?  Won't they want to mirror the new version?
[07:49] <imbrandon> right but thats an addition , hrm
[07:49] <imbrandon> true
[07:50] <LaserJock> I wouldn't want it to change my mirror upon upgrade
[07:50] <LaserJock> I should have to change it no?
[07:50] <imbrandon> yes it wouldent automaticly, as the conf is a true conf in /etc/*
[07:50] <imbrandon> so a package upgrade would ask to diff the conf
[07:50] <persia> Right.  In that case, maybe install-time could work, but I still think having a managed configuration that sources something in /etc/default makes sense, with initial /etc/default set to match lsb-release
[07:50] <jdong> persia: ok, got bug #160403 merged, debdiff attached and uus subscribed :)
[07:50] <ubotu> Launchpad bug 160403 in gpac "Merge gpac 0.4.4-0.3 from debian-multimedia.org unstable" [Undecided,Confirmed] https://launchpad.net/bugs/160403
[07:51] <persia> jdong: Excellent.  I process in FIFO mode, but as I'm currently waiting for a main sponsorship, I'm especially motivated: I may even get to that tonight.
[07:52] <jdong> hehe :)
[07:52] <imbrandon> persia: you need a main upload ?
[07:52] <persia> imbrandon: Yep, and a sparky-specific backport.  Bug #163485
[07:52] <ubotu> Launchpad bug 163485 in linda "please adopt new menu policy" [Undecided,New] https://launchpad.net/bugs/163485
[07:53] <imbrandon> want it uploaded to main or sparky
[07:53] <imbrandon> ( or both )
[07:53] <persia> imbrandon: If I only get one, sparky, but main would be good too :)
[07:53] <jdong> oh god please tell me that gtkpod-aac bug doesn't affect gtkpod too.... :D
[07:53] <imbrandon> k give me 5 minutes to finsh something then i'll get on it
[07:53] <jdong> if so I'm gonna have to cry and mail debian BTS :D
[07:54] <persia> imbrandon: Excellent.  That means that REVU will not be schizophrenic about menu entries for REVU day :)
[07:54] <imbrandon> :)
[07:54] <codemaste1> I've just uploaded srcpd to dput a few hours ago, how come I can't see it on the REWA website?
[07:54] <imbrandon> persia: do you use revu-tools localy ?
[07:54] <persia> imbrandon: No.
[07:54] <imbrandon> ahh
[07:55] <persia> imbrandon: why?
[07:55] <codemaste1> I mean upload srcpd to REVU using dput
[07:55] <persia> codemaste1: Do you belong to the "Contributors to Ubuntu Universe" group?
[07:55] <imbrandon> nice all in one thing, just prior to you spororing an upload
[07:56] <persia> imbrandon: Interesting.  I'll have to take a look.
[07:56] <jdong> whoo! it definitely affects debian gtkpod too.... I get all the fun
[07:57] <imbrandon> codemaste1: srcpd_2.0.10-1_source.changes ?? its in the rejected queue , are you in the "Contributors to Ubuntu Universe" group in LP ( if so i need to sync the key )
[07:57] <imbrandon> and after that you can rm `*.upload' localy and reupload ( after the key is synced )
[07:58] <imbrandon> is that the case ?
[07:59] <codemaste1> yes, I'm already in the "Contributors to Ubuntu Universe" group
[07:59] <codemaste1> I also have submitted my PGP key as instructed
[07:59] <imbrandon> ok let me start a key sync, i'll announce when its complete
[08:00] <codemaste1> a few hours ago
[08:00] <imbrandon> codemaste1: right after thats done a REVU admin must sync the keys
[08:00] <imbrandon> ( and i'm doing that now )
[08:02] <imbrandon> persia: do you have a dgetable link for that linda ?
[08:02] <persia> imbrandon: Not now, but I'll make one.  Hold on...
[08:02] <imbrandon> kk
[08:03] <imbrandon> i assume you've build and tested this, i'm only gonna do a light checking of it considering the source of the package
[08:04] <persia> imbrandon: I've been running it for a few hours, and testing it against packages being reviewed.  It shut up the warning, and the code doesn't seem to be doing much else.  The patches I applied are in the bug.
[08:04] <imbrandon> k
[08:04] <persia> imbrandon: http://people.ubuntuwire.com/~persia/linda_0.3.26ubuntu2.dsc
[08:04] <imbrandon> k grabbing now
[08:05]  * jdong wonders if imbrandon is up for a KTorrent sponsor after he's done with persia :)
[08:06] <imbrandon> ugh, ok gnome-ites this has been bugging me, is there two clipboard managers in gutsy gnome or something ( i'm a kde guy on gnome atm )
[08:06] <imbrandon> shitf+insert == diffrent buffer than rightlcik-paste
[08:06] <persia> imbrandon: Yes, the gnome clipboard is not the X selection
[08:06] <imbrandon> sounds like a bug to me
[08:07] <jdong> imbrandon: no, that's how X works
[08:07] <jdong> imbrandon: it's klipper that combines the two together
[08:07] <jdong> imbrandon: you can use glipper to do the same on GNOME
[08:07] <imbrandon> i was gonna say KDE dosent behave like that
[08:07] <imbrandon> ctl+v , shift+insert , right-click+paste , IMHO should all paste the same contents
[08:07] <jdong> at least I think glipper does
[08:08] <jdong> imbrandon: shift-ins is taken the same as mouse-paste, ctrl+v and rightclick-paste are the same
[08:08] <persia> imbrandon: Depends on what you want.  Install glipper if you want that.  I like it separate, and frequently use X selection to move things around while keeping something different on the clipboard.
[08:09] <jdong> imbrandon: of course you can hotkey shift-ins to paste in keyboard settings or whatever, and then they'll act identically
[08:09] <imbrandon> yea i'd like them all the same as with every other OS heh
[08:09] <persia> imbrandon: Actually, if you run X on Windows or OS X, you get the dual behaviour as well :)
[08:09] <jdong> hahaha
[08:10] <jdong> whenever a defense starts "Actually if you run X on Windows..." :D
[08:10] <imbrandon> persia: nah klipper on X windows on win32 merges them too
[08:10] <imbrandon> i actual so that hehe
[08:10] <imbrandon> s/so/do
[08:10] <persia> imbrandon: Right.  klipper does.  Use glipper if you want it: it's not a bug :)
[08:10] <jdong> imbrandon: if you love klipper so much run it inside GNOME :D
[08:10] <imbrandon> jdong: heh NO
[08:10] <imbrandon> i have to fight myself not to install amarok
[08:11] <jdong> before long you'll echo startkde >> ~/.gnomerc...
[08:11] <imbrandon> heh
[08:11] <jdong> but anyway, hurry up with persia's package so I can bug you to upload ktorrent!
[08:11] <imbrandon> i am now
[08:11] <StevenK> Could you make ktorrent suck less?
[08:11] <jdong> StevenK: I'm working on that :P
[08:12] <jdong> it doesn't crash nearly as often as before
[08:12] <StevenK> jdong: It takes 20% CPU even when no torrents are downloading
[08:12] <imbrandon> have to build on two machines, sparky because i dont have a sparc to build it localy and then localy so i can gpg sign to upload :)
[08:12] <jdong> StevenK: err... how?
[08:12] <jdong> StevenK: I have it running always in the background with no CPU usage whatsoever
[08:12] <jdong> StevenK: can you strace it or otherwise figure out what on earth it's trying to do?
[08:13] <StevenK> jdong: I can, a bit later.
[08:13] <jdong> StevenK: thanks, I'd be interested to know
[08:13] <Fujitsu> Why do all graphical P2P apps seem to suck so badly?
[08:13] <imbrandon> uTorrent+wine , multiverse now !
[08:14]  * imbrandon runs
[08:14] <LaserJock> anybody know if git is more stable than bzr developmentally
[08:14] <LaserJock> ?
[08:14] <jdong> Fujitsu: because graphical P2P almost always means a demand for info-erotica...
[08:14]  * Fujitsu is fine with rtorrent.
[08:14] <LaserJock> I just don't use torrents
[08:14] <jdong> Fujitsu: and that always yields to resource usage, etc. Case and point: Azureus's circle swarm view
[08:14] <LaserJock> they are aweful aweful nasty things
[08:14] <imbrandon> git is what the Linux kernel uses so i would assume its pretty stable, never having used it really
[08:14] <Fujitsu> jdong: I guess, yes.
[08:15] <Fujitsu> LaserJock: I don't often, either.
[08:15] <jdong> draws a circle representing EVERY CONNECTED PEER and chunks flying to and from you.
[08:15] <persia> LaserJock: I believe they are about the same: both under active development, but both currently trying to maintain archive-format stability.
[08:15] <jdong> opening up that tab instantly +30MB on RAM usage
[08:15] <LaserJock> it's irritating when bzr keeps changing stuff
[08:15] <jdong> LaserJock: changing stuff like what?
[08:15] <LaserJock> formats
[08:15] <codemaste1> hey, are the keys resynced yet?
[08:16] <imbrandon> codemaste1: looks like ~3 more minutes
[08:16] <Fujitsu> LaserJock: Hasn't it only changed once or twice in a couple of years?
[08:16] <imbrandon> approx
[08:16] <jdong> LaserJock: the migration path is usually braindead easy and it's a purely optional migration often times too
[08:16] <codemaste1> take your time
[08:16] <jdong> Fujitsu: recently we've been getting a lot of backwards-compatible format bumps
[08:16] <Fujitsu> jdong: Ah.
[08:16] <jdong> Fujitsu: and packs is coming up soon which will be a complete format bump
[08:16] <LaserJock> it's just kind annoying
[08:16] <jdong> they are the only way towards performance imprvoements
[08:16] <jdong> so another classic case of can't please everyone.
[08:16] <LaserJock> makes me feel like they can't settle on something
[08:17] <jdong> Stay with same format, people complain that bzr is too slow
[08:17] <LaserJock> but I realize they know wha they're doing
[08:17] <jdong> move to new faster format, people complain the format changed :)
[08:17] <jdong> LaserJock: I've loosely followed the format changes and they all seem incremental/sane
[08:17] <persia> LaserJock: "Can't settle" is better than "That didn't work: building something completely new now".  At least there is effort to make it compatible.
[08:17] <Fujitsu> LaserJock: Do they know what they're doing?
[08:17] <jdong> it's not like they are radically redesigning it
[08:17] <LaserJock> Fujitsu: I'm sure they must, they're smart people :-)
[08:17] <jdong> and as I said before, the clients seem fairly backwards compatible with each other
[08:18] <jdong> I use bzr 0.11 on Athena and bzr 0.92 locally
[08:18] <jdong> and they interoperate perfectly
[08:18] <LaserJock> jdong: sure, it's just a little unsettling when you do a bzr pull or something and it tells you you're using an obsoleted format
[08:18] <imbrandon> LaserJock: isnt it only one command to upgrade the format ?
[08:18] <imbrandon> and then push
[08:19] <LaserJock> sure
[08:19] <LaserJock> that's not the issue
[08:19] <jdong> LaserJock: if you don't tell the user, how would he know a newer format is available?
[08:19] <LaserJock> they issue is things are changing a lot, which one would expect from something in heavy development
[08:19] <LaserJock> *the
[08:19] <Fujitsu> LaserJock: It is in heavy development.
[08:19] <imbrandon> ahh, well it kinda is
[08:19] <LaserJock> right
[08:20] <jdong> LaserJock: it is in fast-paced 1-month-per-release cycles
[08:20] <imbrandon> but in its defense so is git
[08:20] <LaserJock> and I'm saying that's a bit unsettling to users who rely on things not getting eaten, etc.
[08:20] <jdong> but they are sanely managed for stability
[08:20] <Fujitsu> LaserJock: I have a lot of branches, and none of them have been eaten, ever.
[08:20] <jdong> LaserJock: from what I've been told, bzr has had zero data loss bugs across all of its releases
[08:20] <jdong> not counting if you use a development branch of course
[08:20] <Fujitsu> I've upgraded branches from like 0.6 or so all the way up to now.
[08:20] <Fujitsu> Maybe even earlier.
[08:21] <LaserJock> that's good at least
[08:21] <jdong> yeah, the bzr team has earned my trust of reliability
[08:21] <jdong> LaserJock: their test suite is huge, and for a chagne to get merged into the head branch it must pass the test suite
[08:21] <LaserJock> I'm  just used to CVS/svn which are ... not exactly under heavy development
[08:21] <Fujitsu> LaserJock: But CVS and SVN are crap.
[08:21] <LaserJock> not really
[08:21] <Fujitsu> Particularly the former.
[08:22] <jdong> bzr's reliability with data is not an accident -- it's definitely by design :)
[08:22] <persia> Does anyone have a favorite CLI IRC client?
[08:22] <Fujitsu> persia: irssi
[08:22] <jdong> persia: irssi
[08:22] <imbrandon> irssi
[08:22] <Fujitsu> rofl
[08:22] <jdong> :D
[08:22]  * imbrandon is on it now
[08:22] <LaserJock> I've not found anything that I couldn't do in CVS/svn really
[08:22]  * jdong is on it now
[08:22]  * Fujitsu hasn't used anything else for quite a while.
[08:22] <Fujitsu> LaserJock: Merge.
[08:22] <LaserJock> persia: irssi
[08:22] <persia> Right.  Then irssi will be listed as the "Obsoleted By" for ircii-pana :)
[08:22] <jdong> Fujitsu: (1) host without a specialized server setup
[08:22] <Fujitsu> persia: Yep. I'll be really glad to see that gone.
[08:22] <LaserJock> Fujitsu: I've only done that once before
[08:22] <Fujitsu> jdong: That too.
[08:22] <jdong> Fujitsu: (2) Allow contributors to version their changes while not granting write access to main branch
[08:22] <Fujitsu> LaserJock: You are an edge-case.
[08:23] <LaserJock> ok, great :-)
[08:23] <LaserJock> always an edge case
[08:23] <Fujitsu> jdong: Doesn't svk solve that?
[08:23] <jdong> Fujitsu: well yeah, but svk is analgous to bzr anyway
[08:23] <LaserJock> 1) and 2) aren't a problem for me, it's not hosted and it's just me
[08:23] <persia> Fujitsu: Up to archive-admins now...
[08:23] <jdong> Fujitsu: with svk, still see #1, and Svk's development team is a lot smaller
[08:23] <Fujitsu> persia: Good, though I'm really not sure what to do with the old releases.
[08:23] <jdong> Fujitsu: I've actually lost/corrupted mirrors in svk before... :(
[08:24] <Fujitsu> jdong: I was complaining that SVN was bad, not defending it (except for the SVK bit)
[08:24] <jdong> fortunately they were rebuildable from other sources
[08:24] <LaserJock> I really like svn
[08:24] <jdong> Fujitsu: sorry I meant to aim it at LaserJock :)
[08:24] <LaserJock> CVS is a lot harder to use for me
[08:24] <imbrandon> Fujitsu: -updates with ircii-panna+really_irssi :)
[08:24] <imbrandon> persia: ^^
[08:24] <imbrandon> LOL
[08:24] <LaserJock> but svn is so easy
[08:24] <Fujitsu> imbrandon: Ewww.
[08:24] <persia> Fujitsu: If you want, you could add tasks to Bug #162870, but the barrier to convince the archive-admins for old releases is much higher.  Alternately, you could do a transition SRU that installs irssi, but that doesn't seem right somehow.
[08:24] <ubotu> Launchpad bug 162870 in ircii-pana "Removal of ircii-pana" [Undecided,New] https://launchpad.net/bugs/162870
[08:24] <Fujitsu> LaserJock: How is it easier than bzr!?
[08:24] <imbrandon> Fujitsu: total joke
[08:24] <Fujitsu> persia: That seems really, really broken. `WTF? Where did it go!?'
[08:25] <jdong> LaserJock: svn servers are quit more complex compared to bzr
[08:25] <LaserJock> Fujitsu: it's fast
[08:25] <persia> Fujitsu: Like I said, the barrier to convince is higher.  Just dropping for hardy will be a good thing.
[08:25] <LaserJock> bzr has basically the same features
[08:25] <Fujitsu> persia: Right.
[08:25] <LaserJock> so it doesn't make much of a difference to me
[08:25] <Fujitsu> Upstream vanished ages ago, etc.
[08:25] <jdong> LaserJock: svn is missing distributed development though
[08:25]  * persia is still waiting for nested trees in bzr
[08:26] <LaserJock> jdong: I've never found distributed development to be very interesting
[08:26] <jdong> distributed development is a critical feature for me
[08:26] <LaserJock> I don't like it much in fact
[08:26] <imbrandon> persia: new linda on sparky, working on hardy upload now
[08:26] <persia> imbrandon: Great.  Thanks!
[08:26] <jdong> LaserJock: ah well if you don't need DD then there's much less reason why to choose bzr :)
[08:26] <codemaste1> so how is the key sync?
[08:26] <LaserJock> jdong: exactly
[08:26] <LaserJock> svn works just fine for me mostly
[08:27] <imbrandon> codemaste1: sorry finished, remove your local .upload file and re-dput
[08:27] <LaserJock> although I like that I can create a bzr branch anywhere
[08:27]  * Fujitsu likes that he always has the version history and can work offline.
[08:27] <persia> codemaste1: All the keys are pulled from LP to check the signatures of people who upload.
[08:27] <codemaste1> are you telling to remove my local .upload and re-dput?
[08:27] <persia> codemaste1: Yes
[08:27] <imbrandon> codemaste1: yes
[08:27] <codemaste1> If so, how can I remove my local .upload?
[08:27]  * jdong likes how easy it is to create new repos and branch in bzr
[08:27] <persia> codemaste1: rm?
[08:27] <LaserJock> but I've just not seen much use for distributed development in anything I've done
[08:27] <jdong> I often do merge type work in bzr
[08:27] <imbrandon> rm <file>.upload
[08:27] <jdong> even for non-bzr-managed packages
[08:28] <codemaste1> is it in my local computer?
[08:28] <imbrandon> yes, in the same directory as the dsc
[08:28] <codemaste1> thx
[08:28] <imbrandon> it creates it when you dput the file
[08:28] <imbrandon> so you dont upload the same file 2 times, but in this case you want to
[08:28] <imbrandon> thus removeing it
[08:29] <LaserJock> I'm a little sad that the doc team is finally moving to bzr
[08:29] <LaserJock> svn worked so well in that case
[08:29] <imbrandon> codemaste1: and fyi the newuploads are processes every 5 minutes, iirc, so if you dont see it in the webui in ~15 then poke me/us again
[08:29] <LaserJock> and bzr is so darn slow
[08:30] <jdong> LaserJock: they're making good progress on performance
[08:30] <imbrandon> LaserJock: have you tried bzr+ssh, seems MUCH faster IMHO
[08:30] <LaserJock> yeah
[08:30] <jdong> LaserJock: pushing and branching over bzr+ssh helps immensely
[08:30] <jdong> as is having the latest branch format on both sides
[08:30] <LaserJock> but it took us over a day just to push the first branch
[08:30] <LaserJock> and then we had to have somebody in the DC do the branching for us locally
[08:31] <imbrandon> wow
[08:31] <LaserJock> cause it was going to take at least a week to get our branches uploaded to LP
[08:31] <LaserJock> and now we have so much duplication
[08:31] <jdong> LaserJock: yikes, that's not normal...
[08:31] <imbrandon> how big is this damnd branch ?
[08:31] <persia> Would anyone like to help cleanup the partial Edgy SRU that is Bug #83731?
[08:31] <ubotu> Launchpad bug 83731 in mldonkey "[SRU] Edgy: Urgent patch to solve upload problem" [Undecided,Fix committed] https://launchpad.net/bugs/83731
[08:31] <Fujitsu> persia: Did pitti not remove it?
[08:31] <LaserJock> imbrandon: the svn repo is ~200MB or so
[08:31] <imbrandon> wow
[08:31] <imbrandon> yea thats huge
[08:32] <LaserJock> imbrandon: with around 4k commits
[08:32] <persia> Fujitsu: Yes, but a respin was requested, and it's in the sponsors queue (where it doesn't really belong).  I want someone to own it before sending it off to be forgotten.
[08:32] <LaserJock> and then you have to times that by 4
[08:32] <LaserJock> cause we branched for each *buntu
[08:32] <jdong> persia: wow that's old school... is the only thing that need to be done the version?
[08:32] <codemaste1> how is the upload of srcpd?
[08:32] <Fujitsu> IIRC LP is getting server-side branching soon.
[08:32] <codemaste1> does it look good?
[08:33] <persia> jdong: Just about.  You want it?
[08:33] <imbrandon> i'll look
[08:33] <persia> jdong: Needs verification as well :)
[08:33] <jdong> persia: I'm ambivalent. I don't think I'll be able to solicit verification on an *edgy* package
[08:33] <LaserJock> it still takes hours to branch the docteam repo :(
[08:33] <Fujitsu> LaserJock: Even using bzr+ssh?
[08:33] <jdong> persia: honestly I think it'll end up in this same state 3 months down the road :)
[08:33] <persia> jdong: That has been the problem historically :)
[08:33] <Fujitsu> Edgy dies in 5 months.
[08:33] <imbrandon> codemaste1: dosent looked to be rejected this time, i'll be able to tell better once REVU does its cron magic
[08:33] <LaserJock> Fujitsu: I'm not positive on that, perhaps
[08:33] <jdong> LaserJock: bzr+ssh:// basically tars up and sends over a tarball of the repo
[08:33] <jdong> LaserJock: if that's slow, then it's LP bandwidth issues
[08:34] <LaserJock> I know it took 5 hrs for one person to branch
[08:34] <jdong> which doesn't surprise me at all but *cough*
[08:34] <codemaste1> this is the first time I do packaging...
[08:34] <Fujitsu> mplayer often takes 3 or 4 hours to push a new branch.
[08:34] <LaserJock> yeah, that's nuts
[08:34] <LaserJock> I don't have time for that
[08:34] <Fujitsu> We only have to do that once for each release, fortunately.
[08:35] <Fujitsu> And I haven't done it since bzr+ssh arrived.
[08:35] <LaserJock> and I'm still a tad burned from the bzr 0.11 days
[08:35] <persia> Do we have an active MOTU SRU team?  I'd like to hand this somewhere (even if only to be officially rejected).
[08:35] <LaserJock> when I could use bzr from home
[08:35] <LaserJock> *couldn't
[08:35] <jdong> persia: last comment is 2007-03-24.... since it was fixed in Feisty I honestly doubt anyone still cares
[08:35] <Fujitsu> persia: The MOTU SRU team was abolished 9 months ago.
[08:35] <persia> Fujitsu: Lack of interest, or for a specific reason?
[08:35] <jdong> persia: anyway I'll comment on the bug and see if anyone on Edgy still cares about the bug. If I get two people to commit then I'll do it
[08:35] <Fujitsu> persia: It was previously simply handling approvals.
[08:35] <LaserJock> persia: no longer needed
[08:36] <persia> jdong: Great.  I'll unsubscribe, and assign you :)
[08:36] <Fujitsu> That role is now held by the individual MOTU.
[08:36] <persia> Ah.  I was thinking of a team (including Contributor members) that was committed to testing and prepping solutions: not an approval team.  We need one of these.
[08:37] <jdong> persia: agreed, IMO SRU's tend to be ignored for shinier work
[08:37] <LaserJock> persia: no we don't have one of those, though we maybe should
[08:37] <persia> Right.  Who volunteers to lead the team (No, you don't need to be MOTU).
[08:37] <LaserJock> jdong: speaking of
[08:37] <jdong> I think a SRU wrangling team would be a great thing to have, the question is how many people woudl be interested?
[08:37]  * Fujitsu would prefer a security wrangling team, personally.
[08:37] <LaserJock> jdong: remember those SRUs I gave you a few (many) months ago
[08:37] <LaserJock> ?
[08:38] <jdong> LaserJock: very vaguely, yes
[08:38] <imbrandon> hrm SRU's might be fun, since i'm not doing enough other cruft
[08:38] <imbrandon> lol
[08:38] <LaserJock> jdong: their still sitting around in -proposed I think
[08:38]  * imbrandon needs to re-prioritise some things
[08:38] <persia> Fujitsu: Why separate?  Have one team that helps with all fixes for releases, both security and non-security.  Security gets priority.
[08:38] <Fujitsu> persia: Sounds good.
[08:38] <imbrandon> persia: good idea
[08:38] <StevenK> persia: Works for me.
[08:38] <persia> Fujitsu: You want to run it?
[08:38] <jdong> LaserJock: :( what can I do about it if nobody seems to verify?
[08:38] <LaserJock> jdong: announce that they need verification
[08:39] <Fujitsu> persia: Sure. We already have ~motu-swat.
[08:39]  * StevenK runs off to cook butter chicken for dinner
[08:39] <LaserJock> jdong: one is in Universe and you can send out a SRU:  call for testing email to -motu
[08:39] <imbrandon> i can be a part of it , serouisly, i've been looking to shift that way anyway for various dapper --> hardy bits, but i'm not a leader IMHO
[08:39] <jdong> LaserJock: ah, good idea, I'll put that on my todo list
[08:39] <LaserJock> jdong: the other one is in Main I think and you might have to ask bdmurry about what to do for that
[08:40] <persia> Fujitsu: Great.  As I've forgotten, and I suspect others have as well, please send a note to the ML about all the great things motu-swat does, how to join, and how to ask for help with testing / verification.
[08:40] <Fujitsu> persia: Well, ~motu-swat was meant to handle universe security issues, but hasn't done anything since about March. Very few members seem to exist any more.
[08:41] <persia> Fujitsu: Sure: repurpose.  You need more members, right?
[08:41] <Fujitsu> Right.
[08:41] <imbrandon> Fujitsu wanna add me to ~motu-swat ( i should really leave other various teams i'm no longer active in ) , but as i said that would abe a good focus for my energies since dapper --> hardy will likely take some SRU love
[08:41] <LaserJock> Fujitsu: maybe -swat should handle all stable release stuff for Universe?
[08:42] <Fujitsu> LaserJock: Sounds sane.
[08:42] <imbrandon> LaserJock: yea thats what we was considering
[08:42] <Fujitsu> imbrandon: Sure.
[08:42]  * persia wants to emphasize that motu-swat helps handling all stable release stuff, and that others are welcome to help, even if they aren't in the team.
[08:42] <Fujitsu> Yep. I'll write up an email tonight.
[08:42] <LaserJock> excellent
[08:43] <persia> Fujitsu: Thanks.  That'll go a long way towards getting "community supported" to actually mean something.
[08:43] <LaserJock> do we still have a Universe QA?
[08:43] <LaserJock> team that is
[08:43] <Fujitsu> persia: Heh, hopefully.
[08:43] <persia> LaserJock: Not right now, but we're still assembling tools and stuff: I don't think we're really ready for a marketing push on that.
[08:43] <Fujitsu> LaserJock: Didn't know we ever did...
[08:44] <nenolod> when will the next sync from debian unstable happen?
[08:44] <LaserJock> so MOTU swat handles stable releases and MOTU QA handles development releases
[08:44] <persia> nenolod: Likely Monday
[08:44] <nenolod> groovy
[08:44] <Fujitsu> LaserJock: Sounds good.
[08:44] <persia> LaserJock: Well, loosely, but yes.
[08:44] <LaserJock> that sounds like a winner to me
[08:44]  * persia wants to avoid a choice: people should be able to work on both areas if interested
[08:44] <LaserJock> well sure
[08:45] <imbrandon> persia: linda uploaded
[08:45] <LaserJock> I don't think we need to lock people in or anything
[08:45] <codemaste1> imbrandon: Thanks  I can see srcpd on the site.  What do you think about this package?  Is it good enough?
[08:45] <LaserJock> "Sign up now for a 2 release commitment"
[08:45] <nenolod> i just maintain my packages in universe by sending them through debian unstable
[08:45] <nenolod> which is why i am wondering :P
[08:45] <persia> imbrandon: Extra cool.  Now I just have to wait for the Debian maintainer, and my changes can get undone :)
[08:45] <LaserJock> "Early release penalty is 10 SRUs"
[08:46] <Fujitsu> s/SRU/CVE/
[08:46] <persia> nenolod: OK.  More generally, during the beginning of the Ubuntu release cycle, a sync happens whenever the archive-admins or cron get around to it, which tends to be fairly often.
[08:46] <Fujitsu> Heh.
[08:46] <LaserJock> Fujitsu: hehe
[08:46] <imbrandon> codemaste1: i cant REVU it at the moment, you can either A) copy the package URL from revu.ubuntuwire.com and paste it in here asking for Reviews and/or come arround next revu day and poke people, personaly i sugest both
[08:46] <persia> After DebianImportFreeze, syncs happen per-package and only on-request.
[08:46] <LaserJock> alright, it's almost 1am and I have to be up early
[08:46] <imbrandon> gnight LaserJock
[08:46] <nenolod> i should eventually apply to be a MOTU. from what i have heard, the process is easier than becoming a DD (at least for me, the only people who can sign my key in Debian are like thousands of miles away)
[08:47] <persia> After FeatureFreeze, syncs that add features need approval from the UVF team, and only happen by-package and by-request.
[08:47] <Fujitsu> Night LaserJock.
[08:47] <imbrandon> nenolod: work on getting other Ubuntu MOTU or core-dev to sign it
[08:47] <nenolod> MOTU mandates keysigning too?
[08:47] <nenolod> well, i'm probably boned
[08:48] <nenolod> :P
[08:48] <persia> nenolod: The process is easier, but it also works differently.  For MOTU, you start by preparing candidate uploads for packages.  When you have a lot of stuff in the archive, we'll tell you you should be MOTU, and you are granted upload rights.  It's work first, then process, rather than process first, then work.
[08:48] <imbrandon> yes
[08:48] <Fujitsu> nenolod: We don't, but it's strongly recommended, and I feel uneasy about people letting unsigned keys onto the keyring.
[08:48] <codemaste1> srcpd link: http://revu.tauware.de/details.py?package=srcpd
[08:49] <codemaste1> would you please REVU my srcpd package?  I need constructive feedback
[08:49] <imbrandon> Fujitsu: well we dont require strong set but iirc it has to be atleaste signed by $someone
[08:49] <persia> imbrandon: The requirements fluctuate widely depending on the individual, and who checks.  I believe it should be strong-set (if not Debian-strong or Ubuntu-strong), but not everyone is even signed (especially early people).
[08:49] <imbrandon> but that might have changed since i became core, havent checked since then
[08:50] <nenolod> Fujitsu, well, it's signed by "people", just not ubuntu people :P
[08:50] <nenolod> otoh
[08:50] <persia> nenolod: Are you in the strong set?
[08:50] <persia> nenolod: Also, aside from that, we'd welcome your debdiffs today, regardless of anything else, and the rest can be resolved as time passes :)
[08:51] <nenolod> persia, well my debdiffs would just be against packages i already maintain via debian
[08:51] <imbrandon> persia: yea he has been on that road a while :)
[08:51] <persia> nenolod: That's also welcome, although we encourage breadth for MOTU.  If you don't mind being sponsored, you can keep the packages in shape in both places fairly easily.
[08:52] <nenolod> persia, i don't mind being sponsored
[08:52] <nenolod> persia, a friend of mine sponsors my uploads in debian anyway
[08:52] <nenolod> as i said, i can't get my key signed by anyone in debian because they are all too far away from me :P
[08:52]  * imbrandon goes to trim some teams he is inactive in from LP
[08:53] <nenolod> if i were to get my key signed in debian, i'd have to drive a large distance
[08:53] <jdong> imbrandon: are you up for looking at a ktorrent sponsor? :)
[08:53] <imbrandon> jdong: sure give me a dsc url
[08:53] <jdong> imbrandon: bug #163426 -- debdiff against current hardy version
[08:53] <ubotu> Launchpad bug 163426 in ktorrent "KTorrent 2.2.3 crasher" [Undecided,New] https://launchpad.net/bugs/163426
[08:54] <nenolod> persia, how would a sponsorship process work in that case?
[08:54] <nenolod> because i can upload the fixes to debian today, so all would be needed would be to just dget the update and sync manually
[08:55] <persia> nenolod: Depends.  If it's just syncs, open a sync request bug, and subscribe the sponsors queue.  If you have an Ubuntu-specific variation (e.g. FTBFS issue only in Ubuntu), attach a debdiff to the bug, and subscribe the sponsors queue.
[08:55] <nenolod> works for me
[08:55] <nenolod> :)
[08:55] <persia> Requested syncs usually get done about twice a week after DIF (and are mostly automated before that).
[08:56] <nenolod> right now i am working on projectM in amarok if anyone cares
[08:56] <nenolod> per DarkMageZ
[08:56] <nenolod> ;p
[08:56] <imbrandon> jdong: working on it now
[08:56] <jdong> imbrandon: thank you very much
[08:56] <imbrandon> np
[08:57] <nenolod> but since syncs are automated, i won't bug anyone for now =)
[08:57] <imbrandon> jdong: although from now on if you intend to poke me personaly make a dsc url :) hehe
[08:57] <jdong> imbrandon: hehe *note to self: imbrandon likes dsc's*
[08:57]  * imbrandon grabs mt dew while this test builds
[08:59] <jdong> holy crap it's 4AM
[08:59] <imbrandon> yea i like to do my revuing localy, even for stuff uploaded to revu i normaly grab it local
[08:59] <imbrandon> or ssh in
[08:59]  * jdong heads off to bed
[08:59] <nenolod> persia, btw i wound up using just a standard dh_make rules for that cmake package :P
[08:59] <JDahl> can you use "apt-get build-dep" with "apg-get source" to fetch build-dependencies as sources,  instead of getting the binary versions?
[08:59] <persia> nenolod: Ah.  Likely easier that way :)
[08:59] <imbrandon> nenolod: what cmake pacakge ?
[09:00] <jdong> JDahl: no
[09:00] <imbrandon> just curious
[09:00] <persia> JDahl: You might want to look at apt-build, which can help with that, but not really.
[09:00] <persia> JDahl: Also, it's typically not worth it.
[09:00] <jdong> JDahl: use some grep foo :)
[09:01]  * persia points out that grep-dctrl is likely easier than grep
[09:01] <nenolod> imbrandon, libprojectm
[09:01] <JDahl> persia, I instead Debian sid main section as a source,  since I am trying to build xserver-xorg-intel-video:2.2.0,  but there's alot of dependencies and I hoped I didn't have to build the dependencies manually
[09:01] <JDahl> *inserted
[09:01] <jdong> JDahl: sudo apt-get -s build-dep gcc-4.2 | grep '^Inst' | awk '{print $2}' | xargs -i apt-get source {}
[09:01] <jdong> JDahl: something fun like that :)
[09:01] <nenolod> imbrandon, http://ftp.debian.org/debian/pool/libp/libprojectm/libprojectm_1.01-2.dsc
[09:02] <jdong> JDahl: or loop over the Build-Depends: field on the source :)
[09:02] <persia> JDahl: You shouldn't have to build the dependencies manually: the buildds don't.  Just use apt-get build-dep to grab the ones you can.
[09:02] <imbrandon> nenolod: cool
[09:02] <nenolod> oops
[09:02] <nenolod> imbrandon, http://ftp.debian.org/debian/pool/main/libp/libprojectm/libprojectm_1.01-2.dsc
[09:02] <JDahl> persia, won't that install binaries?
[09:02] <persia> nenolod: Does that need to be archived on REVU?
[09:02] <nenolod> persia, yeah, it can be nuked
[09:02] <jdong> JDahl: that'll install binaries
[09:02] <persia> JDahl: Yes.  Isn't that a good thing?  If you don't install the binaries, you need to compile everything.
[09:03] <imbrandon> nenolod: archived != nukes
[09:03] <imbrandon> err nuked
[09:03] <JDahl> persia, I am backporting something from Debian sid
[09:03] <nenolod> persia, the version on revu was 0.x, which still used autotools
[09:03] <nenolod> imbrandon, oh. ok. it can be archived then ;)
[09:03] <jdong> JDahl: you'd probably want something like a version of pbuilder-satisfy-depends that outputs a list of packages not satisfyable
[09:03] <persia> nenolod: libvisual-projectm?
[09:03] <JDahl> jdong, ok - thanks
[09:03] <nenolod> persia, libvisual-projectm will probably go through NEW later today
[09:03] <persia> or libprojectm?
[09:03] <nenolod> persia, libprojectm
[09:04] <persia> Right.  I'll archive both of them.  Thanks.
[09:04] <jdong> JDahl: you'd probably be better off manually looking at which build dependencies cannot be satisfied, and building those by hand
[09:04] <nenolod> persia, I'm working with DarkMageZ on libvisual-projectm
[09:04] <jdong> JDahl: blindly recursively backporting can lead to some interesting results
[09:04] <JDahl> jdong, yes - it's seems so
[09:04] <JDahl> jdong, but the good things about apt-get source is that you dont need to be root ;)
[09:05] <persia> nenolod: Cool.  Are you also looking at libvisual-plugins in general?  If I remember correctly, that package had a lot of variation between Debian and Ubuntu, and it'd be nice to get it sorted.
[09:05] <jdong> JDahl: I write prevu, a backporting tool, and I've played with the idea of automatically chasing after a dependency chain. I've found most of the times you end up with a good chunk of the development distro :)
[09:05] <nenolod> persia, libvisual doesn't interest me. the only reason why i am working with DarkMageZ on libvisual-projectm is because i already maintain libprojectm, so i figure it would be easier that way
[09:06] <nenolod> the only player that uses libvisual is amarok
[09:06] <persia> nenolod: Ah.  Oh well :)
[09:07] <imbrandon> nenolod: iirc dosent some of the older ones too like xmms ?
[09:07] <imbrandon> ( i did the libvisual0.2 --> 0.4 transition for amaork in dapper )
[09:07] <nenolod> imbrandon, no. they only do libvisual 0.2, which is not compatible with libvisual 0.4
[09:07] <imbrandon> ahh
[09:07] <StevenK> Yay for SOVER bumps
[09:07] <nenolod> audacious used libvisual at one time
[09:08] <nenolod> but we dropped it when lv 0.4 came out and it was entirely different ;p
[09:08] <imbrandon> yea, i rember doing that transition , it was painfull
[09:08] <persia> StevenK: Think of it as upstream giving us a nice NBS list so we don't get bored :)
[09:10] <StevenK> persia: :-)
[09:10] <nenolod> i've only used amarok once
[09:10] <nenolod> that was tonight to make sure the libvisual-projectm package worked :P
[09:11] <imbrandon> amaork == love, me is sadend now
[09:11] <Fujitsu> imbrandon: Why?
[09:11] <nenolod> imbrandon, well, i wrote audacious for me, it suits my needs 100% etc
[09:11] <nenolod> ;p
[09:11] <imbrandon> :)
[09:12] <DarkMageZ> persia, i'm working on pushing the changes in libvisual-plugins up to debian. the old maintainer has declared them rfa.
[09:12]  * StevenK hugs Quod
[09:12] <persia> DarkMageZ: Excellent.  Thanks for chasing that.
[09:12]  * Fujitsu hugs Rhythmbox.
[09:12] <Fujitsu> Even though it has segfaulted on start for the past week.
[09:12] <nenolod> DarkMageZ, well, if he does RFA, then i'll maintain them with you
[09:12] <imbrandon> Fujitsu: because it handles my ipod and music collection just how i like, dunno specific, just one of theose personal prefs
[09:12] <Fujitsu> imbrandon: No, why are you saddened?
[09:12] <StevenK> Fujitsu: If I could make Rhythmbox look like Quod, I'd probably use it.
[09:13] <Fujitsu> StevenK: What do you prefer about Quod's UI?
[09:13] <DarkMageZ> nenolod, declaration of rta @ 451212 & 451213
[09:13] <imbrandon> Fujitsu: ahh that i'm on gnome atm and try not to mix DE apps, e.g if i'm on kde i use qt+kde , gnome gtk+gome
[09:13] <imbrandon> and miss amaork :)
[09:13] <Fujitsu> imbrandon: Ah.
[09:13] <Fujitsu> Exaile!
[09:14] <nenolod> bmpx
[09:14] <StevenK> Fujitsu: Exaile seems to be memory hungry and slow
[09:14]  * Fujitsu hasn't touched it.
[09:14] <nenolod> bmpx.
[09:14] <StevenK> Fujitsu: How clean it is
[09:14] <nenolod> bmpx is the only library like player i've used that hasn't made me want to kill people
[09:14] <imbrandon> i actualy in reality use pympd more than anything else on gnome
[09:15]  * Fujitsu only moved to Rhythmbox from gmpc a couple of months back.
[09:15]  * persia prefers audacious to bmpx
[09:15] <nenolod> persia, those comparisons really are inane
[09:15] <nenolod> bmpx is an entirely different thing
[09:15] <persia> nenolod: Yes :)
[09:15] <nenolod> bmpx is a library player with a big gtk2 ui
[09:15] <nenolod> :P
[09:16] <nenolod> http://bmpx.beep-media-player.org/site/Image:Bmpx-0.40-screenshot-5.jpg
[09:16] <nenolod> like so
[09:17] <imbrandon> jdong: ktorrent uplaoded, updating bug now
[09:17] <DarkMageZ> is bmpx stable yet? i remember when i played with it back in the day it was nuclear
[09:18] <crimsun> jdong: (just a note: you can combine your earlier grep+awk into awk '/^Inst/ {print $2}'
[09:19] <nenolod> audacious is stable :P
[09:19] <nenolod> but apparently mister DarkMageZ uses amarok ;p
[09:19] <nenolod> but seems to enjoy my strangled version of xchat
[09:20] <nenolod> persia, i wonder if ubuntu will follow the pending gtk1 removal from debian?
[09:20] <DarkMageZ> lol, i have a build of conspire on my system somewhere. it's one of those projects i'm keeping a track of to see how far it'll go.
[09:20] <Fujitsu> nenolod: It will be an LTS, so I hope so.
[09:20] <persia> nenolod: It's been mooted.  If we can migrate everything, we will.
[09:21] <nenolod> so ubuntu will never ever get rid of XMMS? :D
[09:21] <persia> nenolod: The difference is the deadline.  We have to finish the transition by 14th February to drop libgtk1.2 this decade.
[09:22] <nenolod> well, xmms 1.2.11 is out, but i don't think the debian maintainer of it cares
[09:22] <persia> nenolod: xmms was demoted to universe for gutsy.  We may be able to remove for hardy, depending on usage counts, plugin support, etc. for other players.
[09:22] <nenolod> persia, audacious supports all of the plugins XMMS does now
[09:22] <Fujitsu> Only 315 rdepends, yay...
[09:22] <nenolod> except for binary-only crap ones
[09:22] <nenolod> like in_mp3pro
[09:22] <persia> nenolod: Yep, and it's currently targeted as a replacement.
[09:23] <nenolod> persia, noes :(
[09:23] <persia> Fujitsu: for libgtk-1.2?
[09:23] <persia> nenolod: noes?
[09:23] <nenolod> persia, please don't do it like lameeyes @ genpoo did it
[09:23] <Fujitsu> persia: Yes.
[09:23] <persia> \o/
[09:23] <nenolod> i got death threats from irate genpoo users
[09:23] <nenolod> that wasn't cool!
[09:24] <persia> nenolod: I'm not sure what that means, but if you've a good package in Debian, and we're syncing, you'll control how it behaves.
[09:24] <nenolod> persia, i mean on audacious being targeted as replacement to xmms
[09:24] <nenolod> persia, the way Flameeyes @gentoo did it was he masked XMMS and put as the message "Use audacious instead"
[09:25] <imbrandon> jesus, i just deactived the membership to teams i'm not active in ( i can always re-join later ) but i'm still in 28 teams !?!!
[09:25] <persia> nenolod: Well, we have to support xmms users somehow.  A number of the meta-packages that used to recommend xmms now recommend audacious.  I suspect the rest will do the same.  I don't know if there will be a replacement package (but I doubt it).
[09:25] <persia> imbrandon: teams can be in teams too :)
[09:25] <imbrandon> yea
[09:26] <nenolod> persia, well, the way gentoo people did it implied it was "100% exactly like XMMS"
[09:26] <imbrandon> most of the 28 are merberships via other ways, like UUC via core etc
[09:26] <Fujitsu> imbrandon: You only left 4 that I can see.
[09:26] <persia> nenolod: Well, that's clearly not true.  Lying is not preferred.
[09:26] <nenolod> persia, :D
[09:26] <imbrandon> yea , 4 i dont do anything in
[09:26] <imbrandon> heh
[09:27] <imbrandon> the others i actively use
[09:27] <nenolod> persia, well i have faith that ubuntu's process is far superior to genpoo's way of doing things
[09:27] <nenolod> ;)
[09:27] <persia> nenolod: Maybe.  Maybe it's also that you are here?
[09:27] <nenolod> yeah that too =)
[09:28] <imbrandon> ok time todo some LP SRU hunting, what was that one someone was itching about earlier
[09:28] <nenolod> ubuntu really is the best option for a debian-ish desktop
[09:29] <imbrandon> win 3
[09:29] <imbrandon> err
[09:29] <RAOF> ENOSLASH
[09:29] <nenolod> persia, generally, debian has handled transitions very eloquently, so i expect the same in ubuntu
[09:29] <persia> imbrandon: You might take a look through https://bugs.launchpad.net/~ubuntu-main-sponsors/ I only see a couple SRUs, but they are easy hits.
[09:29] <nenolod> and i've been using debian since potato/m68k =)
[09:30] <imbrandon> mmm m68k
[09:30] <nenolod> amiga 3000+ ;)
[09:30] <imbrandon> i got one of those in the corner ( iirc its a 68k one )
[09:30] <nenolod> yeah
[09:30] <nenolod> they all are
[09:30] <nenolod> unless you get a cyberstorm card for them
[09:30] <imbrandon> no the old apple i have
[09:31] <imbrandon> i dont have any amegas
[09:31] <nenolod> oh. :P
[09:31] <imbrandon> amigas*
[09:33] <nenolod> i've been using debian for like a really long time. geeze :P
[09:36] <TheMuso> jdong: I was told by other MOTUs that while syncing from multimedia is possible, its actually a lot of manual work for the admins, so they would rather that we don't sync from other repositories than official Debian.
[09:37] <persia> TheMuso: As it turns out, it's a merge anyway: jdong will be pushing a debdiff back into the queue.
[09:38] <TheMuso> persia: Ok thanks.
[09:39] <nenolod> i'm working on a notification-daemon replacement which is OSD like (kinda like Growl)
[09:39] <nenolod> it's neat :P
[09:39] <nenolod> maybe after hardy i will draft a spec to replace notification-daemon with it
[09:39] <nenolod> :D
[09:40] <persia> nenolod: I'd recommend getting it in to the distro first :)
[09:41] <nenolod> persia, yes. i need to finish it first before i do that
[09:41] <nenolod> persia, it uses atheme.org's libaosd framework which also needs completing too
[09:54] <imbrandon> ok anthing with priorty:required dosent need a dap, but what about stuff in ubuntu-minimal ? ( e.g. bash )
[09:54] <imbrandon> s/dap/dep
[09:56] <crimsun> (bash is Pri:required.)
[09:56] <imbrandon> ok so Depends: ${shlibs:Depends}, bash is wrong, correct ?
[09:57] <crimsun> correct.
[09:57] <crimsun> s/bash//
[09:57] <imbrandon> k
[09:57] <crimsun> I went through this for the oprofile SRU waaay back when.
[09:57] <imbrandon> yea looks like unzip hardy/gutsy SRU thought they needed it too
[09:59] <nenolod> what is an SRU?
[09:59] <imbrandon> unzip bug #135086 ( working on it now )
[09:59] <ubotu> Launchpad bug 135086 in unzip "zipgrep: exit code always 0" [Unknown,Confirmed] https://launchpad.net/bugs/135086
[09:59] <crimsun> https://wiki.ubuntu.com/StableReleaseUpdates
[10:00] <nenolod> ah. thanks. i knew what they were, but i didn't know what SRU stood for
[10:00] <nenolod> ;)
[10:00] <imbrandon> ohhh AN sru, sorry read that as what sru
[10:00] <nenolod> Audacious 1.4 should be SRU'd. Audacious 1.3 sucks. :P :P :P
[10:01]  * nenolod hides
[10:01] <DarkMageZ> nenolod, any regressions? :P
[10:02] <nenolod> DarkMageZ, yeah, 1.3 was a disaster
[10:02] <nenolod> ;p
[10:02] <DarkMageZ> oh, so you've removed all my favorite "features" :P
[10:03] <nenolod> well, 1.3 added a lot of stuff
[10:03] <nenolod> but also a lot of bugs :P
[10:05] <DarkMageZ> nenolod, wouldn't it be easier to utilize libvisual for visualizations than to manually maintain each plugin?
[10:06] <nenolod> DarkMageZ, no
[10:06] <nenolod> DarkMageZ, libvisual sucks
[10:06] <nenolod> DarkMageZ, it's dead anyway
[10:06] <nenolod> i doubt there will be a libvisual 0.6
[10:07] <DarkMageZ> i'm trying to secretly find a way to resurrect it
[10:07] <DarkMageZ> but no-one is taking the bait :(
[10:07] <nenolod> i might add a libvisual proxy plugin in the future
[10:08] <nenolod> but it seems unlikely
[10:08] <StevenK> nenolod: If libvisual is dead, is there anything replacing it?
[10:10] <effie_jayx> morning all
[10:10] <persia> DarkMageZ: You could adopt it...
[10:11] <DarkMageZ> i can't code... not well enough to resurrect it.
[10:11] <nenolod> DarkMageZ, well, the reason why libvisual died is because synap like got into some coke or something and decided he was going to write an entire toolkit
[10:11] <nenolod> and everyone who was interested in libvisual went "lol fuck that"
[10:12] <nenolod> StevenK, i don't know of any replacement
[10:13] <StevenK> nenolod: Fair enough, I was just curious
[10:16] <DarkMageZ> last libvisual cvs code change was 13 months ago :( the main developer has now got a full time job and is out of time.
[10:16] <nenolod> DarkMageZ, and nobody cares about his vision for building a full vis toolkit
[10:18] <DarkMageZ> i don't have any particular love for libvisual. it's the concept of the entire project which was good tho. a centralised visualization library. so any media player would only have to know how to call it rather than implement every single visualization themselfs.
[10:19] <JDahl> jdong, thanks for the advice;  unfortunately the list of broken dependencies kept growing to the point of backporting all of Xorg, so I gave up and started focusing on rescuing X
[10:25] <persia> Sorry I'm late about that :(
[10:26] <nenolod> :D
[10:32]  * persia wishes to lash Kmos, but finds no target
[10:33] <Fujitsu> persia: What hath he violated now?
[10:34] <persia> Fujitsu: Just lots of sync requests, without investigation of the changes, or at least insufficient explanantion for me to consider them valid syncs.
[10:34] <Fujitsu> Ah, business as usual.
[10:34] <Fujitsu> Speaking of the devil.
[10:35] <persia> Kmos: Please test to make sure that the Debian packages have all the Ubuntu fixes applied, and that you are examining the latest Debian package before requesting a sync.
[10:35] <Fujitsu> Or people will strangle you. Moreso than usual.
[10:38] <DarkMageZ> nenolod, hey. xmms isn't dead. they just released a new version :P
[10:41] <persia> DarkMageZ: Does the new version include a port to GTK+2.9 ?
[10:42] <persia> s/9/0
[10:42] <Kmos> persia: i was testing.. why? something wrong ?
[10:42] <DarkMageZ> persia, na :P
[10:43] <persia> Kmos: Well, for ccid, I very much doubt you tested with an SCR335 reader, as a sync would have dropped support, and for cynthiune.app, you requested a sync for a version that FTBFS on Ubuntu.  I haven't looked at the others yet.
[10:44] <nenolod> DarkMageZ, XMMS 1.2.11 is the final release of XMMS.
[10:44] <nenolod> DarkMageZ, there will not be any more releases of XMMS.
[10:44] <Kmos> cynthiune.app FTBFS on ubuntu? so why it build in my pbuilder ? (maybe because i've i386 only) ?
[10:44] <Fujitsu> Ooh, it has finally died?
[10:44] <nenolod> 1.2.11 was intended to be "the final version"
[10:44] <Kmos> persia: the ccid has the support for the SCR335 reader, check debian diff.gz
[10:44] <nenolod> they have been talking about that point for several years now
[10:44] <nenolod> ;p
[10:44] <Kmos> and debian/control
[10:44] <persia> Kmos: No, currently it doesn't FTBFS anywhere.  The specific Debian version for which you requested a sync (which is no longer current) FTBFS in hardy.
[10:44] <nenolod> or, to quote Peter Alm directly:
[10:45] <nenolod>  Pinchiukas (n=doucheba@212.122.90.186) has joined #xmms
 so xmms is still being developed?
 no
[10:45] <persia> Kmos: I couldn't find any reference to
[10:45] <Kmos> persia: i'll provide it
[10:45] <persia> 04e5/5115 in the source (and I looked).
[10:46] <persia> Err.  04e6/5115
[10:46] <nenolod> Fujitsu, DarkMageZ, so basically 1.2.11 fixes some of the open issues in 1.2.10
[10:46] <Kmos> persia: +  - SCM Micro SCR 335
[10:47] <Kmos> persia: at .dif.gz - http://ftp.debian.org/debian/pool/main/c/ccid/ccid_1.3.1-1.diff.gz
[10:47] <Kmos> .diff.gz
[10:47] <nenolod> and that's all
[10:47] <nenolod> ;p
[10:47] <persia> Kmos: I don't see 04e6 in that diff.gz
[10:47] <Kmos> nenolod: they're working in xmms2 i think..
[10:48] <nenolod> Kmos, correct.
[10:48] <Kmos> persia: it's applied upstream the support for the reader.
[10:48] <nenolod> Kmos, when i say "XMMS is dead", i mean XMMS1.
[10:48] <nenolod> Kmos, XMMS2 is a client-server thing
[10:48] <persia> Kmos: I can't find support for the 5115 device in the upstream udev rules file either.
[10:49] <Kmos> persia: i'll inspect it :)
[10:49] <Kmos> but the debian maintainer put SCM Micro SCR 335 in the debian/control
[10:49] <Kmos> :(
[10:50] <Fujitsu> Debian isn't perfect. When dropping Ubuntu changes, you should always check that they've done what they say.
[10:51] <persia> Kmos: Everyone makes mistakes, and they need to be checked.  If you check it carefully, I don't have to, which makes me happy, and then I'm more likely to have time to help you with other things.
[10:52] <Kmos> persia: i'm sorry.. i'll check again if debian made a mistake and report it at BTS.. never happened to be, but there is a first time for everything
[10:53] <Kmos> about the cynthiune.app , it builds fine here at my pbuilder. don't know why it FTBFS
[10:53] <persia> Kmos: 0.9.5-5 builds fine for you?
[10:53] <Kmos> i've 0.9.5-6
[10:54] <Kmos> http://packages.qa.debian.org/c/cynthiune.app.html
[10:54] <persia> Kmos: Right.  So the title & description for bug #163344 should probably be different (and I'll fix it)
[10:54] <ubotu> Launchpad bug 163344 in cynthiune.app "Please sync cynthiune.app 0.9.5-5  (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/163344
[10:55] <Kmos> requestsync don't put the latest one
[10:55] <Kmos> :(
[10:55] <Kmos> persia: check if it put -6 in the description
[10:55] <persia> Kmos: That's another case where you should check things...
[10:55] <Kmos> yeah
[10:57] <effie_jayx> hey ... motu hopeful here... Quick Q does it take too long after Install pbuilder and do pbuilder create
[10:57] <effie_jayx> ?
[10:57]  * effie_jayx is currently praticing with building a package and is using pbuilder for the first time
[10:57] <jpatrick> effie_jayx: https://wiki.kubuntu.org/PbuilderHowto - should help you
[10:58] <effie_jayx> jpatrick,  I am there... my quick question was... does it take long? is it normal for it to take long?
[10:58] <geser> effie_jayx: depends on your internet connection to download the debs
[10:59] <effie_jayx> geser, ok I see. it's downloading now
[11:01] <frenchy> ping: quail
[11:01] <effie_jayx> thanks
[11:01] <effie_jayx> it's creating the base tar
[11:02] <frenchy> ping: jpatrick
[11:02] <Kmos> persia: http://pastebin.com/d518bc452
[11:03] <persia> Kmos: Right, so maybe there's something odd happening to qa.debian.org ?
[11:03] <jpatrick> hi frenchy
[11:03] <frenchy> jpatrick, Hi, I'm the developer of Me TV (me-tv).
[11:03] <Fujitsu> I know that madison.cgi was doing odd things 24 hours ago.
[11:03] <jpatrick> frenchy: ok.
[11:03] <frenchy> jpatrick, a day late.
[11:04] <quail> frenchy: pong
[11:04] <Kmos> persia: yep.. reported to elmo :)
[11:04] <frenchy> jpatrick, just wanted to confirm that I've got the versioning thing right now.
[11:04] <persia> Kmos: That's not always the best person to bother...
[11:05] <frenchy> jpatrick, I've sought some help but they couldn't explain a lot of "why" questions?
[11:05] <Kmos> persia: he's the best i know about server things :)
[11:05] <frenchy> jpatrick, thanks for reviewing the package BTW.
[11:05] <persia> Kmos: Sure, but he's busy.  Checking to see if it is generally known, and maybe filing a bug is better.
[11:06] <Kmos> persia: yeah
[11:06] <Kmos> i'll do it
[11:06] <jpatrick> frenchy: me-tv isn't in Debian or Ubuntu it's version in changelog should be 0.4.4-0ubuntu1
[11:06] <Kmos> Fujitsu: or you want to do it ?
[11:06] <persia> Kmos: Thanks, and please try to make sure I don't feel the need to complain at you again :)
[11:06] <Fujitsu> Kmos: I believe it to be a known issue.
[11:07] <frenchy> jpatrick, sweet ... I've got "me-tv (0.4.4-0ubuntu1) gutsy; urgency=low"
[11:07] <jpatrick> frenchy: README.Debian can be removed as "if none, delete this file"
[11:07] <jpatrick> frenchy: should be "hardy"
[11:07] <frenchy> jpatrick, Oh everything else I understand,
[11:07] <frenchy> jpatrick, just the versioning.
[11:07] <Kmos> persia: i hope not :)
[11:07] <Fujitsu> Ah, looks like ftp-master might not be backing up to merkel any more (note the warning when running rmadison).
[11:07] <frenchy> jpatrick, Ooops hardy
[11:08] <jpatrick> frenchy: and since the other versions aren't in either, this should be a "* Initial release" in changelog
[11:08] <frenchy> jpatrick, got ... excellent ... now here's the question.  Why is the version 0ubntu1 when it's not native?
[11:09] <frenchy> *ubuntu
[11:09] <jpatrick> frenchy: because this isn't a native package
[11:09] <frenchy> jpatrick, I thought that non natives did not have 0ubuntu1. Are you telling me that they do?
[11:10] <jpatrick> frenchy: I think natives are only for Ubuntu programs only
[11:12] <persia> Does anyone know much about translations mangling for universe?  I'm not sure what to do about bug #163394, and would appreciate any suggestions
[11:12] <ubotu> Launchpad bug 163394 in gbrainy "[hardy] Please rebuild gbrainy from source" [Low,Confirmed] https://launchpad.net/bugs/163394
[11:12] <frenchy> jpatrick, oh absolutely ... I've received some conflicting advice when it comes to this.  So you are telling me that non-native packages have a version XubuntuY?
[11:12] <jpatrick> frenchy: yes
[11:13] <quail> frenchy: pschulz01 is working on the PPC package for Me TV but he first got tobackup and upgrade to gutsy
[11:13] <frenchy> jpatrick, purging previous data.
[11:13] <Kmos> !info gbrainy hardy
[11:13] <ubotu> gbrainy: a brain teaser game and trainer to have fun and to keep your brain trained. In component universe, is optional. Version 0.3-1 (hardy), package size 153 kB, installed size 692 kB
[11:13]  * Fujitsu checks build logs to see what pkgstriptranslations is doing.
[11:13] <Kmos> it has the latest one
[11:14] <Fujitsu> Right, so pkgstriptranslations ripped the translations out, and then sent them conveniently to /dev/null.
[11:14] <Fujitsu> Not much we can do about that, other than convincing people to give us our damn langpacks.
[11:15] <frenchy> quail, Ta.
[11:15] <persia> Right.  So sending it back won't do any good.
[11:15] <Fujitsu> Right.
[11:15] <Fujitsu> It was ogred to universe, so it wasn't due to accidentally being in main.
[11:16] <persia> Hmm.  I'd like to encourage Catalan speakers to also exercise their brains, but I'm not sure how to accomplish that.
[11:16] <frenchy> jpatrick: Do you have a DVB card?
[11:16] <jpatrick> nop
[11:16] <Fujitsu> persia: Ask people nicely when they're going to develop the infrastructure to give universe translations, I guess.
[11:17] <persia> Fujitsu: Is there any way to block pkgstriptranslations for universe in the meantime?  I'm sure this affects lots more packages.
[11:18] <Fujitsu> persia: One would think it would make sense to only run it if a package is in main or restricted, but that is apparently not how it works.
[11:18] <persia> Hmm..  That sounds like a reasonable request.  Now to see if there is already a Soyuz bug...
[11:19] <frenchy> jpatrick: One last question, does that now mean I have to update the debian/changelog version as well as my AC_INIT() version in configure.ac every time.  Is there a fail-safe for this.
[11:19] <frenchy> ?
[11:19] <persia> Fujitsu: Do you think this is just another case of bug #136399, or is it sufficiently different to deserve it's own?
[11:19] <ubotu> Launchpad bug 136399 in soyuz "PPA builders performing normal Ubuntu binary mangling" [High,Confirmed] https://launchpad.net/bugs/136399
[11:20] <frenchy> Is it the job of the reviewers to test the application, or simply the packaging?
[11:20] <jpatrick> frenchy: no idea
[11:20] <Fujitsu> persia: I'd recommend another bug.
[11:20] <jpatrick> frenchy: both
[11:20] <frenchy> jpatrick: Ta.
[11:22] <frenchy> jpatrick: roger that, I might try and find a MOTU with a DVB card also because I imagine that a reviewer like yourself isn't likely to approve it if you don't know if it works.
[11:22] <frenchy> jpatrick: Does that sound right?
[11:23] <jpatrick> frenchy: I mostly focus on KDE packages
[11:23] <persia> frenchy: It's still worth pushing through REVU a few times until you get the packaging perfect: the last steps will just take a little longer.
[11:24] <Fujitsu> persia: Erk, sorry, I had to move irssi onto my laptop earlier, and X is still being nasty.
[11:24] <frenchy> persia: Thanks for your comments also.  Totally agree, need to get the packaging right first.
[11:24] <persia> Fujitsu: No worries.  I didn't have anything to say to you whilst you were gone :P
[11:25] <persia> frenchy: Today's the best day for that: it's REVU day, so if you can fix things quickly, and ask in-channel, you're likely to get quick reviews.
[11:27] <frenchy> persia: Thanks for that. Uploading latest source now.
[11:30] <frenchy> persia, jpatrick: I thank all of you kindly for your assistance and request that, at your earliest convenience, you please review Me TV.  How's that?
[11:30] <frenchy> ;-)
[11:30] <jpatrick> frenchy: I will :)
[11:31] <persia> frenchy: In my opinion, the ideal advertisement includes 1) the REVU url for the package, 2) the package name, 3) the status (needs first advocate, needs second advocate), and 4) a note saying you've just uploaded a new version.
[11:31] <persia> frenchy: But for now, that was good.  Next time :)
[11:32] <frenchy> persia: yanking those lines for next time.
[11:36] <pkern> Oh REVU day again?
[11:36] <pkern> Quite often recently ;)
[11:38] <persia> pkern: Every Monday.
[11:39] <pochu> persia: today's Sunday ;)
[11:39] <pochu> Oh, at least in my TZ :)
[11:39]  * pochu shuts up
[11:39] <persia> pochu: Right.  TZ skew.  It's Monday in some parts of the pacific islands, but not much more at this point.  NZ is real soon now.
[11:40] <pkern> So a REVU day lasts how long...? ;)
[11:40] <persia> pkern: 49 hours
[11:40]  * pkern giggles.
[11:40] <pochu> So no REVU day for me yet :)
[11:40] <Fujitsu> pkern: Oh dear, quite a few FTBFS bugs coming in...
[11:40] <pochu> (nope that I'd do anything anyway...)
[11:41] <dfiloni> pochu: can you review http://revu.ubuntuwire.com/details.py?package=wxwidgets2.8 ?
[11:42] <persia> dfiloni: I'd strongly recommend advertising generally: you'll likely get a better response than for just one person.
[11:42] <dfiloni> I did it but I didn't receive any reply
[11:43] <nand`> hiya! I'd like a review of the ike package please : http://revu.ubuntuwire.com/details.py?package=ike
[11:43] <minghua> persia: It's wxwidgets, I don't think many people are qualified to review that...
[11:43] <pochu> dfiloni: specially since I was going to give up with wx when you appeared ;)
[11:44] <pochu> minghua: and surely I'm not ;)
[11:44] <nand`> (it should be almost done!)
[11:44] <pkern> Fujitsu: Sorry ):
[11:44] <persia> minghua: Well, pochu and I may be more experienced with it, but anyone can take a look to see if it's relatively sane.
[11:45] <Fujitsu> pkern: /me fixes a couple.
[11:45] <pkern> Fujitsu: Thanks (=
[11:45] <Fujitsu> pkern: No, thankyou.
[11:46] <frenchy> Any MOTUs with a DVB card?
[11:46] <pkern> I think some are strange.  Especially those with failing test cases...
[11:46] <pkern> frenchy: Me, but I'm not at home. ):
[11:46] <persia> nand`: Did you resolve the upstream licensing issue?
[11:46] <frenchy> pkern: Have you tried Me TV?
[11:47] <nand`> persia: Yes, it's done, he updated all his files with licences.
[11:47] <persia> nand`: Excellent.
[11:48] <pkern> frenchy: No.
[11:48] <nand`> persia: he did a private new release for that, and he is waiting for the package to be accepted to make it public.
[11:48] <persia> nand`: In that case, we'll have to get it uploaded today :)
[11:49] <nand`> persia: héhé :)
[11:49] <frenchy> pkern: I'd appreciate your feedback whenever you get the chance.  It's not as complete as kaffeine or klear but it's the best way to watch digital TV under GTK.  IMHO.
[11:50] <pkern> frenchy: What's the package name?
[11:50] <frenchy> me-tv
[11:51] <pkern> A gtk application would be nice, but it's neither in Ubuntu nor in Debian.  On REVU I suppose?
[11:51] <pkern> I might try it tomorrow.  Does it use gstreamer to access the DVB stream?
[11:52] <dfiloni> persia: can you review wxwidgets2.8?
[11:52] <quail> pkern: it uses xine
[11:52] <frenchy> pkern: Yeah http://revu.tauware.de/details.py?package=me-tv
[11:52] <persia> dfiloni: Certainly, but I've a bit of a queue right now.  I still encourage you to ask the channel, rather than specific people.  If nobody else gets to it first, I'll have a look.
[11:52] <frenchy> quail: Thanks dale.
[11:53] <pkern> Hm... kaffeine used xine, too, IIRC.
[11:53] <quail> :-), I just got back
[11:53] <dfiloni> thanks persia
[11:56] <frenchy> pkern: I've actually written a GStreamer engine but it's not as good as libxine.  I found libxine's handling of streams to much more robust as well as GStreamer use to have some issues with FIFOs and and MPEG2 TS.  Those may be fixed now.
[11:57] <minghua> dfiloni: I'm looking at wxwidgets2.8.  Did you use the previous Ubuntu package as a basis, or did you start your packaging from scratch?
[11:57] <pkern> I recall that it needed a special demuxer... if the xine backend is stable, fine.
[11:57] <dfiloni> I use the previous package
[11:57] <persia> pkern: Are you filtering out the known FTBFSs, or publishing all of them?
[11:58] <dfiloni> minghua: I used previous package.
[11:58] <pkern> persia: Mainly pushing all of them.  Feel free to close as duplicate.
[11:58] <pkern> I filter out arch-specific stuff and broken deps, though.
[11:58] <frenchy> pkern: That's correct, I see you've also spent many hours reading.  I tried that demuxer and it never worked ... but I think that was because I was pushing it through a FIFO.
[11:59] <persia> pkern: I'm not sure of duplicates, but we're tracking a number at http://qa.ubuntuwire.com/ftbfs/, and I'm just worried about leftovers.
[11:59] <persia> pkern: On the other hand, don't stop, as it's good to have these tested.
[12:00] <persia> (although pre-DIF is early: the library transitions haven't been processed yet)
[12:00] <pkern> persia: I'm just filing them as new/unknown, not confirmed/medium.
[12:00] <minghua> persia: Is it normal for wxwidgets .orig.tar.gz to have a debian/ directory?
[12:00] <pkern> persia: I am currently testing my environment looking for rebuildd to improve in the meantime.
[12:01] <persia> minghua: Unfortunately.  The packaging is a bit odd.
[12:01] <pkern> I already saw things to be improved, like using quinn-diff with p-a-s.
[12:01] <minghua> persia: That's why I said not many people are qualified to review it...
[12:02]  * Fujitsu grumbles at a lot of builds failing due to bug #160439
[12:02] <ubotu> Launchpad bug 160439 in soyuz "Some builds fail when they should depwait" [Undecided,Triaged] https://launchpad.net/bugs/160439
[12:02] <persia> pkern: That's what I thought.  If you can get your engine working, we're in great shape for real rebuild tests later.  I'm just a little worried about perceived bug volume growth before we've everything in place: I don't want to see any complaints about mass bug filing.
[12:02] <minghua> persia: I am looking at the interdiff, and completely confused.
[12:02]  * pkern giggles at wxwidgets remembering all the discussions on @d-d
[12:02] <pkern> *#d-d
[12:02] <persia> minghua: Ah.  Right.  I forgot just how confusing it was.  Sorry :)
[12:02] <persia> pkern: Both actually, mail & IRC :)
[12:03] <pkern> persia: I would need more build slaves still.  I am not in the position like Lucas on this.
[12:03] <pkern> But rebuildd needs build slave support first.
[12:03] <persia> pkern: If you can get the code perfect, we can ask for resources.  If we had resources, and not a daemon, we aren't in as strong a position :)
[12:04] <pkern> Aye.
[12:04]  * persia requests someone else to look at the merges and SRUs in the U-U-S queue
[12:06] <Fujitsu> persia: I see three merges and no syncs. Is that wrong?
[12:06] <rexbron> persia: Thanks for the review. I am in discussion with the upstream dev regarding having an open dialouge pop up when no organ file is loaded
[12:06] <persia> Fujitsu: I just finished going through the queue?
[12:06] <Fujitsu> persia: Oh, so you mean in the future, not right now.
[12:07] <persia> Fujitsu: Essentially I forget -v or -sa so often on merges, I don't like to sponsor them.
[12:07] <Fujitsu> Ah.
[12:07]  * rexbron now looks for the second ack
[12:07] <minghua> dfiloni: Looking at the 2.8.4.0-0ubuntu3 version, it seems the upstream debian/ dir is moved to debian-upstream/ in the repacked upstream tarball (.orig.tar.gz).  You package put that change into .diff.gz, which is very confusing.
[12:08] <minghua> persia: ^^^ I hope I didn't say anything wrong.
[12:08] <persia> rexbron: Great.  The blank interface is a little odd.
[12:08] <rexbron> persia: The design methodology of genpo is a little odd. It is a gui app that the dev intends to be called from the commandline...
[12:08] <persia> minghua: No, but I haven't looked yet.  If it's that confusing, it sounds like the repack was dropped, which isn't ideal.
[12:09] <rexbron> ergo, the command line switches
[12:09] <persia> rexbron: Your ,desktop file makes it a lot easier.  I actually find a lot of audio apps are close to the command line, but a fully GUI environment shouldn't be that far away.
[12:09] <dfiloni> minghua: I didn't move debian directory in .orig.tar.gz
[12:10] <minghua> dfiloni: Yes.  I am saying that you should move it.
[12:10] <rexbron> persia: Hopefully people will read the manpage if they need to use the commandline options
[12:10] <persia> rexbron: Right.  That's why it's there :)  Now it just needs an icon...
[12:11] <rexbron> persia: Ya, I am going to hop into -artwork
[12:12] <dfiloni> minghua: I've used get-orig-source, do you think I sould move the directory in that target?
[12:12] <minghua> dfiloni: Hmm, then the get-orig-source needs to be fixed.  Let me look.
[12:13]  * effie_jayx is done with the two hours... update package recipe.... CHECKED... :D 
[12:13] <rexbron> persia: re: openlibs and the recursive chrpath rule, I need to learn bash scripting first :P
[12:14] <minghua> dfiloni: I don't see a get-orig-source target in debian/rules?
[12:14] <persia> rexbron: Not bash scripting, make-fu.  http://www.gnu.org/software/make/manual/make.html
[12:16] <rexbron> Hey everyone! Genpo has one ack and is looking for a second: http://revu.tauware.de/details.py?package=genpo
[12:16] <persia> rexbron: The distinction is important because 1) debian/rules is not a shell script, 2) the buildds use dash for /bin/sh, and 3) it's easier to read.
[12:16] <rexbron> lol
[12:17] <dfiloni> minghua: get-orig-source target is at the end of debian/rules file
[12:17] <StevenK> persia: Not only do the buildds use it, it is used as /bin/sh by default.
[12:18] <StevenK> Heh. I didn't think what I said was that bad.
[12:18] <persia> StevenK: True, but I've seen lots of bashisms appear to work for local builds.
[12:18] <StevenK> persia: Changing the /bin/sh symlink is easy.
[12:19] <persia> StevenK: No, it's just that I'm used to vi mappings, and my client maps ^] to "leave channel".
[12:19] <StevenK> Blink.
[12:19] <StevenK> Which client is that?
[12:19] <Kmos> persia: u're right, ccid source doesn't have support for SCM SCR 335 ... :-( Now.. i've mailed debian maintainer about that situation, because he mentions in the control description about support for it.
[12:19] <pkern> Yay, mail backlog of a night cleared.
[12:19] <minghua> dfiloni: I see.  So you wrote that one yourself, but apparently it's not good enough.
[12:19]  * StevenK uses esc-n to switch channels
[12:19] <persia> StevenK: Yes it is, but I still think that because it's not changed on the buildds is especially relevant for packagers (pidgin)
[12:20] <StevenK> persia: Agreed
[12:20] <persia> Kmos: Thanks for tracking that down.  Perhaps you'd like to prepare a merge candidate, and retitle the bug?
[12:21] <Kmos> persia: yeah.. but not now, thanks
[12:21] <dfiloni> minghua: why?
[12:22] <minghua> dfiloni: One minor comment:  Please keep 80 column-width in debian/changelog.
[12:22] <Fujitsu> DktrKranz: Can you possibly convince your FTBFS checker to exclude removed packages?
[12:22] <dfiloni> minghua: ok
[12:22] <DktrKranz> Fujitsu, I was thinking about it yesterday... I caught a couple of them...
[12:22] <persia> DktrKranz: Fujitsu: It might also be worth rehoming it now that the access issues are resolved.
[12:23] <minghua> dfiloni: As I said, the previous package, 2.8.4.0-0ubuntu3, doesn't have a debian/ dir in the .orig.tar.gz.  Yours have.  This makes reviewing much more difficult.
[12:23] <Fujitsu> persia: That's a good point.
[12:24] <minghua> dfiloni: And if you are going to move debian/ to debian-upstream/, I feel it's better to do it in .orig.tar.gz, not in .diff.gz.
[12:24] <dfiloni> minghua: ok, I'm editing get-orig-source target to move debian directory to debian-upstream
[12:26] <persia> dfiloni: More generally, the secret recipe for making an orig.tar.gz for wxwidgets is a bit tricky.  You might want to play with interdiff a few times to see how small you can make the differences between your diff.gz and the diff.gz from the repositories.
[12:26] <Fujitsu> DktrKranz: If you can set it up in your /, I'll repoint the qa.ubuntuwire.com link shortly.
[12:26] <persia> s/\/~/?
[12:26] <Fujitsu> s@/@~/
[12:26] <Fujitsu> Ergh, I suck.
[12:26] <persia> Right.
[12:26] <DktrKranz> Fujitsu, sure. How did you schedule its cron execution?
[12:27] <DktrKranz> s/\//~/
[12:27] <DktrKranz> that's the correct one :)
[12:28] <Fujitsu> DktrKranz: I whipped up a little script to pipe the output of the script to a temporary file, then move that file over the old one, then added a line to my crontab to run it at an arbitrary time daily.
[12:29] <minghua> dfiloni: Previous package changed include/wx/graphics.h, src/gtk/{button,settings,window}.cpp, wxPython/src/wx.pth, and wxPython/wx/build/build_options.py.  What happened to those patches?
[12:29] <DktrKranz> It could be worth to test temp file size before moving it to index.html, since my script does not handle automagically LP timeouts
[12:29] <DktrKranz> and if they happens, page is blank
[12:29] <Fujitsu> DktrKranz: Ah, good point.
[12:31] <minghua> So many people touched wxwidgets before...
[12:31] <minghua> persia: Does wxwidgets packaging have a VCS repo?  (It really should...)
[12:32] <pkern> It has.
[12:32] <pkern> But that one is probably too old for you? :-P
[12:32] <persia> minghua: No.  2.4 and 2.6 are made with special secret ingredients.  2.8 is the result of expediency.
[12:32] <persia> pkern: Which?
[12:32] <pkern> http://git.debian.org/?p=freewx/wx.git;a=summary I'd guess
[12:33] <pkern> No 2.8 in there ;)
[12:33] <persia> Excellent!  That wasn't there when I last was looking at WX closely (early spring).
[12:34] <Fujitsu> persia: That's rather relative, and could be interpreted incorrectly by 6 months.
[12:34] <pkern> persia: Maybe you want to talk with ron on #d-d... ;)
[12:34]  * minghua sighs.
[12:35] <pkern> Fujitsu, persia: I'll step back from #u-motu.  If there are concerns or questions about the rebuild just pm me, I'll stay on Freenode.
[12:35] <persia> pkern: Not right now: I've checked with him before, but my WX interest is mostly about killing 2.4
[12:35] <minghua> ... and thinks about the "not morally acceptable" of the dictionary explanation of "expediency".
[12:35] <persia> Fujitsu: Good point.  Thanks.
[12:38] <persia> minghua: I think you have a different dictionary than I.  I was thinking mostly about the fastest way to accomplish a goal.
[12:38] <dfiloni> how can I move debian directory to debian-upstream directory without unpacking .tar file?
[12:39] <Fujitsu> I see the... erm... Hardy theme mockups from some random user who edited the wiki page have made Digg as being semi-official.
[12:39] <persia> dfiloni: You can't.  You need to unpack, move things around, and repack.  If you do this in get-orig-source, the next person has a recipe for when they do it.
[12:40] <minghua> persia: I was looking at http://dictionary.cambridge.org/define.asp?key=27036&dict=CALD.  But yes, m-w.com seems to give a rather different explanation.
[12:41] <persia> minghua: Ah.  Interesting.  While I agree that in the interests of expediency, one may ignore moral constraints, I hadn't thought of it being a primary association.
[12:41] <persia> "The fastest way", rather than "The right way" or "The good way".
[12:44]  * Fujitsu heads to bed.
[12:44] <pochu> night Fujitsu
[12:45] <Fujitsu> Night pochu.
[12:45] <minghua> dfiloni: Is there any particular reason that you are changing whitespace in the .PHONY part of debian/rules?
[12:45] <minghua> Good night Fujitsu.
[12:45] <Fujitsu> Night minghua.
[12:45]  * Fujitsu stabs Kmos' quit message.
[12:45] <dfiloni> minghua: no
[12:46] <minghua> dfiloni: Can you fix that too?  Besides the repacking upstream tarball issue and the dropped patches issue, the package looks good to me.
[12:46] <minghua> dfiloni: If those patches should be dropped, you want to mention it in debian/changelog.
[12:47] <dfiloni> minghua: ok, I'm fixing that
[12:48] <minghua> dfiloni: You probably should consult the previous uploaders about what is the best way to repack the tarball and to write the get-orig-source rule.
[12:48] <persia> nand`: ike looks fine, and suitable for multiverse.  If you want universe, you'll have to repack.  Let me know if you want an advocate for multiverse.
[12:48] <DktrKranz> persia, regarding bug 162843, do you mind if I mentor and sponsor it once a debdiff will be provided?
[12:48] <ubotu> Launchpad bug 162843 in docbook2odf "Package dependency missing : perlmagick" [Medium,Confirmed] https://launchpad.net/bugs/162843
[12:48] <persia> minghua: Thanks for reviewing that.
[12:49] <persia> DktrKranz: Not at all: it's a trivial fix: just change the changelog entry, and the debdiff is perfect.  Thanks for watching it.
[12:49]  * DktrKranz likes SRUs
[12:49] <dfiloni> minghua: could I fix whitespace in .PHONY part?
[12:50] <minghua> dfiloni: Of course you can... But is that what you mean?
[12:50] <persia> DktrKranz: We were talking earlier about reviving motu-swat, to focus on SRUs and security issues.  If you're not a member, you might want to try to join.
[12:51] <minghua> persia: Sure... I use it too, and help REVU when I can.
[12:51] <persia> DktrKranz: There's also 4 SRUs in the sponsors queue if you like.
[12:51] <DktrKranz> persia, I am happy to help with SRUs.
[12:51] <nand`> nand`: Thanks for the review. But i'm confused concerning the repos... Why can't it go to universe in its current form?
[12:51] <dfiloni> minghua: I did it to see \s at the same coloum
[12:51] <persia> nand`: Because RFCs cannot be modified, so aren't DFSG-free (although they are free enough for multiverse).
[12:52] <DktrKranz> persia, indeed. I need to ping pitti to be sure about versioning for cases where feisty version == gutsy version
[12:52] <nand`> persia: DFSG?
[12:52] <persia> Right.  That's for next week then.
[12:53] <DktrKranz> Yes, I don't want to bother him on Sunday
[12:53] <persia> nand`: Debian Free Software Guidelines (http://www.debian.org/social_contract#guidelines)
[12:53] <persia> nand`: Specifically point 3
[12:55] <minghua> dfiloni: Then maybe breaking the last line is better than changing all other lines?
[12:55] <nand`> persia: Ok I see. But the RFCs are not distributed with the binary packages : is their presence in the source package the problem?
[12:55] <minghua> dfiloni: Also, note all changes in debian/changelog.
[12:56] <persia> nand`: It's generally frowned upon, as the source packages are also distributed.  You could ask an archive-admin for an official position, but I've previously seen package splits for this.
[12:56] <persia> nand`: More critically, it's not ideal to have it not reflected in debian/copyright, as this is intended to be a reference source when looking to extract source from packages.
[12:57] <nand`> persia: Lots of trouble for some RFC files upstream puts here for documentation...
[12:58] <persia> nand`: Yep.  It's annoying: personally, I like having a local mirror of all the RFCs, but it's also important to provide a standard reference location of copyright information when distributing a collection.
[13:00] <nand`> persia: It's the package going to multiverse that annoys me... So unless the RFCs files are removed, it can't go to universe, right?
[13:01] <persia> nand`: That's my understanding, but I'm not an archive-admin, so I may not be correct.
[13:02] <nand`> persia: I guess i will poke upstream again and see
[13:03] <persia> nand`: Actually, I think upstream is being nice by distributing the RFCs, and they ought do so: I would recommend a repack, as it's a local distribution-specific policy issue.
[13:03]  * nand` hides at upstream rumbling at debian packaging
[13:04] <nand`> persia: Ok, but what do you mean by repacking? Adding the reference on the copyright file?
[13:05] <persia> nand`: Create get-orig-source rule in debian/rules that unpacks the source, deletes all the RFCs, and repacks to make the orig.tar.gz
[13:05] <nand`> persia: hmm! Didn't know this trick!
[13:05] <nand`> persia: I'll take care of that, thanks again once more for the infos!
[13:06] <rexbron> persia: I have found a guy who is going to make an icon for genpo
[13:06] <persia> nand`: No worries.  Thanks for the packaging work.
[13:06] <persia> rexbron: Excellent!
[13:07]  * rexbron would prefer it to be as an update to a package though :)
[13:10] <persia> rexbron: No reason for it not to be: it's not a blocking issue.
[13:11] <rexbron> persia: Also re: openlibs ChangeLog, the upstream svn file is empty :/
[13:12] <persia> rexbron: That's fine.  It'd be nice, but it's not the only problem.  If you can fix the rest, you can get away with not having a Changelog.
[13:29] <james_w> If a package is maintained by ubuntu-desktop, and I believe it should be synced, do I contact them to do it?
[13:30] <DktrKranz> james_w, you could ask in #ubuntu-desktop for sponsorship
[13:31] <persia> james_w: You could, or you could file a bug requesting a sync, which should notify the team, and they'll review for possible forwarding to the appropriate groups.
[13:32] <james_w> ok, thanks. I think I'll check with them first, as this is my first sync.
[13:40] <rexbron> persia: sistpoty reviewed genpo and suggested merging genpo-organs into the main package if it will not grow to more than a few megs. What are your thoughts?
[13:40] <rexbron> persia: I see why he suggests it
[13:40] <persia> rexbron: It's a size thing.  If it will be small, I'd agree, as it will compress more.
[13:40] <rexbron> ok, that is not a problem
[14:03] <dfiloni> minghua: done
[14:03] <persia> dfiloni: You've uploaded a new rev?
[14:03] <dfiloni> yes
[14:04] <dfiloni> persia: http://revu.ubuntuwire.com/details.py?package=wxwidgets2.8
[14:05] <persia> dfiloni: OK.  I'd one more open slot in my REVU queue for this evening, and you've just filled it.  I'll likely be about 20 minutes before I get to it.
[14:06] <dfiloni> persia: thanks
[14:33] <rexbron> persia: I think I have addressed sistpoty's comments
[14:34] <persia> rexbron: And there is a new upload?  I don't know that I'll be up long enough to look tonight, but if I've time, I will.
[14:34] <rexbron> persia: Yes, there is a new upload. Thanks :)
[14:47] <persia> rexbron: I had a bit whilst waiting for a build, and I notice that your get-orig-source isn't working.  Did something change?
[14:47] <rexbron> Hmm
[14:47] <rexbron> I will take another look
[14:51] <minghua> dfiloni: Thanks for the work.  I don't think I have time for a second review, but I see that persia will do that.
[14:51] <persia> minghua: In progress
[14:51] <minghua> dfiloni: And persia knows better about wxwidgets than I do anyway.
[14:51] <rexbron> persia: I think I need to use the --force-download option
[14:52] <persia> dfiloni: Looks like you've done a great volume of work here: thanks.  There's a bit more: I'm drafting a comment.
[14:52] <persia> rexbron: Maybe: I tried that, and it didn't seem to be enough.  I'm not sure why: I ran as `debian/rules get-orig-source` after deleting the orig.tar.gz
[14:53] <rexbron> persia: looking into it
[14:55] <rexbron> persia: I also realized that the get-orig-source rule does not remove the .pcs file
[14:55] <persia> rexbron: Interesting.  Perhaps something changed whilst you were fighting with it before, maybe with the new upstream.
[15:02] <persia> dfiloni: http://revu.tauware.de/details.py?upid=694 updated with a comment, if you don't mind one more try.  The package could be uploaded in the current state, but if you've already done so much you might want to try to hit the rest :)
[15:07] <dfiloni> persia: get-orig-source doesn't work?
[15:07] <persia> dfiloni: No, it doesn't have anything to download the source.
[15:07] <persia> dfiloni: You'll want wget or uscan or somthing.
[15:08] <dfiloni> persia: do you think i could include wget... ?
[15:08] <dfiloni> ok
[15:08] <persia> dfiloni: Sure.  That works.
[15:09] <persia> dfiloni: Unfortunately, it's hit my time limit tonight.  If it's not uploaded the next time I look, I'll take another look.
[15:09] <persia> dfiloni: And thank you very, very, very much for working so hard to clean up the package.  It almost looks normal :)
[15:10] <dfiloni> persia: It's an hard work but I do it with pleasure
[15:20] <Ubulette> hi, i'm looking for a sponsor for a merge. anyone ?
[15:23] <minghua> Ubulette: It would help if you give the bug number.
[15:23] <Ubulette> bug 163271
[15:23] <ubotu> Launchpad bug 163271 in xulrunner "Please merge xulrunner 1.8.1.9-1 (universe) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/163271
[15:43] <minghua> Hmm, xulrunner.
[15:45] <warp10> I am going to tackle my first merges, and I don't understand why do we have two tools for the same job, MaM and DaD
[15:45] <warp10> Is there any special reason why I should use just one of them?
[15:45] <Nafallo> MoM and DaD might spawn of a CHiLD in the future if we're lucky ;-)
[15:46] <pochu> Nafallo: ROFL
[15:46] <Lutin> :)
[15:47] <pochu> warp10: dad has comment support, whereas mom is the 'official' one.
[15:48] <warp10> pochu: so when I work on a merge maybe I should use both of them?
[15:49] <Nafallo> GAAH
[15:49] <pochu> warp10: no need. if you are going to leave a comment use dad. otherwise use the one you like more :)
[15:49] <pochu> but the have the same functionality, so no need to use both ;)
[15:49] <Nafallo> don't keep your foot close to the powerbutton of the PDU and then try to drop your food/test your reflexes.
[15:50] <pochu> lol
[15:50] <Nafallo> things go dark...
[15:51] <warp10> pochu: ok, thanks. But I will like very much a CHiLD :)
[15:52] <Nafallo> I want a button the backport stuff in CHiLD ;-)
[15:52] <Nafallo> s/he/o/
[15:52] <minghua> Is ChiLD going to be both official and have comment, or neither?
[15:52] <minghua> :-P
[15:53] <Lutin> that's what sort of got discussed a while back
[15:53] <Nafallo> minghua: probably depends on if DaD ack that he's the father :-P
[15:53] <Ubulette> minghua: what about xulrunner ? ;)
[15:54] <minghua> Ubulette: Not something I am capable to review.
[15:55] <Nafallo> or rather if MoM acks to be the mother.
[15:56] <Ubulette> minghua, yep, it's a big beast
[15:57] <geser> Ubulette: have you asked asac to review the xulrunner merge?
[15:57] <Nafallo> I bet both MoM, DaD and CHiLD would love PiZZA
[15:58] <geser> ordered with an iPHONE?
[15:58] <Nafallo> hehe. why not :-)
[15:59] <Ubulette> geser, yes sure but for once, i wanted to follow the process
[15:59] <Nafallo> the development team behind PiZZA has to be named OWeN
[16:00] <Ubulette> geser, i'm familiar with the package, i did the xulrunner-1.9 in gutsy/hardy
[16:00]  * Nafallo goes back to hiding and eating pizza now :-)
[17:37]  * jdong starts triaging feisty-backports
[17:54] <soothsayer> Is there some place I can get Ubuntu packages for Mplayer subversion trunk?
[17:55] <jdong> not that I'm aware of; we don't build packages against mplayer svn
[17:55] <jdong> but our packaging can probably be spliced on top of a trunk checkout and would work
[17:56] <soothsayer> https://code.launchpad.net/~vcs-imports/mplayer/trunk
[17:56] <soothsayer> What does that hold?
[17:57] <jdong> soothsayer: that looks like a bzr mirror of the mplayer svn repository
[17:58] <soothsayer> jdong: Okay thanks. That's what I suspected.
[18:10] <jeromeg> jdong: hy, are you the John Dong of ubuntu-backporters ?
[18:11] <jdong> jeromeg: yes I am :)
[18:11] <jeromeg> jdong: good :)
[18:12] <jeromeg> jdong: i'm one of the ones bugging you with backports requests :)
[18:12] <jdong> ah yes, name looked familiar :)
[18:13] <jeromeg> jdong: is bug #128896 doable ?
[18:13] <ubotu> Launchpad bug 128896 in rhythmbox "Please backport rhythmbox 0.11.1 to Feisty" [Undecided,Invalid] https://launchpad.net/bugs/128896
[18:13] <jeromeg> and second question :)
[18:14] <jeromeg> is it possible to join ubuntu-backporters ? If yes, what are the conditions ?
[18:14] <jdong> jeromeg: if I recall correctly that rhythmbox backport requires libgpod dependency to be bumped down
[18:15] <jdong> and to join backporters, the main requirement is you have to be MOTU first
[18:15] <jeromeg> jdong: I'm running a backported version of rhythmbox without any other backports
[18:15] <jeromeg> jdong: ok :)
[18:15] <jdong> jeromeg: it does not build without that dependency change, right?
[18:15] <jeromeg> jdong: of course it does
[18:16] <jdong> lemme try it now
[18:16] <jeromeg> or I wouldn't be bugging you, I know how difficult it is to get a source backport
[18:16] <jdong> DIST=feisty prevu lp:rhythmbox/gutsy
[18:16] <jdong> grr
[18:16] <jeromeg> ?
[18:16] <jdong> wrong terminal
[18:16] <jeromeg> I'm not used to prevu
[18:16] <jeromeg> ah ok
[18:16] <jdong> I'm gonna give it a build test and see where that goes
[18:17] <jeromeg> In my feisty pbuilder it builds fine
[18:17] <jdong> prevu rocks for the lazy :)
[18:17] <jeromeg> jdong :)
[18:17] <jpatrick> jdong: could I join? I have some KDE packages which didn't make it info Gutsy
[18:17] <jdong> jpatrick: you just need some packages done, or you want to commit yourself to backports triaging too? :)
[18:18] <jpatrick> both :)
[18:18] <jdong> sure, apply to the team :)
[18:18] <jdong> always great to have more hands on the project
[18:19] <jpatrick> jdong: but do we dput to gutsy-backports or is it something else?
[18:19]  * jeromeg will a motu one day
[18:19] <andy_js> lol
[18:19] <jdong> jpatrick: no, archive managers mangle the sources for us. Set status to In Progress and subscribe ubuntu-archive on backports ready to go into the archive
[18:20] <jpatrick> jdong: ok
[18:20] <andy_js> I'd like to submit a package, how do I do that?
[18:21] <jeromeg> andy_js: for backports ?
[18:21] <jdong> jpatrick: on your first few approvals you should probably mention that you are a new member so archive managers don't automatically ignore you ;-)
[18:21] <jpatrick> hehe
[18:21] <andy_js> jeromeg: well, its a app I'm working on.
[18:22] <andy_js> so I'm not sure
[18:22] <jeromeg> andy_js: so it's a new package ?
[18:22] <jdong> jpatrick: currently my criteria for approval for non-libraries is simply that it builds and installs in a pbuilder login environment without dpkg errors
[18:22] <jdong> jpatrick: Use status Confirmed for stuff that builds in pbuilder but you have reason to suspect regressions and want further testing
[18:22] <jpatrick> jdong: yes, I built all my packages in a gutsy pbuilder without issues
[18:23] <andy_js> jeromeg:  well, its never been in ubuntu before, so yes
[18:23] <jeromeg> andy_js: so you should put it on revu
[18:23]  * jpatrick knotes everything
[18:24] <andy_js> how do I do that?
[18:24] <jpatrick> !packaging > andy_js
[18:24] <jeromeg> andy_js: i'm searching the howto on the wkiki
[18:24] <andy_js> !packaging
[18:24] <ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - See https://wiki.ubuntu.com/MOTU/Packages/New for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources - See also !backports
[18:24] <jeromeg> andy_js: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages?action=show&redirect=MOTU%2FPackages%2FNew
[18:24] <jeromeg> everything should be here
[18:25] <jdong> jpatrick: approved
[18:26] <jpatrick> jdong: thank you
[18:26] <jdong> jeromeg: looks like the build will go through. I have no idea why I had the impression it wouldn't
[18:26] <jeromeg> jdong: you were right but 4 monthes ago
[18:26] <jdong> jeromeg: ah, that's probably why :D
[18:26] <jeromeg> jdong: in june it failed to build but now it's ok
[18:30] <jdong> Mez: you're gonna make fun of me again, so I'll say shut up first, but I accidently hit approve instead of decline on *another* backports join request :D
[18:30] <jdong> sorry to send that guy on a YAY! aww..... rollercoaster ride too
[18:31]  * Mez removes jdong's admin privileges for the group
[18:31] <Mez> :P
[18:31] <jdong> LOL
[18:31] <jdong> Mez: in my defense (1) The buttons should be labeled Cancel or Allow (2) Cancel should be red and Allow should be green.
[18:31] <jdong> :D
[18:31] <Mez> I see you approved jpatrick though
[18:31] <jdong> yeah, he was meant to be approved
[18:32] <Mez> yeah, no, I was just checking the email and thought you'd declined him and was gonna say that I thought he woulda made a good addition
[18:32] <jeromeg> jdong: so it builded ?
[18:32] <jeromeg> s/builded/built
[18:33]  * jeromeg hopes no one has seen it
[18:33] <jdong> jeromeg: it's building
[18:33] <jeromeg> ok
[18:33] <jeromeg> it's true it's a long build :)
[18:34] <jdong> core 2 duos are only so fast....
[18:34] <jdong> *awaits Santa to bring him a 45nm quad*
[18:34] <jeromeg> :)
[18:37] <jdong> jeromeg: build success
[18:37]  * jeromeg waves
[18:38] <jdong> jeromeg: approved
[18:38] <jeromeg> jdong: cool
[18:38] <jeromeg> getdeb -> -1
[18:38] <jeromeg> :)
[18:39] <jdong> :)
[18:42] <andy_js> if I build a package, can someone here review it for me?
[18:43] <jeromeg> jdong: i'll test a few builds for requested backports to help you
[18:43] <jdong> jeromeg: thanks
[18:43] <jeromeg> np
[18:44] <jdong> jeromeg: it seems like we have the biggest backlog in feisty
[18:44] <jdong> I just spent like 6 hours clearing Gutsy in the past two days :)
[18:44] <jeromeg> jdong: yep i've seen it, you are doing a good job
[18:45] <jdong> jeromeg: haha if someone would do my MIT homework I'd be glad to do backports all day :D
[18:45] <jeromeg> :)
[18:45] <jeromeg> i've my share of homework...
[18:45] <jdong> don't we all :)
[18:46] <jeromeg> yep
[18:53] <jeromeg> jdong : pingus builds fine (bug 144682)
[18:53] <ubotu> Launchpad bug 144682 in feisty-backports "Please backport pingus from Gutsy" [Undecided,New] https://launchpad.net/bugs/144682
[18:53] <jdong> jeromeg: thanks; since it's a *game* I'll go ahead and approve it based on that
[18:59] <jeromeg> jdong: bug 129555 seems quite risky
[18:59] <ubotu> Launchpad bug 129555 in feisty-backports "Please backport Mono 1.2.4" [Undecided,New] https://launchpad.net/bugs/129555
[18:59] <jeromeg> jdong: as it's a base for tomboy which is a default app
[19:00] <noolness> why not just fix tomboy to work on a newer version of mono?
[19:01] <noolness> unless the gnome project did something stupid like change all the c# bindings for gtk+
[19:07] <bddebian> Heya gang
[19:08] <jeromeg> jdong: bug 132871 is ok too
[19:08] <ubotu> Launchpad bug 132871 in feisty-backports "Please backport PiTiVi to Feisty from Gutsy" [Undecided,New] https://launchpad.net/bugs/132871
[19:19] <jdong> jeromeg: thanks, dealt with
[19:20] <jeromeg> jdong: i'm testing another few ones, I think you can close the pidgin one it's not possible without modifying the deps
[19:21] <jeromeg> however after modifying the deps it works great
[19:21] <jeromeg> but we have to backport every plugin
[19:21] <jeromeg> one by one
[19:22] <jdong> jeromeg: yeah, I honestly don't like doing the pidgin backport for those reasons, but then again so many people want pidgin I've left it open for the possibility someone would take that responsbility
[19:22] <jeromeg> jdong: ok...
[19:23] <jdong> :-/ I'm a bit undecided on how to proceed with that
[19:23] <jeromeg> maybe you could ask to the pidgin maintainer in Ubuntu ?
[19:23] <jdong> we could just say "Ok we'll backport pidgin core and whatever plugins we can, breakages are known and those installing the backport should be aware of that"
[19:24] <jdong> but I personally don't feel comfortable saying that
[19:24] <jdong> ideally this is the point that a PPA should step in
[19:24] <jdong> 14:23 < jdong> we could just say "Ok we'll backport pidgin core and whatever  plugins we can, breakages are known and those installing the  backport should be aware of that"
[19:24] <jdong> 14:24 < jdong> but I personally don't feel comfortable saying that
[19:24] <jdong> 14:24 < jdong> ideally this is the point that a PPA should step in
[19:24] <jdong> jeromeg: ^^
[19:25] <jeromeg> ok
[19:25] <jeromeg> a trendy topic :)
[19:25] <jdong> gutsy-insanely-idiotic-backports repo :)
[19:26] <jeromeg> :)
[19:27] <RainCT> hi
[19:27] <RainCT> what is hppa (architecture)?
[19:28] <jdong> RainCT: HP PA RISC?
[19:28] <jdong> http://en.wikipedia.org/wiki/HPPA
[19:28] <RainCT> dunno, I got a mail that hppa build of kmyfirewall 1.0-1ubuntu4 failed in hardy
[19:29] <bddebian> Everything fails on hppa and lpia ;-P
[19:29] <RainCT> i thought Ubuntu supports only i386 and amd64?
[19:29] <RainCT> ah, it's also a new one?
[19:29] <jdong> RainCT: I wouldn't care about it
[19:29] <jdong> RainCT: in other words, pretend it's PPC
[19:29] <jdong> *ducks*
[19:30] <bddebian> heh
[19:32]  * jdong takes on x264 :)
[19:33]  * TheMuso pops in, notices talk about PPC, and reminds everybody that he is happy to help test PPC build issues etc if people need help...
[19:33] <jeromeg> jdong: bug 127975 is ok
[19:33] <ubotu> Launchpad bug 127975 in feisty-backports "Please backport gthumb from gutsy" [Undecided,New] https://launchpad.net/bugs/127975
[19:34] <noolness> well do you need to backport things to a release that doesn't have the long term support anyways? i mean realistically does it matter?
[19:34] <jeromeg> jdong: for gcompris we should ask to the edubuntu folks as it's one of their defaults app
[19:34] <Ubulette> hmm, lintian is complaining about changelog-file-not-compressed changelog.Debian, indeed it's not. Am it supposed to do that myself ?? i just call dh_installchangelogs
[19:34] <jdong> noolness: if there are people who still care about a backport on a supported release, I want to help them out
[19:34] <jdong> TheMuso: ooh thanks for volunteering
[19:35] <TheMuso> jdong: I wouldn't if I didn't have a PPC. :)
[19:35] <noolness> yeah i guess it's nice for people that don't want to upgrade, i mean if it's not going to take time away from other more important things by back porting it
[19:35] <jdong> TheMuso: I'll almost certainly need some PPC build testing on this x264 merge I'm taking on... last time it took 3 shots and like 2 weeks of buildd turnaround to get x264 built in ppc
[19:35] <jdong> noolness: I treat the latest stable release with the highest priority anyway
[19:36] <jdong> noolness: so that's why feisty's lag is so great
[19:36] <jdong> *GASP* debian-multimedia.org is down!!1
[19:36] <TheMuso> jdong: Ok, would be happy to help. Just ping me with a package URL if you want something tested.
[19:36] <jdong> TheMuso: ok, thanks :)
[19:38] <jeromeg> jdong: for thunderbird it's a bit like piding, we would have to backport the plugins and the locale
[19:38] <jeromeg> shall I try it ?
[19:40] <jdong> jeromeg: meh don't bother doing things with a reverse chain
[19:41] <jeromeg> ok
[19:42] <jeromeg> jdong: enough for today :) or the ubuntu-archive tema won't be able to cope with my pace !
[19:42] <jdong> jeromeg: hehe :)
[19:42] <jeromeg> ciao all
[20:28] <jdong> https://bugs.edge.launchpad.net/ubuntu/+source/azureus/+bug/163644
[20:28] <ubotu> Launchpad bug 163644 in azureus "azureus : la page s'ouvre et se referme presque aussitot" [Undecided,New]
[20:28] <jdong> my french sucks
[20:28] <jdong> does that say "The window opens and immediately closes"?
[20:30] <soothsayer> jdong: Yes
[20:31] <jdong> merci beaucoup!
[20:43] <RainCT> Adri2000: hi. did the patch for DaD work?
[21:02] <jdong> Now I remember why I didn't like importing new x264
[21:03] <jdong> 5 minute merge job, 3 hours of following reverse-dep chain
[21:03] <Kmos> bug 163208
[21:03] <Kmos> can someone help to answer this guy ?
[21:04] <ubotu> Launchpad bug 163208 in exaile "Please remove debian directory from tarball" [Undecided,New] https://launchpad.net/bugs/163208
[21:15] <james_w> Kmos: which one?
[21:17] <Kmos> [21:04] <ubotu> Launchpad bug 163208 in exaile "Please remove debian directory from tarball" [Undecided,New]  10:<https://launchpad.net/bugs/163208>
[21:17] <ubotu> Launchpad bug 163208 in exaile "Please remove debian directory from tarball" [Undecided,New] https://launchpad.net/bugs/163208
[21:17] <ubotu> Launchpad bug 163208 in exaile "Please remove debian directory from tarball" [Undecided,New]
[21:17] <Kmos> this one
[21:17] <jdong> siretart: I've spent a good chunk of time today analyzing bug #138854 and feel sufficiently confident to recommend the debdiff attached into Hardy; It will not cause any breakages (soname/pkgname is changed properly by debian-multimedia) and my tests show that all but one package will transition with trivial rebuild
[21:17] <ubotu> Launchpad bug 138854 in mplayer "Merge x264 from debian-multimedia" [Undecided,Invalid] https://launchpad.net/bugs/138854
[21:18] <james_w> Kmos: yes, which of the three people commenting in that report would you like to answer?
[21:18] <jdong> lol @ how awful the bugdescription can be when affecting multiple locations
[21:19] <jdong> siretart: at any rate, I will pursue whatever is necessary to complete the transition once the new x264 is uploaded to Hardy.
[21:20] <siretart> jdong: did you already upload to ~motumedia ppa?
[21:21] <jdong> siretart: no, I have not, I've only locally tested with a hardy pbuilder. Would you like x264 and the dependent gpac merge in ~motumedia first?
[21:21] <Amaranth> haha, wow
[21:21] <Amaranth> I have no idea how to create a new branch in bzr
[21:22] <james_w> Amaranth: 'bzr branch oldbranch newbranchname'
[21:22] <jdong> bzr branch, physical directory copy, etc
[21:23] <Amaranth> right but i'm working from a bound branch
[21:23] <siretart> jdong: hm
[21:23] <Amaranth> i need to commit my changes then push the whole thing to launchpad as a new branch
[21:23] <Amaranth> if i just commit it'll push to the main branch
[21:23] <jdong> siretart: both are low-impact and should be good to go directly into Hardy IMO
[21:23] <james_w> Amaranth: bzr unbind; bzr commit; bzr push
[21:23] <siretart> jdong: at this stage of development, I'd be inclined to just throw the new x264 at hardy
[21:24] <jdong> siretart: agreed. Can you sponsor its dependent and linked gpac merge into Hardy too?
[21:24] <siretart> jdong: not today, but I'll put it on my todo list for tomorrow
[21:24] <jdong> okay, thank you :)
[21:25] <Kmos> james_w: to explain him why it's more easy to package without debian dir inside the tarball.
[21:25] <jdong> superm1: I see you've touched mplayer a lot; and that it's done in bzr; after siretart uploads x264 I'll need you to bump b-d ver on x264 for whenver the next upload will be :)
[21:25] <jdong> kthxbye *vanishes*
[21:25] <james_w> Kmos: sure, I can do that.
[21:25] <siretart> jdong: but if you have some spare time, I'd still suggest to throw the sources at the PPAs
[21:26] <Kmos> james_w: thanks
[21:26] <superm1> sure jdong
[21:26] <superm1> i'll subscribe to that x264 bug
[21:26] <jdong> siretart: ok, I'll look at how uploading to PPA's work :D
[21:26] <superm1> to watch when it happens
[21:26] <siretart> jdong: you've prepared the sources anyway, and you can test your versioned build-deps that way
[21:26] <jdong> superm1: thanks muchly
[21:26] <siretart> jdong: oh, that's quite easy. you need to be in launchpad beta testers team, and adjust your .dput.cf
[21:27] <jdong> ok, first is done, second is doing :)
[21:27]  * Amaranth cries watching bzr push
[21:28] <siretart> [ppa-motumedia]
[21:28] <siretart> fqdn = ppa.launchpad.net
[21:28] <siretart> incoming = ~motumedia/ubuntu
[21:28] <siretart> login = anonymous
[21:28] <jdong> siretart: thanks :)
[21:29] <Amaranth> i dunno if it's launchpad or bzr but i could write a new window manager before this finishes :P
[21:29] <jdong> siretart: would you like me to mangle the versions ~ppa1?
[21:30] <Amaranth> jdong: that's required :P
[21:30] <siretart> yes, just append ~ppa1 to the version, that way we can iteratively update the package until prime time
[21:30] <jdong> sounds good
[21:31] <jdong> siretart: do I have to change the distro in the changelog entry?
[21:31] <siretart> jdong: upload target must be 'hardy'
[21:31] <jdong> alright
[21:33] <zul> afternoon
[21:33] <jdong> oops *headdesk* need to -sa for full source
[21:36] <jdong> wow I'm a total klutz today
[21:37] <jdong> siretart: unrelated/partially-related question, do you have any idea what we are going to do about libmp4v2?
[21:38] <jdong> i.e. our version is over 2 years old, built from some snapshot of faad, and already posing an age problem with respect to packages like gtkpod-aac that's  only going to worsen with time
[21:38]  * ajmitch carefully considers the MOTU applications on the MC list
[21:40]  * ScottK ponders if he's going to regret a recent +1 on MOTU applications.
[21:40] <ScottK> No pressure or anything...
[21:42] <jdong> siretart: looks like libmp4v2's "supposed" to be built out of mpeg4ip (present in debian-multimedia, not in Ubuntu at all) rather than faad2... are you familiar with the packaging of libmp4v2 or is some here fluent? If not I guess I can give it the old upload to PPA then analyize reverse-dep chain...
[21:45] <zul> its like living with houdini?
[21:46] <jdong> err make faad2 *3* years old.
[21:46] <jdong> but freshly synced
[21:46]  * jdong finds who did it
[21:47] <siretart> jdong: I have no idea, maybe slomo has?
[21:47] <soothsayer> Does anyone know what Xshape for X11 is?
[21:47] <jdong> yeah, I see slomo recently synced faad2
[21:47] <jdong> Binary: faad, libfaad-dev, libfaad0, xmms-mp4, libfaad2-0
[21:48] <jdong> WHOO! it no longer builds mpeg4v2!
[21:48] <jdong> mp4v2*
[21:49] <soothsayer> Ah, never mind found it
[21:50] <jdong> siretart: since nothing builds libmp4v2 in Ubuntu anymore, do you think it'd be okay for me to start playing with importing mpeg4ip from debian-multimedia?
[21:51] <jdong> i.e. into the motumedia PPA?
[21:56] <jdong> meh looks like slomo probably got it handled considering he imported faad2 2 days ago. I'll poke him later about it
[22:54] <crimsun> in clearing my Debian lists queue, this link[0] should be mandatory reading for NEW source packages
[22:55] <crimsun> [0] http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
[22:56] <ScottK> That's linked somewhere in our wiki (or was at some point).
[22:56] <crimsun> I thought it was, but I don't have the URLs handy
[22:56] <ScottK> With all the reorganization I don't know where to find anything anymore.
[22:58] <apachelogger> siretart: please nuke http://revu.tauware.de/details.py?package=ksquirrel-libs it got renamed to libksquirrel, thanks :)
[22:59] <crimsun> ScottK: hmm.  I have an e-mail from norsetto RE: MOTU Precedures Change, and in it he flags https://wiki.ubuntu.com/MOTU/Meetings/2007-11-05/REVURequirements.  On that wiki page is a link to another recommended page.
[23:21] <Le-Chuck_ITA> Hi there, may I draw your attention to bug #132583?
[23:21] <ubotu> Launchpad bug 132583 in openoffice.org "python-uno can't be imported" [Low,Confirmed] https://launchpad.net/bugs/132583
[23:21] <Le-Chuck_ITA> it seems to have a one line fix
[23:22] <jdong> python-uno | 1:2.3.0-1ubuntu5.1 | gutsy-proposed | amd64, i386, powerpc
[23:22] <jdong> is that SRU not for the aformentioned bug?
[23:22] <jdong> and -> #ubuntu-devel, python-uno is in main
[23:24] <crimsun> no, it's not for that bug.
[23:24] <crimsun> the -proposed is for bug 153132
[23:24] <ubotu> Launchpad bug 153132 in openoffice.org "Openoffice splash screen includes Ubuntu logo" [Medium,Confirmed] https://launchpad.net/bugs/153132
[23:24] <jdong> oh
[23:32] <Le-Chuck_ITA> ok I go to ubuntu-devel then, thank you