[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.


[18:08] <olly_> morning
[18:14] <ibeardslee> morning
[20:34] <mwhudson> morning
[21:12] <chilts> morning
[22:31] <hads> morning


[23:32] <alkisg> The new sch-scripts version (a classroom management tool like iTalc) now works for non-LTSP labs too, if anyone wants to try it, ping me. :)


[19:10] <ibeardslee> morning
[19:10] <ajmitch_> morning
[19:43] <thumper> morning
[19:50] <Atamira> morning
[19:52] <mwhudson> morning


[10:16] <_nbk_> hello,
[10:17] <_nbk_> i need help to enlist the 1st node. It does not show up in the List on the controller in the Browser.
[10:17] <_nbk_> On the node screen an error message is running: "bmc-config:xxxx map pfn expected mapping type uncached-minus xxxx-xxx, got write-back"
[10:21] <rbasak> Sounds like that could be a problem related to IPMI on that hardware. What hardware is it?
[10:31] <_nbk_> both boxes core i5, asus board P8H67-I
[10:32] <_nbk_> the node is booting fine from the maas-controller but after all these bmc- messages it also has a curl error about the ssl certificate
[10:47] <rbasak> What's the error exactly?
[10:58] <_nbk_> i could not read the error about curl and the ssl certificate so fast. i will reboot the node and try again. I have a bad netskin in my eyes :-(
[11:00] <_nbk_> syslog shows all errors about bmc-config but not the error about the ssl certificate
[11:03] <rbasak> Use a camera, perhaps?
[11:03] <rbasak> It might be worth installing one node manually and checking that freeipmi works correctly with the BMC on it.
[11:04] <_nbk_> i use my phone to take a picture.
[11:34] <_nbk_> curl: (60) SSL_Certificate problem, verify that the CA cert is OK. Details:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
[11:34] <_nbk_> More details here: http://curl.haxx.se/docs/sslcerts.html
[11:34] <_nbk_> i would like to use the -k (or --insecure) option on that screen because i have the self signed certificate.
[11:39] <_nbk_> so what can i do to get the 1st node enlisted?
[14:59] <roaksoax> jtv: ping
[14:59] <jtv> Hi roaksoax
[14:59] <roaksoax> jtv: howdy!! so I was wondering something
[15:00] <roaksoax> jtv: how to compare that {} is {} in a test?
[15:00] <roaksoax> jtv: MismatchError: None is not {}
[15:00] <jtv> Then clearly it's not {}.  :)
[15:01] <jtv> You can test that x is an empty dict by doing self.assertEqual(x, {})
[15:01] <roaksoax> jtv: yeah, so I was comparing None with {}. but I want to compare that {} is {}
[15:01] <jtv> I think I may be missing something here...  one of the two must be a variable, and the other a constant, right?
[15:02] <jtv> Because we already know that {} equals {}, although {} is not {} in the sense of the "is" operator.
[15:02] <roaksoax> jtv: http://paste.ubuntu.com/5758477/
[15:02] <jtv> That should work, if get_snippet_dir() really returns {}.
[15:03] <jtv> Ahem — get_snippet_context
[15:03] <jtv> nog get_snippet_dir
[15:03] <roaksoax> jtv: yeah, that worked! thanks! (and yeah was adding that test as per your recommendation)
[15:03] <jtv> Ah :)
[15:04] <jtv> Some background: there's "{} == {}" (which is true),
[15:04] <jtv> and there's "{} is {}" (which is false).
[15:04] <jtv> The reason the latter is false is that "is" compares the identity of the objects.
[15:04] <roaksoax> jtv: test_get_snippet_context_empty_if_no_snippets ->> the test renamed like this sounds better?
[15:05] <jtv> Yes, that's good.
[15:05] <roaksoax> jtv: right, I see, similar to the 'is None' to 'if not None' case
[15:05] <jtv> Yeah — there's only one None.
[15:05] <roaksoax> jtv: btw... are the tests broken in saucy?
[15:05] <jtv> That's why you can compare with "is None."  The "is" operator basically compares the pointers you pass it, instead of the things they point to.
[15:05] <jtv> Tests should work in Saucy, I think.  But there are sometimes changes that break them.
[15:06] <jtv> What are you seeing?
[15:06] <roaksoax> jtv: stuff like: http://pastebin.ubuntu.com/5758493/
[15:07] <roaksoax> jtv: so I upgraded to saucy and tests are now broken, initially thought it was because i did something (like have maas installed), but I removed it and dunno whether it is related
[15:08] <jtv> Oh dear
[15:08] <jtv> This looks a bit as if piston's put() no longer returns anything.
[15:09] <jtv> Let me just see if I can try that on a Saucy system.
[15:10] <roaksoax> jtv: yeah, better double check cause I did a raring->suacy upgrade which might have left something unclean, hence causing this
[15:10] <jtv> Right.  It shouldn't, but then again, there shouldn't be any failures.
[15:23] <jtv> roaksoax: seeing errors too...  :(
[15:30] <roaksoax> boomer
[15:34] <jtv> Boomer?  Isn't that the robot dog from the original Battlestar Galactica series?
[15:37] <roaksoax> lol no idea :)
[15:46] <ehw> er… no that was moffet
[15:46] <ehw> boomer was the (only?) African-American pilot
[15:49] <jtv> Ah thanks
[16:00] <ehw> just doing my job *tips hat*
[16:19] <jtv> roaksoax: at least some of the errors seem to be related to a change in django 1.5.  The tests seem to hang, so I'm not seeing the other ones yet.
[16:22] <roaksoax> jtv: so I'm looking at this: https://jenkins.qa.ubuntu.com/job/maas-merger-trunk/319/console
[16:24] <jtv> Hmmm
[16:25] <roaksoax> jtv: it seems that the tests are testing the rendering of the preseeds (including the enlistment preseed, but instead of calling render_enlistment_preseed for the case of enlistment, it is calling render_preseed
[16:26] <jtv> Yes, IIRC render_preseed has to decide which one it should render.
[16:27] <roaksoax> jtv: right, that's only for commissioning or install
[16:27] <roaksoax> jtv: but enlistment has its own render_enlistment_preseed
[16:28] <roaksoax> jtv: since there's *no* node status for enlistment, then obviously the test would be testing the wrong stuff :)
[16:30] <roaksoax> jtv: so we are basically saying "node.status is commissioning, but test the enlistment preseed" ((i think)
[16:31] <jtv> I don't remember what it was that drove the decision "oh, this node is enlisting" but we'd probably have a comment to mark the spot.
[16:31] <roaksoax> jtv: oh no, i know wthat the issue is.
[16:31] <jtv> ?
[16:31] <roaksoax> jtv: so the running code calls render_enlistment_preseed for enlistment, and for everything else, render_preseed is called
[16:32] <roaksoax> jtv: however, the tests are testing for the enlistment preseed using render_preseed
[16:33] <jtv> Ah.  Maybe the test could assume at some point that the status didn't matter, and that changed?
[16:34] <roaksoax> jtv: so the status always matters, if a node enlist then it has no node status
[16:34] <roaksoax> jtv: so the test is testing depending on PRESEED_TYPE,
[16:36] <roaksoax> jtv: http://pastebin.ubuntu.com/5758742/ --> you'll find the explanation there
[16:37] <jtv> Damn non-wrapping pastebin...
[16:38] <roaksoax> yeah!
[16:39] <roaksoax> jtv: so see what I mean? so test_render_preseed should only test for escenarios with COMMISSIONING, DEFAULT preseeds, while test_enlistment_preseed should test for ENLIST and ENLIST_USERDATA
[16:41] <jtv> I have no idea why load_preseed_template consists of exactly (1) an enclosed function definition and (2) a call to that function.  I feel like punching someone.
[16:43] <roaksoax> jtv: I'm guessing that the key here is that the preseeds (default, commissioning) are being loaded depending on the node.status, while the enlistment preseeds are not
[16:43] <roaksoax> and that's where the difference lies in the code
[16:43] <jtv> Yes, I recall it being something like that.
[16:44] <roaksoax> however, in the tests they do test as if both type of preseeds where the same
[16:44] <jtv> Maybe it was a matter of the node itself being None...
[16:44] <jtv> Ah
[16:46] <roaksoax> jtv: so this is what it should kinda do http://paste.ubuntu.com/5758765/ (note that it is just an example)
[16:47] <jtv> Any idea why this worked before and breaks now?
[16:49] <roaksoax> jtv: yes, it is broken now becuase the maas_ipmi_autodetect stuff for enlistment is inserted in the context in render_enlistment_preseed, but since test_render_preseed calls render_preseed() for the enlist/enlist_userdata templates, then they cannot find the variable in the context
[16:50] <roaksoax> jtv: so doing this would fix it: http://paste.ubuntu.com/5758777/
[16:50] <roaksoax> (or should)
[16:50] <roaksoax> I'm gonna test that
[16:51] <jtv> Doesn't look quite right to circumvent the test scenarios like that though...
[16:52] <roaksoax> jtv: this is what it does the test itself though: preseed = render_preseed(node, self.preseed, "precise")
[16:52] <roaksoax> where self.preseed would be *all* preseeds
[16:52] <jtv> Yes, IIRC the code was deliberately kept very indifferent to that.
[16:52] <jtv> Maybe the test can be split up into two scenarios?
[16:53] <jtv> One for enlistment preseeds, one for the rest?
[16:53] <jtv> Although it is nice to know that all scenarios are tested, even in stupid combinations...
[16:55] <roaksoax> jtv: in reality it is already split in 2 different scenarios
[16:55] <roaksoax> the problem was that the render_preseed scenario was also testing for enlistment preseeds
[16:56] <jtv> So then maybe that could just return if this-is-an-enlistment-preseed-type?
[17:01] <roaksoax> jtv: so how can I filter here: http://pastebin.ubuntu.com/5758815/
[17:01] <roaksoax> jtv: something like. startswidth('ENLIST')
[17:01] <roaksoax> to filter the nelistment preseeds out of it
[17:02] <jtv> Is the filtering appropriate for the entire test case?  Or just for some of the test functions inside it?
[17:02] <jtv> If it's just a few test functions inside it, you can put an "if" inside the test.  For instance, you could just "return" early on if the preseed type starts with ENLIST.
[17:02] <roaksoax> jtv: there's just 2 functions for the class that test this, and both functions uses it
[17:02] <roaksoax> jtv: so I would say that it is necessary to filter it
[17:02] <jtv> If it's the entire test case, then list comprehensions also support "if":
[17:03] <jtv> scenarios = [
[17:03] <jtv>         (name, {'preseed': value})
[17:03] <jtv>         for name, value in map_enum(PRESEED_TYPE).items()
[17:03] <jtv>             if not value.startswith('ENLIST')]
[17:03] <roaksoax> jtv: ok awesome! thakns
[17:05] <jtv> Good luck...  I'll see what I can find out about the Saucy failures.
[17:05] <roaksoax> jtv: ok this does it: http://paste.ubuntu.com/5758825/
[17:06] <jtv> roaksoax: don't forget to update those comments!  It's no longer "each possible value" of preseed type.
[17:09] <roaksoax> jtv: http://paste.ubuntu.com/5758831/ -> alright, this way the test_render_preseed tests everything but enlistment preseeds, and test_render_enlistment_preseed() will test all enlistment preseeds other than just one
[17:11] <jtv> roaksoax: careful!  The comments should say "why" — the "what" is often clear from the code already.
[17:12] <jtv> You could say something like "test against all preseed types, except the enlistment ones.  Those have their own test case."
[17:13] <jtv> (It may seem silly to say what's coming later in the file, but somebody who's reading it has to start somewhere and then all the other stuff is still a mystery to them)
[17:14] <ehw> does anyone have any go-juju maas docs I can follow? I'm having… issues getting this running
[17:15] <roaksoax> jtv: ok, updated
[17:16] <roaksoax> jtv: https://code.launchpad.net/~andreserl/maas/consolidate_maas_ipmi_autodetect/+merge/167806
[17:16] <jtv> Looking...
[17:17] <jtv> (diff still updating)
[17:17] <roaksoax> jtv: done now
[17:18]  * jtv reloads
[17:19] <jtv> roaksoax: looks like it's even going to extend enlistment-preseed test coverage a bit...  Do tests pass now?
[17:19] <roaksoax> jtv: yeah they do
[17:20] <jtv> \o/
[17:20] <roaksoax> \o/
[17:20] <jtv> Then land it!
[17:24]  * jtv is off