[04:32] <bzoltan> is here anybody who knows (remembers) how to convince mako to keep adb available even when the screen is locked? Flashing the latest rc-proposed + touching /userdata/.adb_onlock does not make it.
[04:32] <bzoltan> robru: ^
[04:34] <robru> Uhhh
[04:35] <robru> bzoltan: i dunno. Maybe jibel or fginther might know more about the device side.
[04:37] <bzoltan> robru: thank you.. hopefully someone can help.. it would be nice to put my mako back to work as contnious testing agent ...
[04:38] <bzoltan> I remember ogra mentioned that we might need a special firmware for this... but not sure
[04:39] <robru> bzoltan: maybe ask cihelp if they can share the secret of how they test with devices.
[04:40] <bzoltan> robru: for Mirv it works
[04:41] <Mirv> yeah for some reason I don't have that problem, and I've been flashing a lot again now this week.
[04:41] <robru> bzoltan: Mirv should be around soon
[04:43] <bzoltan> robru:  he is :) already
[05:13] <iahmad> evanwang, ping
[05:13] <evanwang> iahmad, pong
[05:20] <evanwang> iahmad, failed to connect canonical irc server from our site, how is the connection from you site?
[05:20] <iahmad> evanwang, working for me
[05:21] <evanwang> iahmad, seems something wrong at our site :(
[06:09] <bzoltan> robru: Mirv: this failure seems to be serious -> https://launchpadlibrarian.net/218108553/buildlog_ubuntu-wily-amd64.ubuntu-ui-toolkit_1.3.1639%2B15.10.20150916.2-0ubuntu1_BUILDING.txt.gz  "/usr/bin/ld.gold: --push-state: unknown option"
[06:10] <Mirv> bzoltan: FYI robert is on vacation
[06:11] <Mirv> bzoltan: eh..
[06:11] <bzoltan> Mirv:  ohh... i am sorry robru
[06:12] <Mirv> bzoltan: I have never seen that
[06:12] <bzoltan> Mirv:  me neither... it is new to me
[06:16] <Mirv> let's see if anyone else has that on devel
[07:20] <dbarth> mardy: hi
[07:21] <dbarth> mardy: about facebook, i think the solution is to get a pro account
[07:21] <mardy> dbarth: hi!
[07:21] <mardy> dbarth: let's wait a bit, I'm discussing the issue in the forums
[07:21] <dbarth> mardy: i saw a link that offers to go pro, and then you get an "account manager", ie a human, to help with the review
[07:21] <dbarth> ah, do you?
[07:21] <dbarth> do you have a pointer, are they replying ?
[07:22] <mardy> dbarth: some users are replying, but I believe that one might actually be a facebook employee
[07:22] <mardy> dbarth: https://www.facebook.com/groups/fbdevelopers/
[07:40] <dbarth> mardy: i can't find the link to that pro contact, as it was linked from the failed review page
[07:41] <mardy> dbarth: yes, it disappeared. But let's wait for the results of this review
[07:42] <sil2100> pete-woods: hey! Did you manage to test the package from the silo I pasted yesterday? :)
[07:43] <dbarth> mardy: but if next time it fails please keep it as is, and we will check that path
[07:44] <pete-woods> sil2100: sorry, I didn't read my scrollback
[07:44] <pete-woods> will have a look now
[07:44] <mardy> dbarth: ok
[07:45] <pete-woods> sil2100: just snapshotting the VM now
[07:45] <sil2100> Thanks :) I doubt this will work, but at least we'll know that the latest is needed
[07:46] <pete-woods> asdas
[07:46] <pete-woods> whoops
[07:46] <pete-woods> that's fine
[07:46] <pete-woods> happy to do exploratory testing of it
[07:58] <pete-woods> sil2100: the PPA seems to fix the problem! :)
[08:00] <sil2100> pete-woods: uh oh!
[08:00] <sil2100> Who would have thought, a no-change rebuild
[08:00] <pete-woods> sil2100: is that a bad thing?
[08:00] <sil2100> pete-woods: it's good, just didn't expect that ;p
[08:01] <sil2100> Let me copy it to the overlay then
[08:03] <pete-woods> thanks
[08:22] <bzoltan> Mirv: ehh... 2015-09-17 08:19:47,420 ERROR dch: fatal error at line 1141:
[08:22] <bzoltan> New version specified (1.3.1639+15.04.20150917-0ubuntu1) is less than
[08:22] <bzoltan> the current version number (1.3.1639+15.10.20150916-0ubuntu1)!  Use -b to force.
[08:23] <sil2100> bzoltan: yeah, that happens when you want to turn a wily trunk into a vivid one - what do you want to release exactly?
[08:23] <bzoltan> sil2100:  I want a dual landing like normally.. but wily is blocked so I could settle with a vivid only
[08:24] <Saviq> cihelp, hey, it looks like unity8's autopilot on wily/mako is busted, ENOSPC when installing dependencies http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-wily-mako/380/console
[08:27] <Mirv> sil2100: there's a bug #1496743 introduced by new GCC 5 in wily, not sure how it should be fixed
[08:29] <psivaa> Saviq: I dont think i saw this on Mako before,  would need to take a closer look. How urgent is this?
[08:29] <psivaa> i.e. can this wait until late this afternoon?
[08:29] <Saviq> psivaa, yeah
[08:29] <psivaa> Saviq: ack, thanks
[08:30] <Saviq> psivaa, apparently an issue for quite some time now, but we didn't pay close enough attention to wily http://s-jenkins.ubuntu-ci:8080/job/generic-deb-autopilot-runner-wily-mako/376/console
[08:30] <psivaa> Saviq: right, i see
[08:31] <psivaa> Saviq: will add this to the list. We'll look into it
[08:31] <Saviq> psivaa, thanks
[08:31] <Saviq> psivaa, likely the wily image just grew too much
[08:42] <Saviq> trainguards, can we please have publish on https://requests.ci-train.ubuntu.com/#/ticket/359 ?
[08:43] <sil2100> Saviq: on it
[08:53] <sil2100> dobey: hey! Looking at silo 29 now - did those changes land in wily already, or are there any reasons for it not to work there?
[09:04] <sil2100> ogra_: hey! :) I want to upload the new ubuntu-touch-meta source to wily that includes the new pocket-desktop seed - can I have you looking at the debdiff before I upload it?
[09:05] <ogra_> sil2100, after the mtng i'm currently in
[09:05] <sil2100> ogra_: thanks, let me prepare teh diff
[09:06] <sil2100> ogra_: the debdiff - the changes are rather straightforward: http://paste.ubuntu.com/12436400/
[09:06] <sil2100> The generated meta package has proper deps
[09:20] <ogra_> sil2100, the diff looks ok to me
[09:20] <sil2100> ogra_: thanks :)
[09:37] <Laney> is there such a thing as deleting a request?
[09:37] <Laney> (not assigned)
[09:37] <Laney> or do they just stay foreverrrrrrrr
[09:37] <sil2100> Damn, using SUBPROJECT in livecd-rootfs is soo tempting, making ubuntu-pd a separate project would mean sooo much copy & paste
[09:37] <sil2100> Laney: yeah, there's a manual method for that
[09:38] <sil2100> Laney: you edit the request and change its status manually to 'Abandoned'
[09:38] <sil2100> (that's the official way to do it)
[09:38] <Laney> which drop down has that?
[09:38]  * Laney can't find it
[09:39] <sil2100> Laney: it's the 'Status' field, no drop-down there
[09:39] <sil2100> Laney: if you hover over it it says 'Do not touch, auto updated', but that's just for already assigned silos
[09:39] <Laney> ok, I did that, thanks!
[09:39] <sil2100> yw!
[09:39] <Laney> no silos :(
[09:39] <sil2100> Oh! Let me free up mine
[09:41] <sil2100> Laney: silo 35 should be free now
[09:41] <Laney> thanks
[09:41] <sil2100> Ugh, that's a bug that needs to be fixed ^
[09:41] <Laney> it's like building more roads eh
[09:42] <Laney> seb128: on the no free silos, the libusermetrics one failed to clean, do you know why?
[09:45] <Saviq> sil2100, I remember reading something about boot failures in wily, will the boottest failure prevent migration? http://people.canonical.com/~ubuntu-archive/proposed-migration/wily/update_excuses.html#unity8
[09:50] <seb128> Laney, no, I don't
[10:52] <sil2100> Saviq: I think it will... boottests currently are a bit a pain in the ass
[10:53] <Saviq> sil2100, how do we deal with that?
[10:53] <Saviq> FWIW the unity-scope-click tests seem to take a long time, too
[10:53] <Mirv> sil2100: any idea about the part of 029 that it claims it requires qtmir from 027 but davmor2 approved 029 anyway so apparently nothing hugely crashy?
[10:54] <sil2100> Mirv: not sure, I was waiting for dobey to comment on this landing, since I didn't know if the same things landed in wily already or not
[10:54] <sil2100> Mirv: btw. do you have power to re-run boottests?
[10:54] <sil2100> Saviq: I think this requires cihelp, but from what I know currently boottests are unmaintained really ;/
[10:57] <psivaa> sil2100: Saviq: Which job is this?
[10:57] <Mirv> sil2100: yes, just give me boottest urls
[10:57] <psivaa> or package
[10:57] <Saviq> psivaa, unity8
[10:57] <Saviq> psivaa, http://people.canonical.com/~ubuntu-archive/proposed-migration/wily/update_excuses.html#unity8
[10:57] <Mirv> sil2100: but some of them are pretty permanently failing (lately) so needs psivaa anyway
[10:59] <psivaa> Saviq: i've kicked this off again, and watch it
[10:59] <Saviq> psivaa, thanks
[11:01] <psivaa> Saviq: Sorry for this long txt, regarding previous failure:
[11:01] <psivaa> "Tested this manually and found that the UI does not come up when testing unity8. The device is accessible via 'adb shell' so it does pass the basic boottest requirement, it's just failing on the adt-run check for a working UI.
[11:01] <psivaa> The device did come up fully when the rest of the silo containing unity8 was installed. This points to a missing dependency. I discussed this with the unity8 team and this was expected and the silo will all be promoted together."
[11:02] <davmor2> Mirv: I can look at 27 now but everything worked like it has before.
[11:04] <Saviq> psivaa, I think this was resolved by now
[11:04] <psivaa> Saviq: ack, let me see if the rerun works
[11:07] <Saviq> psivaa, btw, (where) can I monitor adt runs in progress? like the unity-scope-click ones from http://people.canonical.com/~ubuntu-archive/proposed-migration/wily/update_excuses.html#unity8
[11:08] <Mirv> davmor2: ok. it's not yet set ready for QA though.
[11:08] <Mirv> davmor2: oh, it is, sorry
[11:08] <psivaa> Saviq: http://d-jenkins.ubuntu-ci:8080/view/Wily/view/BootTest/job/wily-boottest-unity8/23/console, but this would not show anything until the job actually finishes
[11:08] <rvr> abeato: ping
[11:09] <davmor2> Mirv: its' in our queue :P
[11:09] <abeato> rvr, pong
[11:09] <rvr> abeato: Regarding the failures...
[11:09] <rvr> abeato: Can you confirm they work well in your case?
[11:10] <abeato> rvr, call forwarding works fine for pepephone
[11:10] <rvr> abeato: I also had problems with USSD
[11:11] <abeato> rvr, hmm, I tried some ussd strings for vodafone and all looked one
[11:11] <abeato> *good
[11:11] <abeato> rvr, what failed?
[11:12] <rvr> abeato: The first case of the test plan
[11:13] <rvr> abeato: I got an unsupported error
[11:13] <abeato> rvr, which ussd string and which operator?
[11:15] <rvr> abeato: Yoigo
[11:15] <rvr> abeato: “*118#”
[11:17] <abeato> rvr, ussd strings are operator-specific, “*118#” works only for vodafone (ES), I'll make that more explicit in the test
[11:17] <rvr> abeato: Ahh
[11:18] <rvr> abeato: Ok, I see... googling for yoigo's ones
[11:19] <Saviq> psivaa, that's only boottest, how about the package ones?
[11:19] <psivaa> Saviq: you mean 'autopkgtest' ?
[11:20] <Saviq> psivaa, yeah, like unity8 is waiting for unity-scope-click results for a few hours now
[11:20] <psivaa> if that's the case that's now handled by the release team, I think.
[11:20] <Saviq> wanted to check what's going on
[11:20] <Saviq> right
[11:20] <abeato> rvr, if you find something for yoigo please add that to the test case
[11:21] <abeato> rvr, note that ussd codes are for services like asking your balance, data consumed,etc. some time operators use different means for that (say, sms), so maybe yoigo does not have ussd strings
[11:39]  * sil2100 jumps out for some lunch groceries
[11:49] <rvr> abeato: send-ussd "*111#" dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "GetProperties" with signature "" on interface "org.ofono.SupplementaryServices" doesn't exist
[11:50] <abeato> rvr, is that krillin
[11:50] <abeato> ?
[11:50] <abeato> rvr, if that's the case try "send-ussd  /ril_0  "*111#""
[11:52] <rvr> abeato: Yes, krillin
[11:52] <rvr> It worked... somehow USSD: Yoigo Info: Este servicio no esta disponible para clientes de contrato.
[12:02] <rvr> Google results are crappy lately
[12:17] <rvr> abeato: I can't check the USSD menu test, and "3. Receive a USSD notification" fails for me
[12:17] <rvr> abeato: I don't see "{SupplementaryServices} [/ril_0] NotificationReceived" in the logs
[13:14] <abeato> rvr, in krillin you need to specify which modem slot to use when executing the script, that's why you need either /ril_0 or /ril_1 as argument
[13:15] <dobey> sil2100: hmm?
[13:15] <abeato> rvr, for the third test you need an operator that provides those notifications, again, that's operator specific
[13:15] <abeato> rvr, and that's not very common, I know only Tesco UK as an operator that does that
[13:16] <dobey> sil2100: what's the problem with 29?
[13:19] <dobey> sil2100: anyway, yes, the changes there are already in wily
[13:20] <sil2100> dobey: excellent
[13:20] <sil2100> That's what I wanted to know
[13:21] <Saviq> psivaa, any word on the boottest? and any idea who can I ask about autopkgtests?
[13:23] <sil2100> ogra_: heeeey, I know you're probably super busy as always, but - could you maybe take a look at this merge? :) https://code.launchpad.net/~sil2100/livecd-rootfs/pocket-desktop/+merge/271448
[13:24] <sil2100> ogra_: I know I'm pushing on this subproject idea a bit too much, I can seriously change that to a separate project, just want to know if there are any objections to do it this way - as the change now is only 3 lines
[13:31] <psivaa> Saviq: still looking at the boottest issue
[13:32] <psivaa> afaik, pitti was handling the autopkgtests
[13:37] <pstolowski> hey trainguards, any idea what's wrong with silo 35 - https://ci-train.ubuntu.com/job/ubuntu-landing-035-1-build/55/console ?
[13:39] <sil2100> pstolowski: hmm, strange, looks like there's a problem with dh, even though I see it in the Build-Depends
[13:41] <sil2100> pstolowski: ah, maybe the change wasn't there when the silo was built?
[13:41] <sil2100> pstolowski: since I don't see the train installing debhelper
[13:44] <pstolowski> sil2100, no, debhelper was definately there. note however that i'm testing some crazy stuff in this silo (control file is re-generated from control.in)
[13:45] <pstolowski> let me try to rebuild just in case
[13:49] <sil2100> kenvandine: hey! Could you take care of https://ci-train.ubuntu.com/job/ubuntu-landing-029-2-publish/45/ ? I have no power here ;)
[13:51] <pstolowski> sil2100, hmm, failed, debhelper should be installed, see the MP https://code.launchpad.net/~stolowski/unity-scopes-shell/singletree/+merge/271314
[13:51] <kenvandine> sil2100, sure
[13:51] <sil2100> kenvandine: thanks :)
[13:53] <sil2100> pstolowski: interesting... it seems as if the train is unable to find any build deps
[13:53] <sil2100> Let me check this locally here
[13:58] <pstolowski> sil2100, we did same trick in singletree branch of unity-scopes-api, and it worked
[14:05] <kenvandine> sil2100, exception while publishing
[14:11] <sil2100> pstolowski: indeed, so far everything looks fine, but somehow it's not resolving the missing build-deps
[14:11] <sil2100> kenvandine: ouch
[14:13] <rvr> awe_: abeato: Approving the silo
[14:14] <awe_> thanks rvr!
[14:14] <abeato> rvr, \o/ thanks
[14:19] <kenvandine> sil2100, let me know if you need me to try to publish that again
[14:23] <sil2100> kenvandine: thanks, I see the packages have reached the destination so I just merge&cleaned it
[14:23] <kenvandine> oh, cool
[14:28] <dbarth> hey there, i can't find that in the faq, but is there a quick way to force rebuild a package in a silo from bileto?
[14:28] <dbarth> ie, i would do a null merge-proposal or something, but is there something cleaner
[14:28] <dbarth> this is to get a new build of a webapp-container, with the newer platform-api lib we have in a silo
[14:36] <sil2100> dbarth: I think the no-change MP is the fastest, not counting poking someone to prepare the package manually ;)
[14:37] <dbarth> aye aye sir
[14:49] <dbarth> gnn
[15:00] <pstolowski> sil2100, is "debconf: delaying package configuration, since apt-utils is not installed" relevant for that failure in silo 35?
[15:25] <pstolowski> sil2100, btw, any news on silo 10? can we get somebody to push the magic button? ;) we need to that in asap, it's blocking other stuff...
[15:26] <sil2100> pstolowski: poking!
[15:59] <fginther> Saviq, hello, any suggestions on the unity8 wily phone test running out of space?
[15:59] <Saviq> fginther, only thing I can think of is that the wily image grew too much for the unity8 autopilot dependencies to fit on top
[16:01] <fginther> Saviq, that's what I thought too. I don't know if there is anything we can do in CI to make this work... I think we just need a resized or cleaned up image
[16:01] <Saviq> fginther, yeah most likely, we need a bug and some investigation to happen
[16:02] <fginther> Saviq, If the test is of no use, can we disable it for now to free up the resources?
[16:02] <Saviq> fginther, let me just confirm this is what's happening
[16:03] <fginther> Saviq, thanks
[16:03] <jibel> sil2100, is there a landing meeting?
[16:04] <davmor2> sil2100: popey meeting????
[16:04] <sil2100> Oh crap!
[16:04] <sil2100> Be right there
[16:04] <Saviq> I've 500MB free on a freshly installed wily (dual booted, though)
[16:07] <psivaa> Saviq: btw, http://people.canonical.com/~ubuntu-archive/proposed-migration/wily/update_excuses.html#unity8 is not having boottest PASS.
[16:15] <Saviq> psivaa, "now" you meant? thanks, anything we should do or is this going to be better now?
[16:16] <Saviq> now, in absence of pitti, who can help with autopkgtests being stuck in "Test in progress" for the whole day? :/
[16:17] <psivaa> Saviq: yes, 'now'. Sorry finger memory.
[16:17] <fginther> Saviq, I think psivaa meant "now" (as it does show a PASS)
[16:18] <psivaa> Saviq: this unity8 failure is tricky, as we're testing with an older image (191). With the latest one the provisioning is not very complete
[16:19] <Saviq> fginther, "75 upgraded, 127 newly installed, 6 to remove and 412 not upgraded.
[16:19] <Saviq> Need to get 150 MB/168 MB of archives.
[16:19] <Saviq> After this operation, 577 MB of additional disk space will be used.", there's less than .5GB free on wily
[16:19] <Saviq> fginther, I wonder why that list is so big...
[16:20] <Saviq> like g++, really?
[16:20] <Saviq> looks like unity-scope-tool has excessive deps
[16:21] <Saviq> let's see if we can drop that, and/or fix it
[16:21] <sil2100> seb128: hey! Did you get any news regarding the libusermetrics regression?
[16:22] <greyback_> trainguards: any reason silo27 hasn't been landed? QA was granted.
[16:24] <sil2100> greyback_: will land in a minute if possible, just still working on something
[16:24] <greyback_> sil2100: no biggie, just curious
[16:35] <seb128> sil2100, there is a fix approved on https://code.launchpad.net/~mterry/unity8/handle-empty-infographic-label/+merge/271479
[16:35] <sil2100> seb128: would it be able to land today?
[16:40] <seb128> sil2100, don't ask me, I'm not maintaining unity8
[16:40] <seb128> Saviq & co probably know?
[16:40] <sil2100> seb128: ok, thanks for the info ;)
[16:40] <sil2100> Saviq: hey!
[16:41] <seb128> yw
[16:41] <Saviq> sil2100, here, whatup?
[16:41] <sil2100> Saviq: any ETA on mterry's branch ^ to land? :)
[16:42] <sil2100> The one seb128 pasted above
[16:42] <Saviq> sil2100, we've an approved branch for that
[16:42] <Saviq> sil2100, we'll land soon
[16:43] <sil2100> Saviq: you know if that's possible today still?
[16:43] <Saviq> sil2100, no, we're stuck in proposed since this morning
[16:43] <Saviq> because unity-scope-click autopkgtests are endlessly In Progress
[16:43] <sil2100> Ok, so I'll soft-revert the libusermetrics landing in the overlay and then re-release once unity8 is out
[16:43] <sil2100> Uuugh
[16:47] <Saviq> fginther, ok seems we can drop unity-scope-tool, which is the reason all the packages are pulled in, from the job conf, let me try a run without it
[16:47] <Saviq> we need to fix that in any case
[16:50] <Saviq> or is there a reason why all the packages are explicitly installed?
[16:51] <Saviq> fginther, this is the stripped-down run, let's see how it goes http://s-jenkins.ubuntu-ci:8080/job/unity8-ci/6290/console
[17:02] <cjwatson> Saviq: pitti was saying earlier today that it's just processing a long queue
[17:03] <Saviq> cjwatson, anywhere we can see that?
[17:03] <cjwatson> dunno sorry
[17:06] <Saviq> tx anyway, let's hope it sorts itself out then
[17:07] <sil2100> kenvandine: could you publish the two silos that are ready for release? Those are dual silos so with th e current train bug I can't publish them...
[17:07] <sil2100> kenvandine: https://requests.ci-train.ubuntu.com/#/trainguards
[17:08] <kenvandine> sil2100, sure
[17:08] <sil2100> kenvandine: thanks :)
[17:25] <fginther> Saviq, AIRC, those were needed to make sure all of the latest test dependencies were installed. The list could easily be stale now
[17:36] <pmcgowan> silo 55 is being tested now or is it blocked still?
[18:00] <pmcgowan> silo 55 is being tested now or is it blocked still?
[18:00] <pmcgowan> davmor2, ^^
[18:01] <davmor2> pmcgowan: I will have a look at it shortly
[18:02] <pmcgowan> davmor2, cool thanks
[18:10] <pmcgowan> popey, so is there a new music app to go with that mpris silo?
[18:17] <popey> pmcgowan: there is a merge that's being worked on
[18:18] <popey> pmcgowan: issues list -> https://docs.google.com/document/d/1xzI4D6knVJ6VmXxqJ2gyGSMowbtVVoNPgQl1fywim_U/edit
[18:19] <pmcgowan> popey, those seem to be all over the stack, so wondering how silo 55 can be ready for testing
[18:19] <popey> indeed.
[18:19] <popey> this doc was collaboration between jim and ahayzen
[18:20] <popey> ahayzen: that's right, right?
[18:23] <davmor2> pmcgowan, popey: ouch, I wonder why Jim was pushing for the silo then.  Aiui this couldn't land till the ui fix was in place, that has been added to the silo this afternoon so is due a retest and this unblocked everything else then, I was not made aware of a previous issues list
[18:23] <pmcgowan> davmor2, yeah the indicator with fixes is now in the silo but does not sound readt
[18:23] <pmcgowan> ready
[18:25] <davmor2> pmcgowan: also the bulk of stuff you can't actually test due to the fact that nothing uses the playlist feature yet :(
[18:26] <pmcgowan> davmor2, should be a way to at least test the indicator and see no regressions, plus the music app
[18:27] <pmcgowan> then we can land inline playback stuff after
[18:28] <davmor2> pmcgowan: yes so the indicator works for play pause but skip back and forward just end the track/video because there is only one item in the playlist
[18:28] <pmcgowan> davmor2, seems we wait for abeato to give the all clear
[19:21] <ahayzen_> popey, yup that doc is a list tracking issues that me and jim know of between music-app/media-hub/indicator-sound
[19:22] <ahayzen_> popey, silo 55 adds MPRIS support in media-hub... and had some other improves bundled
[19:35] <popey> pmcgowan: ^
[19:39] <pmcgowan> popey, ahayzen right but not clear to me when they get addressed and we can land everything
[19:40] <ahayzen> i think Jim has been trying to iteratively land things and keep them all contained in separate silos
[19:40] <ahayzen> from our point of view the music-app is pretty close, most of the issues are with media-hub itself
[19:41] <ahayzen> or indicator-sound or whatever
[19:41] <pmcgowan> ahayzen, we have al the latest in silo 55, but it cannot land if it breaks music=app
[19:42] <ahayzen> how does it break the music-app?
[19:42] <pmcgowan> davmor2, ?
[19:43] <ahayzen> remember the current music-app in the store isn't using the bg playlists, so assuming the indicator-sound doesn't show the MPRIS controls when running with that, i don't think anything in the existing app would break?
[19:44] <pmcgowan> ahayzen, right but the goal is to enable them in the indicator
[19:44] <pmcgowan> so we can do inline playback in scopes
[19:44] <ahayzen> can it not detect when you are using playlists?
[19:45] <ahayzen> and i assume the scopes will probably have the same issues we are having in our WIP branch
[19:48] <ahayzen> IIRC 047 has just the MPRIS stuff in it as well https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-047
[19:55] <fginther> Saviq, your change to get unity8 on wily running worked, at least it was able to install and run the tests
[19:57] <fginther> Saviq, Also, for dual landing of unity-api, should we drop CI on lp:unity-api/trunk-15.04 ?
[20:26] <Saviq> fginther, yes, and yes
[20:27] <Saviq> fginther, we want dual-landing for lp:qtmir as well, so ci for it on both wily and vivid please
[20:29] <Saviq> fginther, can you please drop unity-scope-tool and indicator-client from unity8's test_packages param?
[20:42] <fginther> Saviq, yes as well. I don't see any other branches for qtmir except lp:qtmir, so nothing to remove there (which is why I only asked about unity-api)
[20:43] <fginther> Saviq, will also have the unity8 job updated shortly
[21:07] <Trevinho> We're still out of free silos?
[21:09] <Saviq> fginther, nothing to remove, but we'd also like both wily and vivid testing on them
[21:10] <fginther> Saviq, I'm setting up qtmir now. See http://s-jenkins.ubuntu-ci:8080/job/qtmir-ci/426/console for the results of testing with lp:qtmir
[21:10] <Saviq> fginther, great, thanks a lot


[03:26] <krafty> richem ping
[07:24] <ara> morning all :)
[08:58] <davmor2> ara: Morning
[08:58] <ara> morning davmor2 :-)
[08:59] <ara> is not the bad twin around today?
[08:59] <ara> davmor2: ^
[09:00] <davmor2> Not at the moment evil twin sleeps in until I'm at least testing :D
[09:22]  * ara takes a break
[12:52]  * ara -> lunch
[16:43] <davmor2> ara: are you ready for your talk :)
[16:43] <ara> davmor2: yes :-)
[16:43] <davmor2> Good :)
[17:51] <lfaraone> ogasawara: would it be sufficent to simply install the new kernel deb from jaunty, or should I just bite the bullet and repartition?
[17:58] <ogasawara> lfaraone:  if you're able to test a fully up to date Jaunty image that would be ideal, but simply installing just the new jaunty is ok (but you won't get the automated bug reporting like we discussed)
[17:58] <lfaraone> ogasawara: I'm currently trying to see if I can boot up on the liveCD using my SD card as a persistant ~, but it seems the kernel doesn't accept the "home=" parameter.
[18:02] <davmor2> nice one ara good session over all
[18:03] <ara> davmor2: thanks ;-) your my favorite student :D
[18:05] <davmor2> ara: praise will get you anywhere :)


[02:56] <qwer> anyone here know a crapload about linux drivers?
[02:58] <qwer> I'm fairly knowledgeable, but I've a problem that no on in any other channel has been able to help me solve for about 2 weeks
[03:00] <qwer> anyway, I'll just tell the story, mysteriously ubuntu 10.04 detects the sata_mv driver properly - as well as an old slackware install cd - I've tried about a dozen recent and current distros though - and even after mod probing sata_mv -> no block devices found.......I've no idea how to continue troubleshooting - I've messed with udevadm, modprobe, etc
[03:01] <hyperair> qwer: try #ubuntu-kernel. the ones knowledgable about these things reside there, usually.
[03:01] <qwer> thanks
[03:01] <qwer> #ubuntu-kernel
[03:02] <qwer> oppppps
[04:46] <wolfe> xD is there a launchpad admin around?
[04:47] <wolfe> "me too. I would also like to unsubscribe and it won't let me. PLEASE, MAKE
[04:47] <wolfe> IT STOP!
[04:47] <wolfe> "
[04:47] <persia> wolfe: You probably have the implict bug subscription issue.  But you also probably want to ask in #launchpad
[04:48] <wolfe> I'm falling out of my seat laughing at this
[04:48] <wolfe> persia: ah okay. I haven't tried to unsubscribe yet, but I'll try too
[04:54] <emgent> persia :-)
[04:56] <twb> So I am rolling lucid live images using Debian's live-helper.
[04:56] <twb> I'm a bit puzzled by the kernel making a "ramzswap" -- why is it creating virtual swap on top of ram?
[04:57] <persia> twb: live-helper is explicitly not supported by the Ubuntu installer team (last I heard).
[04:57] <persia> You *might* get some help out of #ubuntu, but I'm unsure they would have the necessary familiarity.
[04:57] <twb> Ooooooh.  Googling finds http://code.google.com/p/compcache/, which says that ramzswap is a *compressed* virtual swap
[04:58] <twb> persia: I'm asking about the kernel, not about live-helper.
[05:00] <twb> And there's an #ubuntu-kernel, so I guess I'll bug them instead.
[05:43] <crimsun> "/usr/bin/dpkg-deb: line 53: 28311 Segmentation fault      /usr/bin/pkgstriptranslations"
[05:44] <persia> extra points!
[05:44] <crimsun> on armel, nonetheless :-/
[05:44] <crimsun> (http://launchpadlibrarian.net/39501757/buildlog_ubuntu-lucid-armel.pulseaudio_1:0.9.22~0.9.21%2Bstable-queue-32-g8478-0ubuntu10_FAILEDTOBUILD.txt.gz)
[05:46] <StevenK> Ouch
[05:47] <lifeless> isn't that python?
[05:47] <StevenK> # file /usr/bin/pkgstriptranslations
[05:47] <StevenK> /usr/bin/pkgstriptranslations: Bourne-Again shell script text executable
[05:48] <lifeless> wow
[05:48] <StevenK> Ooooh, that's even more impressive
[05:56] <TheMuso> wow that is impressive.
[05:57] <StevenK> crimsun: Throw me a link to the upload page, and I'll try and build it on the porter?
[05:58] <crimsun> StevenK: meaning https://launchpad.net/ubuntu/+source/pulseaudio/1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu10 ?
[05:59] <crimsun> (or https://edge.launchpad.net/ubuntu/+source/pulseaudio/1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu10/+build/1523932)
[05:59] <StevenK> crimsun: Yeah
[05:59] <StevenK> (The former)
[07:09] <pitti> Good morning
[07:12] <lifeless> hi pitti
[07:29] <tjaalton> nice, boot hangs after one unclean shutdown
[07:29] <tjaalton> rescue doesn't work
[07:32] <Speedy2> www.search2.net
[07:34] <tjaalton> no idea what's run after mountall?
[07:34] <tjaalton> much harder to debug with upstart..
[07:39] <lifeless> pitti: I filed a bug on lp-project-upload
[07:39] <lifeless> pitti: I'd like to move it out of ubuntu-dev-tools; its not really ubuntu related ;)
[07:39] <pitti> tjaalton: what do you see?
[07:40] <pitti> lifeless: I know, but u-d-t is a kind of catch-all place for these tools
[07:40] <lifeless> pitti: but I then rewrote it from scratch anyhow :P so perhaps just nuke it now (once my lptools patch lands)
[07:40] <lifeless> pitti: 'lptools'
[07:40] <pitti> lifeless: same is true for lp-set-dup, grab-attachments, lp-shell, and whatnot
[07:40] <tjaalton> pitti: /usr being mounted
[07:40] <lifeless> pitti: for some of them, I totally agree
[07:41] <tjaalton> this worked last night when I upgraded the box
[07:41] <pitti> tjaalton: so it's not the plymouth hang yet?
[07:41] <tjaalton> but the power button didn't make acpid to shut it down (though acpi_listen showed it sending the signal), so I pulled the plug
[07:41] <tjaalton> pitti: no, it's a server install
[07:42] <tjaalton> I've disabled ureadahead and plymouth
[07:42] <tjaalton> by moving the jobs away
[07:49] <dholbach> good morning
[07:54] <tjaalton> even if I don't have splash on the kernel cmdline it loads some framebuffer module (probably vga16fb), which makes debugging even harder
[07:54] <tjaalton> since the screen is reset and previous messages are gone
[07:55] <tjaalton> so is there a way to disable that from grub?
[07:55] <tjaalton> hmm, nofb maybe
[07:56] <tjaalton> nope
[08:32] <tjaalton> oh well, got to reinstall it then..
[09:00] <poolie> pitti, hi
[09:01] <pitti> hey poolie, how are you?
[09:01] <poolie> good
[09:01] <poolie> lifeless pointed me to your lp-shell command
[09:01] <poolie> i would like to show you bugclient in lp:hydrazine
[09:01] <poolie> it gives you a specific command line interface to lp
[09:01] <poolie> rather than a python shell
[09:02] <poolie> eg you can say 'bug 123' 'triage +tags +easy confirmed medium'
[09:02] <pitti> poolie: oh, that's useful
[09:02] <poolie> i find it pretty nice
[09:02] <pitti> poolie: it seems to have quite a different purpose than lp-shell, but useful for mass bug operations
[09:02] <poolie> yes, that's true
[09:03] <poolie> it doesn't really support bulk operations atm
[09:03] <poolie> but it's pretty quick for single operations
[09:03] <lifeless> pitti: so to continue the prior conversation; how do you feel about us moving the non distro stuff to the lptools project; build an upstream there, rather than having them in ubuntu-dev-tools that is a bit more restricted for getting developers
[09:03] <lifeless> this is related to poolies hydrazine project too
[09:03]  * persia thinks this is a good idea
[09:04] <pitti> lifeless: sounds fine to me
[09:04] <pitti> u-d-tools could even recommends: lptools
[09:04] <pitti> to have the same effect
[09:04] <persia> And make the transition near-invisible for most developers.
[09:04] <lifeless> I'm going to have to apply sanity-sticks to get that project to have more committers in the short term; once thats done I'll submit a merge proposal to clear things up
[09:05] <lifeless> we do have different licences on the current code, but the sasme (C) holder. for hilarity.
[09:14] <ogra> seb128, poke ... with the last gtk upload my system started to misbehave massively, i had to downgrade libgtk2.0-2 ... did you hear complaints from anyone else ?
[09:14] <seb128> define misbehave
[09:14] <seb128> "it doesn't work"?
[09:15] <ogra> seb128, like X taking 100% CPU, evo locking up the machine, widgets in xchat's chat window start to flicker heavily, gnome-terminal flikers a lot
[09:15] <seb128> bug #523949
[09:15]  * ogra checks
[09:15] <seb128> for the cpu issue, I'm about to upload an improved version
[09:16] <seb128> dunno about the flickering
[09:16] <ogra> in xchat the separator between nicks and text (that little vertical line) gets random flickering dots ... looks like an old movie :)
[09:17] <ogra> i know jdub had similar issues ... but that bug seems to describe it, i'll try the upgrade
[09:56] <poolie> pitti, lifeless: so having one client set for launchpad is better than having many fractional-assed ones
[09:56] <pitti> poolie: depends on what you need
[09:56] <poolie> the problem is that many are just toys
[09:56] <poolie> and, right, people have different ideas of what is useful
[09:56] <pitti> poolie: the one you pointed me to is great for actually doing work in Launchpad
[09:57] <pitti> poolie: I use lp-shell for testing code snippets using launchpadlib before I put them into programs
[09:57] <poolie> where do you put them?
[09:57] <pitti> not for actually doing stuff on LP
[09:57] <pitti> poolie: apport, for example
[09:57] <pitti> or the work item tracker
[09:57] <poolie> yay apport :-)
[09:58] <qwer> Wholy fucking shit - a bios update fixed EVERYTHING! And I've been using this hardware for 4 years...
[10:04] <persia> !ohmy
[10:08] <cjwatson> I find lp-shell useful for when I'm doing odd one-off things nobody has thought to write explicit programs for yet
[11:05] <dholbach> ifupdown 0.6.8ubuntu21.1 in karmic-proposed tries to overwrite etc/init.d/networking from netbase
[11:05]  * Mamarok was going to report the same :)
[11:06] <pitti> Mamarok, dholbach: erk, can you please report this to bug 497299?
[11:06] <pitti> weird though, the package just changed the postinst
[11:07] <Mamarok> done
[11:11] <dholbach> pitti: http://paste.ubuntu.com/381526/
[11:12]  * pitti removes that version from -proposed
[11:13] <pitti> thanks for the report
[11:13] <dholbach> no worries
[11:14] <pitti> bug updated accordingly
[11:14] <pitti> slangasek: ^ FYI
[11:38]  * ogra tries out seb128's fixed upload ...
[11:39] <ogra> seb128, still the flickering dots in xchat
[11:39] <seb128> ogra: talk to bratsche when he will be there
[11:39] <ogra> yep
[11:40] <seb128> I still get the slowness issue too
[11:40] <ogra> same here
[11:40]  * ogra downgrades gtk again
[11:40] <seb128> so I guess his fixes is not working as expected
[11:40] <ogra> sadly that makes evo unhappy
[11:42] <ogra> ah, better ... gdm looks intresting though with the clinet side frames :)
[11:49] <cjwatson> ArneGoetje: pinyin-database looks like it may need an MIR for promotion to main?
[12:07] <tseliot> mdeslaur: do we ship 64bit flash on amd64?
[12:07] <tseliot> (in lucid)
[12:10] <tjaalton> tseliot: no
[12:10] <tseliot> tjaalton: oh, do you know why?
[12:10] <tjaalton> aiui adobe doesn't want people to ship prerelease versions
[12:11] <tjaalton> there should be a bug about it
[12:11] <tjaalton> s/should be/is/
[12:13] <tjaalton> tseliot: bug 331275
[12:13] <tseliot> tjaalton: thanks
[12:13] <cjwatson> dpm: did you see my request for branch recreation in bug 518718?
[12:14] <dpm> cjwatson, yeah, thanks, I just haven't had the chance to do it
[12:17] <cjwatson> james_w: I'm getting hourly e-mails about "spiv/jam" not being a valid Launchpad account in foundations-lucid-distributed-development work items; can that be regularised?
[12:18] <dpm> pitti, could you please copy the latest karmic PPA to karmic-proposed when you've got some time? They include a fix in FF translations generated with po2xpi which would be good to get tested
[12:19] <dpm> (the language packs, I mean)
[12:26] <pitti> dpm: sure, running
[12:27] <dpm> cool, thanks pitti!
[12:59] <davmor2> pitti: https://bugs.launchpad.net/bugs/422536 seems to of crept back into Lucid.
[13:02] <dholbach> **
[13:10] <pitti> davmor2: eww; mind to reopen it then with a comment?
[13:11] <davmor2> pitti: no probs
[13:15] <nigelb> pitti: hey, you got some time?
[13:15] <nigelb> wondering how to make a report from an apport hook automatically private
[13:15] <pitti> nigelb: I need to leave in 10 mins for some 2.5 hours, so only if it's quick
[13:15] <nigelb> I've been working on a hook for rhythmbox, so some of the data might be private
[13:16] <pitti> but if it's a private bug, nobody will be able to see it..
[13:16] <pitti> nigelb: wouldn't it be better to filter out the potentially private bits?
[13:16] <nigelb> I'm working on that right now
[13:16] <nigelb> but, otherwise, there is no way to make the report private?
[13:17] <pitti> nigelb: we could add that to apport relatively easily
[13:17] <pitti> like report['Private'] = 'Yes'
[13:17] <pitti> report['Subscribers'] = 'ubuntu-core-dev'
[13:18] <nigelb> oh, that works now?
[13:18] <pitti> but I don't think it's a very clean use case
[13:18] <pitti> nigelb: no, it doesn't right now
[13:18] <nigelb> from the angle of how many people can work on the bug, I agree, it looks messy
[13:18] <pitti> we sort of have to deal with it for crashes, but for hooks we might just better try to obfuscate/filter sensitive stuff
[13:18] <nigelb> it would mean only bug control and a small group of people can see the report
[13:19] <nigelb> I'll get around to filtering it then.  Thanks :)
[13:19] <pitti> nigelb: like, if you dump the DB, you could replace all file and tag names with a dummy
[13:19] <pitti> so that structural damage is detected, but no actual information exposed
[13:19] <pitti> credentials from the music stores should of course be filtered out entirely
[13:20] <pitti> nigelb: ok, good luck! if you have further questions, I'll answer scrollback once I'm back
[13:20] <nigelb> I'm just getting a dump of gconf data.  I've figured of all fields that needs to be removed, so the data in the fields is going to be replaced with ##masked##
[13:20] <pitti> nigelb: for the ease of triaging, you might just check their validity, and remove them altogether?
[13:21] <pitti> i. e. see what you would like to look at as a triager, and try to automate that, so that the "unusal" bits stand out
[13:21] <pitti> anyway, need to go, cu later
[13:21] <nigelb> okay :)
[13:21] <persia> So we just get a nice report "Database OK" or "Database corrupt", or similar?
[13:22]  * nigelb frowns
[13:22] <nigelb> thats a lot of work
[13:22] <nigelb> persia: this is what I have right now.  Its not much.  the masking is not working (yet), http://etherpad.com/nJwmxU3dGv
[13:24] <persia> nigelb: I think you want to capture some data about the pulse configuration as well.  Maybe crimsun has a good suggestion for that.
[13:24] <nigelb> I thought "report.add_package_info("pulseaudio")" did that
[13:24] <persia> (or at least with my limited python it appears you're capturing gstreamer and alsa config, but not pulse config)
[13:25] <nigelb> the pulse bit it between alsa and gstreamer
[13:25] <persia> Oh, I missed that bit, perhaps because it came after the paplay call.
[13:25]  * persia apologises for the unnecessary highlight
[13:25] <nigelb> the more eyeballs it get, the more bugs i correct
[13:26] <nigelb> (otherwise, I would have never known the earlier wav didn't work)
[13:39] <ogra> seb128, ha ! my armel desktops are not affected by the csd bug :)
[13:39] <ogra> we should just all switch to armel :)
[13:39] <seb128> lol
[14:16] <soren> cjwatson: I just stumbled upon bug 246558. I'd still love to get that fixed. Do you have an opinion on the approach taken in my patch? The patch is a couple of years old, so probably needs fixing up.
[14:20] <nigelb> seb128: do you deal with merges for rhythmbox?
[14:20] <seb128> nigelb, yes, why?
[14:20] <nigelb> seb128: I'm merging an apport hook :)
[14:20] <nigelb> or requesting a merge for rather
[14:20] <seb128> hum, what we call merge usually is taking debian changes
[14:20] <seb128> that's rather sponsoring
[14:20] <nigelb> sorry, should have been more clearer
[14:21] <seb128> nice, thanks, I will have a look to that
[14:21] <nigelb> just doing it locally now, will ping you once finished
[14:21] <seb128> ok thanks
[14:23] <zul> soren: ssh uses upstart now as well fyi
[14:25] <soren> zul: Really? The package still ships an init script?
[14:25] <soren> Bah, I'm on crack.
[14:25]  * soren can't spell "init"
[14:26] <zul> heh
[14:29] <cjwatson> soren: doing anything like this at boot makes me uncomfortable - I keep imagining Scott turning up at my door with an axe
[14:30] <cjwatson> soren: and this patch wouldn't deal with Bjorn's use case, because of the special postinst handling of no HostKey directives
[14:31] <cjwatson> all looks rather tricky :(
[14:32] <soren> I never understood the no-hostkey thing.
[14:32] <soren> How does openssh do without a hostkey?
[14:33] <cjwatson> I thought Bjorn explained that
[14:33]  * soren rereads
[14:33] <cjwatson> #ifndef GSSAPI
[14:33] <cjwatson>         /* The GSSAPI key exchange can run without a host key */
[14:33] <cjwatson>         if ((options.protocol & SSH_PROTO_2) && !sensitive_data.have_ssh2_key) {
[14:33] <cjwatson>                 logit("Disabling protocol version 2. Could not load host key");
[14:33] <cjwatson>                 options.protocol &= ~SSH_PROTO_2;
[14:33] <cjwatson>         }
[14:33] <cjwatson> #endif
[14:33] <cjwatson> (sshd.c)
[14:33] <soren> I see.
[14:34]  * soren goes to a phone call
[14:55] <james_w> davmor2: hey, could you open a new bug for the EDAC warning thing please?
[14:56] <davmor2> james_w: I can indeed
[14:56] <mdeslaur> Is it possible to use an icon from a path when porting a python app to application indicators?
[14:56] <james_w> that bug is too huge and horrible to be useful
[14:56] <james_w> I want it to go away
[14:56] <davmor2> james_w: np's 2 ticks
[14:56] <james_w> thanks davmor2
[15:03] <davmor2> james_w: bug 525792
[15:03] <james_w> davmor2: you are getting this as an apport popup?
[15:04] <davmor2> james_w: Yeap
[15:04] <james_w> thanks
[15:07] <sgnb> anyone here willing to help with OCaml transition (#522358, #522363)?
[15:09] <davmor2> james_w: Is there anything else you'd like adding that might be useful?
[15:09] <james_w> davmor2: a patch? :-)
[15:10] <james_w> davmor2: I understand the issue and your logs that apport attached should be sufficient to work out why the pattern isn't matching to ignore this issues
[15:10] <davmor2> james_w: Hmmmm a patch from me do you hate the kernel?
[15:11] <james_w> davmor2: it's not really a kernel issue
[15:11] <james_w> though I don't think it should be acting like this
[15:11] <james_w> the issue is with kerneloops, it shouldn't be causing an apport report for this issue, I just reassigned
[15:12] <BenC> Good morning software scally wags
[15:13] <mdeslaur> tedg: Is it possible to use an icon from a path when porting a python app to application indicators?
[15:15] <tedg> mdeslaur: Not currently.  Do you have a use-case?  Why is the icon not installed?
[15:20] <mdeslaur> tedg: well, I started to port virt-manager to app indicators, and it's icons are in it's own directory...
[15:21] <tedg> mdeslaur: Is it in an "icon-theme" format?  Like with all the different sizes?
[15:22] <tedg> mdeslaur: If so, you just need "new_with_path" which installs an icon theme path, but I think that's not in the Python bindings for some reason.
[15:22] <mdeslaur> tedg: unfortunately not, it's just a single icon in a directory
[15:23] <tedg> mdeslaur: :-/  We probably should fix that... can we just install it in /usr/share/icons/hicolor ?
[15:23] <tedg> mdeslaur: (that's the spec locations for one-of icons)
[15:24] <qense> tedg: we did find an appindicator.icon_path property, but that was the only reference to an icon path we could find.
[15:24] <qense> I've also got a problem with an icon being located in /usr/share/pixmaps/{appname}/{appname}_tray.png
[15:24] <qense> at*
[15:26] <jcastro> mdeslaur: did you file a bug for virt-manager app indicators?
[15:26] <tedg> qense: Yeah, it needs to be built at construction time.  So in the current Python bindings you really need the special _new function.  With PyGI it would be possible to se it.
[15:26] <mdeslaur> tedg: ok, I'll try putting a symlink in there
[15:26] <mdeslaur> jcastro: LP #525462
[15:26] <jcastro> ta
[15:43] <nxvl> kirkland: ping
[15:43] <kirkland> nxvl: yo
[15:43] <nxvl> kirkland: are you still maintaining encrypted home directory?
[15:44] <nxvl> kirkland: a friend of mine hited a really weird bug
[15:44] <nxvl> and i was able to reproduce it
[15:45] <kirkland> nxvl: yes
[15:45] <kirkland> nxvl: what's the bug?
[15:45] <nxvl> kirkland: if you have EHD, and change the user password from A to B, then reboot, for some reason the system won't accept B, but it will A, but your HD won't get decrypted
[15:47] <nxvl> kirkland: (change the password using the UI, haven't tried using passwd)
[15:50] <kirkland> nxvl: you can successfully change the password as the user, using either passwd or System->Preferences->About Me->Change password
[15:51] <kirkland> nxvl: but you can't use the admin user to force-overwrite the user's password, using passwd or System->Administration->Users
[15:51] <nxvl> i used.... System > Administration > Users and Groups
[15:51] <kirkland> nxvl: because if the admin does it, the admin is not prompted for the user's old password
[15:51] <kirkland> nxvl: note that this is fixed in Lucid
[15:51] <kirkland> nxvl: the key is that we need to "re-wrap" the passphrase
[15:51] <kirkland> nxvl: for that, we need the old password and the new password
[15:52] <nxvl> kirkland: actually i used the same user to change it's own password, and it was indeed prompted for the old password
[15:52] <kirkland> nxvl: are you *sure*?
[15:52] <kirkland> nxvl: i bet you were prompted by gk-sudo to run that app
[15:52] <kirkland> nxvl: and then you were asked for the user's new password, and that's all
[15:52] <kirkland> nxvl: is this 9.10?
[15:53] <nxvl> kirkland: i went to Users and Groups, the selected the user, clicked properties, click on change password, it asked me for the current password, once i hitted autenticate it unblocked the new password and repeat pasword input field
[15:53] <nxvl> kirkland: yup, 9.10
[15:53] <kirkland> nxvl: yes, the first password you entered just unlocked administrator mode
[15:53] <chrisccoulson> nxvl - if you're referring to users-admin, did you use it to change somebody elses password?
[15:53] <kirkland> nxvl: it was not used in the passwd call
[15:54] <kirkland> nxvl: hence the problem
[15:54] <kirkland> nxvl: again, i note, look at the behavior in Lucid -- this is fixed
[15:54] <nxvl> chrisccoulson: nope
[15:54] <nxvl> kirkland: no, not the onlocking
[15:55] <chrisccoulson> nxvl - that should work in karmic too if you are changing your own password
[15:55] <nxvl> kirkland: on the users and groups dialog you have a button with keys on it, that's the one to unlock, that's NOT the one i pressed
[15:55] <chrisccoulson> is gnome-about-me installed?
[15:55] <nxvl> kirkland: i selected the user (i.e. nxvl) from the list the dialog shows
[15:55] <nxvl> kirkland: then clicked properties on the right
[15:56] <nxvl> kirkland: once in that new dialog there is another button "Change Password..."
[15:56] <nxvl> clicked on that and a "Change password" dialog apeared
[15:56] <nxvl> let me take a screenshort
[16:01] <nxvl> kirkland: how do i upload to people.ubuntu.com?
[16:01] <kirkland> nxvl: it's people.canonical.com now
[16:01] <nxvl> oh, ok
[16:02] <jpds> nxvl: That or: https://wiki.ubuntu.com/PeopleUbuntuCom
[16:03] <nxvl> kirkland: http://people.canonical.com/~nxvl/change_password.png\
[16:03] <nxvl> kirkland: http://people.canonical.com/~nxvl/change_password.png
[16:03] <chrisccoulson> that dialog is part of gnome-control-center
[16:03] <chrisccoulson> i'd be surprised if that doesn't work. it just calls passwd
[16:04] <nxvl> it doesn't, it seems that it changes something in cryptfs, but not the password itself in the system
[16:04] <nxvl> is really weird
[16:05] <kirkland> nxvl: fwiw, i have this script in my ~bin/pcc, pcc=people.canonical.com: http://people.canonical.com/~kirkland/pcc
[16:05] <kirkland> nxvl: so i can just pcc <FILE> or pcc <DIR>
[16:05] <kirkland> nxvl: yep, this is broken in 9.10
[16:06] <kirkland> nxvl: because the "authenticate" step is separate from the change password step
[16:06] <nxvl> oh really?
[16:06] <kirkland> nxvl: so the password given in the first step is NOT passed to passwd on the change password
[16:06] <kirkland> nxvl: rather, after being authenticated, it just force changes the password as root
[16:06] <kirkland> nxvl: so i'm telling you ...
[16:06] <nxvl> ohhh
[16:06] <kirkland> nxvl: a) this is fixed in Lucid
[16:06] <nxvl> ok, that makes sense
[16:07] <kirkland> nxvl: b) use passwd on the command line
[16:07] <kirkland> nxvl: or c) use About Me to change password
[16:07] <chrisccoulson> kirkland - the gnome-about-me dialog should actually work though (it passes the old password to passwd)
[16:07] <kirkland> nxvl: and if you really want this fixed, then propose an SRU or something
[16:07] <kirkland> chrisccoulson: absolutely, About Me will definitely work
[16:07] <chrisccoulson> the one with the issue was users-admin, which we worked around in karmic by calling gnome-about-me
[16:07] <chrisccoulson> but the dialog nxvl shows is the gnome-about-me dialog
[16:07] <kirkland> chrisccoulson: hrm
[16:08] <nxvl> kirkland: oh yeah, actually it is
[16:08] <nxvl> i just tried the About me and got the same dialog
[16:20] <randomaction> Can some core dev(s) please help with the OCaml transition? Currently 2 packages are waiting for a sync ACK (bug 522358), and 2 packages need to be rebuilt (bug 522363).
[16:20] <randomaction> In total, around 100 uninstallable packages are blocked on this.
[16:23] <pitti> randomaction: the two syncs are already approved
[16:23] <pitti> randomaction: do you need them synced right now?
[16:30] <pitti> randomaction: hevea/ocaml synced
[16:30] <pitti> "jocaml"
[16:37] <pitti> randomaction: and the two rebuilds uploaded
[16:37] <randomaction> pitti: thanks for that
[16:38] <pitti> randomaction: oh, seems I missed camlp5; syncing
[16:42] <randomaction> pitti: great, thanks again!
[16:42] <randomaction> james_w: thank you, too
[16:43] <randomaction> sgnb: round 2 complete (except for actual building)
[16:43] <Laney> bah
[16:43] <Laney> you guys and your easy ocaml transition!
[16:44] <Laney> ghc6 is having trouble even building...
[16:46] <randomaction> sgnb: for the next rounds, it'll probably be more handy filing separate bug reports for packages in main and universe
[16:47] <nigelb> seb128: bzr merge requested for rhythmbox apport hook :)
[16:47] <seb128> nigelb, thanks
[16:47] <nigelb> :)
[16:48] <sgnb> randomaction: I've just added two packages for round 2 that I overlooked
[16:48] <sgnb> randomaction: you mean 4 bugs per round?
[16:49] <sgnb> (i.e. {main,universe} x {sync,rebuild})
[16:49] <Laney> can't you just poke a friendly archive admin with a list of stuff to sync?
[16:49] <sgnb> Laney: I don't know any
[16:50] <randomaction> Laney: that's a more efficient way to handle a transition :)
[16:50] <sgnb> (I mean, I don't know any archive admin... not that all archive admin are not friendly)
[16:52]  * Laney is sure that some read this channel :)
[16:53] <sgnb> Laney: what's the difference between archive admins and sponsors?
[16:53] <sgnb> (in Debian, archive admins mostly don't care about transitions)
[16:54] <nigelb> seb128: hold off, I made a mistake.  will correct and push again
[16:54] <seb128> nigelb, ok
[16:54] <Laney> sgnb: Archive admins push the buttons to make syncs happen
[16:55] <Laney> and other things like handling removals
[16:55] <sgnb> ok
[16:55] <Laney> and NEWing, kind of like ftpmasters
[16:55] <sgnb> Laney: but how are rebuilds handled?
[16:55] <Laney> by doing a new sourceful upload
[16:55] <sgnb> (most of the work is in rebuilds)
[16:56] <Laney> don't need archive admin powers to do that, just upload access
[16:56] <sebner> Laney: NEW is so awfully full *hrhrhrhr*
[16:58] <sgnb> Laney: there are no such things as binNMUs, right?
[16:58] <Laney> nope (sadly)
[16:59] <nigelb> seb128: Done.  Sorry. I forgot to change changelog from karmic to lucid :)
[17:03] <randomaction> sgnb: I'm confused about confluence and ocamldsort, they only depend on libc6, do they need to be updated?
[17:04] <sgnb> randomaction: they depend on ocaml on armel and ia64 (aka "bytecode" architectures)
[17:04] <nxvl> james_w: hi
[17:05] <nxvl> james_w: i just hitted BTS #570504
[17:05] <sgnb> (and btw, I've juste understood why I overlooked them at first)
[17:05] <nxvl> james_w: is there a workaround or something i can do to use bzr bd?
[17:05] <nxvl> i kinda need it
[17:05] <seb128> nigelb, do you have a bug about this change?
[17:06] <james_w> bug 570504
[17:06] <james_w> debian bug 570504
[17:06] <nxvl> mm ubottu sould know what BTS is
[17:07] <randomaction> sgnb: ok, I missed that on i386 :)
[17:07] <james_w> nxvl: hmm, I'm not sure of how to workaround this without editing files
[17:07] <james_w> nxvl: I can tell you what change to make to fix it if you want to edit the files on your system
[17:07] <james_w> or you could use lp:bzr-builddeb temorarily
[17:08] <nxvl> james_w: would those changes be overriden by the next package installed?
[17:08] <james_w> yeah
[17:08] <nxvl> james_w: as in, when the package with the fix is uploaded to the ppa, would the files edited dump the changes?
[17:08] <james_w> yeah
[17:08] <nxvl> then i can edit some files, will take a look at the patch in the branch
[17:10] <nigelb> seb128: no
[17:11] <seb128> nigelb, can you maybe open one and put the url for the change there?
[17:11] <cjwatson> jcastro: I was about to go and fix bug 494282, but I see you're assigned to it - do you need a branch merged or anything?
[17:11] <seb128> it's easier to keep track of those
[17:11] <seb128> I'm not even sure I get bug emails otherwise
[17:12] <cjwatson> dup> er, yeah, that one
[17:12] <nigelb> seb128: you mean open a bug and put a closes into changelog?
[17:12] <seb128> nigelb, just open a bug, I'm going to do a new git snapshot
[17:12] <seb128> so I will tweak changelog anyway
[17:12] <nigelb> will do :)
[17:12] <seb128> but I got nothing now, I think I don't get those merge request emails
[17:13] <nxvl> james_w: what's the revision with the fix? i don't find the patch
[17:13] <seb128> we usually use sponsoring bugs rather for desktop changes
[17:13] <seb128> nigelb, thanks
[17:13] <nxvl> james_w: nm, found it
[17:13] <nigelb> seb128: ah, I know, but this is not exactly a bug, thats why went this route
[17:13] <seb128> well a feature request
[17:14] <seb128> or a sponsoring request
[17:14] <seb128> all the same we use bug reports
[17:14] <nigelb> will do this in the future :)
[17:14] <jcastro> cjwatson: I was going to fix it when we upload the free culture showcase winner.
[17:14] <seb128> nigelb, thanks
[17:14] <jcastro> cjwatson: feel free to do it now if you want!
[17:15] <nxvl> james_w: works \o/
[17:15] <james_w> score
[17:15] <james_w> thanks for testing
[17:15] <nigelb> seb128: bug 525888 opened :)
[17:15] <seb128> nigelb, thanks
[17:22] <jdong> hmm, after archive reorg, seems like I lost my magic powers to upload to the -backports pocket...
[17:22] <jdong> *sniff sniff*
[17:23] <jdong> can an archive admin / core-dev take a look at bug 411849 please? sponsor the debdiff in the initial comment to hardy-backports?
[17:23] <cjwatson> ... I didn't know you had such powers?  didn't the TB say it should be core-dev only for direct uploads?
[17:24] <jdong> cjwatson: that was what it was supposed to be, yeah, but for quite some time I seemingly posessed the power to do so
[17:24] <jdong> maybe that was by error/accident :)
[17:25] <jdong> I seem to recall we had a conversation about it (or maybe it was just ScottK) and concluded that the ACL was okay since an archive-admin has to prod it through anyway
[17:25] <cjwatson> not aware of archivereorg affecting this
[17:26] <Laney> any developer could upload to -backports
[17:26]  * Laney has done so before
[17:26] <jdong> Laney: I just got shot down :)
[17:26] <jdong> Signer is not permitted to upload to the component 'main'.
[17:26] <jdong> maybe it's -universe only for MOTU?
[17:26] <jdong> "MOTU"
[17:26] <Laney> you can probably find a backport to test with
[17:27] <jdong> Laney: or find someone who knows the answer ;-)
[17:27] <Laney> bah, that's no fun!
[17:28] <shtylman_> has the libmysqlclient situation been unmangled?
[17:36] <pitti> shtylman_: yes
[17:37] <shtylman_> pitti: when will that hit the repos? any idea?
[17:37] <pitti> shtylman_: last week :)
[17:38] <shtylman_> pitti: really?
[17:38] <shtylman_> pitti: http://packages.ubuntu.com/lucid/liblua5.1-sql-mysql-2
[17:38] <shtylman_> I look at that ... and that one in particular is still on 15
[17:38] <pitti> libmysqlclient16 | 5.1.41-3ubuntu6 |         lucid | amd64, i386
[17:38] <pitti> shtylman_: if you have the 7 version installed locally, you need to purge it
[17:39] <shtylman_> pitti: k... I will try that
[17:39] <persia> shtylman_: You may find rmadison more usefully informative than packages.ubuntu.com
[17:41] <shtylman_> persia: thanks
[17:41] <cjwatson> jcastro: ok, thanks, will do
[17:41] <cjwatson> happened to see YA duplicate of it going past ...
[17:43] <james_w> was the entirety of mysql-cluster nuked?
[17:43] <james_w> it's in binary NEW, and all the binaries it builds are showing as new
[17:50] <shtylman_> pitti: is there a nice way to purge that package without also uninstalling what depends on it?
[17:50] <pitti> shtylman_: does somethign depend on it?
[17:51] <pitti> shtylman_: I could just purge it here; it had one other library dependency which got purged along
[17:51] <pitti> shtylman_: if you actually need it, use apt-get install libmysqlclient/lucid
[17:51] <shtylman_> libmysqlclient16 yea... when I purge it .. it also wants to remove akonadi ... etc
[17:51] <james_w> would apt-get install libmysqlclient16=5.1.41-3ubuntu6 work
[17:51] <cjwatson> dpkg --purge --force-depends
[17:51] <james_w> possibly with --force-downgrade
[17:51] <cjwatson> (BE VERY CAREFUL)
[17:51] <pitti> james_w: libmysqlclient/lucid should do that as well, it downgrades
[17:51] <cjwatson> installing a lower version explicitly is definitely better if you can
[17:51] <pitti> sorry
[17:52] <pitti> apt-get install libmysqlclient16/lucid
[17:52] <pitti> (forgot the number)
[17:52] <shtylman_> the lower version install worked
[17:52] <shtylman_> thanks all :)
[18:01] <nailora> there is bug 11334 that i am following for quite some time because it bugs me, too :) it is about what happens to the clipboard contents when an application quits. discussion has become more and more off-topic, and there seems to be a lack of developer participation. i'd like to know how to proceed with this...
[18:04] <nailora> it is somewhat broken deep within the x-server (or the spec the x-server follows). or nearly all application just do not to the right thing as it can be fixed on application level, too. but this will not happen for all legacy applications. clipboard managers are not the solution but a workaround, but waiting for a solution in x.org/the spec x.org follows will take lots of time and a workaround might be good in the meantime... ...
[18:04] <genii> I have Intel Pro/1000 XF (fibre optic card) ethtool is reporting only 1000 Base T (copper) capability (when should be 1000 Base FX). Is there some known prob/fix for the e1000 driver?
[18:05] <cjwatson> nailora: workaround: use a clipboard manager application, that takes a copy of the clipboard contents and stashes it
[18:06]  * pitti reenables hourly WI tracker updates, sorry
[18:06] <cjwatson> it's an X design issue, I wouldn't expect it to be fixed any other way
[18:06] <cjwatson> indeed I don't think it is *fixable* any other way
[18:07] <nailora> cjwatson: i know that and i do it it that way personally. but arguably this should "just work" for everyone. that would require a solution that could be included in the default installation
[18:07] <cjwatson> if you're starting from the position that "clipboard managers are not the solution but a workaround", then there is no other option except to wait for (or participate in?) an X design fix
[18:08] <cjwatson> X clipboard clients ask the clipboard owner (an application) for clipboard contents when they need it, and if the application exits then there's no owner to respond; there's no way that can be an application bug
[18:09] <chrisccoulson> which applications don't work correctly?
[18:09] <chrisccoulson> i could only recreate that with firefox, and that's been fixed upstream recently
[18:10] <cjwatson> maybe something is managing the clipboard centrally now?
[18:10] <nailora> it seems that upon exiting an application is able to ask the x server to preserve the contents somehow (most gnome apps and notably firefox nowadays do it). so it can be fixed on application level
[18:12] <jdong> isn't that something introduced way bac: http://library.gnome.org/misc/release-notes/2.12/#rngeneral
[18:12]  * cjwatson is just five seconds late with the same link
[18:12] <chrisccoulson> the clipboard is still based around the selection mechanism
[18:12] <nailora> but most apps simply do not do that. and somehow it seems redundant that you have to request this "feature" if i cannot think of a situation where you would not want it. so it should be default to save the contents and thus be handled in x.org (even so contents from crashing applications would still be lost that way).
[18:13] <cjwatson> gnome-settings-daemon, apparently
[18:13] <chrisccoulson> but applications that don't work explicitly destroy these resources when they close
[18:13] <nailora> therefore i think a push solution (instead of pull like now) is in fact better (and clipboard managers are basically transforming it from pull to push)
[18:14] <cjwatson> nailora: do you have evidence that applications need to explicitly request this feature?
[18:16] <cjwatson> the current state appears to be basically just a clipboard manager built into gnome-settings-daemon
[18:17] <cjwatson> I don't see any application-level requests going on - gnome-settings-daemon responds to various X events
[18:17] <nailora> however todays clipboard managers are to much bling bling. they should run in the background, have no gui, just make things work. history and stuff like current implementations offer could optionally be added for power users). and something sensible should be done with binary data in case applications offer different content depending on the receiver (notably the gimp does this). these things could be fixed easily. but no developer commen
[18:17] <cjwatson> nailora: gnome-settings-daemon's clipboard manager runs in the background, with no bling
[18:17] <cjwatson> no UI at all AFAICS
[18:18] <nailora> no i have no strong evidence, it is just how i understood the discussion in the bug
[18:18] <cjwatson> you're making some assertions that don't seem to match how the code works
[18:18] <cjwatson> at this point, I imagine that developers are put off commenting on the bug simply because it's one of those enormous unmanageable bugs
[18:18] <nailora> cjwatson: gnome-settings-daemon's clipboard manager does not seem to fix all problems
[18:19] <cjwatson> this is why bugs need to be kept small and focused, and why jumping into an existing bug to expand its scope tends to be harmful
[18:19] <nailora> so you basically are suggesting a new bug should be opened containing a short&precise list of applications that are still broken and an overview about the possible solutions?
[18:19] <cjwatson> ah, let's see, there's a SAVE_TARGETS request
[18:19] <cjwatson> not suggesting that at all
[18:20] <cjwatson> I'm suggesting that, if it works for many applications, there ought to be a separate individual bug against each application that seems to have a problem in conjunction with the clipboard
[18:20] <cjwatson> grab-bag bugs are fundamentally doomed
[18:21] <cjwatson> apologies for not noticing SAVE_TARGETS before now, that supports the application-request assertion you made
[18:21] <nailora> installing a clipboard manager by default would have solved all the issues so it was not unreasonable to group it at that time.
[18:22] <cjwatson> it may not have been unreasonable, but it was never going to work well :)
[18:22] <nailora> when favoring the fix-every-application-solution this massive collection is counterproductive
[18:23] <cjwatson> http://www.freedesktop.org/wiki/ClipboardManager seems to be the closest thing that's going to happen to a spec-level change
[18:23] <nailora> but it seems as if this is not a simple "bug" but something that needs more discussion
[18:23] <nailora> has been featured in forums & brainstorm too
[18:23] <cjwatson> it seems reasonable to file separate bugs against individual applications (presumably non-GTK applications, for the most part? don't know about Qt) that don't support it
[18:30] <nailora> just tried dolphin and it fails :)
[18:32] <nailora> so yeah, perhaps all qt-apps could be fixed with one change. this would be a big improvement but still leaves a lot more apps. but it shows why the "applications can request this feature" is the wrong default imho. apps should be allowed to opt-out but have it enabled by default because that way data loss is prevented.
[18:35] <slangasek> pitti: sorry about that; ifupdown reuploaded
[18:39] <pitti> slangasek: ah, thanks; what happened there?
[18:40] <slangasek> pitti: ifupdown hadn't been rebuilt with the karmic-final version of debhelper, so this conflict went unnoticed; was already fixed in lucid, but I'd forgotten about it and didn't do a test install of ifupdown on karmic before upload, thinking it was a trivial change :/
[18:41] <pitti> I suspected something like that when the problem was reported, but it wasn't obvious that something like that could happen when I reviewed the diff
[18:41] <pitti> thanks for the fast fix
[18:41] <pitti> I'll check/accept it right away
[18:45] <slangasek> pitti: ta!
[18:54] <mrenouf> Is it possible to make unattended-upgrade work like 'apt-get distupgrade' ? Specifically, permit it to install versions with new dependencies?
[18:54] <mrenouf> I'm now reading the apt source for clues ;-)
[18:57] <slangasek> cjwatson: hmm, we have a topic lock here?
[18:57] <cjwatson> slangasek: maybe imposed during the last days of hyperion?
[18:57] <cjwatson> (sounds like a Dan Simmons novel)
[18:58] <slangasek> heh
[18:58] <slangasek> cjwatson: could you unset, or add a mention of FF? :)
[18:59] <cjwatson> unset
[18:59] <slangasek> cheers
[19:14] <mathiaz> bdmurray: hi! I'd like to add a query to bughugger
[19:15] <mathiaz> bdmurray: I'd like to generate a list of bugs to which the ubuntu-server is subscribed, that are in New,Undecided and that haven't been created today
[19:16] <mathiaz> bdmurray: being able to filter by date in LP is not possible from the advanced search AFAICT
[19:16] <mathiaz> bdmurray: the next option I'm looking into is bughugger
[19:20] <ccheney> anyone notice thinkpads not spinning their fans up enough to cool down?
[19:20] <tkamppeter> pitti, hi
[19:20] <Pici> ccheney: Yes.  But I thought it was just mine, I had to replace the fan not that long ago and thought it might be acting up again.
[19:20] <ccheney> i'm building webkit and the cpu is up to 87C
[19:21] <mrenouf> ouch
[19:21] <ccheney> and the fan doesn't seem to be making too much noise
[19:21] <kklimonda> ccheney: 87C is bad? My get up to 99C :/
[19:21] <ccheney> kklimonda: its still climbing
[19:21] <Pici> I hit 102C the other day.
[19:21] <ccheney> iirc my system has gotten in the mid 90s before and starting having errors
[19:22] <kklimonda> my started acting strange when it got over 100C once :/
[19:22] <kklimonda> gcc was segfaulting
[19:22] <ccheney> i'm not sure what the max speed of the fan is supposed to be but it claims to be at ~ 4300rpm
[19:22] <mrenouf> if you're doing something cpu intensive for long periods of time, i'd recommend a stand where there is free airflow around all sides
[19:23] <ccheney> its sitting on a flat desk with plenty of airflow
[19:23] <Pici> Anyone know if there is already a bug logged for this?
[19:23] <kklimonda> my laptop is going to die anyway - I'm a lucky owner of the nvidia gpu from G86 serie..
[19:24] <kklimonda> Pici: is it even a bug? laptops get hot. period. :)
[19:25] <mrenouf> well if you could simulate the same cpu activity under windows and that results in lower sustained temps. then yes. it's a bug.
[19:25] <ccheney> 89C now
[19:26] <ccheney> handrest is very warm :-\
[19:26] <ccheney> i guess i'll try testing out the windows side after this build completes or dies due to heat, heh
[19:26] <kklimonda> mrenouf: well - I've noticed that laptops get hotter when running linux in the idle but last time I've checked I could get my laptop to about 99C using Windows so I'm not sure if there is a bug
[19:26] <ccheney> also i could try 9.10 or 9.04 to make sure it doesn't have the same issue also
[19:27] <kklimonda> ccheney: have you tried cleaning it up?
[19:27] <ccheney> hmm?
[19:27] <ccheney> compressed air i suppose? just did that
[19:27] <kklimonda> ccheney: using compressed air or a vacuum cleaner to get all the dust out of it ;)
[19:27] <ccheney> it seems to have cooled it down at least temporarily
[19:27] <bdmurray> mathiaz: http://qa.ubuntu.com/reports/team-subscribed/ubuntu-server-subscribed-bug-tasks.json would likely be a good a start
[19:28] <ccheney> it was suprisingly dusty
[19:28] <bdmurray> mathiaz: I could add in date_reported as a field then you could filter that result set with bughugger
[19:28] <kklimonda> ccheney: well - you just have to believe in linux and your laptop to shut down itself when temperature gets critical
[19:28] <mathiaz> bdmurray: that would be great!
[19:28] <ccheney> yea
[19:28] <mathiaz> bdmurray: how do I add a filter by date in bughugger?
[19:29] <kklimonda> ccheney: I have an old T23 with a broken fan and it can get up to 103-104C and then system shuts down
[19:29] <ccheney> actually its staying lower temp, i might have to run the build again to make sure that solved it, but its looking good so far :)
[19:29] <ccheney> already down to 69C
[19:29] <bdmurray> mathiaz: well the data (date reported) would need to be there first ;-)  I'll set it up and e-mail you or something
[19:29] <tlyu> ccheney: it ingested a dustbunny that didn't agree with it?
[19:30] <mathiaz> bdmurray: great - thanks!
[19:30] <kklimonda> after I've cleaned up my T61 recently it idles at around 53C for cpu and 55C for gpu
[19:30] <ccheney> tlyu: seems to have, lol :)
[19:30] <mathiaz> bdmurray: does ubuntu-server-subscribed-bug-tasks.json include the list of bugs for packages to which the ubuntu-server team is a bug contact?
[19:30] <ccheney> but it might not be doing as much work atm, so will need to rerun the build or run cpuburn to verify
[19:31] <ccheney> it definitely had a disturbing amount of dust that blew out
[19:31] <bdmurray> mathiaz: yes
[19:31] <kklimonda> yeah, it's hard to believe how much dust can you blow out of your laptop :)
[19:31] <ccheney> it seems to just be linking now instead of compiling so that may be part of the reason it cooled down
[19:32]  * ccheney needs another can of air
[19:36] <csurbhi> i have a question on acpi bios... i want to blacklist an acpi bios.. the options for blacklisting are a "system id" or "board id" .. i am in favor of using a board id as i think that a bios will be dependent on the board rather than the machine/laptop
[19:36] <csurbhi> for eg: dell inspiron laptop (which shows an acpi bug) could have a different motherboard and then the bug may not show its face..
[19:36] <csurbhi> oops.. wrong window :P
[19:40] <ccheney> so far on the new build hasn't gone over 56C
[19:40] <ccheney> its amazing what a heatsink can do if not coated in dust :)
[19:47] <Caesar> slangasek: everything in main is supposed to be using upstart jobs now, right?
[19:50] <james_w> no
[19:50] <slangasek> Caesar: I don't think that was ever explicitly the target for lucid; certainly everything in main is a candidate for conversion, but there are some things that are probably too touchy to convert this late
[19:53] <apachelogger> superm1: ping
[19:54]  * sebner waves at apachelogger :)
[19:54]  * apachelogger hugs sebner
[20:31] <superm1> apachelogger, contentless pong
[20:33] <apachelogger> superm1: hey, are you ok with moving bluez-gstreamer from a recommends of the bluetooth package to suggests? ... hence it probably needs to be added to the ubuntu-desktop seed
[20:34] <apachelogger> currently it (along with all of gstreamer) gets pulled in on kubuntu
[20:34] <superm1> sounds fine by me
[20:34] <apachelogger> superm1: ok, are you going to add it to the seed?
[20:34] <persia> May also have to be added to the serveral other gstreamer using flavour seeds.
[20:35] <apachelogger> persia: good point, I better drop a mail somewhere
[20:35] <persia> ubuntu-devel@ seems likely.
[20:35] <persia> Alternately, check the set of tasks that currently apply, and go fiddle the seeds yourself/
[20:36] <apachelogger> ah, I better let the appropriate people do that :)
[20:36] <nxvl> james_w: still around?
[20:36] <apachelogger> superm1: fixed package uploaded
[20:36] <nxvl> james_w: how do i pass '-sa' or an equivalent to bzr bd?
[20:36] <crimsun> nxvl: --
[20:37] <nxvl> crimsun: thnx
[20:37] <crimsun> bzr bd -S -- -sa [..]
[20:42] <crimsun> pitti: help for apport-hookutils references http://docs.python.org/library/apport.hookutils, which is 404
[21:04] <jcole> too much noise in #ubuntu
[21:23] <jp_> hi guys. is there a way to fix lirc on intrepid without making a re install? i just saw that a reinstall fixes problms with it. any ideas???
[21:23] <lifeless> jp_: #ubuntu for support please
[21:24] <jp_> i've been there for 1 hours waiting for an answer, lifeless
[21:24] <jp_> thank you anyway for the reminder
[21:24] <lifeless> you can also try the forums
[21:24] <lifeless> and answers.launchpad.net/ubuntu
[21:25] <jp_> i have a forum post for 1 week with no answer
[21:25] <jp_> thanks for the reminder again, you're so kind lifeless :)
[21:34] <persia> james_w: I've just noticed an interesting case: bug #360590 received a branch link from the package upload import branch after the fix was released.  Is this intentional for tracking, or an artifact of how the upload was structured?
[21:35] <crimsun> slangasek: do you know if using "on mounted MOUNTPOINT=/var/lib" in an upstart job will DTRT, i.e., perform an action if /var/lib is mounted?
[21:36] <slangasek> crimsun: I think that depends on what you think "TRT" is.  You shouldn't use that as a start condition for any job uploaded to Ubuntu
[21:36] <james_w> persia: intentional
[21:36] <slangasek> because /var/lib isn't going to be a separate mount point on 99.999% of systems, so you'll never see that signal
[21:36] <persia> james_w: Nifty.  Do we need to do anything to make sure it happens?
[21:37] <james_w> either upload a package with LP: or use --fixes when using bzr
[21:37] <persia> ah, so the same things we do anyway.  Thanks for the work to make it so transparent.
[21:37] <crimsun> slangasek: might "on mounted MOUNTPOINT=/var" be acceptable?
[21:37] <slangasek> crimsun: what are you trying to accomplish?
[21:38] <crimsun> slangasek: run a job only if /var/lib/alsa is accessible to fix the store race
[21:38] <crimsun> I suppose since in most cases /var isn't separate, /var really wouldn't be correct either
[21:38] <slangasek> you will only get 'mounted' signals for things that are actually mount points.  You can't assume that any mount point other than / is or isn't a separate mount point.
[21:38] <slangasek> you want 'on filesystem' for that
[21:39] <crimsun> slangasek: ok, thanks
[21:39] <slangasek> (what store race?)
[21:40] <crimsun> slangasek: on some system it appears that / is mounted read-only, so alsactl store will fail
[21:41] <slangasek> crimsun: in what job?
[21:41] <slangasek> I only have alsa-mixer-save.conf here, and that only runs on shutdown
[21:41] <crimsun> slangasek: this was karmic's alsa-utils, but it appears to be reproducible in lucid's
[21:41] <crimsun> right, lucid added that job
[21:42] <slangasek> ok, so what job has the bug?
[21:42] <persia> crimsun: Could you stick it in /var/run (exceedingly likely to be mounted separately and early), and copy to /var/lib if it's writable?
[21:42] <crimsun> slangasek: meaning which version? lucid'sl
[21:42] <slangasek> crimsun: no, what *job*?
[21:43] <crimsun> slangasek: alsa-mixer-save
[21:43] <slangasek> crimsun: the only job I have in alsa-utils is one that runs on *shutdown*
[21:43] <crimsun> slangasek: right, that's the job
[21:43] <slangasek> then 'on mounted' and 'on filesystem' have nothing to do with it
[21:43] <crimsun> persia: eek? I don't think that's any better than attempting the store directly.
[21:44] <persia> crimsun: It's only better in terms of error codes without || true :)
[21:45] <slangasek> crimsun: is there a bug number for this?
[21:45] <crimsun> slangasek: https://bugs.launchpad.net/ubuntu/+source/alsa-utils/+bug/366160
[21:48] <slangasek> crimsun: start on starting rc RUNLEVEL=[06]
[21:49] <hacker07_> hey
[21:49] <crimsun> slangasek: great, thanks
[21:50] <hacker07_> i have a question
[21:50] <slangasek> crimsun: that works because what you want is to serialize alsa-mixer-save wrt /etc/rc[06].d/, which is what mounts / ro at shutdown
[21:51] <crimsun> slangasek: excellent, thanks for the explanation
[21:52] <cjwatson> hacker07_: just ask, rather than asking to ask
[21:52] <hacker07_> okay
[21:52] <hacker07_> is there an application in development to change the xsplash theme? or images?
[22:18] <slangasek> ccheney: do you know why OOo wants to pull ttf-sil-gentium-basic into main, and whether we should sub a different font that's already in main for Ubuntu?
[22:20] <slangasek> ccheney: _rene_'s changelog says "for graphite support"
[22:20] <slangasek> but I don't know what that is
[22:20] <ccheney> ah then most likely for graphite which does font support for non-latin 1 based (complicated glyph) languages
[22:21] <ccheney> but afaict it only has this dep in 'openoffice.org' itself which isn't in a seed?
[22:21]  * ccheney greps control to see if it is somewhere else
[22:22] <slangasek> ccheney: everything in main is seeded somewhere
[22:22] <slangasek> why does graphite need this font /specifically/, when we already have other fonts in main that correctly implement glyphs for languages with shaping?
[22:23] <ccheney> the sil gentium font is for the sil graphite library afaict which is the thing that does font support for complicated glyphs (for lack a better explanation)
[22:23] <ccheney> http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&cat_id=RenderingGraphite
[22:24] <slangasek> ccheney: so is this not a Unicode font?
[22:24] <slangasek> if it is, it should be redundant wrt the other fonts we already have that handle shaping
[22:25] <geser> mathiaz: Hi, are you working on merging mutt?
[22:25] <mathiaz> geser: no
[22:25]  * ccheney still investigating to see what it does exactly
[22:26] <ccheney> actually if i am reading this correctly its by the people who wrote graphite but its not for graphite itself, hmm will have to ask rene what is going on
[22:28] <geser> james_w: have you an idea what those date-versioned branches listed on https://code.edge.launchpad.net/ubuntu/+source/mutt and https://code.edge.launchpad.net/debian/sid/+source/mutt are? left over from the package importer?
[22:28] <james_w> yes I do
[22:29] <ccheney> slangasek: apparently it is an extended latin font as opposed to normal latin font, though i am unsure what that means, still waiting to hear from rene to see if he has any additional insight
[22:29] <slangasek> ccheney: that's not a term with a standard definition in fontland, but anyway I'm almost certain it's redundant with stuff we already have in main if it's Latin
[22:29] <james_w> geser: they are when there are collisions between someone uploading a source package and someone pushing the branch. Currently they are more likely to be bugs though.
[22:29] <slangasek> we have very good coverage of Latin glyphs :)
[22:30] <ccheney> ok, i don't know much about fonts myself so not sure if its better or not
[22:30] <ccheney> ArneGoetje: do you happen to know?
[22:31] <ccheney> slangasek: so is the openoffice.org package seeded to the dvd or something, i didn't realize it was seeded anywhere
[22:31] <ccheney> or just a general 'supported' seed i suppose?
[22:33] <slangasek> ccheney: curiously, I can't actually find what's pulling in the openoffice.org metapackage
[22:33] <slangasek> will dig
[22:33] <slangasek> (I /assumed/ it was seeded, because it shows up as the reason on the component-mismatches report)
[22:35] <ccheney> slangasek: talking to rene it apparently does special graphite things already but more is in the queue
[22:35] <ccheney> http://qa.openoffice.org/issues/show_bug.cgi?id=89682
[22:36] <ccheney> "This font supports various advanced typographic capabilities using the Graphite, OpenType, or AAT font technologies." and goes on to explain some of them (in the URL referenced by the bug report)
[22:39] <slangasek> ccheney: ok; I can't say whether those font features are implemented by other fonts we have in main
[22:40] <ccheney> i somehow doubt they are as the font is written by the same people who wrote the extra feature library (graphite)
[22:40] <ccheney> should i file a MIR bug for it to resolve the issue?
[22:40] <slangasek> ccheney: well, let me see what the archive thinks if I move the openoffice.org binary to universe :)
[22:41] <ccheney> heh ok
[22:41] <slangasek> ccheney: if it pops back up on my radar, I'll let you know
[22:41] <ccheney> ok
[22:41] <slangasek> (but it's probably a bug in the component-mismatches report, not caring about the difference between source and binary packages here)
[22:42] <soren> slangasek: Is there any more information I need to provide for bug 525741?
[22:48] <slangasek> soren: followup question sent to the bug
[22:53] <soren> slangasek: ta
[22:55] <sgnb> does lpia still exist?
[22:56] <slangasek> sgnb: no lpia architecture will be released with lucid
[23:04] <bdrung_> jdstrand: hi
[23:05] <bdrung_> jdstrand: yofrankie upstream devs do not have released an tarball yet. that's why the version contains ~svn. You can find a get-orig-source rule for grepping the source from their svn.
[23:06] <jdstrand> bdrung_: I thought I saw a release note for it though...
[23:06] <bdrung_> jdstrand: not that i am aware of.
[23:10] <jdstrand> bdrung_: I found a reference to it in google's cache and thought there might have been a tarball
[23:11] <bdrung_> jdstrand: link?
[23:11] <jdstrand> http://<IP_ADDRESS>/search?q=cache:19uCvkl0NUMJ:www.yofrankie.org/+yofrankie+download&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a
[23:11] <bdrung_> jdstrand: there is yofrankie_1_1b_bge.zip, but that's not the source tarball
[23:12] <jdstrand> yeah..
[23:12] <bdrung_> jdstrand: i extended the makefile for making the generation of the tarball simpler. so he has to run "make dist" and upload the tarball somewhere.
[23:15] <jdstrand> bdrung_: fyi, you have a git Vcs in control but an svn pull
[23:16] <jdstrand> bdrung_: where is their svn?
[23:17] <bdrung_> jdstrand: the svn belongs to upstream, the git is for package (but not yet created) - it will be moved to pkg-games
[23:18] <bdrung_> s/for/for the/
[23:19] <jdstrand> bdrung_: your debina/copyright said you downloaded it from www.yofrankie.org, but you are saying you got it from svn. that should really be somewhere-- this is very hard for me to verify
[23:19] <jdstrand> bdrung_: can you give me an svn url?
[23:19] <jdstrand> bdrung_: I see it in the rules file. nm
[23:20] <bdrung_> jdstrand: the url is in the get-orig-source rule: https://svn.blender.org/svnroot/yofrankie
[23:44] <cjwatson> chrisccoulson: do you have any idea what's going on in https://launchpad.net/~cjwatson/+archive/ppa/+build/1526187/+files/buildlog_ubuntu-lucid-i386.gnome-format_0.1.1-0ubuntu8~ppa1_FAILEDTOBUILD.txt.gz ?  I'm trying to rebuild gnome-format against parted 2.1, and, er, well, vala is not my first language
[23:57] <slangasek> cjwatson: heh, I thought you were making a Tolkien joke
[23:58] <cjwatson> I think I can probably manage Quenya very marginally better than GNOME's Vala, not that that's saying much
[23:58]  * slangasek grins
[23:59] <chrisccoulson> cjwatson - i'm just taking a look now, although i'm not that familiar with vala either ;)