[00:44]  * sistpoty gives up on abiword
[03:04] <ScottK> FYI, language packs are done, so we're accepting Universe packages again.
[06:06] <Whyu> Askum all
[09:21] <alkisg> Hi, I'm using python distutils and I want to produce two binary packages from the same source package. How can I do that in setup.py? Call setup() with different parameters depending on which package is being built?
[09:22] <POX> man dh_install
[09:23] <POX> (dh or cdbs will instal to debian/tmp, then just use debian/package.install files to select which file goes where)
[09:25] <alkisg> POX, I had the package made with debian/*.install files, but then I was told that I was supposed to move those to setup.py
[09:26] <alkisg> So I deleted the .install files
[09:27] <alkisg> How can I register python modules if I use debian/*.install files?
[09:28] <POX> will both binary packages contain Python modules?
[09:28] <alkisg> Yes
[09:29] <POX> I'd tell setup.py to install to package_a and then move few files to package_b in debian/rules
[09:30] <POX> there are many possibilities, just use the one which requeres less typing ;)
[09:30] <POX> (I doubt your setup.py hardcodes installation paths)
[09:30] <alkisg> I'm not sure I got what you mean. Are you proposing that I'd install package_b without using setup.py, i.e. manually registering the python modules?
[09:31] <alkisg> Can I have 2 different calls to setup() in setup.py, based on which package is being built?
[09:31] <POX> ./setup.py -root debian/package_a; mv debian/package_a/foo/bar debian/package_b/foo
[09:32] <POX> and debian/package_b/foo in debian/package_b.dirs
[09:32] <POX> s,debian/package_b/foo,foo actually
[09:33] <POX> (only in .dirs file)
[09:33] <alkisg> Ah. Thanks, I got what you mean, but I need to experiment on that as I've never done something like this before (my debian/rules is just %: dh $@).
[09:33] <POX> you can have two setup.py calls as well, just make sure they install different files
[09:34] <alkisg> That sounds a little easier to me. Thanks a lot! :)
[09:34] <POX> once you'll have it ready, join #debian-python
[09:35] <geser> don't forget to mention that the #debian-python channel is on OFTC
[09:35] <POX> right
[09:35] <alkisg> That will probably take years - it's not secure enough to be generaly released yet :)
[09:36] <alkisg> It's just for certain schools following a specific tutorial on how to setup ubuntu on their labs...
[09:36] <alkisg> I hope in 1-2 years it'll be mature enough to try to get it into the archives
[09:43] <alkisg> Hmmm setup.py is called for both packages by default, right? How can I find out which binary package it was called to build? I don't see anything useful on the environment: http://paste.ubuntu.com/421555/
[09:46] <POX> if you're upstream, then the easiest option would be to add something like --only-module-a and --only-module-b in setup.py and then use setup.py --root=debian/package_a --only-module-a and setup.py --root=debian/package_b --only-module-b
[09:46] <POX> how to invoke it? depends what you use (dh, cdbs, pure debhelper)
[09:47] <POX> +pure Makefile :)
[09:48] <alkisg> debhelper... let me look if it passes the name of the binary package as a command line argument to setup.py...
[09:49] <POX> in dh, you can do that in override_dh_auto_install:
[09:50] <alkisg> nah... it just calls ['setup.py', 'install', '--force', '--root=/home/alkisg/Documents/Linux/ppa/sch-scripts/debian/tmp', '--no-compile', '-O0', '--install-layout=deb']
[09:50] <POX> yup
[09:50] <POX> see above
[09:51] <alkisg> Got it, thanks
[09:52] <POX> it's a little bit more complicated if you're installing Python extensions (.so files)
[09:54] <alkisg> No it's just python/shell, no extensions
[10:58] <ari-tczew> I've requested bzr merge, but I need to update my branch. What I need to do if I want to got bzr merge with my next revision?
[12:19] <geser> just update your branch, the merge proposal gets updated and the sponsor usually merges your latest revision
[12:44] <benste> hi - how can I get reading access to a bug report whihch i'm not allowed to read ? https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/505857
[12:44] <benste> :-)
[12:44] <benste> what the hell s going on with this bug report ?
[12:45] <joaopinto> it's private ?
[12:46] <benste> don't know
[12:46] <benste> it's the successor of a bug reporting FF crashing with segfault on startup
[12:46] <benste> https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/505186
[12:46] <persia> Most crash bugs are private by default.
[12:47] <benste> + looks like ubottu is not working too :-9
[12:47] <persia> *especially* browser bugs often stay private for a while, as they may expose things that users consider private (e.g. cookies, authentication tokens, etc.)
[12:47] <benste> persia: and who does have access to private bugs - only package maintainers ?
[12:47] <persia> No, the bot just can't read the bug any more than you can.
[12:48] <persia> Only subscribers.
[12:48] <persia> For crash bugs, there's a team that gets automatically subscribed.
[12:48] <benste> sry - posted the wrong url - this one should be the old https://bugs.launchpad.net/ubuntu/+source/firefox-3.5/+bug/505186
[12:48] <hyperair> i remember managing to see private bugs for ubuntu
[12:48] <persia> I've just checked the bug in question, but there is a note asking it to stay private, so I shan't open or expose it.
[12:48] <benste> ah - as it is a duplicate it's linking to the new one right ?
[12:48] <benste> persia: thanks for checking
[12:49] <persia> benste: No useful information in the bug yet: just automatic data and waiting for analysis.
[12:49] <benste> k
[12:49] <benste> I'll try  sudo apt-get purge firefox && sudo apt-get install firefox
[12:49] <persia> benste: In future, I'll suggest that you might get faster information about bug management from #ubuntu-bugs, and you might want to check with #ubuntu-mozillateam about mozilla packages (like firefox).
[12:50] <benste> :-) thx - just remebered motu :-)
[12:50] <persia> benste: The private bug includes the text "Creating a new profile does not solve the issue."
[12:50] <benste> yip that's what I've tested to
[12:51] <benste> persia: if you'll have time to care a bout it you may want to participate to my discussion on #ubuntu
[12:51] <persia> Given that purge/reinstall doesn't even do that (as it doesn't change anything in your home directory), I very much doubt that will help at all, but you might want to check with someone who knows better (see references above)
[12:51] <benste> i#ll do
[12:51]  * persia doesn't really, sorry
[13:57] <porthose> Release Team: Are bug fix uploads for universe packages still being accepted?  I have a fix for bug #558697 (minor change to preinst and postinst) would it be ok to upload this fix?
[13:58] <persia> Yes.
[13:58]  * persia isn't on the release team, but knows the answer.
[13:58] <porthose> persia, thx :)
[13:58] <persia> porthose: I believe the criteria for bugfixes is rapidly approaching "stuff that would qualify for SRU".
[13:59] <persia> And if the change is potentially invasive, or may need more time to verify the fix is correct, the release team might say "Please publish as SRU".
[13:59] <persia> But *every* upload is being reviewed now, so be sure to get your bugs filed, and describe them clearly, etc.
[14:10]  * carstenh just realised that the name of the next enterprise editition will start with Q ;)
[14:12] <persia> Not necessarily.
[14:12] <persia> There was no "A" or "C", for example.  No promises other letters won't be skipped along the way.
[14:13] <persia> Also, prior to Breezy, the letters weren't used in order, so no promises that each name is in order.
[14:13] <persia> And lastly, the letter "H" has been used twice, so no promises other letters won't be used multiple times.
[14:15] <carstenh> well, the reason seems to be that nobody thought of alphabetically sorting the release names before dapper
[14:38] <ScottK> geser wins the FTBFS fixing award for the day.
[14:38] <ScottK> Thanks geser (all accepted)
[14:39] <ScottK> porthose: persia is correct.  Please get stuff uploaded.
[14:52] <porthose> ScottK, uploaded
[14:52] <ScottK> If it was ampache, I'm looking at it now.
[14:52] <porthose> yes
[14:57] <ScottK> porthose: Looking at the diff, the second hunk of change in the postinst and the postrm change look like they are white space only changes.  Is that right?
[14:58] <porthose> ScottK, yes
[14:58] <ScottK> OK.  As a rule, it's nice to avoid those as it complicates the reviewers work.
[15:00] <porthose> k
[15:02] <ScottK> porthose: accepted.
[15:02] <porthose> ScottK, thx
[15:08] <ScottK> If there are any emacs users around: Could you have a look at anjsp?  It currently fails to build, but that's easy enough to fix.  The question is does it work?  It's old enough that it uses the delightfully quaint debhelper compat of 3.  It wasn't in Debian and looks like one of those ancient packages grabbed from some random source in the early mists of Ubuntu's history.
[15:26] <geser> ScottK: syncs are still accepted? (sync a package from Debian unstable to build with the default postgresql)
[15:26] <ScottK> geser: Yes.
[15:28] <persia> Needs someone to actually process the syncs and removals though.  Maybe we'll get lucky Monday.
[15:28] <persia> (because Tuesday verges on too late)
[15:29] <ScottK> persia: We discussed it the last release team meeting and I have commitments for availability tomorrow and Monday.
[15:29] <ScottK> persia: Now the driver for stopping uploads is mirror sync and that only needs ~24 hours before release, so we can keep going longer.
[15:30] <ScottK> (security-in-soyuz was very helpful in this regard)
[15:32] <persia> Oh, that's an improvement on last time I was paying close attention as the release hardened.  Nice!
[15:32] <persia> (and it makes me feel a bit better about falling asleep before finishing the stuff I'm doing increasingly more slowly tonight)
[15:33] <geser> ScottK: a next batch of fixes for gtk related FTBFS will appear soon in the queue
[15:33] <ScottK> geser: Great.  Those are easy enough to review ....
[15:37] <Rhonda> hmm
[15:37] <Rhonda> persia: I have a fix for the "missing icon" wesnoth bug in my git.
[15:38] <ScottK> persia: Perhaps ^^^ could be combined with the -3 from Debian and uploaded as a merge.
[15:53] <Rhonda> ScottK: Yes, would make much sense, I fear I won't upload to Debian just because of that yet again.
[15:53] <Rhonda> 1.8.1 might come out soon and I want to give people a bit time to test it in Debian.
[15:53] <ScottK> Understand.
[15:53] <ScottK> If you can find a MOTU to upload it, I can review it for the release team.
[15:58] <Rhonda> persia said he wanted to give it a try. :)
[15:58] <Rhonda> … and someone else, IIRC.
[15:58] <Rhonda> Ah, slytherin also thought about giving -3 a try.
[15:59] <Rhonda> The changes in git for -4 can be reviewed just through the diff, I highly doubt that those require an extra build to test them. :)
[15:59] <ScottK> persia also said something about going to sleep, so perhaps he'll do it 'tomorrow'
[15:59] <Rhonda> That was two days ago, but that's not meant as a preassure or complaint statement, just trying to point out what I perceived.
[16:00] <ScottK> Understood.
[16:00] <ScottK> I didn't get to getting a set of package syncs together yesterday like I had hoped.  It's on my list again for today.
[16:01] <Rhonda> Am a bit short on time right now, am at the LinuxTage event over here in austria and rather should care for the booth. ;)
[16:01] <ScottK> Understand.
[16:01] <ScottK> I think there's more than enough in the backscroll now for persia when he wakes up.
[16:03] <Rhonda> e65b3e0a is the commit for the desktop file in wesnoth.git on git.debian.org
[16:03] <Rhonda> But I'm confident that persia will find that. :)
[16:30] <ScottK> If someone is looking for something productive to do, gnome-gmail-notifier is currently totally broken and there's a new upstream release that will fix that.
[16:33] <dutchie> ScottK: I'll have a punt at it
[16:33] <ScottK> OK
[16:34] <imbrandon> dutchie: lemme know if you get stuck on anything , i'll give ya a hand
[16:34] <imbrandon> moins all
[16:36] <imbrandon> ScottK: not gonna be in/arround KC next weekend are ya ? heheh j/k
[16:37] <ScottK> imbrandon: Nope.  I'll be flying over on Friday.  I'm in CA for work all next week.
[16:37] <imbrandon> ScottK: ahh cool
[16:37] <imbrandon> brb gotta go make sure my pot of caffeine is on
[16:40] <imbrandon> ScottK: but yea, was just getting a keysigning / release party thing going for the 30th, dident figure ya'd be in the area but ya never know ;)
[16:42] <ScottK> Sure.
[16:42] <ScottK> FYI, there are release team members available for reviews and no Universe packages waiting ....
[16:44] <imbrandon> cool give me about ~10 min to resetup pidgin ( reinstalled lucid on this laptop last night ) and i'll get some crackin
[16:58] <dutchie> is there a better solution to make debuild find the .orig.tar.bz2 file than bunzip2'ing it and just gzipping it again? the debuild man page doesn't seem that helpful
[16:58] <maco> dutchie: long way round is how i always do it
[16:59] <geser> dutchie: v1 or v3 source package?
[16:59] <dutchie> don't know
[17:00] <dutchie> it says version=3 in debian/watch
[17:00] <geser> does debian/source/format exist? if yes => v3, else v1
[17:00] <dutchie> v1 then
[17:00] <geser> and only v3 allows .orig.tar.bz2
[17:01] <ari-tczew> geser: does v2 exist?
[17:01] <ScottK> It does but it should not be used
[17:01] <ScottK> It we never really deployed
[17:01] <geser> only on paper, see "man dpkg-source"
[17:03] <POX> geser: what about "1.0" in debian/source/format? ;-P
[17:03] <ScottK> POX: I think it's dangerous and should be avoided
[17:04] <POX> what is dangerous?
[17:04] <geser> POX: you are right, I hope that's not common
[17:04]  * POX was reffering to "does debian/source/format exist? if yes => v3, else v1"
[17:04] <ScottK> POX: The mistaken belief that the absence of debian/source/format can mean anything other than it should be a v1 format.
[17:05] <POX> did I say something about that?
[17:05] <ScottK> POX: But your point about having to inspect the contents of the file to determine the version is correct.
[17:06] <ScottK> POX: No, I misread your initial comment.
[17:06] <POX> ok
[17:22] <ScottK> ajmitch: You are listed as a bug contact for krb5-auth-dialog.  I'm hoping that means you have some interest in the package.  The current one we have needs a newer heimdal that is in Lucid.  I was wondering if you could have a look at it and see what we need to do (I suspect revert to an earlier version of the package).
[17:28] <imbrandon> ScottK: we got a list of universe with patches i can lookat/test ?
[17:28] <ScottK> imbrandon: My recommendation would be work on http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[17:29] <imbrandon> k
[17:29] <ScottK> geser hit a large stack of the GTK deprecation issues already
[17:39] <dutchie> hmm
[17:40] <dutchie> checking the build-deps for gnome-gmail-notifier, the configure.ac has "GNOME_KEYRING_REQUIRED=0.4.2", which is nothing like the libgnome-keyring-dev package version
[17:48] <dutchie> what version should I put in the Build-Depends line?
[18:00] <imbrandon> dutchie: looks like an upstream bug/typo
[18:01] <imbrandon> err maybe not
[18:06] <dutchie> maybe not?
[18:06] <imbrandon> well it does look like a typo, but thats whats listed on the webpage too as a depends
[18:06] <imbrandon> sooooo
[18:07] <imbrandon> and the current control dosent mention the keyring ....
[18:07] <imbrandon> hum hum hum
[18:07] <imbrandon> ( but has the same requirement )
[18:07] <ScottK> YokoZar: I think a new wine1.2 upload that conflicts/replaces wine << 1.1.42-0ubuntu4 and a new upload of wine 1:1.0.1-0ubuntu12 would DTRT and leave current wine1.2 users with wine1.2, but allow the wine package to upload.  What do you think?
[18:08] <imbrandon> does one of the other build depends pull in keyring ?
[18:09] <imbrandon> ScottK: ewww epoch mess ?
[18:11] <dutchie> I just pulled out the dependency and got that intltool is too old
[18:11] <dutchie> configure: error: Your intltool is too old.  You need intltool 0.35.0 or later.
[18:14] <Laney> what's the problem?
[18:14] <Laney> it'll be a >= dependency
[18:14] <dutchie> there wasn't a dependency at all, that was the problem :)
[18:14] <imbrandon> dutchie: lemme grab the source and have a closer look, give me a few and i'll get back to ya
[18:14] <Laney> was it being pulled in by something else?
[18:14] <dutchie> didn't seem sot
[18:14] <dutchie> so*
[18:14] <Laney> must have been
[18:15] <dutchie> I've added an explicit dep now
[18:15] <Laney> Selecting previously deselected package libgnome-keyring-dev.
[18:15] <Laney> Unpacking libgnome-keyring-dev (from .../libgnome-keyring-dev_2.27.90-0ubuntu1_i386.deb) ...
[18:18] <dutchie> No package 'gnome-keyring-1' found
[18:18] <dutchie> but it's supper now, back in a bit
[18:21] <Laney> libgnome-keyring-dev installs /usr/lib/pkgconfig/gnome-keyring-1.pc
[18:24] <imbrandon> dutchie: i would send a patch upstream too that mentions the configure.ac keyring requirement should be like 2.30.0 ( or something close to that )
[18:24] <Laney> why?
[18:25] <imbrandon> because it is now 0.4.2 witch is very wrong
[18:25] <Laney> I don't see why that is wrong
[18:26] <imbrandon> gnome keyring hasent been at version 0.4.2 in YEARS well before gnome-gmail-notifier ever existied, if it was ever at 0.4.2 ( it corrosoponds with the gnome version does it not )
[18:27] <Laney> I don't see why you should second guess upstream's compatibility assessment without evidence that it's not right
[18:28] <Laney> (there was indeed a version 0.4.2 in the past)
[18:28] <imbrandon> Laney: because doing upstream developemt myself i know that things can easily slip through the cracks like this, and it seems very out of place, it wont hurt to send a note to them, i'm not saying i'm 100% right, i'm saying verify it
[18:29] <Laney> maybe you should try to build it against 0.4.2 and see what breaks
[18:30] <imbrandon> Laney: maybe i should , but an email is just as easy , why the hostility ?
[18:30] <Laney> I don't think I'm being hostile :(
[18:30] <Laney> but you seem to have decided that this is probably wrong when there is every chance that it's not
[18:30] <imbrandon> okies, i took the conversation wrong then, no worries, anyhow was just a sugestion
[18:31] <imbrandon> no i decided it warented a further look, nothing more
[18:31] <imbrandon> it *seemed* wrong ;)
[18:32] <imbrandon> but alas , lets get on with some real work, no need to drag this out more, we're both clear now ;)
[18:34] <dutchie> back
[18:35] <lfaraone> Right now GroundControl isn't working due to a change in the LP API. Upstream worked around this by embedding a WebKit frame to handle authentication in a way that won't break in the future. Upstream changelog is at http://sprunge.us/TFSS , would a FFe be sane at this point? (since we're looking at "package does not work at all")
[18:37] <imbrandon> lfaraone: can the change be cherry picked ?
[18:37] <lfaraone> imbrandon: maybe. let me see.
[18:38] <imbrandon> if its easy/sane to cherry pick it, i would say thats the way to go, but if not a FFe could be warented IMHO ( but i'm not in a position to make that call )
[18:40] <dutchie> I'm sure it said that libgnome-keyring-dev was uninstallable earlier
[18:41] <lfaraone> imbrandon: mk. if we don't currently use a patch system, can we patch the source directly?
[18:42] <ScottK> lfaraone: Since it's a new package, there's no risk of regression, so if upstream would prefer to go with the new release, I'm fine with that.
[18:43] <ScottK> lfaraone: So please file FFe and get doctormo to ask for it in the bug.
[18:43] <lfaraone> ScottK: awesome, thanks. (it was on my request that he put out 1.6 so we wouldn't have to pick from bzr)
[18:43] <lfaraone> ScottK: should I amend the existing "lp is broken by everything!" bug, or author a new one?
[18:44] <ScottK> lfaraone: Existing bug is fine.
[18:47] <imbrandon> ahh did not realize it was a new-to-lucid package
[18:48] <imbrandon> i'm 0-2 today it seems :)
[18:49] <dutchie> ooh, it's built
[18:53] <dutchie> seems to run too
[18:53] <dutchie> imbrandon: where should I upload it to?
[18:59] <imbrandon> the new version ? is there an open bug?
[19:00] <dutchie> not afaik
[19:00] <dutchie> all I know is what ScottK said
[19:01] <imbrandon> open a bug with all the FFe info if there is not one ( ScottK mentioned that it fixed current problems so there might be one open already ) then attach the debdif between whats in the repo now and yours
[19:01] <dutchie> righto
[19:01] <imbrandon> then give me the bug number and i'll check it / sponsor if neeeded
[19:02] <ScottK> imbrandon and dutchie: Actually for a new upstream we wan't the diff.gz in the bug.  The sponsor should fetch the tarball themselves
[19:02] <lfaraone> Is anybody familiar with update-notifier's syntax? I'm trying to use a command of "Command: nautilus --quit & nohup nautilus -n &" and it's not working.
[19:02] <imbrandon> ScottK: i was going to ;)
[19:02] <dutchie> bug 521185
[19:03] <dutchie> that look right?
[19:03] <imbrandon> that looks like a start, it will need to have the FFe stuff added
[19:07] <dutchie> should I do that?
[19:08] <lfaraone> dutchie: yes.
[19:08] <dutchie> ok
[19:11] <DktrKranz> imbrandon: did you get to upload apt-mirror then?
[19:19] <imbrandon> DktrKranz: no its still fubared in dak, i'm just going to do a few more fixes and release a new upstream version
[19:19] <imbrandon> that will fix most everything
[19:19] <imbrandon> the important fixes i uploaded to ubuntu as -0ubuntu1 so we'll be golden
[19:24] <DktrKranz> nice
[19:25] <DktrKranz> btw, old files are still in unchecked, I wonder what the heck happened
[19:25] <lfaraone> imbrandon: could you please upload the SRU detailed in bug 301190 ?
[19:25] <lfaraone> (if you have a chance)
[19:26] <imbrandon> lfaraone: sure, i'll look in just a moment
[19:26] <lfaraone> imbrandon: awesome, thanks.
[19:28] <imbrandon> wow its broken all the way back to intrepid ? heh
[19:28] <lfaraone> ScottK: by the way, are you a DD? If so, I'd greatly appreciate it if you could sponsor http://mentors.debian.net/debian/pool/main/g/groundcontrol/groundcontrol_1.6-1.dsc so I can sync it rather than introducing an Ubuntu delta.
[19:28] <lfaraone> imbrandon: unloved stepchild of debian-edu and Ubuntu's sugarteam :)
[19:28] <ScottK> lfaraone: I'm not
[19:29] <lfaraone> imbrandon:  I don't think it was in hardy, btw. So we've never shipped a working etoys, it looks like.
[19:29] <DktrKranz> lfaraone: if you need one, I am
[19:30] <lfaraone> DktrKranz: much appreciated, see the above dsc.
[19:30] <lfaraone> DktrKranz: (DMUA is set in that upload, feel free to unset it if you don't feel comfortable having it that way)
[19:32] <DktrKranz> lfaraone: I'll leave that out for the moment, thanks for the hint
[19:36] <DktrKranz> lfaraone: should I run debian/rules get-orig-source to fetch upstream tarball, or just uscan?
[19:39] <lfaraone> DktrKranz: uscan.
[19:40] <DktrKranz> oki
[19:47] <DktrKranz> lfaraone: uploading
[19:47] <lfaraone> DktrKranz: thanks.
[19:48] <DktrKranz> it will be accepted in ~13 minutes
[20:07] <imbrandon> ScottK: when uploading to proposed i dont have to include a orig.tar.gz correct ?
[20:08] <imbrandon> assuming same upstream ver etc
[20:08] <ScottK> imbrandon: That's correct.
[20:08] <imbrandon> k
[20:08] <ScottK> Other than using up more bandwidth, it doesn't actually hurt.
[20:09] <ScottK> Unlike in Debian, Soyuz won't reject for that
[20:09] <imbrandon> yea, its a huge orig.at.gz and i have to upload it ~3 times, so i would rather not if not needed
[20:09] <imbrandon> lol yea i figutred that out the hard way on DAK
[20:09] <imbrandon> figured*
[20:09]  * DktrKranz hides
[20:09] <imbrandon> hahahaha
[20:09] <imbrandon> :)
[20:10] <ScottK> BTW, if you get the gmail notifier thing sorted, go ahead and upload.  Don't wait for the FFe.
[20:10] <imbrandon> k
[20:10] <imbrandon> i'm just waiting on dutchie to tell me its redy to check it
[20:10] <imbrandon> ;)
[20:10]  * ScottK nods
[20:11] <ScottK> No pressure dutchie.
[20:11] <imbrandon> wow i cant type today ( well most dayss, but its bad today )
[20:11] <dutchie> wonderful
[20:11] <imbrandon> dutchie: :)
[20:11] <dutchie> I'm going to be honest and say that I don't really have much of a clue what I'm doing
[20:11] <dutchie> I've got https://wiki.ubuntu.com/FreezeExceptionProcess up
[20:11] <dutchie> do I need to open a new bug?
[20:12] <imbrandon> dutchie: no worries, just ask, umm basicly at this point you need to ....
[20:12] <imbrandon> open the bug you linked earlier
[20:12] <imbrandon> do a testbuild localy
[20:12] <imbrandon> then attach your diff.gz to the bug
[20:12] <imbrandon> then
[20:13] <imbrandon> *looking at what info is there or not, one sec*
[20:13]  * ScottK loves these verbose debian/changelog entries: "   * Redo packaging."
[20:14] <imbrandon> actualy i dont have the bug open anymore, just make sure that the bug has that info and i'll fill in the rest and let you know what i did for future ref
[20:14] <dutchie> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-gmail-notifier/+bug/521185
[20:14] <dutchie> so I'ev attached the diff.gz
[20:15] <imbrandon> k, that should be good enough for me to look at, if the bug is lacking more info i'll add it when i check the diff
[20:15] <imbrandon> i started this sru upload so give me about ~10 min to re-open it
[20:16] <dutchie> ok
[20:26] <imbrandon> lfaraone: sru uploaded
[20:26] <imbrandon> make sure to watch the bugs for it etc
[20:26] <lfaraone> imbrandon: of course. thanks.
[20:29] <ajmitch> ScottK: I'll take a look at krb5-auth-dialog again, I'd noticed that it was wanting a newer heimdal
[20:29] <ScottK> ajmitch: Thank you.
[20:31] <ajmitch> iirc it was dragged in with the autosync back in february
[20:31] <ScottK> Sounds right.
[20:33] <ajmitch> it may be possible to keep the current version & build against MIT krb5, I'll upload it in a few hours if that's the case
[20:33]  * ajmitch has to head out for a bit this morning 
[20:59] <imbrandon> fsck !!
[20:59] <imbrandon> ScottK: can you reject that gnome-gmail-notifier upload please
[21:02] <ajmitch> imbrandon: you did an oops?
[21:02] <dutchie> anything to do with me?
[21:03]  * ajmitch heads out, will upload later
[21:04] <imbrandon> dutchie: no i included the wrong orig with the upload
[21:05] <imbrandon> ajmitch: yes :(
[21:06] <imbrandon> ScottK: if you would lemme know when thats rejected and i'll re-upload the correct way
[21:11] <ScottK> imbrandon: Done
[21:14] <imbrandon> ScottK: ty
[21:16] <imbrandon> ScottK / dutchie : ok correct files uploaded
[21:16]  * imbrandon lunches
[21:22] <lfaraone> ScottK: FFe requested for bug 527978.
[21:24] <ScottK> lfaraone: Please put the usual FFe stuff in there including the testing you've done with it.
[21:31] <lfaraone> ScottK: never mind, looks like upstream has come across a moderately-important bug with login. (not blocker, from what I can tell)
[21:31] <ScottK> lfaraone: OK.  Once you're ready update the bug and upload.  No need to wait for the FFe to upload.
[21:32] <lfaraone> ScottK: well, I'm not a MOTU, or I would :)
[21:33] <ScottK> OK.
[21:33] <ScottK> upload/get it uploaded
[22:19] <Quartz> hello
[22:20] <Quartz> lucas: can you make a patch in order to have rubyripper functional has it should be (like on ubuntu 9.04 and 9.10)
[22:22] <Quartz> When it compare the wav extraction from a same track, it hangs; normalyy it should need only one second. Sometimes it takes 10minutes.
[22:22] <Quartz> Imagine when a CD has 30 tracks :(
[22:23] <Quartz> http://rubyripper.googlecode.com/files/rubyripper-0.5.7.tar.bz2
[23:50] <YokoZar> ScottK: the other option is what we have in my PPA.