[03:37] <pitti> Good morning
[03:37] <pitti> OdyX: pyppd license change> no problem at all for Ubuntu, thanks!
[05:24] <larsduesing> cjwatson: oh.. I think I get the picture... -proposed has to be related -security, -updates, -release; -release has to be related to -security, -release; updates - aehmm... getting complicated, yes...
[06:49] <dholbach> good morning
[06:49] <didrocks> bonjour dholbach
[06:50] <dholbach> salut didrocks
[06:50] <dholbach> comment ça va?
[06:50] <didrocks> dholbach: ça va bien, et toi?
[06:51] <dholbach> oui, ça va - mais j'ai besoin d'un autre tasse de café :)
[06:52] <didrocks> déjà fait ici ;)
[07:33] <sil2100> huh?
[08:16] <apw> mvo, ok so in that squid-deb-proxy branch is an updated fix which uses the same criteria that apt does in selecting which IP addresses it can use, which should eliminate the 'something wierd' errors: https://code.launchpad.net/~apw/ubuntu/quantal/squid-deb-proxy/lp1021298
[08:17] <apw> mvo, it does involve a switch of language for the client script there, so i am slightly unsure if we need a dep there
[08:17] <apw> i believe it is Essential: so we don't, but best to check
[08:22] <robotex> Hello
[08:22] <robotex> I created application for Ubuntu Showdown, but I can't create deb package
[08:22] <robotex> please, somebody help me
[08:30] <dpm> hi robotex, can you be a bit more specific? What is not working for you?
[08:33] <robotex> I created PPA and signed it with PGP. Now I go to the my app source directory and trying it: http://developer.ubuntu.com/packaging/html/packaging-new-software.html But in this step I have next problems:
[08:34] <robotex> 1. Checking the program. In this section tells about downloading and building sources, but I create my own sources. So, I thought I can go to the next step.
[08:37] <robotex> so, I tar my sources to archive and go to step 'Starting a package'
[08:37] <robotex> and first command:
[08:37] <robotex> so, step 'Starting a package'
[08:37] <robotex> robotex@robotex-laptop:~/workspace$ bzr dh-make mirrorcam 1.0 mirrorcam-1.0.tar-gz
[08:37] <robotex> bzr: ERROR: Either run the command from an existing branch of upstream, or move mirrorcam aside and a new branch will be created there.
[08:37] <robotex> What's wrong?
[08:40] <mvo> apw: thanks, I have a look
[08:47] <robotex> dpm, where can I read fully step by step instruction how to build deb package from pure source code
[08:54] <dpm> robotex, would you mind moving over to the #ubuntu-app-devel channel to help you with your app showdown submission?
[08:58] <robotex> ok, I'll go there
[09:20] <ev> mpt: presumably we shouldn't show the "send an error report to help fix this problem" checkbox on debconf progress windows, right?
[09:20] <mpt> ev, I didn't know there was such a thing as a debconf progress window
[09:20] <mpt> Can you take a screenshot?
[09:23] <ev> mpt: http://people.canonical.com/~evand/tmp/Screen%20shot%202012-07-09%20at%2010.22.42.png
[09:26] <cjwatson> I don't think anything other than the installer uses the debconf progress type in practice (and the installer turns it into a rather better UI)
[09:27] <ev> cjwatson: true. Somewhat relatedly, I think I'm going to ignore SETBLOCK
[09:27] <ev> I can't see the rationale for "lets stuff a bunch of questions all on the same page", other than d-i
[09:27] <cjwatson> nearly everything else does :-)
[09:27] <ev> :)
[09:28] <cjwatson> Oh, there's reasonable rationale for it in general, in that there may well be questions that are actually related; it's just not widely used
[09:28] <cjwatson> For example, your MySQL username and password
[09:28] <ev> ah, interesting
[09:30] <cjwatson> Actually, mysql-server-* installation doesn't ask for a username, as it happens, it's asking for the DB root password.  But you get the idea
[09:30] <ev> yeah, it's a reasonable example regardless
[09:31] <cjwatson> Nobody uses it much because the dialog frontend doesn't implement it; although it would perhaps be interesting to grep the archive for uses of it, if you can be bothered
[09:31] <cjwatson> Anyway, it'll always contain some other question which presumably you aren't ignoring
[09:31] <cjwatson> (I assume you mean BEGINBLOCK/ENDBLOCK)
[09:32] <cjwatson> You should ignore STOP too, if we're talking about intercepting the debconf protocol
[09:32] <cjwatson> And VERSION, CAPB, probably SETTITLE/TITLE ... basically anything other than a GO that actually asks some questions, I suppose
[09:33] <cjwatson> Definitely shouldn't error on any INPUT, because many of those won't be presented
[09:38] <seb128> cjwatson, ev, hey, do you know if somebody in the foundation team looked at the recent daily iso testing issues: https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-i386_default/60/
[09:39] <cjwatson> Not again :-(
[09:39] <cjwatson> I guess I'll look today
[09:40] <mpt> ev, yowsers. Do you have any idea how often that appears between steps, and how often just by itself?
[09:40] <mpt> ("Yowsers"? I meant "Gadzooks", of course.)
[09:41] <seb128> cjwatson, it seems random, like i386 worked on saturday and not on sunday, and amd64 the opposite way
[09:42] <seb128> cjwatson, I wonder if there is an issue with the jenkins setup...
[09:42] <mpt> ev, it should be easy to imagine how SETBLOCK would be laid out -- you'd need to apply a sanity check to ensure the alert never gets taller than the screen, but you should be doing that anyway ;-)
[09:43] <cjwatson> seb128: Well, there's an actual crash there
[09:48] <seb128> cjwatson, ok, I'm not sure how to read those log, the i386 logs for #59 and #60 are quite different, like they would not test the same things...
[09:51] <ev> mpt: what does the sanity check do when it fails? :) Split across pages?
[09:51] <ev> for what it's worth, it does already work and its layout falls out of the UI code I've written
[09:52] <mpt> ev, for multiple questions, yes. If even a single question is too tall, I guess you'd have to ellipsize it
[09:52] <ev> good point
[09:52] <ev> I suspect I can coerce the toolkit do to the latter automatically
[09:53] <ev> I hope
[09:53] <ev> this is GTK+ after all
[09:53] <mpt> And remember, this text you're receiving is untrusted. Check what happens when someone gives you an EOF or a RTL direction change marker
[09:53] <mpt> or 138 LF characters
[09:54] <ev> sounds like we need a test harness
[10:04] <robotex> robotex@robotex-laptop:~/workspace/mirrorcam-1.0$ fakeroot debian/rules clean debian/rules:13: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.
[10:04] <robotex>  what's wrong?
[10:05] <robotex> there is no tabs in this file
[10:08] <cjwatson> robotex: sounds like you read the error message backwards; command lines in a Makefile (which debian/rules is) *must* start with a tab character
[10:09] <robotex> oh
[10:09] <robotex> tab or spaces
[10:09] <robotex> ?
[10:09] <cjwatson> tab
[10:10] <mpt> ev, I dont have time to design that progress window now, but I can tackle it on Thursday
[10:10] <cjwatson> it's a syntactic requirement, not subject to personal preferences
[10:10] <ev> mpt: that's fine
[10:11] <ev> I'll leave the one we have in place for now
[10:13] <rbasak> Is the ubuntu-devel lists.u.c moderation queue monitored? I'd like to email it.
, thanks
[10:20] <robotex> It's compiling!
[10:20] <robotex> Yahoo!
[10:21] <robotex> Done!
[10:23] <robotex> my first deb package in a life ^_^
[10:25] <Chipzz> cjwatson: I have wondered about that in teh past (debconf grouping); I suspect it is because a lot of front-ends ignore it (all the text-based ones do)
[10:25] <Chipzz> that and people probably don't know about it
[10:31] <cjwatson> rbasak: occasionally
[10:37] <robotex> What?! Why package is empty? 0_o
[10:38] <cjwatson> Could you ask this kind of thing on #ubuntu-app-devel, please?
[10:38] <cjwatson> They're better suited to this kind of question
[10:41]  * rbasak emails ubuntu-devel
[10:42] <shakaran1> Could somebody sponsor this bug? https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1012602 It is very reproducible (with duplicates) and it contains a successful path. It only needs apply and release it
[10:44] <shakaran1> s/path/patch/
[10:46] <ev> is it just me or is ./test_debconf.pl broken? The "call to abstract method CopyDBTestSetup::name" error isn't particularly helpful either.
[10:48] <ev> ah, I get it now. Nevermind
[10:48] <ev> still looking a bit bit-rotten though
[10:53] <jamespage> if I do a seed update for packages which are not yet in main will it break everything todo with that seed?  or will it pull in the new packages anyway and stuff appears in component mismatches?
[10:54] <jamespage> (context tomcat6 -> tomcat7 transition)
[10:54] <cjwatson> jamespage: typically the latter but if it needs an MIR then please don't leave the MIR too long
[10:55] <jamespage> cjwatson, MIR is already raised - still pending review and approval
[10:57] <rbasak> shakaran1: it should enter the sponsorship queue automatically if you attach a debdiff. Do you know how to make one?
[10:59] <shakaran1> rbasak: I don't know how to do it. Some useful tutorial?
[11:03] <rbasak> shakaran1: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff, and also see https://wiki.ubuntu.com/SponsorshipProcess. Using UDD may be easier.
[11:05] <shakaran1> rbasak: thanks I gonna read it just now ;)
[11:06] <rbasak> shakaran1: note that you don't have to do this, since the reviewers team will work to get there from your patch, which is appreciated. But submitting something directly in the form that a sponsor can use speeds things up :)
[11:08] <shakaran1> rbasak: it is not my patch. It is from another person. I am just a user affected with another duplicate. So if I just can save some time and speed up the process it is ok ;)
[11:08] <shakaran1> rbasak: also I like learn new things ;)
[11:13] <cjwatson> A debdiff is no faster for me than any other kind of patch.
[11:14] <cjwatson> This is an odd myth.  You run patch over it either way, and chances are you'll probably have to edit or at least review the changelog, integration with the patch system, and such either way.  In fact sometimes it can take longer if somebody's tried to integrate it into the local patch system and got it wrong.
[11:31] <shakaran1> cjwatson: the patch is only a string cast with utf8 function on python. But the bug has weeks and the patch 3 days. So if nobody can ship it until now I try to speed up the process. I just want the fix released soon.
[11:37] <rbasak> cjwatson: ah, OK. The thing is, attaching a patch automatically subscribes ubuntu-reviewers, but attaching a debdiff automatically subscribers ubuntu-sponsors
[11:37] <rbasak> cjwatson: is it OK to subscribe ubuntu-sponsors (since I seem to have permission to do that) with just a patch and no debdiff?
[11:54] <mvo> apw: I'm looking at the squid-deb-proxy branch now, looks great, I assume you considered something like REACHABLE=$(cat /dev/null|nc $addrform $port) to be less good as it adds additional traffic to squid?
[11:55] <apw> mvo, i was trying to avoid additional traffic, but if you think thats acceptable i can go that route
[11:55] <mvo> apw: I think python is acceptable too :) was just wondering
[11:56] <apw> as the key think is finding out what answers getaddrinfo(..., AI_ADDRCONFIG) will return
[11:56] <cjwatson> rbasak: sure, I don't see why not
[11:56] <cjwatson> rbasak: if you think it's actually something that somebody is trying to have uploaded
[11:56] <apw> and i wanted a language which was _all capable so as to not need a binary package
[11:56] <mvo> apw: yeah, just read about this in the manpage, haven't crossed that one yet
[11:57] <apw> mvo, it was a new one on me too, i was all confused as to why a fe80 addr wouldn't not lookup but my 2001: ones would.  seems they don't count as a configured address to libc
[11:57] <mvo> apw: so +1 for python and I'm happy to merge it, I will do some tiny bits of python changes during the merge if you don't mind. if yu do mind I'm happy to branch from your branch and you can review (will be tiny stylistic things)
[11:57] <apw> which kinda makes sense.  though when looking up an fe80: having an fe80: should work imo, but thats an eglibc 'bug' in that case
[11:57] <rbasak> cjwatson: ok, I'll do that, thanks
[11:58] <apw> mvo, heh no please hack away on it, i would love to know what you prefer in python, its not a native language for me yet
[11:58] <apw> mvo, so i can get it right next time :)
[11:58] <mvo> apw: cool, once I'm done I will show you the diff (meh, phonecall)
[12:00] <rbasak> shakaran1: I subscribed ubuntu-sponsors for you, so it should be in the sponsorship queue shortly. You can see its progress at: http://reports.qa.ubuntu.com/reports/sponsoring/index.html
[12:03] <shakaran1> rbasak: thanks
[13:03] <stgraber> @pilot in
[13:06] <shakaran1> There are some specific channel for ubuntu webkit related stuff?
[13:16] <mvo> apw: thanks a bunch, merged to trunk, it would be great if you would remerge and double check that i did not do something silly during the merge
[13:16] <mvo> apw: if it looks good, I can upload (or you can, either way is fine with me)
[13:20] <apw> mvo, its cirtainly prettier :)  i'll retest the new construction on my systems here and let you know
[13:20] <mvo> apw: awsome, thanks a lot (plus a big THANKS for the fix itself of course)
[13:26] <seb128> cjwatson, is you or anyone else looking at the ubiquity,daily iso test issues? can we help in some way?
[13:27] <cjwatson> seb128: I'm looking at it
[13:28] <cjwatson> Not sure how you could help apart from also attempting to work it out from scratch ;)
[13:28] <cjwatson> I can reproduce it
[13:30] <seb128> cjwatson, ok, thanks, I will let you handle it then ;-)
[13:31] <seb128> cjwatson, sorry for being nagging about it, I'm trying to make sure we keep rick happy ;-)
[13:32] <cjwatson> Yeah, I know, that's among the reasons I'm looking ;-)
[13:33] <cjwatson> Looks like it was triggered by usb-storage becoming modular (I'm guessing), but it's a ubiquity bug anyway
[13:33] <cjwatson> Or maybe a hw-detect bug, but it smells like ubiquity to me
[13:38] <cjwatson> It's peculiar; the debconf debug trace doesn't make a lot of sense.  I might have to reboot and set -x it
[13:38] <cjwatson> GO returns 0 and then it seems to bail out
[13:39] <cjwatson> And my previous guess at the trigger is wrong because usb-storage was modular in precise too
[13:43] <seb128> cjwatson, :-(
[14:08] <seb128> ScottK, hey
[14:08] <ScottK> Hello seb128.
[14:08] <seb128> ScottK, those libreoffice SRU issues are a bit confusing, do you know what update is breaking what exactly? does lo 3.5.4 with the old menubar works fine or is that creating issues?
[14:08] <seb128> ScottK, or is the menubar update creating the bug?
[14:08] <seb128> or both together?
[14:09] <ScottK> seb128: It's not clear to me either.
[14:09] <seb128> ok :-(
[14:09] <ScottK> One thing I was sure of on Friday though was leaving the new menubar in updates over the weekend with no one around was not the right answer.
[14:10] <seb128> right, good call, thanks for getting that sorted ;-)
[14:10] <ScottK> I use LO for $WORK every day, so I'm not going to experiment myself.
[14:10] <seb128> ScottK, is there anyone around who is,was having the issue and could help figuring the combinaison of versions leading to the bug?
[14:11] <ScottK> I don't know anything more than is in the bug, so not that I know of.
[14:11] <Daviey> smoser: mterry just uploaded cloud-init ftbfs fix.
[14:11] <seb128> ScottK, ok, I will follow up on the bug, thanks
[14:11] <smoser> yeah. :-(
[14:11] <smoser> i should have marked in progress
[14:11] <smoser> suck
[14:11] <ScottK> I don't think anyone what tried to contact the original reporter with specific test requests.
[14:11] <cjwatson> You know what really annoys me?  rsyslog deciding to rate-limit my debugging output
[14:11] <cjwatson> NO YOU STUPID PROGRAM I WANTED IT ALL
[14:12] <smoser> YOU STUPID HUMAN I AM SMARTER THAN YOU
[14:13]  * smoser has sworn at that rsyslog feature more than once.
[14:16] <stgraber> seb128: what's the bug# for the libreoffice issue you mentioned earlier? I noticed that on my laptop I no longer have global menu integration (I have lo-menubar installed)
[14:16] <stgraber> seb128: and that's on precise without -proposed enabled (LO 3.5.3-0ubuntu1 + lo-menubar 0.1.1-0ubuntu0.1)
[14:17] <micahg> stgraber: and you had integration before the lo-menubar update>
[14:18] <stgraber> micahg: yes
[14:19] <seb128> micahg, stgraber: integration being broken is a known issue, but we decided it was less of an issue (cosmetic) than having libreoffice segfaulting on print preview and making you loose work
[14:19] <seb128> stgraber, bug #754562  is the lo-menubar SRU, it documents that bug
[14:19] <seb128> stgraber, https://bugs.launchpad.net/bugs/1021946 is the "new" bug
[14:20] <micahg> well, the integration issue isn't listed under regression potential in the lo-menubar SRU bug
[14:23] <micahg> ah, I see it's mentioned in comment 38, I wonder if that was noticed
[14:24] <micahg> so, it effectively disabled the lo-menubar anyways
[14:24]  * micahg guesses we have to wait for RAOF to come online to find out if that was noticed or not when accepting :)
[14:32]  * cjwatson syncs tiff and tiff3 now that jbigkit is in main
[14:32] <mdeslaur> cjwatson: thanks
[14:32] <micahg> that should clear a few depwaits :)
[14:32] <cjwatson> mdeslaur: And I did check your recent upload was covered
[14:36] <hallyn> so is libudisks2-dev meant to be a full drop-in replacement for libgdu-dev, i wonder
[14:42] <cyphermox> hallyn: not without some porting
[14:43] <hallyn> drat
[14:44] <hallyn> cyphermox: so what would be the right thing to do wrt unity?  Do the porting for them, or open a bug?
[14:44] <cyphermox> hallyn: unity was supposed to be taken care of by the unity developers; I think they already know about it
[14:44] <cyphermox> didrocks: ^ ?
[14:45] <hallyn> cool, thanks.
[14:45] <didrocks> cyphermox: yeah, I sent that to popey
[14:46] <didrocks> he's the team tracking the dep changes
[14:46] <didrocks> hallyn: please open a bug, I'm sure there is already one
[14:46] <hallyn> that seems contradictory :)
[14:49] <hallyn> filed
[15:01] <hallyn> mterry: amarok has NBS against liblastfm-0 which is replaced by liblastfm-1.  however it has build-dep against liblastfm-dev.  Do I understand right tha ta simple rebuild will fix it then?
[15:01] <mterry> hallyn, very likely
[15:02] <hallyn> mterry: is there a button one can click to make that happen?
[15:03] <mterry> hallyn, no, you'll still need to do a new source upload.  If it was a ftbfs, you can click a button to rebuild it.  But for NBS kinds of things, you need a new source (otherwise you couldn't tell old binaries from the new ones)
[15:03] <mterry> hallyn, so a "dch -R" will get you the right version number, then a simple comment like "no change rebuild for ..."
[15:03] <hallyn> mterry: ok, thanks
[15:03] <mterry> hallyn, but definitely test-build in a chroot first
[15:04] <hallyn> yup
[15:04] <mterry> it's possible other problems have cropped up since the last time it was built
[15:04] <hallyn> will do, thanks.
[15:04] <hallyn> (then i'll have to bug you/someone again to upload :)
[15:17] <debfx> hallyn: afaik rebuilding amarok won't work as the API changed, apachelogger was working on it
[15:18] <hallyn> debfx: yeah, i already ran into kdemultimedia-dev no longer existing, too.  thanks, i'll leave it to apachelogger then! :)
[15:32] <stgraber> dupondje: hey there, I'm going through the sponsoring queue and noticed that bug 1015753 is waiting on a reply from you. Just wanted to make sure you're aware of it so we're not stuck there.
[15:33] <xnox> stgraber: me looks at it just in case ;-)
[15:36] <apw> mvo, ok seems to work in all three of the cases i can easily test here
[15:36] <dupondje> stgraber: it needs to be merged indeed. Cause upstart files changed name.
[15:38] <stgraber> dupondje: will you take care of this? from my understanding, it should just be a matter of adding a .maintscript file to transition the two conf files
[15:39] <dupondje> stgraber: should be enough indeed. Need to check that out when having a bit time
[15:39] <stgraber> dupondje: cool, thanks
[15:39] <dupondje> or if somebody else feels to take it :) xnox? :)
[15:40] <mvo> apw: very nice, want me to upload it? or do you want to upload yourself, either way is fine for me
[15:40] <apw> mvo, /me can't upload it :)
[15:41] <xnox> dupondje: I may look at it. i don't think I ever did conf file name transition.
[15:41] <dupondje> me neither :)
[15:42] <mvo> apw: thats fine, uploading in a sec
[15:46] <stgraber> xnox: add .maintscript file containing "mv_conffile <source> <destination> <last version with source> <binary package name>", you'll need to pre-depends on dpkg >= 1.15.7.2 (man dpkg-maintscript-helper)
[15:46] <xnox> stgraber: awesome, thanks. And keep it until 14.04....
[15:47] <dupondje> stgraber: or is there another way in dh_installinit to have different named upstart files then .init files?
[15:50] <stgraber> dupondje: I don't know dh_installinit that well, it's certainly possible with some hacks but I'd think it'd just end up being more confusing. Adding the .maintscript is the easiest (it'll generate a preinst entry moving the old conffile to the new path before dpkg unpacks, so you'll get the usual conffile prompt if it's different)
[16:32] <doko> cjwatson, Daviey: is the python3.3 udeb needed in the forseeable future?
[16:34] <Daviey> doko: very unlucky
[16:34] <Daviey> unlikely
[16:35]  * cjwatson denies knowledge
[16:35] <cjwatson> seb128: argh, I can't get the blasted thing to fail under any decent level of debugging
[16:49] <doko> chrisccoulson, ogasawara, Sweetshark: the ubuntu-toolchain-r/test ppa has a binutils snapshot. please could you do a kernel/firefox/lo test build with it?
[16:50] <ogasawara> doko: sure
[16:52] <OdyX> pitti: thanks.
[16:53] <micahg> doko: which release is this for?
[16:54] <doko> micahg, q
[17:01] <doko> micahg, so yes, a chromium build would be nice too
[17:02] <micahg> doko: I'm not looking really looking after q ATM
[17:16] <seb128> cjwatson, :-(
[17:17] <seb128> cjwatson, is there any update which was likely to have caused the issue that we could revert while we debug? (asking because rick already hinted that after several days of test not working we should have reverted the problematic update)
[17:19] <cjwatson> seb128: I have absolutely no idea what to revert or else I would have already done so.
[17:19] <micahg> doko: chrisccoulson is a bit busy right now, I'll kick off a Firefox build for you
[17:20] <cjwatson> seb128: And previous test failures were different ...
[17:20] <seb128> cjwatson, ok...
[17:20] <seb128> cjwatson, previous ones on the same iso, or you mean until you fixed the other bug on friday?
[17:20] <cjwatson> the latter
[17:20] <seb128> cjwatson, what is weird is that some of the builds success
[17:20] <cjwatson> It seems to be racy, but I haven't worked out why
[17:20] <seb128> so seems racy as a bug
[17:21] <cjwatson> Friday> so what I mean is that I'm not prepared to take responsibility for not fixing any failures that arose over the weekend :-P
[17:22] <seb128> hehe, fair enough
[17:22] <seb128> in your defense the first build on saturday was green ;-)
[17:31] <stgraber> @pilot out
[17:35] <cjwatson> seb128: I don't suppose you know if there's any way to get ubiquity --debug output from https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-i386_default/60/ ?
[17:37] <cjwatson> Hm, it doesn't run with --debug at the moment by the looks of things
[17:39] <micahg> doko: I"ll have to do it later, apparently the package that allowed adding PPAs from the cli has changed in quantal and it's breaking my local scripts, someone from the desktop team will have to help you
[17:42] <seb128> cjwatson, sorry I don't know, we would need jibel there...
[17:52] <cjwatson> seb128: I'm not getting anywhere and have apparently stopped being able to reproduce it.  Giving up for today.
[17:54] <seb128> cjwatson, ok
[17:54] <seb128> cjwatson, have a good evening
[17:55] <seb128> the iso tests are at least not all red for days so while we are still on the hook we might get away with it ;-)
[17:55] <cjwatson> If it recurs then maybe it will come with some kind of clue on reproducing it more reliably.
[19:54] <hallyn> does anyone see why python-support has not been built for anything but i386?
[19:54] <hallyn> doesn't look like it failed...
[19:54] <hallyn> just didn't try
[19:55] <Laney> because it's arch:all. the same binary package can be used on any architecture.
[19:55] <pitti> hallyn: it's arch:all
[19:55] <SpamapS> all together now
[19:55] <SpamapS> its arch:all!
[19:55] <SpamapS> this is how musical numbers start
[19:55] <hallyn> so the python-greenlet build failure should be resolved if we just hit re-build?
[19:56] <hallyn> (it failed bc of python-support being unavailable)
[19:56] <jtaylor> no
[19:56] <jtaylor> python-support is removed from main, it needs to be transition to dh_python2
[19:56] <Laney> smells like a component mismatch
[19:57] <hallyn> python-support needs to be transitioned to dh_python2 so it can go back into main?
[19:57] <jtaylor> no greenlet
[19:58] <jtaylor> python-support and dh_python2 are both packaging helpers, the former is deprecated
[19:58] <hallyn> gotcha
[19:58] <hallyn> thanks
[19:58] <Laney> there's a dh_python2 patch on the bts
[19:58] <Laney> you can probably use that, assuming Daviey has clue :P
[20:02] <hallyn> Daviey: ^ do you think we should push your debdiff into python-greenlet for q, or wait for debian to accept it?
[20:02] <jtaylor> debian won't accept it till wheezy +1
[20:02] <pitti> FYI, Debian is in freeze now; I wouldn't depend on Debian to accept anything non-urgent right now
[20:03] <hallyn> ok thanks
[20:03] <Daviey> hallyn: yeah, i had hoped it would have got in.. it's been there for ages.. feel free to sponsor it in, or i'll do it tomorrow
[20:03] <Daviey> thanks for asking
[20:04] <Daviey> Laney: the clue i had, i lost long ago
[20:05] <Laney> I think I sold it, soz for that
[20:05] <Daviey> hallyn: debian bug 673244
[20:06] <hallyn> Daviey: yup, already test-building, thanks
[20:07] <Daviey> I really wish installing language-pack-en didn't bring in firefox-locale-en.. it urks me
[20:08] <hallyn> that's not how you spell irk :)
[20:10] <ScottK> Maybe it is in en-GB.
[20:11] <hallyn> Daviey: you never opened an ubuntu bug for that one right?  (about to create one)
[20:14] <Daviey> hallyn: i did not..  i often think it's not worth opening a bug just to close it again a few mins later.
[20:14] <Daviey> but does increase street cred via karma i suppose :)
[20:14] <hallyn> OTOH it gives something to reference in changelog...  <shrug>
[20:17] <soren> At one point I had a script that did all of that for me. I'd just do "whatever.py 'Title' 'Description'". It'd file a bug with the relevant title and description and add a changelog entry saying 'Fixed "$TITLE" (LP: #XXX)'
[20:17] <soren> I wonder where that went..
[20:18] <hallyn> you've since re-written it in go, and posted it at code.google
[20:18] <Daviey> soren: why not just write a while true: open-pointless-bug(title=rand()) done ?
[20:19] <soren> I think it was back in the day when we had to do weekly activity reports. This way, I had a paper trail.
[20:19] <Daviey> eww
[20:19] <soren> "eww paper trail" or "eww activity reports"?
[20:21] <hallyn> i dunno, i still like the idea, especially for figuring out, while doing a big merge, wtf person x was thinking 10 commits ago
[20:25] <Daviey> soren: both.
[20:26] <Laney> Most stuff can be adequately dealt with by being a bit more verbose in your changelogs.
[20:33] <infinity> hallyn / Daviey: Unless it's for an SRU (where we want to bugs for verification-tracking and such), I'm not sure I see the point in clogging up the bug database just to have something to close in a changelog.
[20:33] <infinity> hallyn / Daviey: Given that, in the short window between opening and closing it, the only person reading it will be you, it seems entirely pointless.
[20:34] <hallyn> infinity: so assuming that there is an open debian bug, and we don't want to (i assume) put 'Closes: XXX' in the ubuntu changelog, isn't the ubuntu bug (with debian bug linked) useful in the changelog?
[20:35] <hallyn> ok, less work, i'm on board
[20:35] <infinity> hallyn: I put close: 1234 in Ubuntu changelogs all the time.
[20:35] <infinity> hallyn: closes*
[20:35] <hallyn> when it hasn't gone in through debian?
[20:35] <infinity> hallyn: A reference to a bug is handy, if the bug has traffic, a reference to a bug you artificially created to have a reference is silly, you should just have better changelogs.
[20:36] <hallyn> my changelogs reads like a first rate novel
[20:36] <infinity> hallyn: If it hasn't been uploaded to Debian, it's still not a lie that your change *would* closes: 1234. :P
[20:36] <tumbleweed> there's no point in copying a bug to LP just so we can link to it from the changelog. Closes on debian bugs ++
[20:36] <infinity> (I'd also argue that, freeze or not, if the dh_python2 conversion is clean, it would be perfectly acceptable to upload to Debian)
[20:37] <infinity> python-support dying is, unfortunately, not a release goal, but it's still awful and needs to die.
[20:37] <Laney> I'm not sure the release team would accept that argumentation
[20:37] <ScottK> Wheezy +1.  Both -support and -central should die.
[20:38] <Laney> what about The Morph Factor?
[20:38] <jtaylor> opinions on -support vary greatly in debian
[20:38] <jtaylor> you won't get a dh_python2 patch through jwilk or morph until support is removed
[20:38] <ScottK> jwilk is making suggestions now.
[20:38] <tumbleweed> jwilk has sponsored dh_python2 packgaes (although not often)
[20:38] <tumbleweed> (I think)
[20:39] <ScottK> I think he's coming around and in Wheezy +1 POX can work to satisfy his concerns.
[20:39] <ScottK> Someone's going to have to fix an RC bug in python-support before release.
[20:40] <infinity> Laney: Well, I don't maintain any python junk, so I can give random advice without it actually affecting me. ;)
[20:41] <Laney> Me neither. I just know that the freeze guidelines rule out random packaging changes
[20:41] <infinity> Laney: Sure, though this is, arguably, not a "random change", but fixing a bug.
[20:41] <Laney> but you're there, so can convince folk over $cheese and $wine.
[20:41] <infinity> The bug being "oh god, python-support".
[20:41] <jtaylor> jcristau recenty said dh_python2 does not get an exception
[20:41] <jtaylor> as long as support does not cause issues
[20:41] <infinity> jtaylor: Ahh, shame.
[20:42] <doko> sometimes you have to "convince" jcristeau
[20:43] <jtaylor> change it just because it makes ubuntu delta smaller will probably not be convincing
[20:43] <infinity> doko: I know how you tend to "convince" me.
[20:44]  * Laney blushes
[20:45] <jtaylor> doko: do we need the mpich2 delta?
[20:45] <jtaylor> to my knowledge blcr does not work anyway
[20:45] <jtaylor> brcl
[20:45] <doko> jtaylor, then fix brcl
[20:46] <jtaylor> doko: upstream fails at that, why should I succeed?
[20:46] <jtaylor> mpch2 is semi-broken in precise and quantal, a sync would fix it, I don'T feel like merging for no reason
[20:48] <jtaylor> the newest kernel upstream supports is 2.6.38
[20:55] <dobey> infinity: hey
[20:56] <dobey> infinity: test-building re-packing of ubuntuone-client right now. do i need to upload it as 0ubuntu1.1 now, or is 0ubuntu1 still fine since it hasn't been accepted?
[22:54] <psusi> cjwatson, the documentation on the ubuntu wiki says to reinstall grub from the livecd, you should use --boot-directory=/mnt/boot.  AFAICS, this is dead wrong.  That switch changes the /boot directory, but grub-install needs to know --root-directory=/mnt, otherwise it assumes the root of the livecd is the root, however, --root-directory is also not mentioned in the man page, and the script comments say it is accepted for backward compatibility.  Am I mi
[22:54] <psusi> ssing something?
[23:04] <RAOF> micahg: I didn't notice comments posted after I accepted lo-menubar into -proposed when I accepted lo-menubar into -proposed, no ☺. slangasek would appear to be the person who accepted it into -updates; I don't know whether he noticed the "it doesn't actually work" comments.
[23:14] <ScottK> RAOF: I think they were added after once someone noticed the other bug.
[23:15] <psusi> cjwatson, nevermind
[23:15] <RAOF> ScottK: They seemed to be directly above slangasek's verification-done tagging; maybe this was a race, though.
[23:15] <ScottK> Not sure.
[23:15] <ScottK> That was my impression on Friday, anyway.
[23:24] <cjwatson> psusi: the chroot method on the wiki is the only one I endorse or recommend; I didn't write that page and have not had the time it would take to edit it into complete sanity