[02:22] <olli_> fginther, so we have a good ppa?
[06:34] <duflu> This makes me sad :(  https://bugs.launchpad.net/ubuntu-power-consumption/+bug/1161212
[07:24] <smspillaz> duflu: have you looked into it ?
[07:24] <smspillaz> duflu: this stuff is easy to regress when you don't have constant metrics
[07:24] <duflu> smspillaz: I don't look at such code any more
[07:25] <duflu> And so far have succeeded in not looking since releasing <IP_ADDRESS>
[07:25] <smspillaz> duflu: I'm only get 5.9 w/s
[07:25] <smspillaz> *getting
[07:25] <smspillaz> where is my english today
[07:25] <smspillaz> duflu: its still higher than it should be (should be around 0.3)
[07:26] <duflu> smspillaz: I didn't spend long looking at the default idle rate but it went at least as low as 13
[07:27] <duflu> I was comparing it with Mir's new on-demand scheduling (which seems to work)
[07:29] <smspillaz> duflu: did you check the very first result from powertop ?
[07:29] <smspillaz> or after the first refresh
[07:30] <smspillaz> its around 190w/s on the first check, but I suspect that's because of all the repaint-flurry caused by loading powertop
[07:30] <smspillaz> after that it returns to a stable number
[07:34] <duflu> smspillaz: No it sits at 190 for several refreshes at least
[07:35] <duflu> Maybe I needed to give it a few minutes to come back down? Doesn't sound right
[09:32] <Saviq> hey everyone, after yesterday's updates we need to update the unity tree in ../build_unity/unity
[09:32] <Saviq> this can usually be done by ./build_unity -u
[09:33] <Saviq> but this time: `bzr pull --overwrite -d ../build_unity/unity; ./build_unity`
[09:33] <Saviq> that's because we rebased unity on lp:unity
[09:57] <didrocks> dednick: hey, do you mind getting all your branches merged to trunk?
[09:57] <MacSlow> Saviq, is that perhaps the reason I'm getting "Error on creating style rule:..." for my test and the shell?
[09:58] <Saviq> MacSlow, nope, that sounds like theming issues
[09:59] <dednick> didrocks: sure
[10:00] <didrocks> thanks :)
[10:04] <Saviq> dandrader, can you https://code.launchpad.net/~saviq/unity/phablet.revert-carousel/+merge/155919
[10:05] <dandrader> Saviq, ok. Will check it now
[10:05] <Saviq> dandrader, cheers
[10:14] <dandrader> Saviq, this crash, is it easy to reproduce?
[10:14] <Saviq> dandrader, yeah, just search in the dash
[10:14] <Saviq> dandrader, click on search in top panel
[10:14] <Saviq> dandrader, type anything
[10:14] <Saviq> dandrader, in people / music / video, not home / apss
[10:14] <Saviq> apps
[10:52] <Saviq> greyback, around?
[10:52] <greyback> Saviq: yep
[10:52] <Saviq> greyback, can you mumble?
[10:52] <greyback> sure
[10:52] <greyback> 1 sec
[11:17] <davidcalle> didrocks, (not sure if you have answered - network issue)
[11:23] <didrocks> davidcalle: not sure your ping even reached me ;)
[11:23] <didrocks> but it seems not
[11:24] <dednick> didrocks: did you want me to merge with trunk (3255). there seems to be a daily release at 3254, but it's not mentioned in the changelog
[11:25] <didrocks> dednick: where do you see a daily release shipped to distro? the last one I'm seeing is rev 3252
[11:25] <dandrader> Saviq, which dependency should I update to get rid of this? http://paste.ubuntu.com/5654895/
[11:26] <Saviq> dandrader, did you update unity?
[11:26] <Saviq> dandrader, see above - `bzr pull --overwrite -d ../unity_build/unity; ./build_unity`
[11:27] <dednick> didrocks: ah. my bad. dont know how all this shipping things work. So what did you want me to merge at? 3255?
[11:28] <didrocks> dednick: 3252, but I guess this was already done :)
[11:28] <didrocks> dednick: the changelog is the authorative answer :)
[11:28] <dednick> didrocks: yeah. it was done a few days ago. ok
[11:28] <didrocks> dednick: the merge back is done when we ship to distro
[11:31] <didrocks> (meaning, tests are running)
[11:31] <didrocks> dednick: like today, we have 40 failures on nvidia
[11:31] <didrocks> dednick: I think it's due to a service failing, (the hud most of the time) and not respawning
[11:31] <didrocks> so the tests are taking ages
[11:31] <didrocks> and all timeouts
[11:32] <dandrader> Saviq, ah, unity comes from lp:unity/phablet-mods now
[11:32] <Saviq> dandrader, it always did, only we rebased on lp:unity
[11:33] <dandrader> Saviq,  hmm, it seems I was using bzr+ssh://bazaar.launchpad.net/~anjali-team/anjali/unity.trunk/
[11:33] <Saviq> dandrader, ah, that was before
[11:33] <dednick> didrocks: hm. ok. looks like the latest exp ppa ones are pretty good though.
[11:33] <Saviq> dandrader, drop the whole of ../unity then
[11:33] <Saviq> dandrader, to be sure, and ./build_unity -s
[11:33] <didrocks> dednick: yeah, I'm talking about unity trunk ones
[11:33] <dednick> didrocks: sure
[11:34] <didrocks> dednick: it's really "random crash of hud (especially on nvidia) -> everything fails"
[11:38] <MacSlow> Saviq, any idea... although I did "bzr pull --overwrite -d ../unity_build/unity; ./build_unity" I'm still getting this with current lp:unity/phablet http://pastebin.ubuntu.com/5654917
[11:38] <Saviq> MacSlow, ./build, not straight cmake
[11:38] <Saviq> MacSlow, and make sure you ./unity_build
[11:39] <Saviq> MacSlow, that error means your UnityCore build failed
[11:39] <Saviq> MacSlow, just drop ../unity_build
[11:39] <MacSlow> Saviq, ok... trying again
[11:39] <Saviq> MacSlow, and go `./build_unity -s; ./build_unity` from a clean slate
[11:42] <MacSlow> Saviq, also took a first look at the notification-interface test... only found one minor thing
[11:46] <Saviq> MacSlow, why do we need to test for that hint?
[11:48] <MacSlow> Saviq, just a suggestion... it is implicitly covered by the Type.Confirmation... still it has to be passed by clients, which intend to trigger a confirmation/synchronous notification
[11:48] <Saviq> MacSlow, yes, an implementation detail that the shell does not need to know about
[11:48] <MacSlow> Saviq, ok
[11:48] <Saviq> MacSlow, imagine we move away from libnotify at some point
[11:49] <Saviq> MacSlow, we'd have to artificially set that hing
[11:49] <Saviq> hint
[11:49] <MacSlow> Saviq, true... safer to hide it then
[11:50] <Saviq> MacSlow, about that, what does the tint hint do?
[11:51] <MacSlow> Saviq, a way to indicate that the positive answer for a snap-decision is colored (Design wants this)
[11:51] <Saviq> MacSlow, yeah, that's fine, just wanted to know what it does
[11:51] <MacSlow> Saviq, is meant to be reserved for "system-level" snap-decision... regular apps should not use that hint
[11:52] <Saviq> MacSlow, k
[13:29] <seb128> cyphermox, hey, do you think you could trigger a raring landing of the indicators stack? there is an indicator-sync fix in there I would like to see in raring before the freeze tonight
[13:29] <seb128> (that's the 3rd most reported issue on e.u.c/raring)
[13:48] <kgunn> paulliu: just checking in, saw you had a feature branch based on unity/phablet, you able to build ok now?
[13:49] <paulliu> kgunn: no..that doesn't builld
[13:49] <didrocks> mhr3: \o/
[13:49] <paulliu> kgunn: I'm still checking.
[13:51] <kgunn> paulliu: pastebin your build probs if you need to...lots of folks can help
[13:51] <paulliu> kgunn: http://paste.ubuntu.com/5654866/
[13:52] <paulliu> kgunn: I've tried bzr pull --overwrite -d ../unity_build/unity; ./build_unity
[13:52] <paulliu> kgunn: still not working.
[13:52] <kgunn> paulliu: yeah...i had the same problem
[13:52] <kgunn> paulliu: Saviq told me the same :) but the bzr pull didn't work for me either
[13:52] <paulliu> kgunn: how did you solve your problem?
[13:53] <kgunn> paulliu: i ended up rm -rf my unity-build dir
[13:53] <kgunn> paulliu: then re-run ./build -s
[13:53] <kgunn> paulliu: and that seemed to work
[13:54] <paulliu> kgunn: ok, let me try it again. I thought I remove unity_build few hours ago.
[13:54] <mterry> didrocks, slangasek was asking yesterday why we don't plan to just publish the touch stack directly to raring.  Apparently we have a standing FFe
[13:55] <didrocks> mterry:
[13:55] <didrocks> mterry: I'll talk to him, but reasons are:
[13:55] <didrocks> - we depend on hud 2.0 which will break existing desktop infra
[13:55] <kgunn> paulliu: yeah, try again...let me know how you get on
[13:55] <didrocks> - I was busy with 100 scopes/in dash payment as I told him
[13:55] <paulliu> kgunn: ok
[13:55] <didrocks> - libhybris and such needs to build on all arch
[13:57] <mterry> didrocks, don't get your last comment, but OK.  I do understand hud2 issue
[13:57] <mterry> didrocks, (Good EST morning btw!  :)
[13:58] <didrocks> hey mterry ;)
[13:58] <mterry> didrocks, regarding the touch stack, any issues with starting to enable some apps?   gallery app should be good to go
[13:58] <didrocks> mterry: you are adding it to head/, right?
[13:59] <mterry> didrocks, no, let me add it to configs
[14:00] <mterry> didrocks, so raring is fully split off by now?
[14:00] <mterry> didrocks, should I add a new stack?  touch-apps?
[14:00] <didrocks> mterry: not fully split yet
[14:00] <mterry> I recall, we were considering "touch-platform", "touch-apps", and one more?
[14:00] <didrocks> mterry: jibel is fixing a bug
[14:01] <didrocks> mterry: we didn't decide on the stack, I was waiting for sergio to get a list before his holidays
[14:01] <didrocks> what I didn't get btw
[14:01] <cyphermox> seb128: yeah, let's just make sure it's ok with didrocks
[14:02] <cyphermox> didrocks: indicator-sync landing ^ ??
[14:02] <mterry> didrocks, I remember in the hangout, they said they split the packages along team lines.  They had a team for platform, one for apps, and one for something else.  That's where I got my idea I guess
[14:02] <didrocks> cyphermox: good for me
[14:02] <didrocks> mterry: yeah, there is an existing platform one, let's use that one
[14:03] <cyphermox> ok, I was just making sure with the branch changes and all
[14:03] <didrocks> mterry: and add an apps one
[14:03] <mterry> sure
[14:03] <didrocks> mterry: we'll figure out later moving stuff
[14:11] <mterry> didrocks, OK, pushed a bare new apps.cfg.  I have it disabled via to_transition right now, but if you like it, we could try enabling it
[14:11] <mhr3> didrocks, ?
[14:12] <didrocks> mterry: you think it would build?
[14:12] <didrocks> mhr3: on the "let's have the scope shutting down" :)
[14:12] <mhr3> oh
[14:12] <mhr3> i don't like it much though :P
[14:13] <didrocks> :)
[14:13] <mhr3> i'd rather have all python scopes in a single process and see how that works
[14:13] <mhr3> something to try over the weekend i guess :)
[14:13] <Saviq> paulliu, let me know if you have any issues
[14:14] <paulliu> Saviq: ok.
[14:14] <paulliu> Saviq: BTW, just pushed a new commit to the merge request.
[14:14] <Saviq> paulliu, cheers
[14:15] <mhr3> didrocks, is there any way to make bzr bd use parallel build?
[14:16] <mterry> didrocks, gallery-app?  it should.  It needs stuff not in the PPA to run...  But it should build fine
[14:17] <tvoss> kgunn, ping
[14:18] <didrocks> mhr3: --parallel in debian/rules (the dh line)
[14:18] <didrocks> mterry: ok
[14:18] <mhr3> didrocks, any envvar for that? not sure i'd want it permanent
[14:19] <mterry> mhr3, if the package can handle parallel build, why not always?
[14:19] <mhr3> hmm
[14:19] <mhr3> good point
[14:19] <didrocks> :)
[14:21] <mhr3> didrocks, and since we have time to clean up now, how can i remove/hide all unity_internal_* symbols from the so?
[14:22] <mhr3> i remember there being a ldflag for it
[14:23] <mhr3> or was that a libtool thing?
[14:23] <didrocks> mhr3: it was a libtool
[14:23] <didrocks> thing
[14:23] <didrocks> that we used in dee IIRC
[14:23] <mhr3> oh? /me checks
[14:33] <kgunn> MacSlow: hey, could you rebase your notification branch to latest trunk?....the build is giving me fits since unity update is needed
[14:33] <jibel> didrocks, https://code.launchpad.net/~jibel/cupstream2distro-config/skip_downstream_task_if_no_project/+merge/155975
[14:33] <didrocks> jibel: thanks!
[14:34] <MacSlow> kgunn, I did that already and pushed 2 hours ago... rev 531 did you get that?
[14:34] <kgunn> MacSlow: :) my bad....i was trying last night...will pull
[14:46] <MacSlow> Is the script run_on_device still meant to be the way to get the qml-phone-shell from the dev-machine cross-compiled, put on the phone and executed?
[14:46] <MacSlow> of course running "./run_on_device -s" first to get it all setup
[14:50] <greyback> MacSlow: yes
[14:51] <greyback> MacSlow: where are things going wrong on you? Does the setup succeed?
[14:52] <MacSlow> greyback, wait... jsut reflashed the phone... so it's missing rsync again
[14:53] <greyback> MacSlow: my usual procedure after a reflash is "phablet-network-setup -i, run_on_device -s"
[14:53] <kgunn> MacSlow: phablet-network-setup
[14:54] <Saviq> paulliu, come here btw
[14:54] <Saviq> paulliu, http://pastebin.ubuntu.com/5655340/
[14:55] <Saviq> paulliu, we need a fix ApplicationManager.startProcess, though, to take the stage hint into account
[14:55] <paulliu> Saviq: but now we don't have stage hint in daemon?
[14:56] <Saviq> paulliu, yes, the ApplicationManager needs to read it and launch the app correctly
[14:56] <paulliu> Saviq: ok.. Yes, since we have desktop file path in daemon, Qt should be able to parse the .desktop files.
[14:57] <Saviq> paulliu, yeah, we just pass the desktop file name to the ApplicationManager and it should do its thing
[14:57] <paulliu> ok.
[15:01] <didrocks> mterry: did you look at why unity can't publish btw?
[15:02] <mterry> didrocks, guh, just more nvidia test failures.  Went up by 30
[15:02] <didrocks> mterry: yeah, I think it's the hud failing again
[15:02] <didrocks> mterry: so maybe try to restart it and get integration tests running?
[15:02] <didrocks> mterry: I'm blocked on knowing if I should redeploy head or not yet for unity :)
[15:02] <mterry> k
[15:03] <mterry> I can restart no problem
[15:03] <mterry> didrocks, done; I wish these builds were more reliable
[15:04] <didrocks> mterry: I wish as well :)
[15:07] <MacSlow> greyback, kgunn: working now again... mock notifications show up on the phone
[15:07] <greyback> cool
[15:07] <kgunn> MacSlow: cool!...now break it :)
[15:07] <kgunn> by adding more code that is :)
[15:07] <MacSlow> kgunn, nooooo :)
[15:07] <MacSlow> kgunn, sure
[15:08] <kgunn> MacSlow: reminds me of my favorite bug ever....working on audio for a phone, a real user submitted a bug
[15:08] <kgunn> MacSlow: saying after they submerged their phone in water
[15:08] <kgunn> MacSlow: it didn't make any sound :)
[15:09] <MacSlow> kgunn, btw... I'm off tomorrow and Monday... forgot to mention that in standup
[15:09] <kgunn> MacSlow: enjoy
[15:09] <MacSlow> kgunn, you honestly got that filed in your bug-db?
[15:09] <kgunn> MacSlow: it was a classic :)
[15:10] <MacSlow> kgunn, as long as the phone wasn't meant to be water-proof, how can people expect that to work
[15:10] <kgunn> MacSlow: i told them i fixed in sw & to please retest :)
[15:10] <MacSlow> kgunn, these days phone-hw is cheap anyway ;)
[15:13] <kgunn> Saviq: been talking to kalikiana about dash blueprint work item "merge DeeVariantText into dee-qt"
[15:14] <kgunn> but looks like it out of date in lp, branch superceded
[15:14] <kgunn> is there something to be done? ....wonder if someone on strehl's team would need to own this?
[15:15] <Saviq> kgunn, yeah, the superseding branch needs review/fixing/merging https://code.launchpad.net/~unity-team/dee-qt/deevarianttext-and-tests/+merge/153530
[15:17] <Saviq> kgunn, the tests there are most useful
[15:17] <Saviq> kgunn, DeeVariantText... it depends whether GVariant string representation will be used anywhere passed to the shell
[15:17] <Saviq> kgunn, but all in all, yeah, it's the API team that needs to own it
[15:18] <kgunn> Saviq: thanks, i'll ping tstrehl
[15:19] <Saviq> kgunn, the DeeVariantText does not even belong with dee either
[15:19] <Saviq> kgunn, we just slapped it on because we needed it, and quick
[15:19] <kgunn> Saviq: where's the best "conceptual" home?
[15:20] <Saviq> kgunn, I don't think there is, yet, it would have to be some kind of qt<>gio compatibility layer
[15:33] <kgunn> didrocks: you joining ? https://plus.google.com/hangouts/_/47a4dfa53a9b99896e07a788f1bdf66c07bafd01
[15:38] <didrocks> kgunn: sorry, 3 more minutes?
[15:39] <kgunn> didrocks: :) sure...we'll just talk about you until you're here
[15:40] <Saviq> paulliu, if you're still around (go to sleep)
[15:41] <paulliu> Saviq: hmm..
[15:41] <Saviq> paulliu, we're in testing mode, so just look in tests/{unittests,qmluitests}
[15:41] <paulliu> Saviq: ok
[15:44] <Saviq> paulliu, so just find a component (start with the Components dir)
[15:45] <Saviq> paulliu, that doesn't have tests
[15:47] <paulliu> Saviq: Yeah. I can take that one.
[15:48] <paulliu> Saviq: got it.
[15:50] <kgunn> didrocks: you want to do tomorrow? i have something in 10 min
[15:50] <didrocks> kgunn: just joining now
[16:12] <didrocks> Trevinho: my obfsucated perl code!!! how dare you? :)
[16:13] <didrocks> Trevinho: well, it's still in perl, so still obfuscated I guess :p
[16:13] <Trevinho> didrocks: eheh
[16:13] <Trevinho> didrocks: I wrote it in-line, for what it worth... Then I thought it could be easier to maintain it in that form, don't you think? :)
[16:14] <didrocks> Trevinho: but but… I felt like a powa-user :-)
[16:14] <didrocks> Trevinho: more seriously, yeah, way much better, thanks!
[16:14] <Trevinho> didrocks: you are
[16:14] <didrocks> Trevinho: I hope you did the change on a Friday
[16:14] <didrocks> Trevinho: that's my rule: always touching perl on a Friday :)
[16:15] <didrocks> (evening for bonus points)
[16:15] <Trevinho> didrocks: ops, I was one day ahead :)
[16:15] <didrocks> :p
[16:15] <didrocks> Trevinho: more seriouly, the perl part looks good, I'll let someone else testing the rest :)
[16:16] <Trevinho> didrocks: ok, thanks
[16:17]  * Trevinho hates the change in DesktopAppInfo that needs a valid exec to return a valid GAppINfo..
[16:17] <Trevinho> it makes testing so bad :/
[16:17] <didrocks> cyphermox: in case you didn't see: http://<IP_ADDRESS>:8080/view/cu2d/view/Raring/view/Indicators/ failure on the -check
[16:17] <cyphermox> dah
[16:17] <didrocks> Trevinho: are we impacted a lot?
[16:18] <didrocks> Trevinho: I had to fix some tests in libunity for that
[16:18] <Trevinho> didrocks: well, also in BAMF
[16:18] <didrocks> Trevinho: it's in the 100scopes
[16:18] <didrocks> branch
[16:18] <Trevinho> didrocks: yes, I've seen it
[16:18] <didrocks> Trevinho: I'm using /bin/true as you saw then
[16:18] <Trevinho> didrocks: however in bamf changing the exec to /bin/true changes the world
[16:18] <didrocks> don't think about a better way…
[16:18] <didrocks> yeah
[16:18] <didrocks> seb128 was proposing to eventually revert it ^
[16:18] <didrocks> if we have too many issues
[16:19] <Trevinho> for real world it's a good thing, but I don't like the fact that the app-info should be null... they could have been added just a getter
[16:20] <didrocks> yep
[16:20] <didrocks> Trevinho: do you think we'll get badly impacted, like what's your feeling?
[16:20] <didrocks> should we revert this glib change
[16:21] <didrocks> or just fix whatever we need to fix
[16:21] <Trevinho> didrocks: well, I was trying to fix the tests... And I can, but the actual result is different
[16:22] <Trevinho> didrocks: I mean, in BAMF we have that a .desktop file has less or more priority based on the fact that its name matches the exec basename, and this is broken by that on tests
[16:22] <didrocks> Trevinho: ok, do you think it won't take too much of your time to fix that this release?
[16:23] <Trevinho> didrocks: I'm not sure how I can fix it :)
[16:23] <Trevinho> didrocks: let me check something
[16:29] <Trevinho> didrocks: ok, I've faked it adding a local program and changing the PATH during the test
[16:30] <didrocks> Trevinho: sounds good to me
[16:49] <didrocks> kenvandine: robru: mterry: cyphermox: so, FYI, apart from Unity, I redeployed everything. The "raring" view is now the one with daily releases.
[16:50] <kenvandine> didrocks, cool
[16:50] <didrocks> cyphermox: the indicator has the new branches for the 13.04 branch enabled, I just disabled daily as I want for head to run a full time one first
[16:50] <didrocks> kenvandine: robru: cyphermox: so, think about looking at the "raring" view now
[16:51] <didrocks> and when upstream want to diverge trunk from a feature branch
[16:51] <didrocks> hhttps://wiki.ubuntu.com/DailyRelease/MovingNewRelease#Diverging_.22trunk.22_and_a_.22maintenance.22_branch
[16:52] <cyphermox> didrocks: cool
[16:52]  * cyphermox finishing up review of sil2100's branches
[16:53] <cyphermox> didrocks: symbols file for C++ ?
[16:54] <didrocks> cyphermox: no, we can't have those :(
[16:54] <didrocks> cyphermox: the symbols are different between archs
[16:54] <cyphermox> right, that's what I thought
[16:54] <cyphermox> just drop them
[16:57] <didrocks> yep
[17:04] <cyphermox> sil2100: did you see my comments?
[17:04] <cyphermox> I'd like to see this land like, real soon
[17:04] <cyphermox> esp. given that we only have 4 more hours
[17:14] <mterry> didrocks, anything I can help with for 100scopes?  You know, I can create that MIR bug for ya, take some paperwork off your back
[17:14] <didrocks> mterry: ok, need to get you up to date with latest news
[17:14] <mterry> didrocks, oh boy news
[17:22] <cyphermox> sil2100: what PPA were you using to test the -qt stuff?
[17:39] <mhall119> didrocks: seb128: I remember last physical UDS there was discussion around automated performance testing of Ubuntu core
[17:39] <mhall119> do you have a system for that now?
[17:40] <seb128> no
[17:40] <seb128> I don't think much work went into that (yet)
[17:40] <mhall119> :/
[17:40] <mhall119> ok
[17:40] <seb128> mhall119, try talking the the qa team maybe?
[17:41] <mhall119> ok, thanks
[17:48] <sil2100> cyphermox: ppa:sil2100/qt mostly
[22:02] <tigrang> andy__ == andyrock?


[01:21] <whisk848> ▄▄▄▄▄▄▄▄▄▄▄▄▄ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL<PHONE_NUMBER> #LRH EFNETplcvndlw: darkxst sary jjohansen drjam grrr[m] ubot9 hurricanehrndz potashnik[m] ayan jhernandez anpok micahg robert_ancell marlinc duflu jibel hyperair koza muktupavels chiluk el jzheng vila frederico4d[m] mbiebl_ DB9[m] Texou mcs_ isantop mgedmin chrisccouls
[01:21] <whisk848> ▄▄▄▄▄▄▄▄▄▄ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!!  CALL<PHONE_NUMBER> #LRH EFNETjvdogfgmf: jzheng bschaefer chrisccoulson veebers cpaelzer robert_ancell lifeless ayan frederico4d[m] el potashnik[m] ochosi hyperair chiluk vila ember duflu g4Fd63FhtS55rx6r jjohansen ejat sary drjam mcs_ ubot9 dgadomski shiznix muktupavels jhernandez ddstree
[01:22] <whisk848> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL<PHONE_NUMBER> #LRH EFNETukuueb: jbicha el jzheng anpok hggdh robert_ancell koza darkxst ximion Texou flocculant g4Fd63FhtS55rx6r ubot9 davidcalle muktupavels frederico4d[m] mgedmin mcs_ jhernandez beidl chiluk sary dgadomski mdeslaur
[01:22] <whisk848> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL<PHONE_NUMBER> #LRH EFNETbjilvi: el jibel ayan ember anpok sary vila mcs_ edwinksl davidcalle mbiebl_ jbicha hurricanehrndz drjam lifeless mdeslaur chiluk bschaefer DB9[m] Texou shiznix mgedmin marlinc jhernandez potashnik[m] flocculant slashd isantop dgadomski mic
[02:05] <bac35> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL<PHONE_NUMBER> #LRH EFNETjctwwmbuaw: koza jibel potashnik[m] marlinc micahg anpok muktupavels jzheng el ubot9 hggdh hurricanehrndz drjam hyperair davidcalle edwinksl handsome_feng flocculant robert_ancell mcs_ vila mbiebl_ DB9[m] ddstr
[02:05] <bac35> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!! CALL<PHONE_NUMBER> #LRH EFNETjmcwsdc: edwinksl ochosi bschaefer muktupavels jbicha lifeless ryeguy[m] dgadomski vila anpok mdeslaur ayan marlinc hggdh ubot9 el jibel handsome_feng jjohansen hyperair flocculant jzheng em
[02:05] <bac35> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ https://www.youtube.com/watch?v=--jYqzJErTI LRH IS LIVE NOW!!  CALL<PHONE_NUMBER> #LRH EFNETpptdjyn: jbicha ddstreet marlinc jjohansen ejat Texou frederico4d[m] mbiebl_ DB9[m] micahg veebers mcs_ handsome_feng darkxst anpok sary vila hurricanehrndz slashd flocculant cpaelzer chiluk jhernandez koza mdeslaur ember jzheng hyperair chrisccoulso
[08:50] <oSoMoN> good morning desktoppers!
[08:56] <tjaalton> duflu: hi, the libinput backport was too aggressive, had to drop it from debian
[08:56] <tjaalton> which means it'll autosync to bionic too
[08:57] <tjaalton> seems to be in proposed
[08:57] <duflu> tjaalton, I know, that's annoying, but am dealing with lots of home maintenance emerergencies today... I think libinput perhaps should have followed our request and made it a configurable option
[08:57] <duflu> *emergencies
[08:58] <tjaalton> ok, no worries, just a FYI
[09:12] <Nafallo> morning o/
[09:16] <oSoMoN> morning Nafallo
[13:42] <Trevinho> Hello guys... A little jatlagged...
[13:53] <dechinchilla> Friends, I pitched an app for Ubuntu I'd like to kickstart in the hopes of getting some early input and feedback. https://answers.launchpad.net/ubuntu/+question/661688 I didn't get quite as much of either as I had hoped. What's my next move? Where do I go?
[14:04] <oSoMoN> good morning/afternoon Trevinho
[14:25] <seb128> hey Trevinho, back to good old Europe?
[14:25] <seb128> lut oSoMoN
[14:26] <seb128> dechinchilla, hey, try maybe ubuntu-users list or forums?
[14:26] <dechinchilla> seb128, Thanks
[14:27] <seb128> yw! and good luck with the app
[14:49] <oSoMoN> salut seb128
[15:05] <Trevinho> seb128: yeah.. back to the cold :)
[15:05] <Trevinho> hey oSoMoN
[15:52] <kenvandine> jibel, sru bug 1736232 has been in the queue for 10 days.  anything we can do to get that to updates?
[15:52] <ubot5`> bug 1736232 in gnome-software (Ubuntu Zesty) "GNOME Software shows U1 login for snaps" [High,Fix committed] https://launchpad.net/bugs/1736232
[16:07] <jibel> kenvandine, I approved bug 1716633 this morning (needed to wait to check if there was new crashes for this version on errors.u.c)
[16:07] <ubot5`> bug 1716633 in gnome-software (Ubuntu Zesty) "Installed, popular and featured snaps are loaded in parallel threads can crash" [High,Fix committed] https://launchpad.net/bugs/1716633
[16:07] <jibel> kenvandine, it should be good to publish now.
[16:08] <kenvandine> jibel, awesome
[16:08] <jibel> kenvandine, you can ask someone from the sru team on #ubuntu-release
[16:11] <kenvandine> jibel, thx, i pinged
[16:11] <kenvandine> jibel, we're very anxious to get started on the next critical gnome-software SRU :)
[16:54] <flexiondotorg> Hello desktopers
[16:54] <flexiondotorg> Anyone here familiar with the the supported resolutions are for banner-icon.png that is overlaid on banner.png for feature snaps in GNOME Software?
[17:03] <oSoMoN> hello flexiondotorg
[17:03] <oSoMoN> sorry I'm not familiar with that
[17:03] <flexiondotorg> oSoMoN: o/
[17:04] <jibel> kenvandine, whn is it planned?
[17:04] <jibel> when*
[17:05] <kenvandine> jibel, robert already did the backport and james should be working on getting it in proposed
[17:05] <kenvandine> jibel, bug 1690280
[17:05] <ubot5`> bug 1690280 in gnome-software (Ubuntu Xenial) "Classic confined snaps don't install" [High,In progress] https://launchpad.net/bugs/1690280
[17:06] <jibel> kenvandine, okay, QA can probably do the verification this week for a release 1st week of january
[17:07] <kenvandine> jibel, great
[17:07] <kenvandine> popey, ^^
[17:08] <popey> yay
[17:09] <flexiondotorg> oSoMoN: Where is the source for the snap plugin for GNOME software?
[17:10] <jbicha> flexiondotorg: it's upstream so https://git.gnome.org/browse/gnome-software/tree/plugins/snap
[17:10] <flexiondotorg> Thanks jbicha
[18:57] <GunnarHj> jbicha: Are you there?
[18:58] <jbicha> I'm half here .)
[19:06] <GunnarHj> jbicha: Ok. Just wondered if you could sponsor bug #1735362. But it's no urgency, I suppose.
[19:06] <ubot5`> bug 1735362 in ibus-libpinyin (Ubuntu) "Replace ibus-sunpinyin with ibus-libpinyin" [Medium,In progress] https://launchpad.net/bugs/1735362
[19:08] <GunnarHj> doko: If I forward to Debian, that would be including your change of the build dep from python2 to python3.
[19:08] <doko> GunnarHj: ta!
[19:08] <GunnarHj> doko: Ok.
[19:11] <jbicha> GunnarHj: ask Seb if you want the desktop bugs team subscribed to pkgs
[19:32] <doko> GunnarHj: hmm, where did you forward the patch to Debian?
[19:48] <GunnarHj> doko: Haven't done it yet...
[19:48] <jibel> kenvandine, is there a card on the board for next sru?
[19:48] <kenvandine> jibel, nope
[19:49] <kenvandine> well, i don't think so :)
[19:49] <jibel> kenvandine, I didn't find any
[19:49] <GunnarHj> jbicha: Ok, I'll ask Seb about that. Or do you see an alternative?
[19:49] <kenvandine> jibel, i'll add one
[19:49] <jibel> kenvandine, thanks.
[19:50] <jbicha> alternative to Seb? no, he's irreplacable :)
[19:50] <kenvandine> jibel, actually there is
[19:50] <kenvandine> https://trello.com/c/onHI86gJ/62-bug1690280-support-installing-of-classic-snaps
[19:50] <kenvandine> well, not specifically for the sru
[19:50] <kenvandine> but that's for the fix
[19:51] <kenvandine> jibel, i assume we need a new card?
[19:51] <jbicha> my understanding is that Main packages need a Canonical team subscriber and I guess that means ibus stuff falls to the Desktop team these days
[19:52] <jibel> kenvandine, i'd be useful to have a card for each SRU with the list of bugs that it will address
[19:53] <jibel> so yes, a new card
[19:53] <kenvandine> jibel, will do
[19:53] <jibel> unless it's the only bug fixed in this sru
[19:53] <kenvandine> it is just one bug
[19:53] <kenvandine> afaik
[19:53] <kenvandine> jamesh should be able to confirm
[19:53] <GunnarHj> jbicha: Yeah, that was my understanding.
[19:55] <jibel> i find cards to document a single bug redundant with LP, but that's my opinion :)
[19:55] <kenvandine> jibel, cool, then we'll just use the bug :)
[20:01] <doko> GunnarHj: please do
[20:11] <GunnarHj> doko: I will in an hour or two.
[21:48] <oSoMoN> g’night folks


[00:17] <qwebirc4139> Hello i am having problems setting up Mythbuntu, when i add a folder which contains my videos and then go to videos it says there are no videos, but i can play these videos from Thunar. any suggestions?
[00:23] <klucas> are you using storage groups or the traditional method?
[00:24] <qwebirc4139> sorry im quite new to lunix im not sure what u mean
[00:25] <klucas> okay cool not a problem is your mythbuntu machine a stand alone machine with all your video files loaded locally or do you have a separate backend and frontend?
[00:26] <qwebirc4139> yep its a stand alone, but the video files are on NTFS partitions
[00:28] <klucas> humm. okay, so if you're in the mythtv frontend and you go into... <give me a sec>
[00:29] <klucas> utilities/setup
[00:29] <klucas> setup
[00:29] <klucas> media settings
[00:29] <klucas> video settings
[00:30] <klucas> general
[00:30] <qwebirc4139> yep
[00:30] <klucas> and change the 'directories that hold videos' to the directory with the video files
[00:30] <klucas> then
[00:31] <klucas> go back into the 'watch videos' area
[00:31] <klucas> press 'm'
[00:31] <klucas> and select 'scan for changes'
[00:31] <klucas> do you see the video files?
[00:33] <qwebirc4139> yes they are there thanks alot
[00:33] <klucas> not a problem :)
[00:33] <klucas> enjoy
[00:33] <qwebirc4139> will do thank you very much
[00:33] <klucas> you're welcome :)
[00:34] <klucas> incidentally, I figured out recently that if you take a dvd and copy the image to that directory in just the raw .iso
[00:34] <klucas> it'll play the thing with all the dvd menus in tact
[00:34] <klucas> and he's left
[00:34] <klucas> okay find.
[00:34] <klucas> fine*
[00:34] <klucas> :P
[03:00] <Te3-BloodyIron> anyone else getting their X11 sessions freezing up on them lately?
[03:28] <Guest14516> i set my resolution to something that my monitor doesn't support.  how to i reset it?
[04:09] <myth-learner> Hi - I'm an (myth/u)buntu newbie.  How can I change my firewall so I can run ssh on a different port?  (I know how to change ssh, just not change the (myth/u)buntu firewall.  Can anyone help?
[04:10] <myth-learner> ...and yeah, I know this is more ubuntu rather than mythtv related...
[04:21] <myth-learner> Just got some ubuntu help on #ubuntu.  Later.
[08:34] <mokkan> hey, got mythbuntu 10.10 installed, and i can't seem to get my avi files to play in mythvideo... i got a matroska video to work, but none of my avi's
[08:36] <mokkan> this is what i could find in mythfrontend.log http://pastebin.ca/2023388
[08:36] <Zinn> [pastebin.ca] pastebin - Stuff - post number 2023388
[09:47] <freex> hi all
[12:08] <larson9999> i changed my resolution so a value that my tv doesn't support.  how to a reset it?
[12:08] <larson9999> i'm runnint 10.10
[14:20] <DaPsou> Hi, what's the equivalent of .xinitrc for mythbuntu 10.10 ?
[14:21] <DaPsou> it seems that .xinitrc and .xsession doesn"t work, i need it for xrandr commands
[17:14] <bogustrumper> hello, everyone
[17:15] <bogustrumper> does anybody have any experience with serial IR blasters in mythbuntu?


[08:03] <Korvo> hi, new installation of ubuntu studio 2204 shows enormous system windows and text size, no way to resize and make it smaller, screen resolution is ok. even after installing tested nvidia graphic drivers, nothing changed


[00:11] <broder> slangasek: ok, my initial analysis is that /usr/lib/libconf2-4/gconfd-2 needs to be moved to a new multi-arch: foreign package that libgconf2-4 depends on, but gconfd-2 also links libgconf, so you'd have a circular dependency. so i'm stuck
[00:16] <slangasek> broder: oh.  well, maybe we could have gstreamer-good not depend on gstreamer-gconf, which is a just-merged change anyway
[00:22] <SpamapS> hmm, https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/893420 .. with this bug.. libpst was accidentally demoted to universe in oneiric. How do we re-promote it ?
[00:23] <broder> slangasek: also, i *think* that corba is intended to be cross-arch safe, but i don't know whether gconf's implementation is or not
[00:24] <slangasek> if it isn't, we can assume that's somebody else's problem
[00:24] <slangasek> it was shipped in ia32-libs for a long while IIRC
[00:25] <broder> it's not in oneiric's ia32-libs
[00:26] <mdeslaur> I don't believe gconf uses corba anymore
[00:26] <broder> is it all dbus now?
[00:26] <mdeslaur> I think so, yes
[00:26] <broder> i thought it used dbus to negotiate a corba...thing. but i could be out of date
[00:27] <mdeslaur> oh, hrm
[00:37] <infinity> SpamapS: How do we re-promote it in oneiric or in precise?
[00:38] <infinity> SpamapS: In oneiric, it would require a new version in updates that we could then promote to main, which is a moderately icky thing to do in a released distro, but we've done it in the past in extreme cases.
[00:38] <infinity> SpamapS: In precise, you just need to make sure it's pulled in by something in main (or seeded), and we'll fix.  Shouldn't need an MIR if it was in main before.
[00:38] <SpamapS> infinity: I believe its already back in main in precise
[00:39] <SpamapS> infinity: the SRU is trying to re-enable the libpst functionality in evolution.. which somehow disappeared. I haven't dug into the issue tho.
[00:39] <infinity> SpamapS: Kay.  So, yeah, fixing is in oneiric requires a new upload.  Because we don't change dists/ in a release pocket.
[00:40] <SpamapS> infinity: makes sense, so allow the no change rebuild into -proposed and then subscribe ubuntu-archive ?
[00:40] <infinity> SpamapS: (ie: we won't ever promote the version that shipped with oneiric, but we could promote one in oneiric-updates, if it's really dire)
[00:40] <micahg> SpamapS: was it done by accident or since Thunderbird is the new mail default?
[00:40] <SpamapS> micahg: I don't know.
[00:40] <infinity> There's also that...
[00:41] <SpamapS> evolution is still in main
[00:42] <SpamapS> whether or not that is intentional, I do not know
[00:42] <micahg> maybe talk to the desktop team?
[00:43] <infinity> It might only still be in main because people ran out of time to hunt down all the rdeps and kick it out.
[00:43] <infinity> So, yeah, possibly worth a talk with the desktop team.
[00:43] <micahg> I think the plan was to keep evo in main at least for oneiric
[00:44] <infinity> Well, there are cute comments on evo-related things in the seeds like:
[00:44] <infinity> ubuntu.oneiric/supported: * libreoffice-evolution # no rdepends any more, noticed too late
[00:44] <infinity> Which makes me wonder if there was an effort to get it out, and time just ran out. :P
[00:45] <infinity> SpamapS: Anyhow.  Assuming it has the blessing of the desktop team to fix it, my above outlined solution would be the answer.
[00:45] <TheMuso> broder: mdeslaur, I am sure gconf can be built with either CORBA, or dbus support, and we use dbus now.
[00:46] <broder> TheMuso: ok, cool. so theoretically it should be multiarch safe, other than the cyclic dependency issue
[00:46] <TheMuso> broder: As one can see from the build deps of gconf, it depends on dbus, and no bonobo stuff.
[00:47] <SpamapS> infinity: i'll punt to pitti
[00:47] <SpamapS> there's plenty more to fix in the SRU queues at the moment. :-P
[00:47] <infinity> Heh.
[00:52] <slangasek> broder: would it work to simply install gconfd-2 to /usr/lib/$arch/libgconf2-4/gconfd-2?  It only gets launched by the lib if it's not already running and we don't care which one gets started, right?
[00:52] <slangasek> this is not ideal, but it would work without a circular dep
[00:52] <broder> i haven't checked, but i assume it gets launched by dbus autospawn
[00:53] <slangasek> I don't think it does
[00:53] <broder> so the full path would have to be in /usr/share/dbus-1/services/blah
[00:53] <broder> gconf2-common ships a /usr/share/dbus-1/services/org.gnome.GConf.service
[00:53] <slangasek> ah, ok
[00:53] <slangasek> you're right
[00:59] <infinity> And, it looks libe libglib2.0-dev has grown an undeclared dependency on libpcre3-dev
[01:00] <broder> i was just about to file a bug on that
[01:05] <infinity> Or just reupload glib2.0 with that added to control?
[01:05] <infinity> libglib2.0-0 has depended on libpcre3 for ages, if anything, it's a bug that the -dev package didn't require pcre-dev until now.
[01:05] <broder> i can't upload it - i'm still just motu
[01:05] <infinity> Oh.
[01:06] <infinity> I'll take the proactive approach and do so.
[01:10] <infinity> broder: Fixed.
[05:07] <pitti> Good morning
[05:10] <pitti> bdmurray: yes, it's from apport/crashdb/pitti.py
[05:10] <pitti> bdmurray: seriously, I was working on some retracer bug cleanup before and forgot to switch back to my normal LP account
[05:12] <pitti> sladen: seed3ed f-u-f-f-c to server
[05:16] <pitti> broder: generating precise-* pockets on ddebs now
[05:18] <pitti> infinity, SpamapS: "I'll punt to pitti" -> that's for the re-promotion of the accidentally dropped libpst in oneiric? yes, I already told cyphermox that we'll need a no-change rebuild in -proposed in order to promote it
[05:18] <pitti> broder: there now
[05:18] <infinity> pitti: The punting wasn't about that process, but about whether the dropping of pst support may have been intentional due to evolution being demoted as the default mail app.
[05:19] <pitti> infinity: no, it was entirely accidental; evolution is meant to be in main still
[05:19] <infinity> Kay.
[05:28] <pitti> infinity: can you please commit your glib2.0 change to bzr?
[05:28] <infinity> pitti: To a bzr other than ubuntu/glib2.0?
[05:28] <pitti> yes, to lp:~ubuntu-desktop/glib/ubuntu
[05:28] <pitti> what Vcs-Bzr: says
[05:28] <infinity> (We need to stop having all these mismatched ways of doing this...)
[05:28] <pitti> we don't use ubuntu/glib2.0
[05:29] <pitti> it shouldn't even exist
[05:29] <infinity> Yes, why use the branch that auto-imports and stays synced with uploads? :)
[05:29] <pitti> but our requests of not having UDD branches for packages with an explicit Vcs-Bzr: weren't considered
[05:30] <infinity> (And there's no Vcs-Bzr in the package)
[05:30] <infinity> Just the Debian Vcs-Svn.
[05:30] <pitti> keek, who dropped that..
[05:30] <pitti> I'll add it back
[05:37] <pitti> infinity: so, want me to grab the diff from LP and commit it then?
[05:38] <infinity> pitti: Just did.
[05:38] <pitti> infinity: ah, tahnks
[05:39] <infinity> Still, I wonder why people resist the UDD thing.
[05:39] <infinity> It makes life so much simpler for people like me who prefer to just fix source packages. :P
[05:39] <infinity> Cause it keeps the two in sync.
[05:39] <pitti> many reasons
[05:39] <pitti> we actually did try UDD
[05:40] <pitti> but pre-applied quilt patches in bzr are horrific, evil, bad, and wrong
[05:40] <pitti> and everyone gets them wrong
[05:40] <infinity> Yeah, full source + 3.0(quilt) is pretty ugly.
[05:40] <infinity> There used to be an elegant solution for that.
[05:40] <infinity> Many years ago. :P
[05:40] <pitti> you end up with patches auto-reversed with debian/patches/debian-changed, patches not unapplying, etc.
[05:40] <pitti> merge-upstream fails over horribly with pre-applied patches
[05:41] <infinity> Didn't Scott have clever tools, like, in Sydney, that did branch-per-patch magic?
[05:41] <pitti> also, it's a bit pathetic that UDD gets exactly those things in proper revision control which we _don't_ ever want to touch (the upstream bits)
[05:41] <infinity> Would make a lot more sense now with 3.0
[05:42] <pitti> right, that would be a sensible step
[05:42] <infinity> And yeah, I'm not saying UDD is perfect (in fact, I don't use it), I just like the idea of my source uploads being auto-merged into other people's VCS workflows.
[05:42] <pitti> so right now UDD just makes things a whole lot harder than it needs to be
[05:42] <pitti> the debian/ only branches and bzr bd -S is pretty much perfect
[05:42] <infinity> Instead of things getting lost because I didn't learn the VCS flavour of the week, and no one debdiffs against old source before they upload.
[05:43] <pitti> yeah, the dropped Vcs-Bzr: is totally our fault
[05:43] <pitti> it's back now in bzr (but won't upload just for that, the buildds are busy enough already)
[05:45] <pitti> infinity: the irony is, it's still much cheaper for us to deal with the occasional de-sync than routinely using UDD for everything
[05:45] <infinity> pitti: I don't suppose you've tried to convince people to do debian-only in UDD?
[05:45] <pitti> infinity: at first, but I quickly gave that up
[05:45] <pitti> I don't mind having full source trees, they are reasonably fast these days
[05:45] <infinity> The syncing magic is really the only thing I like, I don't really care about the rest. :P
[05:45] <pitti> infinity: but I whined uncountable times to poolie and other guys to pretty please drop teh pre-applied patches insanity
[05:46] <diwic> Having debian/ only branches often leads to stuff like "could not find the upstream tarball", when somebody is working on packaging a new version, but have not yet uploaded that to the archive.
[05:46] <infinity> diwic: Er.
[05:46] <infinity> diwic: If they don't have the orig lying around, then they're going to accidentally build native.
[05:46] <pitti> bzr bd -S gets that all for you
[05:46] <infinity> diwic: I don't see how that's any better.
[05:47] <pitti> it downloads it through debian/watch
[05:47] <diwic> pitti, in the best of worlds, yes
[05:47] <diwic> but maybe one should fixup debian/watch in case it's wrong then
[05:47] <infinity> diwic: Having no tarball is better than accidentally flipping to native.  One's an error message people can learn to deal with, the other is irritating to fix.
[05:48] <pitti> yes, we do that in ~ubuntu-desktop, but they don't tend to change often
[05:49] <diwic> infinity, Eh, I'm not suggesting we do something completely wrong just to remove the error message.
[05:49] <micahg> pitti: the langpacks are built in a PPA and then copied to -proposed, right?
[05:49] <pitti> micahg: no, we'll build them directly in -proposed
[05:49] <micahg> pitti: ah, ok, nevermind then :)
[05:49] <pitti> micahg: we can't do binary copies from normal PPAs to -proposed unfortunately
[05:49] <diwic> I think pitti is right, we should make sure debian/watch is always able to download the orig source
[05:49] <pitti> that would require one of these "blessed" ppas
[05:49] <diwic> (or point to the orig source)
[05:50] <pitti> for debian/ only branches anyway
[05:50] <pitti> that makes them utterly convenient
[05:50] <pitti> debcheckout -a mysrc, bzr bd, there it is
[05:50] <diwic> But that is, unless somebody works with a git snapshot
[05:50] <pitti> yes, of course
[05:50] <diwic> rather than a source tarball
[05:51] <pitti> well, _and_ it isn't in the archive yet
[05:51] <diwic> yep
[05:51] <pitti> bzr bd will first try to download from archive, then from watch, then from get-orig-source
[05:51] <ScottK> Does it look in Debian too?
[05:51] <pitti> no, not right now
[05:51] <pitti> there's no reason why it couldn't, I guess it just didn't come up yet
[05:52] <infinity> Would make some sense.
[05:52] <pitti> in our GNOME world at least, downloading from upstream usually is what we want anyway
[05:52] <infinity> In fact, it would make sense to check Debian right after Ubuntu, to make sure there's no orig skew.
[05:52] <pitti> (for new versions)
[05:52] <infinity> (Cause skew sucks)
[05:59] <slangasek> bdmurray: does your "package already installed and configured" check speak Polish yet? (bug #904082)
[06:01] <ScottK> I think I filed a bug about that (checking Debian), but I don't recall for sure.
[06:03] <bdmurray> slangasek: no but it will
[06:03] <slangasek> hurray :)
[08:42] <pitti> zul, Daviey: do we want nova-console seeded anywhere? it currently wants to go to universe
[09:00] <jibel> pitti, another 'missing openoffice-dicts' bug 903869
[09:00] <pitti> bonjour jibel
[09:00] <jibel> pitti, good morning :)
[09:00] <pitti> jibel: thanks, will fix
[09:00] <pitti> darn, I thought I already caught all rdependencies
[09:03] <jibel> pitti, oh, it's not part of openthesaurus
[09:04] <jfi> Hello, actually, for precise should package sync from debian be requested or it is still automatically done?
[09:08] <pitti> jfi: Debian import freeze is Jan 12, so still automatic
[09:09] <jfi> pitti, ok, thanks
[09:10] <pitti> jibel: oh, I know why -- it doesn't depend on dictionaries-common
[09:11] <pitti> jibel: I'll try and start a complete archive grep then; I was hoping I could avoid it
[09:11] <jibel> pitti, I tried the other mythes-* and they install correctly.
[09:13] <doko_> TheMuso, pulseaudio ftbfs on any arch execpt amd64
[09:16] <pitti> jibel: bug 903869 is a hard nut to crack.. could I ask you or jamespage to re-run the main-all test once I did the two changes I mentioned in the bug?
[09:16] <pitti> jibel: how long does that take?
[09:20] <jibel> pitti, sure, it takes 2 hours or so
[09:34] <pitti> jibel: mythes-it fixed, updated dictionaries-common for the new Breaks:
[10:46] <pitti> jibel: ok, I think it's worth trying the main-all upgrade again
[10:46] <pitti> jibel: if it still fails, it should fail differently, but I have high hopes that it won't fail with this particular bug any more
[10:48] <jibel> pitti, I'll try as soon the lab is back.
[10:48] <pitti> jibel: oh, did it go out for lunch?
[10:49] <jibel> pitti, it rather didn't woke up this morning, so it missed breakfast too.
[10:51] <ppisati> why some libraries don't have the corresponding -dbg version? (e.g. libfuse2)
[10:51] <pitti> ppisati: we have -dbgsym packages for pretty much everything
[10:51] <pitti> https://wiki.ubuntu.com/DebuggingProgramCrash
[10:52] <ppisati> pitti: ok, let me try again
[10:52] <pitti> ppisati: in particular, we do have libfuse2-dbgsym
[10:55] <ppisati> pitti: i can't find it, where is it?
[10:56] <pitti> ppisati: you need to add the http://ddebs.ubuntu.com apt sources for it, as in above wiki page
[10:56] <ppisati> pitti: did
[10:56] <pitti> hm, did you run apt-get update?
[10:57] <ppisati> yes
[10:57] <ppisati> i'm in oneiric amd64
[10:58] <pitti> ppisati: does apt-cache search dbgsym give any results at all?
[10:59] <ppisati> [flag@newluxor ~]$ apt-cache search dbgsym | wc -l
[10:59] <ppisati> 8149
[10:59] <ppisati> pitti: ^^
[10:59] <pitti> ok, good
[11:00] <ppisati> pitti: can you point where the file is?
[11:00] <pitti> ppisati: sorry, just checked; we are indeed missing the libfuse2 dbgsym in oneiric
[11:00] <pitti> it's there in precise and older versions
[11:00] <ppisati> pitti: doh :(
[11:01] <pitti> http://ddebs.u.c. is a rather brittle makeshift solution, which was never meant to run for so many years
[11:01] <pitti> we are waiting for Launchpad to get real ddeb support
[11:02] <pitti> ppisati: so if you want to debug something, I'm afraid you'll need to rebuild the oneiric source locally with DEB_BUILD_OPTIONS=nostrip,noopt
[11:02] <ppisati> pitti: that was the plan, thanks for the support
[11:03] <pitti> ppisati: sorry, bad luck :/
[11:05] <pitti> jibel: so, good luck with the CPR!
[11:06] <wendar> doko: it's temporary while the maintainer of magics++ and libemos works out what he wants to do. more correct would be adding the linking flags for -lquadmath and -lgfortran in libemos (or farther up the chain, if that's where they're needed),  but  weighing between the options it seemed better to minimise the number of packages touched in the meantime.
[11:07] <wendar> doko: but, I'll fix up powerpc in a few hours (it's 3am at the moment)
[11:54] <zul> pitti: universe is fine
[13:44] <pitti> ugh, http://people.canonical.com/~ubuntu-archive/component-mismatches.svg just turned ... interesting
[13:45] <pitti> I suppose I revert libcommons-lang-java
[13:45] <pitti> (looks like an autosync)
[13:47] <ScottK> pitti: It is a really good case for that tool though.  I skimmed the component mismatches email and it's far easier to see the source of the problem in the picture.
[13:47] <scott-work> not sure this is the correct channel, if it isn't please point me in the right direction:
[13:47] <pitti> ScottK: even there it's a challenge to follow the line from the green bubble :)
[13:47] <pitti> but yes, quite easy to see the root of the problem
[13:48] <scott-work> ubuntu studio would like to be able to install .deb files, we used to use gdebi but it seems that software-center can do it now
[13:48] <doko> well, that's maven as its best
[13:48] <scott-work> do we need to include an extra package for software-center for it to install .deb files or will it do it natively?
[13:48] <scott-work> i meant local .deb files
[13:49] <ScottK> scott-work: mvo can answer that, I'm sure.
[13:49] <mvo> scott-work, ScottK: software-center will do it natively
[13:50] <scott-work> sweet, thanks mvo
[13:50] <mvo> yw
[13:50] <scott-work> we had a user having a problem but it might have been with a release where we didn't include software-center due to package name change
[13:50] <mvo> thats possible, I would welcome more info if its a real problem, but they should share the same backend code (debfile.py from python-apt)
[13:51] <scott-work> mvo: i'll see if i can find that email or question and do a quick check on it
[13:51] <ogra_> hmpf software-center is seriously broked here
[13:54] <mvo> scott-work: thanks
[13:59] <pitti> jibel, jamespage: any luck with reviving the QA lab?
[14:23] <scott-work> there is good talk on the jack-devel ML about dropping current jack1/jack2 and developing a new implementation...that's bloody exciting news!
[14:23] <scott-work> oh, crap...wrong channel, sorry
[14:27] <pitti> SpamapS: thanks for handling the kernel -proposed upload
[14:28] <pitti> SpamapS: I closed the task on the tracking bug, can you please do this next time, too?
[14:28] <pitti> SpamapS: btw, we don't usually run sru-accept.py on kernels, the kernel bot already covers this
[14:28] <pitti> SpamapS: (it doesn't hurt, of course)
[14:29] <rbasak> is there a channel for udd discussion? I'm trying to figure out where I can branch the current lucid-updates openldap from. That's at 2.4.21-0ubuntu5.6 but the bzr branches seem to be behind - lucid at 2.4.21-0ubuntu5, lucid-proposed at 2.4.21-0ubuntu5.5, lucid-updates at 2.4.21-0ubuntu5.4 and lucid-security at 2.4.21-0ubuntu5.4
[14:30] <rbasak> is lp:ubuntu/lucid-updates/openldap stuck in some way or is this expected?
[14:33] <geser> it got stuck by bug #653320 (see http://package-import.ubuntu.com/status/openldap.html)
[14:37] <rbasak> thanks geser, I'll go back to !udd for this one I guess
[14:38] <pitti> slangasek, mvo: bug 902603 is an interesting dpkg multi-arch bug; is that known to you already? WDYT about the proposed workaround to unbreak upgrades?
[14:39] <pitti> slangasek, mvo: tl;dr: if you have an empty metapackage and install the :i386 version of it, dpkg will consider the amd64 package entirely "replaced" and mark it as not installed
[14:40] <pitti> slangasek, mvo: but I can't mark it as M-A: foreign, as its dependencies are M-A: same (right?)
[14:45] <cjwatson> pitti: Sounds like the problem slangasek noted in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632555#20, although I can't find an actual dpkg bug report for it
[14:46] <cjwatson> Shipping a fake file to make the file lists distinct isn't a totally awful workaround
[14:46] <pitti> cjwatson: ah, thanks for the pointer
[14:47] <pitti> cjwatson: right, and harmless and easy to revert; I'd just have a better feeling once I get confirmation from Steve that it's an actual bug, not a mis-use of Multi-Arch:
[14:47] <mugwort13> anyone know the name of the ubuntu installer?   Like what I would search for in synaptic?
[14:47] <pitti> (and then making sure that's filed)
[14:47] <pitti> mugwort13: ubiquity, but you don't usually install that in an already installed system
[14:49] <mugwort13> pitti:  yes, I understand, this box has no cdrom & no usb , so I am going to install via wubi --> install via ubiquity --> uninstall wubi ... I hate doing it this way but the bios won't even allow pxe boot
[14:49] <mugwort13> thanks
[14:49] <pitti> mugwort13: you almost certainly want ubiquity-frontend-gtk then
[14:50] <mugwort13> kk
[14:50] <cjwatson> pitti: It is an actual bug
[14:50] <cjwatson> dpkg shouldn't be doing disappearance on all-files-common between two different architectures
[14:52] <pitti> cjwatson: can't find it either -- I guess I'll file it then
[14:53] <kenvandine> @pilot in
[14:56] <barry> doko: no idea why that would hang but i'll look at it
[15:04] <mvo> pitti: sorry for the delay, I was in a call. indeed, putting in a stuf file to keep it on the system sounds sensible to me
[15:04] <pitti> mvo: ok, thanks; I'm typing a Debian bug report for it, then I have less guilt applying a workaround
[15:04] <pitti> mvo: want me to CC: you, or not? (I'm CCing slangasek)
[15:06] <mvo> pitti: please do, thanks!
[15:07] <SpamapS> pitti: ... please.. can we write this all down?
[15:07] <SpamapS> pitti: I'm sorry if its already written down and I just forgot where it is.
[15:08] <pitti> SpamapS: https://wiki.ubuntu.com/ArchiveAdministration#Copying_PPA_kernels_to_proposed
[15:08] <SpamapS> pitti: bookmarked. Thanks. :)
[15:08] <pitti> SpamapS: FYI, I'm using https://bugs.launchpad.net/~ubuntu-sru/+assignedbugs?field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED
[15:08] <pitti> SpamapS: as a TODO list for what we need to do for kernels
[15:10] <SpamapS> it helps me to see it there in my bookmarks toolbar as "kernel->proposed" :)
[15:12] <SpamapS> pitti: ok, I've just been responding to pings fro skaet
[15:15] <cjwatson> pitti: I gather that multiarch bugs are better filed in Ubuntu at the moment
[15:15] <pitti> cjwatson: filed as Debian bug 652063 FYI (with some preemtive apology if that was too early, as that dpkg branch isn't in Debian yet)
[15:15] <cjwatson> oh well
[15:16] <pitti> cjwatson: bug 902603 is now the corresponding Ubuntu bug
[15:17] <pitti> cjwatson: at least now I'm comfortable with filing a workaround
[15:17] <pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html \o/
[15:17] <pitti> after only four days
[15:17] <pitti> jamespage: ^ FYI
[15:18] <pitti> and the http://people.canonical.com/~ubuntu-archive/component-mismatches.txt madness is gone, too
[15:18] <Daviey> no precise_probs?!  Can we ship now? :)
[15:18] <jamespage> ship ship ship ship!
[15:19] <jamespage> OH - not yet :-)
[15:19] <pitti> *cough* NBS, component-mismatches, FTBFS, etc :)
[15:19] <jamespage> pitti: w00t - its be a dry four days!
[15:19] <pitti> well, to be honest most of it was buildd lag
[15:19] <pitti> there were only a few real fixes there
[15:19] <pitti> but I helped it a bit with bumping some build scores
[15:20] <pitti> jamespage: and no jenkins to turn green :(
[15:20] <pitti> jamespage: still no response to CPR?
[15:24] <ogra> could an archive admin let the linux-ac100 package out of NEW ?
[15:25] <slangasek> pitti: 902603> I was sure I had filed a bug on dpkg for this in LP already, but I don't see it now
[15:25] <pitti> ogra: yes, can do
[15:25] <ogra> (needs to go to universe)
[15:26] <pitti> slangasek: I checked debian and ubuntu bugs, didn't find somethign with a searchable name ("disappear", "Multi-arch", "multiarch")
[15:26] <mvo> broder: silly question about backports - you do not have a "apt-show-backports" tools right? if not, do you want one?
[15:28] <mvo> (or maybe someone else from the ubuntu-backports team can help me with that question)
[15:39] <ScottK> mvo: What would such a tool do?  (It's not obvious to me from the name)
[15:42] <mvo> ScottK: it would show on the commandline what packages are available as backports (and also what packages that you have installed on your system have a backport)
[15:42] <ScottK> mvo: No.  I don't think we have such a thing and yes, I think it would be very nice.
[15:44] <mvo> ScottK: cool, now I just need to find a pkg to place it in and a good name (maybe the name is already good enough)
[15:56] <Daviey> barry (or anyone else)): should debian/pydist-overrides be used to state, i DON'T want a depends?
[15:57] <nemo> So. Just FYI for y'all
[15:57] <nemo> I did an "upgrade" of ubuntu 10.10 to 11.10
[15:58] <nemo> 3 times the install over existing one crashed. the 3rd time I noticed in the log an error on writing to /usr/local/man
[15:58] <nemo> said that there was already something there
[15:58] <nemo> so I blew away everything in /usr/local, which was all stuff I didn't really need anymore anyway
[15:58] <nemo> aaaaand, install worked the 4th time
[15:58] <ScottK> Direct upgrade from 10.10 to 11.10 isn't supported.  You need to do 10.10 -> 11.04 -> 11.10.
[15:58] <nemo> ScottK: I meant I popped in an 11.10 disc
[15:58] <nemo> and used the option in the disc to upgrade an existing install
[15:59] <nemo> ScottK: anyway. seems the installer has some bug WRT /usr/local/man - thought I'd toss it out there
[15:59] <nemo> ScottK: it was from 10.10 32bit to 11.10 64bit, so no form of normal upgrade would have worked.
[15:59] <ScottK> More likely software from outside the archive.  Ubuntu packages should never install anything there.
[15:59] <nemo> ScottK: sure. but. the installer shouldn't crash either
[16:00] <cjwatson> I agree, but please file a bug in LP rather than on IRC
[16:00] <ScottK> If you're trying to cross-grade between architectures I think the expected behavior is completely undefined.
[16:00] <cjwatson> no, this is defined
[16:00] <cjwatson> it's not a regular upgrade, it's more like save off everything not part of the system, blat new system in place, restore
[16:01] <nemo> cjwatson: eh. I file stuff there in detail, it languishes, then someone urges I retest 4 months later when my entire system is gone or a completely different config
[16:01] <cjwatson> nemo: stuff filed on IRC is *certain* to languish
[16:01] <nemo> cjwatson: I'm fed up w/ LP - it is basically a bug auto-expiring mechanism
[16:01] <cjwatson> I fix bugs in LP, not from IRC
[16:01] <nemo> cjwatson: yeah, but at least I don't get the heartbreak of the autoexpire :)
[16:01] <nemo> cjwatson: well. you now know as much about it as I do :-p
[16:02] <slangasek> bugs only autoexpire if requests for information from developers have gone unanswered
[16:02] <cjwatson> for the ten minutes until I forget, given that I'm in a meeting
[16:02] <ScottK> nemo: I understand you're frustration, but he's right.  Even if the odds are low, they are better in LP than here.
[16:02] <cjwatson> I agree the percentage of bugs fixed from LP is not as good as it should be, but IRC is AWFUL as a bug-reporting mechanism
[16:02] <nemo> ScottK: hm. I see that the upgrade put a symlink in - perhaps it was blowing up on trying to symlink something that was not a symlink
[16:02] <cjwatson> and worse as a bug-remembering mechanism
[16:02] <nemo> cjwatson: the worst thing is I file the bugs so other users can learn
[16:02] <nemo> cjwatson: and then someone closes it so my workarounds vanish
[16:02] <cjwatson> I suppose you can hope somebody else has already filed it, if you won't file it yourself
[16:02] <skaet> pitti, Spamaps - http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/kernel-sru-workflow.html is also useful to get an overview.
[16:03] <cjwatson> nemo: no, this is me asking you to file it and give me the number so that I can keep track of it
[16:03] <barry> Daviey: sorry, i don't know the answer to that
[16:03] <cjwatson> nemo: I'm one of the two or three people who can fix this bug so maybe it might be a good idea to listen :-)
[16:03] <ScottK> nemo: He's also the guy that fixes installer bugs, so I'd listen
[16:03] <ScottK> :-)
[16:03] <nemo> cjwatson: yeah, yeah. I'll get to it if I remember. in order to use launchpad from here I still have to integrate those <button> patches into my w3m
[16:03] <nemo> due to the login mechanism
[16:03] <Laney> mvo: yeah, that would be nice — is it something that apt could have a command for itself? More general than backports, for any NotAutomatic source
[16:03] <cjwatson> which I was able to find for you because they were tracked in LP ...
[16:04] <nemo> :-p
[16:04] <nemo> cjwatson: someone must have not autoexpired them like they do all my hardware bugs :)
[16:04] <cjwatson> what you're complaining about isn't fundamentally LP, it's that we don't have enough resource to fix all the bugs that get fixled
[16:04] <cjwatson> er, filed
[16:04] <cjwatson> refusing to file bugs doesn't particularly help that
[16:04] <nemo> cjwatson: sure. I just wish they were left open so other people would know. oh. hey. that laptop model has this problem. here is a workaround
[16:05] <nemo> what you guys need is a hardware database I could record this stuff in
[16:05] <cjwatson> oh, I agree with you and have been banging that drum for years; but refusing to file bugs doesn't help matters
[16:05] <ScottK> I think it's also the reasonable complaint that triagers do too much "is this still a problem" -> Incomplete triaging.
[16:05] <nemo> ubuntu version, hardware component, support, workaround
[16:05] <ScottK> nemo: You're talking with one of the Ubuntu devs that has been most outspoken about it and it still happens.
[16:05] <nemo> cjwatson: anyway. either I'll get setup on the external network, or I'll apply the w3m patch. I'll get to it eventually
[16:06] <nemo> but fundamental problem is /usr/local/man was a physical dir and installer apparently wanted to symlink to /usr/local/share/man  - it panicked and exploded
[16:06] <nemo> probably correct behaviour would have been mv /usr/local/man /usr/local/share/man
[16:06] <nemo> then symlink
[16:06] <cjwatson> sure, that is probably fixable.  but I want an audit trail for this
[16:07] <cjwatson> because otherwise it's hard for me to keep track of what bits of the code are there for
[16:07] <cjwatson> it's unfortunately rather complex
[16:08] <cjwatson> (I don't think we can decide how to move things around in /usr/local; we should just not fail)
[16:10] <tgall_foo> doko, ping - where are we at with libjpeg-turbo8 hitting the archive ?
[16:10] <nemo> cjwatson: hm. symlinks should work functionally the same, so you'd think moving would be harmless.  of course, the interesting thing is that the new /usr/local/share/man is empty anyway :)
[16:10] <nemo> cjwatson: so it blew up on trying to create an empty dir :D
[16:10] <nemo> guess it was some standard disc layout
[16:10] <cjwatson> complexity leads to failures; I'd rather keep it as simple as possible
[16:11] <nemo> it also made a bunch of other dirs - so maybe my blowing away all of /usr/local was important too
[16:12] <nemo> all empty btw :D
[16:12] <nemo> local$ find | xargs
[16:12] <nemo> . ./etc ./src ./man ./lib ./lib/site_ruby ./lib/site_ruby/1.8 ./lib/site_ruby/1.8/x86_64-linux ./lib/python2.7 ./lib/python2.7/dist-packages ./lib/python2.7/site-packages ./sbin ./bin ./share ./share/fonts ./share/man ./share/ca-certificates ./share/xml ./share/xml/misc ./share/xml/entities ./share/xml/schema ./share/xml/declaration ./share/ppd ./share/sgml ./share/sgml/dtd ./share/sgml/misc ./share/sgml/entities ./share/sgml/declaration
[16:12] <cjwatson> *please put this in a bug*
[16:12] <cjwatson> I am NOT going to remember this when I next have a chance to fix this
[16:13] <cjwatson> the above is very likely enough for me to set up a reproduction environment, and that's great
[16:13] <nemo> oh. one interesting side effect of this (bug blah blah blah)  was that on later attempts to install it decided it was upgrading from 11.10 to 11.10
[16:13] <nemo> instead of 10.10 to 10.10
[16:14] <cjwatson> yes, it had already overwritten the bit that said it was 10.10
[16:14] <cjwatson> notabug
[16:14] <nemo> I have no idea if this impacted its ability to ID existing packages, but I was missing a lot of packages
[16:14] <cjwatson> except insofar as the previous run failed
[16:14] <cjwatson> yes, it would have done
[16:14] <nemo> cjwatson: sure. I was just thinking it might have screwed up the upgrade
[16:14] <nemo> cjwatson: only way to avoid that would be if there was some sort of incomplete upgrade log
[16:14] <cjwatson> it probably would have done a bit
[16:14] <nemo> including enumeration of prior packages
[16:14] <nemo> that you could blow away once successful
[16:15] <nemo> cjwatson: it is a mild bug in that you could keep track of that if you wanted to. but certainly the circumstance shouldn't happen anyway
[16:15] <nemo> not like a user would be able to do much once they hit the crash anyway
[16:19] <nemo> yeah, reason I could blow away /usr/local/ is it just contained cuda (which I needed to update anyway) and Aventail (which workplace abandoned for something w/ even less linux support)
[16:21] <nemo> cjwatson: oh. one more thing. reason I didn't submit a crash report at the time, even though I had internet, was that it said it would include my password (!) in the crash report.
[16:22] <nemo> cjwatson: why is the installer keeping that in its memory so late in the install? or is that a just-in-case because it might have crashed in the hopefully tiny action to put it in a password file as soon as it is collected
[16:22] <nemo> heck. you'd think the first thing you'd do would be to hash it, wipe the original's memory location, then only use the hash until you can ditch it :)
[16:23] <nemo> you could probably even determine whether it was still in the installer's memory by a checkpoint on how far the installer got :)
[16:23] <nemo> anyway. scary message = no crash report from me ;)
[16:23] <nemo> I'm sure I'm not the only one
[16:24] <cjwatson> were you running the installer in debug mode?
[16:24] <nemo> I guess had I known that could happen I would have used a throwaway password and changed it after install
[16:24] <nemo> cjwatson: nope. just poppped in a standard disc
[16:24] <cjwatson> otherwise I don't recognise that message
[16:24] <cjwatson> oh, maybe:
[16:24] <cjwatson>     if os.path.exists('/var/log/installer/debug'):
[16:24] <cjwatson>         response = ui.yesno("The debug log file from your installation would help us a lot but includes the password you used for your user when installing Ubuntu.  Do you want to include this log file?")
[16:24] <nemo> yep
[16:25] <cjwatson> so (a) you have the option to submit a crash report without that debug log file
[16:25] <cjwatson> (b) I *think* it only includes that when in debug mode, but haven't checked
[16:25] <nemo> mm
[16:25] <nemo> well. apparently the installer did not know this :)
[16:25] <cjwatson> debug mode traces all debconf transactions without caring what it is, it's like strace
[16:25] <nemo> I assumed it was submitting some core file w/ installer's memory
[16:26] <cjwatson> anyway, you could have said no and filed the bug.
[16:26] <nemo> it made me all paranoid :-p
[16:26] <nemo> didn't want to accidentally send my password to a public server
[16:26] <nemo> heck. it had already crashed, I didn't trust it :)
[16:28] <mvo> Laney: yeah, good idea
[16:29] <Laney> :-)
[16:29] <cjwatson> slangasek: should bug 800561 be on rls-p-tracking, given that I don't think we can commit to fixing this until GI-friendly xklavier bindings are available?
[16:31] <slangasek> cjwatson: probably only if the xklavier GI dependency is also tracked... or if we want to commit to doing that ourselves
[16:32] <slangasek> pitti: ^^ do you know if we're going to get GI xklavier bindings this cycle, and when?
[18:54] <stgraber> cjwatson: looking at bug 219260, is that something you think we should try to solve this cycle (calling console-setup directly)
[19:18] <dobey> is there an easy way to install the amd64 kernel, but keep a 32bit userspace?
[19:36] <broder> dobey: i think linux-image-generic is multiarch cross-installable
[19:36] <broder> so apt-get install linux-image-generic:amd64
[19:36] <dobey> E: Unable to locate package linux-image-generic:amd64
[19:36] <broder> uh, echo foreign-architecture amd64 | sudo tee /etc/dpkg/dpkg.cfg.d/multiarch
[19:37] <broder> apt-get update, etc., etc.
[19:42] <broder> dobey: hmm...looks like that only works on precise, not oneiric, fyi
[19:42] <dobey> yeah, the packages seem to be broken
[19:42] <broder> it also may not willingly uninstall your current kernel before grabbing the foreign arch one - you may have to do that yourself
[19:43] <hallyn> mdeslaur: my gift to you is bug 903307.  As I don't have upload rights, i'll just leave it there with debdiff attached?
[19:43] <dobey> broder: ideally i'd like to have both installed, in case the amd64 one doesn't work
[19:44] <dobey> so i can at least boot my system again if it fails
[19:44] <mdeslaur> hallyn: is that my xmas gift? :)
[19:44] <hallyn> sorry there's no bow
[19:45] <hallyn> i was afraid it might still be due to some delta in our libvirt, but no, same thing on f16
[19:45] <mdeslaur> hallyn: does virt-manager reuse the same ssh tunnel if you have two consoles opened to the same server?
[19:45] <mdeslaur> my other question was if it could be because of the nc madness
[19:45] <hallyn> well it could be, but as i say it's also in f16
[19:45] <mdeslaur> hallyn: you tried with an ubuntu server, or ith a f16 server?
[19:46] <hallyn> i don't know how to pen two consoles to the same server
[19:46] <hallyn> both
[19:46] <mdeslaur> hallyn: ok, I'll take a look and upload it
[19:46] <hallyn> mdeslaur: thanks!
[19:46] <mdeslaur> hallyn: thanks!
[19:46] <hallyn> (i did send it upstream, we'll see what they say)
[19:48] <tgall_foo> doko, ping - where are we at with libjpeg-turbo8 hitting the archive ?
[19:49] <doko> tgall_foo, I know, on my todo list. did want to wait until armhf was bootstrapped
[19:49] <tgall_foo> ok thanks
[19:52] <micahg> doko: sorry about trillinos, I thought I had tried that build-dep switch
[19:58] <doko> micahg, well, the R build system is broken
[19:59] <doko> barry, see bug #904248 and bug #904249, python-central isn't a big issue anymore, python-support requires some more effort
[20:00] <barry> doko: ack, thanks
[20:04] <iceroot> can someone tell me why libgnome-control-center1 has a "1" at the end? in changelog its just called libgnome-control-center
[20:05] <iceroot> apt-cache search libgnome-control-center
[20:05] <micahg> iceroot: binary vs source naming?
[20:08] <iceroot> micahg: ah its some of these "one source-package but many binary-packages" in debian/control there is libgnome-control-center and libgnome-control-center1
[20:10] <micahg> iceroot: source is gnome-control-center, libgnome-control-center1 is the binary package
[20:10] <iceroot> micahg: but why libgnome-control-center1 and not libgnome-control-center as binary
[20:10] <micahg> iceroot: SONAME versioning probably
[20:11] <iceroot> micahg: ok, thanks for the info
[20:11] <infinity> iceroot: library package names have the SOVER in the package name.
[20:12] <infinity> iceroot: So that if there's ever a libgnome-control-center.so.2, it will be co-installable as libgnome-control-center2
[20:12] <iceroot> infinity: ah ok, thanks for the example now i get it
[20:34] <jtaylor> lamont: can you give some insight on whats going wrong here: https://launchpadlibrarian.net/87386428/buildlog_ubuntu-precise-i386.pyzmq_2.1.10-2_FAILEDTOBUILD.txt.gz
[20:34] <jtaylor> lamont: it seems to fail binding to <IP_ADDRESS> on i386 and amd64 but not on arm, local and on debians i386 and amd64 buildd's
[20:35] <jtaylor> the testsuite does not require internet access
[20:42] <debfx> slangasek: do you have a moment to review my phonon multiarch changes?
[20:43] <cjwatson> stgraber: it's a technical debt item, but it has a substantial chance of regressions; I don't think it would be a good candidate for this cycle
[20:43] <cjwatson> dobey: it does work on precise, FWIW, although you can only (easily) have one or the other, I think
[20:43] <cjwatson> dobey: I'm running an amd64 kernel with an i386 userspace on this system, having put some effort in at the start of the cycle to get this working
[20:43] <slangasek> debfx: not this moment; I would in an hour or so
[20:43] <stgraber> cjwatson: ok, won't touch that one then :)
[20:45] <dobey> cjwatson: ok, maybe i'll upgrade this system; i'll try it on another machine first
[20:45] <debfx> ok
[20:46] <broder> cjwatson: i don't suppose there's any chance you took measurements of memory savings in that setup vs. all i386? i'm curious how it compares to cking's numbers
[21:04] <kenvandine> @pilot out
[21:05] <cjwatson> broder: no, sorry
[21:05] <broder> i'm assuming bryceh isn't still piloting at this point
[21:26] <barry> tumbleweed: will you sync precise python-virtualenv to 1.7-1 when it lands, or do you want me to?
[21:29] <bryceh> broder, yeah sorry forgot to log out
[23:22] <TheMuso> doko: Yes I know, I gave it back on amd64, but had to leave before I could give back on other arches.
[23:24] <slangasek> TheMuso: ah, so a give-back should fix it? Are you doing that now?  I was about to come pestering about that myself :-)
[23:31] <doko> qcontrol only built for armel??? https://launchpad.net/ubuntu/precise/+source/qcontrol/0.4.2-7
[23:32] <infinity> doko: Architecture: armel
[23:32] <infinity> doko: Right in the .dsc
[23:33] <doko> infinity, ok, building for armhf too
[23:51] <TheMuso> slangasek: yes gave them all back.
[23:51] <slangasek> TheMuso: great, thanks