[00:12] <TheMuso> bdrung: Please include debian changelog entries with merge uploads.
[00:13] <bdrung> TheMuso: damn, i forgot it again.
[00:13] <bdrung> TheMuso: i need to make sponsor-patch usable for my own uploads, too. :)
[00:14] <bdrung> TheMuso: you refer to vlc, right?
[00:14] <TheMuso> bdrung: yes.
[00:14] <TheMuso> As long as you are aware of it.
[00:14] <bdrung> TheMuso: it happens way to often.
[00:14] <TheMuso> Don't worry, you're not the only one.
[00:15] <bdrung> TheMuso: now i have to close the bug manually.
[00:15] <micahg> it seems to be happening quite a bit lately (I've done it a few times as well)
[00:15] <bdrung> TheMuso: i hope that x264 is accepted soon (the we can sync vlc)
[00:16] <TheMuso> Yeah.
[00:16] <TheMuso> micahg: Yeah its easy to miss.
[00:17] <TheMuso> Thats where MoM has an advantage...
[00:17] <bdrung> TheMuso: but mom is too slow for my workflow (upload to debian, merge, upload to ubuntu)
[00:17] <TheMuso> Yeah I understand.
[00:18] <TheMuso> I am just saying that MoM has a merge-package script which includes the -v flag for you.
[00:18] <micahg> TheMuso: last one I missed was when I didn't sign the file for testing, then I signed and uploaded, I intended to use -v when I regenerated and signed, but forgot
[00:18] <TheMuso> heh
[00:18] <bdrung> debuild should be more intelegent with Xubuntu1 versions
[00:19] <TheMuso> That could be a solution, yes.
[00:20] <micahg> bdrung: that's hard as the last upload might have been some random previous debian version, but now a merge is required
[00:20] <bdrung> micahg: at least a warning would be nice
[00:21] <micahg> bdrung: yep, that could work
[00:21] <xnox> bdrung, micahg: from bzr bd --help
[00:21] <xnox>   --package-merge       Build using the appropriate -v and -sa options for
[00:21] <xnox>                         merging in the changes from another source.
[00:22]  * xnox is not sure what that one does =)
[00:22] <bdrung> xnox: that's nice
[00:23] <xnox> I have just noticed this on launchpad:"A newer version of yelp is available for packaging: Yelp 2.30.2"
[00:23] <xnox> Wow =) this is cool =)
[00:24] <xnox> Where is launchpad *new features* changelog btw? for stuff like that.
[00:25] <bdrung> xnox: link?
[00:26] <xnox> https://launchpad.net/ubuntu/+source/yelp
[00:26] <xnox> it seems that launchpad needs tarballs/milestones in launchpad to do that =)
[00:26] <bdrung> nice
[00:27] <bdrung> micahg: are you member of the pkg-mozext team?
[00:27] <micahg> bdrung: nt yet
[00:27] <micahg> *not
[00:27] <bdrung> micahg: it's the place where we should update the extensions
[00:28] <micahg> bdrung: makes sense, i still need to get comfortable with git though
[00:28] <bdrung> micahg: that will take as long as it takes to learn packaging ;)
[00:34] <xnox> bdrung, rubish =) git is easy =) easier than autoconf =))))
[00:36] <bdrung> xnox: that's not hard (to be easier than autoconf)
[00:46] <sivang> hi all
[00:47] <sivang> I wonder if anybody could toss a quick pointer to where this is used in kubuntu? https://code.launchpad.net/~apachelogger/+junk/couchdb-qt
[00:48] <Riddell> sivang: it's not
[00:48] <sivang> Riddell: hey :)
[00:48] <sivang> Riddell: so what was its purpose?
[00:49] <Riddell> looks like harald was looking at using it with his summer of code ubuntu one kde project
[00:49] <sivang> Riddell: I want to have a similar qt implementation to what Couchdbkit does, it might be a god start.
[00:49] <sivang> Riddell: the code does feel as if it was left in the middle
[00:49] <sivang> Riddell: I see, thanks for the note.
[00:49] <Riddell> apachelogger is the guy to ask
[00:50] <Riddell> but he'll be asleep
[00:50] <sivang> Riddell: okay, I'll email him
[02:12] <Chipaca> ajmitch: thanks for the info. I'll continue to hug my notmuchmail then :)
[02:52] <ssj6akshat> How do i translate the debian-installer?
[05:35] <cjwatson> I answered ssj6akshat in /msg
[05:37] <hugoshi> this is wierd and quite specific - I've been having trouble with emacs because all the shift arrow keys work inside a terminal except for shift up
[05:37] <hugoshi> I've fixed it
[05:37] <hugoshi> by simply recompiling the terminfo for xterm-256color
[05:38] <hugoshi> I'm not sure how that fixed it, but the recompiled binary is a different size than the original.. which is strange
[05:52] <twb> On lucid in LSB sysvinit scripts, log_progress_msg is defined with the comment
[05:52] <twb> # On Ubuntu, one would expect log_progress_msg to be a no-op.
[05:52] <twb> ...but its definition appears to print things, and I'm no seeing anything being printed.
[05:53] <twb> Ah, it seems that log_action_end_msg eats it
[05:55] <twb> I'm still confused as to where the newlines between " * starting foo" and "   ...done." come from.
[06:12] <ssj6akshat> Is there any ubuntu multitouch devel channel?
[06:14] <bilalakhtar> ssj6akshat: #ayatana
[06:15] <bilalakhtar> uTouch is a part of the Ayatana project
[06:16] <ssj6akshat> bilalakhtar, ah thanks
[06:16] <bilalakhtar> ssj6akshat: no, wait a minute, I don't think that is
[06:18] <cjwatson> #ubuntu-touch
[06:18] <bilalakhtar> ssj6akshat: ^
[06:18] <cjwatson> https://wiki.ubuntu.com/Multitouch
[06:19] <ssj6akshat> cjwatson, ah thanks
[06:20] <ebroder> You know, it's still way too early to be declaring victory, but the length of the sponsorship queue appears to be gaining downwards momentum this week
[06:34] <twb> Aha, busted. /etc/lsb-base-logging.sh redefines stuff
[06:34] <twb> (To talk to usplash, which is weird, because plymouth replaced it.)
[07:02] <twb> WTF
[07:02] <twb> The GRUB_HIDDEN_TIMEOUT code is handled in /etc/grub.d/30_os-prober -- which exists despite os-prober being purged
[07:02] <twb> Oops, wrong channel.
[07:04] <ssj6akshat> no one in #ubuntu-touch seems to be responding
[07:04] <ebroder> ssj6akshat: It's a holiday in the States and early morning in Europe. Be patient
[07:10] <ssj6akshat> ebroder, ok
[07:14] <twb> ebroder: oh, THAT's where everybody is
[07:29] <pitti> Good morning
[07:30] <nigelb> Morning pitti
[07:31] <ssj6akshat> morning pitti
[07:55] <didrocks> good morning
[07:59] <dholbach> good morning!
[08:34] <LetoThe2nd> g'morning! Yesterday I reported a bug via apport, which got marked as duplicate. the message said i shall lookup the original and see if i can provide additional information. i think i can (workaround), but the original bug is marked private. therefore, the mail i received is kind of pointless - i can't access and comment the original bug :-(
[08:56] <pitti> @pilot in
[08:56] <pitti> welcome ladies and gentlemen, I'll be your pilot today
[08:56] <twb> Hmph
[08:57] <twb> The 10.04 udev security update assumes udevadm isn't dpkg-diverted by the local sysadmin.
[08:57] <nigelb> pitti: heh, Martin Airlines ;) ?
[08:57]  * ebroder is certain there's a good "Airplane" joke buried somewhere in this patch pilot business
[08:58] <pitti> yes, they are a bit patchy :)
[08:58] <dholbach> ebroder, I know the guy who draws http://www.chickenwingscomics.com/ - I'm sure you'll find enough ideas for airplane jokes in there :)
[08:59] <ebroder> dholbach: I was thinking of http://www.imdb.com/title/tt0080339/ . Awesome comedy movie
[09:00] <dholbach> oh ok - I didn't know it before
[09:01] <goodwill> could someone with Ubuntu 10.04 tell me if inputlirc run there by default? You can do it by running this in terminal: ps auxw|grep inputlirc
[09:03] <dholbach> goodwill, not as far as I can see
[09:04] <goodwill> dholbach: thank you
[09:04] <twb> goodwill: wouldn't that depend on whether it was installed?
[09:05] <twb> It's not pulled in by any of the normal metapackages (e.g. ubuntu-desktop, ubuntu-standard).
[09:06] <LetoThe2nd> (sorry, bump) g'morning! Yesterday I reported a bug via apport, which got marked as duplicate. the message said i shall lookup the original and see if i can provide additional information. i think i can (workaround), but the original bug is marked private. therefore, the mail i received is kind of pointless - i can't access and comment the original bug :-( - so how to make the maintainer aware of the workaround, which might lead to a fix?
[09:07] <goodwill> twb: I did not think so ... but I had lircd vs. inputlirc issues in 10.10 I am writing about in XBMC which are a bit similar
[09:08] <goodwill> dholbach: can you do me one additional small favor and tell me if inputlirc is at all available in 10.04. You can use: apt-cache search inputlirc
[09:11] <ebroder> goodwill: You can find this out yourself by going to http://packages.ubuntu.com/inputlirc or https://launchpad.net/ubuntu/lucid/+package/inputlirc
[09:11] <goodwill> ebroder: right ... forgot about that
[09:12] <twb> Or the heavyweight solution: pbuilder create --distribution lucid; pbuilder login; apt-cache policy inputlirc
[09:44] <ari-tczew> pitti: ready for sponsoring? :)
[09:44] <pitti> yep, already working on one bug
[09:46] <ari-tczew> pitti: could you take a look on this branch? https://code.launchpad.net/~om26er/ubuntu/maverick/telepathy-haze/telepathy-haze-fix-652944/+merge/41597
[09:48] <pitti> ari-tczew: sure
[09:58] <ari-tczew> pitti: do you will copy this change to natty? ^^
[09:59] <pitti> ari-tczew: I'll upload it to natty
[09:59] <ari-tczew> ok
[10:00] <ari-tczew> dholbach: do you know who deals with hall-of-fame? It seems to be outdated so far
[10:00] <dholbach> ari-tczew, it's in the process of being rewritten
[10:00] <ari-tczew> aha ok
[10:00] <dholbach> the old version is pretty much unmaintained
[10:00] <dholbach> https://wiki.ubuntu.com/Spec/HallOfFameRewrite if you're interested in helping out
[10:02] <pitti> ari-tczew: done
[10:03] <ari-tczew> dholbach: I can't. I'm a n00b in code write.
[10:05] <dholbach> like in all other things having interest in making it work is the most important thing :)
[10:11] <pitti> lamont: I sponsored bug 533601 and attached a debdiff suitable for Debian; want me to create a Debian bug for this, or is this sufficient for you?
[10:11] <ari-tczew> pitti: could you check status of branch?  https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/apache2/maverick-passphrase-plymouth-change/+merge/36610
[10:12] <pitti> ari-tczew: will put as second into my queue
[10:12] <pitti> rodrigo asked earlier :)
[10:12] <ari-tczew> pitti: for my question?
[10:13] <pitti> for above branch review
[10:21] <pitti> ari-tczew: seems it's already applied in natty
[10:22] <pitti> but this is not ever something that I'd put into an SRU
[10:22] <pitti> plymouth integration for apache on a server?
[10:22] <pitti> this looks seriously broken
[10:22] <pitti> wouldn't that stop your boot?
[10:25] <ogra_ac> would it show your websites on plymouth ? :P
[10:25] <ari-tczew> pitti: dunno, I'm only reviewing sponsors queue
[10:25] <pitti> ari-tczew: I commented on the branch and bug
[10:33] <ari-tczew> pitti: could you take a look on bug 677129 ?
[10:35] <pitti> ari-tczew: yep, will do
[10:41] <ari-tczew> pitti: thanks for your time and patience due to quantity of my highlights :)
[10:43] <pitti> ari-tczew: that's my job today :) but I need to balance it with other requests, and also the old stuff which is in the queue, so I can't get to everything immediately
[10:43] <ari-tczew> pitti: so, do you will review a couple of old bugs also?
[10:44] <pitti> ari-tczew: I'm starting from oldest first
[10:44] <ari-tczew> pitti: I'm pleased!
[10:49] <ari-tczew> pitti: do you mind if me or someone else will take your merges?
[10:49] <pitti> ari-tczew: how you mean "take my merges"?
[10:49] <pitti> oh, my merges!
[10:50] <pitti> ari-tczew: no, not at all
[10:50] <pitti> ari-tczew: (sorry, I'm looking at merge proposals all the time, got confused :) )
[10:50] <pitti> ari-tczew: I'd appreciate a quick ping if you do, since I've looked at some which don't make much sense to do
[10:50] <ari-tczew> pitti: understand ;)
[10:53] <xnox> how often does: http://reports.qa.ubuntu.com/reports/sponsoring/ update? My merge proposal is not visible yet =)
[10:53] <xnox> or do I have to have a bug as well?
[10:53] <pitti> at least every 30 minutes, possibly more often
[10:54] <xnox> It's up there already =) never mind missed it in the sorting view =)
[10:54] <xnox> ari-tczew, heya =) it's me with xiphos update branch
[10:54] <xnox> I'll check the comments now ;-)
[10:55] <ari-tczew> xnox: HELLO
[10:55]  * ari-tczew sorry for caps
[10:56] <xnox> ari-tczew, I'm the maintainer of Xiphos in Debian as well. We would like to push sword-1.6.2 to debian experimental first. and then update xiphos and bibletime against sword 1.6.2 in experimental.
[10:56] <xnox> It is not a priority to get it into debian experimental since squeeze is frozen =)
[10:57] <xnox> But bdrung has asked me about xiphos 3.1.4 to make it compatible with xul20 and gtkthml 3.32 so easy the migrations / dist-upgrades in natty asap
[10:57] <ari-tczew> xnox: ok, would be nice. my proposition is: get these changes to Debian experimental first, then sync into ubuntu natty
[10:57] <xnox> ok
[10:57] <xnox> Will seek sponsorship now then.
[11:02] <pitti> ari-tczew: xterm bug already seems to be in progress, and mvo had some concerns about it
[11:03] <ari-tczew> ok
[11:09] <xnox> micahg, with xulrunner-2.0 package there will be no incompatible changes between released 2.0.0 an 2.0.99 to the UPPER/LOWER_RANGES?
[11:10] <xnox> or they have some new policy for those?
[11:14] <chrisccoulson> xnox - the policy hasn't changed AFAIK, so there's no guarantee that there will be no breakage
[11:15] <chrisccoulson> in fact, there's more likely to be breakage now (see https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0)
[11:15] <chrisccoulson> "No more frozen interfaces"
[11:44] <xnox> chrisccoulson, now that is just wonderful =) how do I keep up with future xulrunner updates and test xiphos before each new xulrunner revision in e.g. released natty?
[11:45] <chrisccoulson> xnox, i'm not sure. watching the ubuntu-mozilla-security PPA for updates might be one way
[11:46] <chrisccoulson> we generally don't test these updates on everything before we publish them (else I'd spend my entire time testing security updates)
[11:47] <xnox> hm. 1.9.1 -> 1.9.2 transition failed for xiphos. Xiphos build against 1.9.2, users had 1.9.1 and 1.9.2 installed resulting in xiphos crashing.
[11:47] <xnox> And then later 1.9.2.2 -> 1.9.2.3 updated cause UI bugs in Xiphos.......
[11:47] <chrisccoulson> xnox, we need to tighten GREVersion to stop that from happening (for the 1.9.1 -> 1.9.2 case)
[11:47] <xnox> well this is just me rumbuling =)
[11:48] <xnox> chrisccoulson, I will tigthen GREVersion. But how tight?
[11:48] <xnox> 2.0.0 - 2.0.99?
[11:48] <chrisccoulson> for the 1.9.2.2 -> 1.9.2.3 case, i'm not sure what to do about that. in general, interfaces shouldn't break in minor versions, but there is no guarantee there
[11:48] <xnox> or less than that?
[11:48] <chrisccoulson> xnox, yeah, basically, i want everything in the archive in natty to only work with 2.0.0
[11:48] <chrisccoulson> the reason for this is:
[11:49] <chrisccoulson> sometime in the future, natty will get a new xulrunner version (when 2.0 goes EOL)
[11:49] <chrisccoulson> we will port some applications to the new version
[11:49] <chrisccoulson> but others need to carry on working with the current 2.0
[11:50] <chrisccoulson> one of the difficulties we had when backporting 1.9.2 to our old releases, is that a lot of applications set crazy wide limits for the GREVersion, which meant i had to fix/patch a lot more applications than i wanted to
[11:54] <xnox> chrisccoulson, ok. so currently I get build-dep on xulrunner-2.0 via shlibdeps so appropriate GREVersion limits are 2.0.0 and 2.0.99? And then hope for the best for no minor breakages in between.
[11:54] <chrisccoulson> xnox, you'll need to set the lower version to 2.0b to work with the current version
[11:55] <chrisccoulson> and i set the upper version to 2.0.0.* (gecko usually has a 4 part version number)
[11:55] <xnox> Currently xiphos is fine from xulrunner 1.9.0 -> 2.0.0 so we should detect which xulrunner we are building against at configure time, and preserve the limits in the binary to ${xul-mayor}.${xul-minor}.0 - 99?
[11:55] <chrisccoulson> yeah, that would be ok
[11:55] <xnox> chrisccoulson, 2.0.0 loads fine on my natty for lower bound?
[11:56] <xnox> with xul-2.0.....
[11:58] <quadrispro> pitti, ping
[11:58] <chrisccoulson> xnox, oh, that's good then. that probably means i can change that in gnome-python-extras too
[11:58] <xnox> Yelp is no-go with xulrunner 2.0 yet?
[11:58] <quadrispro> pitti, would you mind to review my commit? http://git.debian.org/?p=collab-maint/libmtp.git;a=commitdiff;h=75a69d
[11:58] <lamont> pitti: looking at the bug
[12:01] <xnox> chrisccoulson, also for Universe we get stuff from debian which has 1.9.2 in experimental so far.....
[12:05]  * quadrispro having launch
[12:08] <chrisccoulson> xnox, yeah, that is a side effect of our different maintenance policy in ubuntu. i don't think there is anything we can do about that
[12:09] <chrisccoulson> i'm generally taking care of the packages which come from debian to make sure they work with our newer firefox version
[12:09] <chrisccoulson> xnox, if you feel like helping out at all, i have a list here - https://wiki.ubuntu.com/DesktopTeam/Specs/Natty/Firefox4/XULRunner20Transition :)
[12:10] <xnox> chrisccoulson, ok thanks =)
[12:12] <quadrispro> pitti, it needs some work
[12:12] <chrisccoulson> xnox - you might want to add your name to xiphos if you're working on that :)
[12:12] <chrisccoulson> so i don't end up duplicating work
[12:13] <xnox> chrisccoulson, yeap =) sure
[12:13] <chrisccoulson> thanks
[12:25] <xnox> chrisccoulson, about the four-part version number. Why the package is called xulrunner-2.0 and not xulrunner-2.0.0? or does it not matter?
[12:26] <xnox> is the next one going to be xulrunner-2.0.1 or will 2.0.1.0 land inside xulrunner-2.0?
[12:27] <chrisccoulson> xnox - unless it's changed, the current 2.0 series will all have 2.0.0.* version numbers, and 2.0.1 will be the next "major"-ish version
[12:27] <chrisccoulson> just like with 1.9
[12:27] <xnox> ok cool =)
[12:49] <pitti> quadrispro, lamont: re (back from lunch)
[12:49] <lamont> wb
[12:54] <pitti> quadrispro: oh argh, there's a comma missing -- is that upstream as well?
[12:54] <pitti> ++  char default_udev_action[] = "SYMLINK+=\"libmtp-%k\", MODE=\"666\" ENV{ID_MEDIA_PLAYER}=\"1\"";
[12:55] <pitti> quadrispro: there needs to be a , between MODE and ENV
[12:56] <pitti> quadrispro: otherwise it looks fine to me
[13:02] <quadrispro> pitti, yes, it's upstream
[13:05] <quadrispro> pitti, pushed. Now I should update udev's rule, but I'm wondering if it's needed to fill ENV{ID_MEDIA_PLAYER}=\"1\"" with the proper media-info device's ID
[13:05] <pitti> quadrispro: shouldn't; MTP devices can tell by themselves which capabilities they have
[13:06] <pitti> quadrispro: but I haven't actually tested banshee other music players what they do
[13:06] <pitti> quadrispro: seems that at least in the current version, rhythmbox doesn't really need the ID_MEDIA_PLAYER flag on MTP devices, it just enumerates /dev/libmtp*
[13:06] <pitti> so the patch isn't really necessary for rhythmbox
[13:06] <quadrispro> yes, I see
[13:06] <quadrispro> would it be sane to upload it now?
[13:07] <pitti> quadrispro: so, I think you should just test banshee and perhaps amarok whether they care about it, and whether it makes a difference
[13:07] <quadrispro> (sure, after doing a bunch of tests)
[13:07] <pitti> quadrispro: I just saw that libmtp's rules come after 40-usb-media-players.rules
[13:08] <pitti> so these need to make sure not to tag any device which is already an USB storage device
[13:09] <quadrispro> mmm, so building now, testing later and then let you know
[13:12] <xnox> chrisccoulson, you are right the min version must be 2.0b or something like that.
[13:18] <xnox> chrisccoulson, can you add two variables to xulrunner pkg-config? GREVerMin and GREVerMax?
[13:19] <chrisccoulson> xnox - yeah, i could do. that's a good idea actually
[13:19] <xnox> with those values that are preferred in Ubuntu when building against that xulrunner e.g. 2.0b and 2.0.0.99 now and other pairs updated later?
[13:19] <chrisccoulson> yeah, i'll do that
[13:19] <chrisccoulson> thanks for the suggestion!
[13:19] <xnox> cause I really don't want to have in my configure script "when it is alpha, when it is beta, when it is released" logic for xulrunner =)))))
[13:21] <pitti> slangasek: does the plymouth bzr head package work for you? I do get a splash screen, but it looks very ugly (jittery font)
[13:35] <ari-tczew> how long process backport?
[13:35]  * ogra_ac glares at his local shadow build 
[13:35] <ogra_ac> yacc   getdate.y
[13:35] <ogra_ac> /bin/bash: yacc: Kommando nicht gefunden.
[13:35] <ogra_ac> why the heck isnt yacc in the build deps if its used by the build
[13:36] <ogra_ac> is yacc pulled in by anything in debian we dont ?
[13:47] <pitti> ogra_ac: that doesn't matter, though; if shadow uses yacc by itself, it needs to b-dep on it, regardless of transitive build deps
[13:47] <pitti> ogra_ac: which is to say, if it doesn't, that's a bug in Debian as well
[13:48] <ogra_ac> well, i dont think that was added recently
[13:48] <ogra_ac> and it built before
[13:48] <ogra_ac> also we have the same deps as debian and it seems to have built there too
[13:51] <soren> ogra_ac: Build logs for shadow in maverick don't mention yacc.
[13:51] <soren> ogra_ac: Or bison, for that matter.
[13:51] <pitti> ogra_ac: does the source already ship the preprocessed yacc output?
[13:51] <pitti> ogra_ac: might be a race condition when the .y gets patched, and thus gets newer than the output
[13:53] <ogra_ac> pitti, ah, that might be
[13:55] <ogra_ac> hmm, though no patch touches getdate
[14:12] <geser> cjwatson: as bug 681535 is "Fix committed", should I check the patch to confirm that it fixes my grub problem?
[14:18] <cjwatson> geser: feel free, or I'll upload it later this afternoon
[14:19] <cjwatson> I'm pretty sure it does - I mimicked the setup you described and encountered a bug which was at the very least extremely similar
[14:30] <cjwatson> geser: do keep the md lines out of device.map though
[14:31] <geser> sure, as you said that the md lines got there by error, I removed them from device.map and kept only those for my harddisks
[14:31] <cjwatson> *nod*
[14:32] <geser> I'll check if booting from my usb-stick still works before upgrading grub again :)
[14:34] <cjwatson> geser: the patch in bzr may not fix it on its own, of course - there was another patch I committed upstream, plus a postinst patch committed to Debian to avoid a spurious question
[14:34] <cjwatson> geser: I'm merging all of that together for the next upload
[14:37] <geser> ok, I'll wait on your upload then
[14:39] <cjwatson> geser: source uploaded now
[14:45] <ogra_ac> hmpf
[14:45] <ogra_ac> debian touched the file but doesnt run yacc during build
[14:45] <ogra_ac> we didnt touch the same file but yacc is executed
[14:45]  * ogra_ac doesnt get that
[14:56] <pitti> tseliot: can you handle bug 639976? it's a trivial change, but I can't commit to your git
[14:57]  * tseliot has a look
[14:57] <ogra_ac> grrr, ok. yacc is not executed on x86
[14:58] <tseliot> pitti: sure, I'll do it now
[14:58] <pitti> tseliot: (no upload required for that, just to not forget it); thanks!
[14:58] <tseliot> pitti: right, I'll just commit it in git, in case I forget
[15:07] <pitti> dholbach: I like the slope of the first graph at http://reports.qa.ubuntu.com/reports/sponsoring-stats/ since we started this pilot thing ;)
[15:08] <dholbach> pitti, same here :)
[15:08] <dholbach> it's awesome
[15:08] <dholbach> once we're done with that, there's still 2000 bugs with patches in LP :-P
[15:09] <sladen> pitti: do you have a tag for  installed-footprint  opportunities and  cd-size  opportunities?
[15:09] <pitti> sladen: I don't; feel free to invent one :)
[15:11] <geser> cjwatson: thanks, the new grub version installs and boots without problems
[15:11] <hallyn> all right is there any text-based browserthat works right with lp+openid?
[15:12] <dholbach> w3m?
[15:12] <geser> there was one: elinks or links if I remember correctly
[15:12] <hallyn> lynx gives me an infinite loop,
[15:12] <hallyn> i thought elinks had failed me, but i'll re-try hat i guess
[15:13] <hallyn> think i tried w3m in prague, but wth i'll try again
[15:15] <hallyn> w3m won't show me the 'submit' button at lp login
[15:16] <hallyn> elinks just clears the form and asks me to fill it back in
[15:18] <geser> see bug 628755 for the w3m issue which got fixed for natty
[15:18] <bdrung> wow, the sponsor queue gets smaller!
[15:19] <ari-tczew> yes, I agreed. today work is very good. thanks for pitti!
[15:19] <ari-tczew> maybe pitti should be patch pilot more frequently?
[15:19] <pitti> it wasn't just me :)
[15:20] <pitti> we have had patch pilots every day now
[15:20] <hallyn> geser: interesting, thanks.  so if i update that one to natty i could do it :)
[15:20] <ari-tczew> pitti: but your activities are strong because you have expierence and knowledge with handling SRUs
[15:22] <geser> hallyn: perhaps; there also some other bugs about cookies, LP and text-browsers: e.g. bug 535456
[15:23] <geser> just try every text-browser out till you find one that works
[15:23] <hallyn> geser: well i've just tried lynx, elinks, and w3m, so think i'm resorting to install vnc+fvwm+firefox :(
[15:24] <quadrispro> pitti, 40-usb-media-player.rules and 45-libmtp8.rules share several device IDs
[15:24] <pitti> quadrispro: some devices offer both access modes
[15:25] <quadrispro> so this is not a problem, isn't it?
[15:26] <pitti> quadrispro: well, it means that the ="1" tagged ones will overwrite the ones in media-player-info
[15:26] <pitti> quadrispro: ideally we could move libmtp rules before m-p-i rules
[15:27] <pitti> then the hand-maintained mpi ones could fine-tune/override the autogenerated mtp ones as needed
[15:29] <quadrispro> yep, I've written a small script to calculate differences between the two rules and so, what should we do to re-order them without introducing regressions?
[15:32] <pitti> quadrispro: well, either move libmtp to 40-* (which would be more adhering to the current convention), or move m-p-i rules to 50-*
[15:32] <pitti> or rather 46-*
[15:33] <pitti> @pilot out
[15:34] <pitti> now, 19 sponsoring items less :)
[15:34] <dholbach> yeeeeeeeeeeeeehaw
[15:34]  * dholbach hugs pitti
[15:34]  * pitti hugs dholbach for his perseverance
[15:34] <ogra_ac> but you could at least properly land the plane before jumping off :P
[15:34] <ogra_ac> poor passengers
[15:34] <pitti> dholbach: I have to admit it does work better if you have a schedule and a solid block, instead of this fuzzy "one hour a week"
[15:35] <quadrispro> pitti, yep, it was clear :) sorry, my wrong question, 2nd attempt: what should we do *before* re-arranging them?
[15:35] <pitti> ogra_ac: this is Unix. 90% solutions are okay!
[15:35] <pitti> *cough*
[15:35] <dholbach> pitti, now we need just more people on the schedule :)
[15:35] <pitti> quadrispro: if we swap their order, I think the mtp change is just fine
[15:35]  * quadrispro hugs dholbach 
[15:35] <ogra_ac> pitti, dholbach, though a proper gmail schedule you can subscribe to for reminders would be a lot better
[15:35]  * dholbach hugs quadrispro back
[15:35] <pitti> ogra_ac: I just added my days to my calendar
[15:35] <dholbach> pitti++ :)
[15:36]  * ogra_ac isnt sure he will remember in two months when exactly his pilot days are
[15:36] <ogra_ac> pitti, well, i'd like an automatic reminder
[15:36] <dholbach> and there's people in the community who don't use gmail
[15:36] <ari-tczew> dholbach: can we order pitti more frequently as patch pilot?
[15:36] <ogra_ac> without having to add it every month
[15:36] <ogra_ac> because i will surely forget to over time
[15:36] <hallyn> where *is* the schedule again?
[15:37] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Schedule
[15:37] <pitti> ari-tczew: well, it's not like I've not done sponsoring before; I do that every other day (just not that intense)
[15:37] <pitti> I think the point of this is to spread it to more people :)
[15:37] <pitti> ari-tczew: also, it seems that I got signed up for Jan 3 and 10
[15:37] <hallyn> thanks!
[15:37] <pitti> dholbach: ^ :)
[15:38] <ari-tczew> with that strong I believe that we get clean sponsors queue before FeatureFreeze
[15:38] <pitti> (but that's ok)
[15:38] <dholbach> pitti, it wasn't me!
[15:38] <ari-tczew> pitti: I mean not only done clean today by you. I include feedback from our today cooperation.
[15:39] <dholbach> I suspect a copying mistake, let me fix it
[15:41] <geser> ogra_ac: I assume those with sponsoring items in the queue will remind you when it's your time to fly :)
[15:42] <ogra_ac> geser, well
[15:51] <bdrung> ebroder: around? i need your help for bug #681242.
[15:52] <bdrung> ebroder: i need a sbuild equivalent for "sudo", "-E", "DIST=" + dist, "pbuilder", "--build", "--distribution", dist, "--buildresult", result_directory, "--architecture", self.architecture, dsc_file
[15:53] <hyperair> result_directory is pwd, so i reckon you could chdir
[15:53] <hyperair> otherwise there's sbuild -d $distribution-$architecture $dsc_file
[15:54] <hyperair> bdrung: ^
[15:55] <dholbach> holy cow
[15:55] <dholbach> we're at 14 sponsoring items
[15:55] <dholbach> erm
[15:55] <dholbach> 44
[15:55] <dholbach> 44°
[15:55] <dholbach> 44!
[15:55]  * dholbach is a happy man
[15:56] <soren> Wow! 44! That like 2658271574788448768043625811014615890319638528000000000!
[15:56] <soren> That's just crazy.
[15:56] <dholbach> we were over 100 consistantly for a long time before :)
[15:57] <dholbach> ... in case my excitement is not understandable :)
[15:57] <soren> 44! = 2658271574788448768043625811014615890319638528000000000
[15:57] <bdrung> hyperair: -d $distribution-$architecture? really?
[15:57] <ttx> dholbach: would be better if you had 42. Let me see what I can do to fix that.
[15:57]  * dholbach hugs ttx
[15:57] <dholbach> :)
[15:57]  * dholbach hugs soren too
[15:57] <hyperair> bdrung: yep.
[15:57]  * soren hugs dholbach back
[15:57] <ttx> dholbach: my sbuild is a bit stuck in openldap tests for an update that pitti asked for, though :)
[15:58] <bdrung> soren: 2658271574788448768043625811014615890319638528000000000! != 44!
[15:58] <hyperair> bdrung: if you omit -$arch, then it defaults to uname -m
[15:58] <hyperair> er i mean whatever architecture you're using, in dpkg's arch format
[15:58] <mvo> dholbach: \o/
[15:58] <geser> ttx: hopefully nobody sabotage you by adding items to queue
[15:58] <soren> bdrung: Very much not equal, no.
[15:59] <soren> bdrung: *My* "!" was an exclamation point, not the factorial operator. Clearly :)
[15:59] <ttx> 46
[15:59] <ttx> geser: stop that !
[15:59] <soren> ttx: You did it wrong.
[16:03] <geser> dholbach: http://interfacelift.com/wallpaper_beta/D0eee69d/02430_hugme_2560x1600.jpg :)
[16:03] <dholbach> File Not Found
[16:04] <dholbach> Error 404.
[16:05] <geser> hmm, works here
[16:05] <dholbach> no, sorry - not here :/
[16:07] <bdrung> hyperair: does this command work too: "sudo", "sbuild", "-A", "--dist=" + dist, "--arch=" + self.architecture, dsc_file
[16:08] <hyperair> bdrung: i'd avoid the sudo. sbuild doesn't need it.
[16:08] <bdrung> k
[16:08] <hyperair> -A, --arch-all
[16:08] <hyperair> bdrung: ^^ got that from manpage
[16:08] <hyperair> and --dist= works, yeah
[16:09] <bdrung> hyperair: do you have time to test sbuild with sponsor-patch?
[16:10] <hyperair> bdrung: mm give me a quick test case
[16:10] <bdrung> hyperair: sponsor-patch -B sbuild -b 681418
[16:11] <hyperair> bdrung: do i need to patch sponsor-patch first?
[16:11] <bdrung> hyperair: you need to pull the latest u-d-t branch and apply http://pastebin.com/rA3ZpysD
[16:11] <hyperair> bdrung: what's that in bzrfu
[16:11] <bdrung> bzr pull lp:ubuntu-dev-tools
[16:11] <hyperair> i suppose i'll need to branch
[16:11] <bdrung> patch -p0 < patchfile
[16:12] <bdrung> hyperair: yes (branch)
[16:12] <hyperair> okay
[16:14] <bdrung> tumbleweed: you fail with wrapping. please split "paragraph["Architecture"] = " ".join( sorted(archs, key=lambda x: (1 - int("any" in x), x)))" into two commands
[16:15] <bdrung> tumbleweed: what's that for: lambda x: (1 - int("any" in x), x)? please comment it
[16:15] <tumbleweed> right, to put wildcards first
[16:15] <bdrung> tumbleweed: wildcards? like what?
[16:16] <tumbleweed> linx-any
[16:16] <hyperair> bdrung: ..
[16:16] <hyperair> patching file sponsor-patch
[16:16] <hyperair> patch unexpectedly ends in middle of line
[16:16] <bdrung> tumbleweed: ah, ok. please comment that and maybe add an example
[16:16] <hyperair> patch: **** malformed patch at line 145:
[16:17] <hyperair> bdrung: could you use paste.debian.net? it's much more patch friendly.
[16:17] <hyperair> bdrung: i aliased my pastebinit away from pastebin.com precisely for that reason
[16:18] <bdrung> hyperair: gimme your alias
[16:18] <hyperair> alias pastebinit='pastebinit -b http://paste.debian.net'
[16:18] <bdrung> hyperair: there you are:
[16:18] <bdrung> http://paste.debian.net/100818/
[16:18] <hyperair> thanks
[16:19] <hyperair> and there we go, it works
[16:19] <stgraber> you can also store a configuration file in your home directory ;)
[16:19] <hyperair> now then.. where was that command..
[16:20] <hyperair>   File "./sponsor-patch", line 812, in <module>
[16:20] <hyperair> NameError: name 'Sbuild' is not defined
[16:20] <bdrung> ./sponsor-patch -B sbuild -b 681418 -v
[16:20] <hyperair> same thing
[16:20] <stgraber> bdrung, hyperair: http://paste.ubuntu.com/536749/ (~/.pastebinit.xml)
[16:21] <hyperair> stgraber: hmm nice.
[16:21] <hyperair> stgraber: but i don't like paste.ubuntu.com either, because you need to log in in order to download. makes it *extremely* annoying.
[16:21] <hyperair> stgraber: if you know who maintains paste.ubuntu.com, please relay my message.
[16:21] <bdrung> hyperair: http://paste.debian.net/100819/
[16:22] <stgraber> hyperair: I'd guess #canonical-sysadmin. Obviously you can have your .pastebinit.xml file to point to paste.debian.net
[16:22] <hyperair> stgraber: yeah, i'll do that
[16:22] <bdrung> pastebinit lacks an killer feature - autodetecting file type
[16:23] <stgraber> bdrung: patches are welcome :) I remember a few people asking me for that feature though I usually only spend 30min to an hour a year working on pastebinit :)
[16:23] <hyperair> bdrung: actually, even if you told it that you were uploading a patch, those @@'s get stripped. stupid thing.
[16:23] <stgraber> (and that's mostly reviewing patches, merging, testing and pushing to the archive)
[16:24] <hyperair> bdrung: with pastebin.com, you'd be better off base64enc'ing everything before pasting
[16:25] <bdrung> hyperair: i prefer paste.d.o anyway
[16:26] <hyperair> .n
[16:28] <hyperair> bdrung: okay, sponsor-patch keeps failing at debsign.
[16:28] <bdrung> hyperair: add a -k option
[16:29] <hyperair> ok
[16:32] <cjwatson> geser: excellent, thanks for confirming
[16:35] <hyperair> bdrung: okay, it's building. should i get worried now about it accidentally uploading a package or will it prompt me again?
[16:38] <ebroder> bdrung: ["sbuild", "-d", dist, "--arch", self.architecture, "-A", dsc_file]. But I don't see a way to change the output directory, so you might have to play with your working dir
[16:39] <hyperair> ebroder: http://paste.debian.net/100819/
[16:39] <hyperair> ebroder: all done.
[16:39] <hyperair> bdrung: and it works =)
[16:39] <hyperair> bdrung: it ends at lintian. i assume that's correct?
[16:40] <ebroder> hyperair: Yeah, noticed as I was finishing my scrolling
[16:40] <ebroder> hyperair, bdring: You guys know that subprocess.call has a cwd= kwarg, right?
[16:41]  * hyperair didn't have any part in modifying that patch
[16:42] <ebroder> bdrung: Looks fine. Are you sure dsc_file is going to be an absolute pth? I don't have the code in front of me, just the patch, so I don't know if I'm missing something
[16:43] <ebroder> pitti: Congratulations. Way to kick ass on piloting
[16:44] <pitti> thanks :)
[16:53] <ebroder> xnox: If you're going to fix xiphos through Debian, should I reject your merge proposal?
[17:16] <mpt> I wonder if the people who use Ubuntu in Occitan wish that we didn't call it "Occitan (post 1500)"
[17:18] <ebroder> Haha. Do we call our Hellenic language "Modern Greek" as well?
[17:34] <bdrung> hyperair: yes, it ends with lintian. can you try the same with "-u ubuntu" (and say no if you get ask if you want to upload it)?
[17:34] <bdrung> ebroder: yes, it uses absolute paths
[17:54] <cjwatson> NCommander: AFAICS your last cdimage change has the net effect of not only stopping building ubuntu-netbook for armel+dove, but starting to build it again for i386 (due to the later wildcard).  Was this intentional?  if not, ubuntu-netbook/daily-live needs to be removed from the crontab if it isn't supposed to build for anything
[17:56] <doko> JamesPage: could you have a look at http://people.canonical.com/~ubuntu-archive/component-mismatches.txt for the java stuff (the ones wanting to promote to main)?
[18:34] <hyperair> bdrung: erm it says [Y/e/n]. what's e?
[18:34] <bdrung> hyperair: edit
[18:35] <hyperair> ah
[18:35] <hyperair> bdrung: you should add a ? option to expand these things.
[18:35] <hyperair> it's not particularly verbose there
[18:35] <hyperair> i don't believe it's documented anywhere either
[18:36] <bdrung> hyperair: file a bug. if you type something else, it will print: "Please answer the question with yes, edit, or no."
[18:36]  * hyperair has exams and is lazy to file bugs. >_>
[18:38] <bdrung> hyperair: look in the man page: "the user has an option to edit the patched source and try  building  it again."
[18:38] <hyperair> ah okay, i missed that
[19:34] <SeanInSeattle> Hey all.  Can anyone tell me whether or not the following functionality is slated to be included in a future and/or current release of Ubuntu:  When a laptop is disconnected from any, or is connected to one or more, external monitors is updates the nvidia/x configuration accordingly?
[20:03] <RoAkSoAx> kirkland: ping
[21:51] <JamesPage> doko: ack; will pickup first thing monday
[23:02] <psusi> pitti, you mentioned about basing off the new rev in debian ( of lvm2 ).  Are you saying I should do a merge from the debian branch first, and THEN update to the new upstream?
[23:03] <psusi> ahh, there's the debian bzr branch... hrm... now which one?  squeeze or sid?
[23:05] <ebroder> psusi: Yes, that's definitely what you should be doing
[23:06] <psusi> hrm.... ok...
[23:13] <psusi> aw geeze... the debian package has the wrong version number
[23:13] <psusi> lvm2 (2.02.66-3) by  Bastian Blank says:  Bastian Blank
[23:13] <psusi> bah... Import upstream version 2.02.72:
[23:14] <psusi> he forgot to bump the package revision number