[00:00] <menn0> jw4: i will keep digging now
[00:00] <wallyworld> ericsnow: why the dial changes?
[00:00] <jw4> menn0: I'll be in and out for the next few hours... making supper for kids, and then school open house - I'll try to get on longer later
[00:00] <menn0> jw4: no worries
[00:04] <ericsnow> wallyworld: in 1.2 http.Transport doesn't have the KeepAlive field, so I had to manually create the same effect
[00:05] <wallyworld> ok
[00:09] <ericsnow> wallyworld: thanks for the review :)
[00:09] <wallyworld> np
[00:19] <mup> Bug #1447853 was opened: Local charms are not added to storage on upgrade to 1.22.x <charms> <regression> <storage> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1447853>
[00:23] <wallyworld> menn0: fixes pushed when you get a chance
[00:23] <menn0> wallyworld: kk
[00:26] <menn0> wallyworld: ship it
[00:26] <wallyworld> \o/
[00:26] <wallyworld> ty
[00:31] <mup> Bug #1447853 changed: Local charms are not added to storage on upgrade to 1.22.x <charms> <regression> <storage> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1447853>
[00:40] <mup> Bug #1447853 was opened: Local charms are not added to storage on upgrade to 1.22.x <charms> <regression> <storage> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1447853>
[00:52] <sinzui> wallyworld, I am exhausted. I haven't found much. I split bug 1447846 from the other upgrade issue and captured some unit log
[00:52] <mup> Bug #1447846: Hooks don't fire after upgrade 1.23.0 <hooks> <regression> <upgrade-juju> <juju-core:Triaged by menno.smits> <juju-core 1.23:In Progress by menno.smits> <https://launchpad.net/bugs/1447846>
[00:53] <wallyworld> sinzui: ty, menn0 is working that bug at the moment
[00:53] <sinzui> wallyworld, mgz and I also discovered bug 1447853, but I know have a cheep work around
[00:53] <mup> Bug #1447853: Local charms are not added to storage on upgrade to 1.22.x <charms> <regression> <storage> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1447853>
[00:53] <wallyworld> ah bollocks, saw that float past
[00:54] <wallyworld> will have to fix for 1.24
[00:54] <sinzui> wallyworld, the work around is to upgrade-charm --force. it works a minute later :)
[00:54] <wallyworld> at least there is that
[02:01] <ericsnow> anyone have a minute to review a patch for a very mechanical change: https://github.com/juju/govmomi/pull/2
[02:30] <menn0> fwereade: ping?
[02:34] <menn0> jam: ping?
[03:00] <menn0> wallyworld: i have a learned a lot more about the hook not firing bug
[03:00] <menn0> wallyworld: not sure I know how to fix it though
[03:00] <wallyworld> oh?
[03:01] <wallyworld> did you want to talk?
[03:01] <menn0> wallyworld: having jam or fwereade around would be handy. it's leader related.
[03:01] <wallyworld> oh joy
[03:01] <wallyworld> jam will be online soonish
[03:01] <menn0> wallyworld: quick chat would be good
[03:01] <wallyworld> ok, same hangout
[03:02] <menn0> wallyworld: i'm there now
[03:25] <wallyworld> menn0: if you get a chance, but doesn't matter if not http://reviews.vapour.ws/r/1481/
[03:26] <menn0> wallyworld: got it
[03:40] <jw4> menn0: does that mean it's not related to my changes?
[03:41] <menn0> jw4: at this stage it's looking like the hooks not firing issue is related to the leadership work
[03:41] <menn0> jw4: i'm not any wiser about that mode error in the logs though
[03:42] <jw4> menn0: well I know about the error - that's not critical
[03:42] <jw4> menn0: cool, I'll try and dig into it too
[03:42] <jw4> for my edification
[03:43] <menn0> we just had an earthquake, 6.4 but very deep
[03:44] <jw4> whoa
[03:44] <menn0> because of the depth it wasn't that severe
[03:44] <jw4> menn0: any damage
[03:44] <menn0> but my chair was rolling around by itself
[03:45] <menn0> no damage i think but it was a strange rolling feeling and went on for a while
[03:45] <menn0> i've only experienced short "bangs" up until now
[03:45] <anastasiamac> menn0: is south island sinking?
[03:45] <jw4> that's freaky... are earthquakes common in that area? Pacific Rim and all
[03:45] <menn0> yep, quite common in NZ
[03:48] <jw4> anastasiamac: he's ignoring the question... I think he's rescuing pets or something
[03:49] <menn0> anastasiamac: probably :)
[03:50] <jw4> quite a bit of activity recently: http://www.geonet.org.nz/quakes/felt
[03:51] <anastasiamac> jw4: :D
[03:51] <jw4> :)
[03:51] <anastasiamac> menn0: u should have apost-earthquake party, considering it's friday
[03:56] <menn0> anastasiamac: they're a little too common to be having parties for each one :)
[03:57] <anastasiamac> menn0: on a serious note, it's gr8 that it was deep. 6.4 sounds really scary... :))
[03:59] <menn0> anastasiamac: yes. this one was the same magnitude as the one that did this a few years ago: http://en.wikipedia.org/wiki/2011_Christchurch_earthquake
[04:00] <menn0> the city is still a long way from recovering from that one
[04:09] <wallyworld> menn0: the earth moved for you in cape town as well didn't it?
[04:10] <menn0> wallyworld: ssh not in public :)
[04:11] <mup> Bug #1447895 was opened: Panic if jujud restarts while action is running <actions> <juju-core:New> <https://launchpad.net/bugs/1447895>
[04:11] <mup> Bug #1447899 was opened: upgrade fails if no explicit version is specified <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1447899>
[04:28] <jw4> nice sleuthing menn0
[04:28] <menn0> jw4: with the hook not firing bug?
[04:28] <jw4> yeah
[04:29] <jw4> finding the WatchLeadershipSettings missing document
[04:50] <menn0> wallyworld, jw4: bingo!
[04:50] <menn0> wallyworld, jw4: I have a fix for the hook not firing issue
[04:51] <menn0> wallyworld, jw4: adding an upgrade step that adds the leadership documents in the settings collection fixes the issue
[04:51] <menn0> wallyworld, jw4: I hacked it in without tests so let me sort that out before proposing
[04:52] <jw4> menn0: suh-weet!
[04:59] <menn0> wallyworld, jw4: initial, rough fix for hooks not firing issue
[04:59] <menn0> https://github.com/mjs/juju/tree/1447846-hooks-dont-fire-after-upgrade-1.23
[04:59] <menn0> writing the tests now
[05:04] <jw4> other than missing docstring on https://github.com/juju/juju/compare/1.23...mjs:1447846-hooks-dont-fire-after-upgrade-1.23#diff-d7b2b2c8e8ce6dfc1b7f09c3cf9744d1R1203
[05:04] <jw4> and forthcoming tests...
[05:04] <jw4> looks great menn0
[05:13] <wallyworld> menn0: branch looks good, still want to understand why listener hangs if there's no record. i think that's poor behaviour
[05:14] <jw4> wallyworld: I bet it's because the watcher isn't returning an initial empty event, like it's supposed to
[05:15] <jw4> wallyworld, menn0 it was a little tricky getting that initial guaranteed event in the Action Watchers, so I wouldn't be surprised if the Leadership Watchers have a problem there too
[05:15] <menn0> jw4: I think the problem here is that the code assumes the leadership doc will be there b/c it is for services created under 1.23
[05:16] <menn0> jw4: but someone forgot to write this upgrade step
[05:16] <jw4> the Watchers (afair) are supposed to guarantee an initial event, possibly empty, even if there are no records...
[05:16] <menn0> jw4: and without the doc there when the watcher is created the initial event isn't fired
[05:16] <menn0> jw4: are you sure about that?
[05:16] <jw4> menn0: yeah, I think you're right, but I remember fwereade stressing to me the importance of that... (but I could be remembering wrong)
[05:17] <jw4> (the importance of the initial, possibly empty, guaranteed event)
[05:17] <menn0> jw4: yeah, I know there's been talk about this but I'm not exactly sure what should happen
[05:18] <jw4> hopefully fwereade will be on soon and will chime in... I guess it's EOD for you though now (and EOW)
[05:19] <menn0> jw4: i've got a bit more time left
[05:19] <menn0> jw4: i'm going to try and get this fix done as much as I can
[05:20] <menn0> jw4: regardless of what the watchers are supposed to do I'm pretty sure we want this upgrade step
[05:20] <jw4> menn0: regardless, I think your fix is appropriate in this case
[05:20] <wallyworld> jw4: exactly, but to me that's not how i thought the watchers worked
[05:21] <wallyworld> +1
[05:21] <jw4> wallyworld: yeah, I'm fairly confident that's how I was instructed to implement the actions related watchers, but we should verify
[05:32]  * jw4 off to bed
[05:51] <menn0> wallyworld: ping
[05:52] <wallyworld> yo
[05:52] <menn0> wallyworld: i have to EOD very soon
[05:52] <wallyworld> one sec
[05:54] <wallyworld> back
[05:54] <menn0> wallyworld: just need to hand over the fix for this
[05:54] <menn0> wallyworld: pushing now...
[05:54] <menn0> wallyworld: give me a sec
[05:54] <wallyworld> sure, is it ready to land after review?
[05:54] <wallyworld> or tests needed?
[05:55] <menn0> wallyworld: the hard tests are done
[05:55] <menn0> wallyworld: just needs a test for upgrade step idempotency
[05:56] <wallyworld> ok
[05:58] <menn0> it's here: https://github.com/mjs/juju/tree/1447846-hooks-dont-fire-after-upgrade-1.23
[05:58] <wallyworld> menn0: i'll either do it or hand over; it's my son's birthday today and i have to go to dinner soonish. either way will be done. thanks for fixing
[05:58] <menn0> it's ready to go apart from that one test
[05:59] <menn0> if no-one gets it done today it'll take me almost no time on Monday
[05:59] <menn0> wallyworld: and we need to forward port to master
[05:59] <wallyworld> ok, np. tbh, i don't think we are cutting a release on friday anyway
[06:00] <wallyworld> but it's now done so the risk is removed
[06:02] <menn0> wallyworld: ok good
[06:02] <menn0> wallyworld: well have a good night and a weekend
[06:02] <menn0> speak to you next week
[06:54] <wallyworld> fwereade: you online?
[10:17] <wallyworld> fwereade: hiya
[10:28] <wallyworld> TheMue: hi there, you ocr? would love a review of this so as it needs to land for 1.24 http://reviews.vapour.ws/r/1481/ it removes a feature flag
[11:13] <wwitzel3> jam: ping
[11:27] <mattyw> wwitzel3, ping?
[11:30] <wwitzel3> mattyw: pong
[11:40] <fwereade> wallyworld_, so do we still serve client facade v0? I'm not seeing where we do
[11:40] <fwereade> wallyworld_, and that would STM to be a problem...
[11:41] <wallyworld_> fwereade: ah, right, i wasn't sure about that. i wasn't sure what the exact mechanism was there
[11:42] <fwereade> wallyworld_, the ideal, I think, is to *never touch* the client API, and carve off changing functionality into more service-specific facades
[11:42] <fwereade> wallyworld_, otherwise you have to have an almost-perfectly-cloned Client facade
[11:43] <fwereade> wallyworld_, then when (say) storage evolves, it shouldn't need to hit more than one or two small facades
[11:43] <fwereade> wallyworld_, rather than dragging the Client mess into the equation every time
[11:44] <fwereade> wallyworld_, what actually changed on Client?
[11:44] <wallyworld_> fwereade: yeah sadly i think you are right, i'll have to do that, but will miss the branching of 1.24. bollocks. will have to forward port
[11:44] <fwereade> wallyworld_, bad luck :(
[11:44] <wallyworld_> fwereade: new params to 2 apis were added
[11:45] <wallyworld_> fwereade: if a newer client adds additonal params to the call, they will be ignored, but we need a way to tell the user
[11:45] <wallyworld_> hence the api bump
[11:45] <fwereade> wallyworld_, yeah, indeed, it really is a different API
[11:46] <fwereade> wallyworld_, so I *think* that the right thing to do
[11:46] <fwereade> wallyworld_, is to pull out a Service service facade from client
[11:46] <wallyworld_> yeah, i suspect so too
[11:46] <wallyworld_> i'll revisit over the weekend
[11:47] <wallyworld_> i really want to remove the flag for 1.24
[12:35] <perrito666> morning
[12:44] <mgz> perrito666: wala
[12:45] <redelmann> perrito666, ¿good? morning
[14:02] <katco> wwitzel3: ericsnow: stand up
[15:56] <alexisb> all, looking at this: https://bugs.launchpad.net/juju-core/+bug/1447846
[15:56] <mup> Bug #1447846: Hooks don't fire after upgrade 1.23.0 <hooks> <regression> <upgrade-juju> <juju-core:Triaged by menno.smits> <juju-core 1.23:In Progress by menno.smits> <https://launchpad.net/bugs/1447846>
[15:57] <alexisb> ^^^ based on menno's last comment is this something someone can pick up and complete today?
[15:57] <jw4> alexisb: menn0 said it's almost done.. just one test for idempotency left
[15:58] <katco> alexisb: yeah looks doable for someone to pick up
[15:58] <alexisb> katco, can you please delegate
[15:58] <katco> alexisb: sure
[15:58] <alexisb> thanks
[15:59] <katco> moonstone are all currently working on bugs. any volunteers?
[16:03] <katco> cherylj: perrito666: do you two have capacity to land a simple bug?
[16:07] <perrito666> katco: sorry I dont feel really reliable right now.
[17:04] <katco> perrito666: no worries. feel better soon
[17:04] <katco> cherylj: sorry i lost connection. can you take that bug?
[17:23] <natefinch> man I really hate that we require go 1.2 for juju, it totally screws up my development environment for everything else... and many projects already require 1.3+
[17:26] <katco> natefinch: here's my setup
[17:26] <katco> natefinch: ~/.local/go-1.{2,3,4}
[17:26] <katco> natefinch: ~/.local/go -> go-1.2 during day
[17:26] <katco> natefinch: export GOPATH=~/.local/go
[17:26] <katco> natefinch: there is some churn with having to rebuild utils
[17:27] <ericsnow> hmmm...virtualenv for go...
[17:27] <katco> ericsnow: or there's that :)
[17:29] <natefinch> ericsnow: there's a tool for that... forget which of the myriad tools out there it is.  of  course, as katco said, you can always just run them side by side.
[17:32] <katco> natefinch: wwitzel3: planning time!
[17:32] <wwitzel3> I'm there?
[17:33] <wwitzel3> is it not in moonstone? .. (checks calendar)
[17:34] <natefinch> wwitzel3: not moonstone
[17:50] <wwitzel3> cmars: http://reviews.vapour.ws/r/1484/
[17:55] <cmars> wwitzel3, so i guess CI is going to set that feature flag to get that test to pass? what's the difference between not registering the provider vs. blocking bootstrap?
[17:57] <wwitzel3> cmars: the code on the unit doesn't see the provider as registered since the flag is local
[17:57] <wwitzel3> cmars: jam pointed this out no the ML and the QA ran in to it with CI tests
[17:58] <aznashwan> hey; could I please get a quick review on http://reviews.vapour.ws/r/1486/
[17:58] <cmars> wwitzel3, ok, got it. so this moves the featureflag check to the client? in what context does environ.Bootstrap run?
[17:58] <cmars> (environ's not an area of the codebase I'm familiar with)
[17:58] <aznashwan> it's a simple module; ~100 lines of code that actually does something
[18:03] <wwitzel3> cmars: just during juju bootstrap
[18:34] <natefinch> cmars: quick review?  http://reviews.vapour.ws/r/1487/diff/#
[18:40] <wwitzel3> cmars: thanks for the review
[19:53] <perrito666>  /query alexisb
[19:53] <perrito666> well, another bug in my irc client
[19:53] <perrito666> I should stop using daily snapshots
[20:24] <natefinch> sometimes I think Juju is the biggest example of what not to do with interfaces :/
[20:25] <perrito666> you exagerate
[20:25] <natefinch> perhaps slightly
[20:25] <natefinch> there might be a few worse examples in the world ;)
[20:27] <natefinch> I like the way everything is a nice generic interface and then in the comments we just say "this is for precise0
[20:27] <natefinch> s/0/"
[20:34] <perrito666> natefinch: I think that is an example on how not to used a typed language
[21:10] <mgz> anyone still around for trivial reviews?
[21:16] <mup> Bug #1448308 was opened: Skipped TestUniterUpgradeConflicts on ppc64 <skipped-test> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1448308>
[21:21] <ericsnow> mgz: sorry I missed that format stuff :/
[21:22] <ericsnow> anyone around that feels comfortable reviewing http://reviews.vapour.ws/r/1490/
[21:23] <ericsnow> it fixes the "hooks not firing" bug
[21:23] <ericsnow> #1447846
[21:23] <mup> Bug #1447846: Hooks don't fire after upgrade 1.23.0 <hooks> <regression> <upgrade-juju> <juju-core:Triaged by menno.smits> <juju-core 1.23:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1447846>
[21:23] <mgz> ericsnow: I can look
[21:23] <ericsnow> mgz: oh, cool
[21:24] <mgz> ericsnow: I also have a trivial ppc64 test skip branch
[21:24] <ericsnow> mgz: note that I only added the idempotency test, menn0 did the rest
[21:24] <mgz> /1488
[21:24] <ericsnow> mgz: I'll take a look
[21:24] <mgz> ericsnow: yeah, I already looked over menno's branch
[21:24] <ericsnow> mgz: nice
[21:25] <ericsnow> mgz: I'm pretty sure I got the idempotency check right
[21:27] <ericsnow> mgz: in the bug you make it sound like skipping the test might be masking a real bug
[21:28] <mgz> ericsnow: it might be, but we hav ehte bug, and know we need to do functional testing of the leadership stuff
[21:28] <ericsnow> mgz: k
[21:29] <ericsnow> mgz: so 1448308 will be closed only as soon as we resolve the issue (and not when the skip-the-test patch merges), right?
[21:29] <mgz> ericsnow: how-upgrades-work question
[21:29] <ericsnow> mgz: sure
[21:30] <mgz> ericsnow: indeed, I'm keeping the skipped-tests bugs open, because we keep filing bugs and linking them in the codebase, but counting them as fixed when the test is skipped
[21:30] <mgz> which is wrong...
[21:31] <ericsnow> mgz: cool, then LGTM
[21:31] <mgz> I'm on 1.23.0 which did not do this step, my state server notices there's a 1.23.2 with this fix and downloads it... how does it know to run this step?
[21:32] <mgz> we just always do steps on new versions and the steps must apply?
[21:32] <mgz> even minor ones, right?
[21:33] <ericsnow> mgz: I'm not sure, but...the idempotency invariant of upgrade steps ensures it's a noop if you're already okay
[21:33] <mgz> right
[21:34] <ericsnow> I expect it simply runs all the steps
[21:37] <mgz> ericsnow: test changes look good
[21:37] <ericsnow> mgz: k, cool
[21:38] <ericsnow> mgz: it made sense to factor out that stuff into helpers :)
[21:38] <mgz> I'd be somewhat interested in a test that ran the step on a as-if just bootstrapped system, no services
[21:39] <mgz> we don't try and do all error paths in these things, but that one does seem relevent
[21:41] <ericsnow> mgz: so basically the same thing as the existing test but without adding any services first?
[21:42] <mgz> (it should just return success without running any ops basically)
[21:42] <mgz> ericsnow: yup
[21:42] <ericsnow> mgz: I'll add such a test!
[21:42] <mgz> ericsnow: lgtm
[21:43] <mgz> hm, can I shipit and leave a comment in the same thing? not sure on the magic
[21:43] <mgz> I guess I jsut include that string in my text huh.
[21:58] <ericsnow> mgz: so is it correct that CI covers the upgrade scenarios now (i.e. the bug trigger will get exercised)?
[21:59] <mgz> ericsnow: see all the failures on upgrade jobs on 1.23 and trunk :)
[22:00] <ericsnow> mgz: that's what I figured :)
[22:00] <ericsnow> mgz: thanks for the review
[22:00] <mgz> http://reports.vapour.ws/releases/2557
[22:30] <mgz> "panic: rescanned document misses transaction in queue" ...that one's new to me
[22:43] <ericsnow> mgz: yeah, me too :\
[22:47] <ericsnow> mgz: hmmm...see #1318366
[22:47] <mup> Bug #1318366: jujud on state server panic misses transaction in queue <cloud-installer> <landscape> <orange-box> <panic> <performance> <sm15k> <juju-core:Fix Released by menno.smits> <juju-core 1.20:Fix Released by menno.smits> <juju-core (Ubuntu):Fix Released> <https://launchpad.net/bugs/1318366>
[22:48] <fwereade> ericsnow, menn0, dammit, sorry, thanks
[23:00] <ericsnow> mgz: I'm going to ask menn0 to double check the upgrade step and tests when he gets a chance; that failure is a little suspicious.
[23:06] <mgz> ericsnow: seems wise, we're not in a rush now
[23:07] <ericsnow> mgz: yep :)


[00:02] <xnox> .... one must not run -proposed on development release....
[00:02]  * xnox is not ssure where tmartins went.
[00:35] <ThiagoCMC> xnox, why not enable proposed on development branch ? Everything is fine here, it was my confusion...   =)
[00:36] <xnox> ThiagoCMC, humans should not run -proposed on the devel release.
[00:37] <xnox> ThiagoCMC, it's not meant for end user consumption, and only for automated systems. it has all abi transitions in progress, and shall be used by buildds only, and automated testing. once things are good, things migrate to release pocket. Hence for "rolling" release one should run devel release only, without -proposed enabled. -proposed has like 700 broken packages at the moment. Whereas devel without -proposed should be entirely installable.
[00:38] <xnox> and we remove things from -proposed when we realise we uploaded really broken things, that fail testing.
[00:38] <xnox> (e.g. autopackage tests, and britney transitions, arch skew etc.)
[00:39] <ThiagoCMC> got it
[00:39] <ThiagoCMC> thank you!
[00:40] <xnox> ThiagoCMC, in practice, without -proposed one gets shiny stuff, daily, with a small delay, and never broken things. Or so is the effort =)
[00:41] <ThiagoCMC> sounds cool
[02:57] <goddard> why doesn't the resolution get set on tty and lightdm when inside unity?
[02:58] <goddard> i have a 2k laptop screen, but i run in 1080p because it saves battery and is more readable, but my tty and lightdm screens are 1440p
[02:58] <goddard> why don't they just read what Unity has set?
[06:04] <infinity> pitti: Hrm.
[06:05] <infinity> pitti: What will trigger libselinux to retry against the new glibc?
[06:06] <Mirv> pitti: I guess autopkgtest infra is still struggling and there's a new glibc too. anyway, updated kwin + marble were copied from a landing PPA 12h ago so for now I just wait
[06:21] <pitti> Mirv: right, see http://autopkgtest.ubuntu.com/running.shtml -- I suppose at some point we need to cut off the triggered tests for glibc, they won't ever all succeed anyway; but we should give it some time so that we get enough results to be confident
[06:21] <pitti> infinity: at the moment this needs to be done manually; there's a bug report against britney to do it automatically
[06:46] <pitti> infinity: I re-ran selinux now
[08:03] <Saviq> Mirv, morning, I've been havnig trouble with xenial proposed unfortunately, upgrading to it made unity8 crash-loop :/, trying from scratch again, but another thing is that apt reported additional 24MB of disk space used, we should make certain what's happening there...
[08:05] <Mirv> Saviq: did you remove QML cache?
[08:06] <Saviq> Mirv, d'oh
[08:06] <Mirv> :)
[08:07] <Saviq> Mirv, any case, the "additional 24MB" is scary
[08:08] <Saviq> Mirv, but yeah, removing QML cache helped :)
[08:08] <Mirv> Saviq: right, do you have scrollback of the upgrade? I remember some new dep was being installed, but I thought it was small. I wonder what has then bloated and how much.
[08:09] <Mirv> Saviq: yes, I was at some point apport-retrace:ing and seeing "wow, crashing inside v4!" until I remebered that right... this feels familiar
[08:09] <Saviq> Mirv, no, scrolled off I'm afraid, but I'll try from scratch anyway
[08:10] <Mirv> Saviq: ok, let's check the newly installed packages first and then consider comparing the package sizes of themselves
[08:12] <Mirv> Saviq: there seems to be also new poppler and apt libraries in proposed that when upgrading are installed alongside the old ones, those make up >4MB already
[08:13] <Saviq> Mirv, right, might try going the silo route instead
[08:13] <dholbach> good morning
[08:13] <Saviq> moi
[08:13] <Saviq> n
[08:15] <Mirv> Saviq: FYI necessary packages are spread to two silos 012 + 059 so that'd mean manual configuring and pinning of both
[08:16] <Saviq> Mirv, ack
[09:03] <zzarr> hello! is there a way to install a 16.04 framework (kit) in Qt (Ubuntu SDK)?
[09:18] <Unit193> cjwatson: Dang you are on top of it then, just saw your comment in the twisted bug about switching to Pyca.  Nice!
[09:22] <Odd_Bloke> doko: Did you get a chance to look at the new comment on bug 1500768?  It looks like we still have a problem with the urllib3 that's bundled in python-virtualenv.
[09:48] <snkt> hiii
[09:49] <snkt> Can anyone help me how to customize Live ubuntu ISO to autologin with root
[11:03] <caribou> Anything obvious could explain the fact that, on one node, rsyslog exits with a SEGV when started by upstart but works fine if started from a shell ?
[11:35] <cjwatson> Unit193: Well, that was only in passing really, I'm not actually working on the Twisted->PyCA thing
[11:35] <Unit193> Didn't look like you were, just looked like you were watching it.
[12:06] <cjwatson> Unit193: The really horrible archaisms (SHA-1 only) are out of the way now, but it'd certainly be nice to be able to add ECC and whatnot.
[12:07] <Unit193> cjwatson: Indeed, personally I'm waiting for Ed25519 support.  I'm trying to use it everywhere, even though the router's dropbear sshd won't get it anytime (soon.)  Already was crazy enough to cross build putty for PA.c.  Anywho, no need to be taking up your time here with this.
[12:27] <cjwatson> doko: Mind if I merge ncurses?
[12:57] <pete-woods> pitti: it's that time again! (https://github.com/martinpitt/python-dbusmock/pull/17)
[13:29] <doko> cjwatson, please do
[13:30] <cjwatson> doko: ok, thanks
[13:53] <davidsha> Quick question, is pciutils supposed to support libkmod on Ubuntu? I've seen it's supported on fedora and I'm just curious.
[13:56] <cjwatson> davidsha: you seem to have filed a bug, which I think is the appropriate thing to do.  I'll forward it to Debian though.
[13:57] <davidsha> cjwatson: thanks, sorry for bugging you guys about it!
[14:09] <cjwatson> davidsha: forwarded, and linked the LP bug
[14:09] <cjwatson> (https://bugs.launchpad.net/bugs/1516095)
[14:12] <davidsha> cjwatson: thanks!
[14:25] <ubiquity> how to create official ISO from ubuntu source?
[14:30] <highvoltage> you can't create official ISOs
[14:31] <highvoltage> (well afaik)
[14:32] <sladen> ubiquity: google for Ubuntu ISO customisation
[14:34] <xnox> doko, it is ok to upgrade to new cython point release? =)
[14:34]  * xnox uploaded it...
[14:36] <ubiquity> livecd customization can create the same iso as the official one?
[14:36] <doko> xnox, why do you ask then? ;p
[14:37] <xnox> ubiquity, if it ends up the same, why customize. if it's different, it's not official anymore now is it =) only ubuntu publishes official images ;-)
[14:37] <xnox> ubiquity, it will boot and it will install. but if you use packages or sources not from the archive, you will have to support it yourself.
[14:38] <ubiquity> i want to know the process to create the official ISO
[14:43] <doko> xnox, fyi, https://launchpadlibrarian.net/228711711/buildlog_ubuntu-xenial-s390x.gcc-5_5.3.1-0ubuntu1_BUILDING.txt.gz
[14:43] <xnox> doko, >infinity ^
[15:05] <smoser> xnox, was away yesterday. wrt qemu, talk to hallyn
[15:06] <xnox> smoser, cool, thanks.
[15:06] <xnox> hallyn, i'd like to have qemu 2.5 sooner, rather than later. Can we start working on packaging rc release? and are we targetting to ship with 2.5? Should we package them in ubuntu proper, or ppa?
[15:08] <xnox> stgraber, i see you mark procps as please take, on MoM. I shall take it, as I need fixes from the merge.
[15:09] <xnox> ... unless doko do you want to merge procps? =)
[15:12] <doko> xnox, go ahead
[15:27] <stevenm_> Hey, anyone here familiar with the ubiquity installer?  i'm looking at the bottom of the ubiquity/plugins/ubi-prepare.py file
[15:28] <roaksoax> pitti: howdy! is there a way to force an app to use a newer postgress in packaging? ie. upgrading from trusty to xenial would mean a change of postgres versions
[15:28] <roaksoax> pitti: how can I ensure that my app uses the latest postgresq ?
[15:31] <roaksoax> pitti: specially when the packaging is using dbconfig-common
[15:35] <hallyn> xnox: mjt has started packaging 2.5 for debian.  are you on oftc#debian-qemu?  that's where we generally discuss that
[15:36] <hallyn> think you used to sit there... if memory serves :)
[15:45] <pitti> roaksoax: you can of course depend on postgresql (>= 9.4) or so
[15:45] <pitti> roaksoax: or perhaps better postgresql-9.4 | postgresql (>= 9.4), in case someone doesn't want the metapackage
[15:47] <roaksoax> pitti: will that ensure than the DB is migrated to use postgresql-9.4 from 9.3 ?
[15:47] <roaksoax> pitti: and all handled by dbconfig-common ?
[15:47] <pitti> roaksoax: no, you can't, that needs to be done by the admin after the upgrade
[15:50] <smoser> infinity, hey. i know that you have more than a few things that you take care of...
[15:50] <smoser> but just pinging on presense of 'wily-netboot' at http://archive.ubuntu.com/ubuntu/dists/trusty-proposed/main/installer-amd64/current/images/
[15:50] <smoser> https://bugs.launchpad.net/maas-images/+bug/1511497
[15:52] <roaksoax> pitti: ok, so is this something we can do in packaging ?
[15:52] <roaksoax> pitti: rather than have the admin do it?
[15:52] <pitti> roaksoax: no, we can't do programmatic DB upgrades
[15:53] <roaksoax> pitti: ok, cool! So then I guess we need to cry out load that users upgrade from trusty -> xenial will need to upgrade their DB's
[15:53] <cjwatson> That's always been the case anyway
[15:53] <pitti> roaksoax: that sohuld alreayd happen via debconf
[15:53] <cjwatson> Launchpad would be very sad if you tried to do it automatically ;-)
[15:57] <roaksoax> pitti: ok cool
[15:57] <pitti> the package used to try in-place upgrades until 2005, it was all really brittle and sorry, so we stopped that
[15:58] <didrocks> tseliot: apw: is the video framebuffer still part of the kernel or of any use? I'm looking at our custom vga16fb for plymouth and wonder if we shouldn't drop it?
[16:00] <tseliot> didrocks: we should be able to drop it soon enough
[16:01] <tseliot> didrocks: fglrx and nvidia are still the reason why we have that in place
[16:01] <didrocks> tseliot: yeah, so, it's still a valid thing for xenial and plymouth should support it?
[16:05] <tseliot> didrocks: yes
[16:06] <didrocks> tseliot: I hope you have hardware to test the merge once done (thanks for volunteering btw :p) ;)
[16:07] <tseliot> didrocks: yes, assuming I'm not on holiday by the time you do it ;)
[16:08] <didrocks> tseliot: around next week? I hope to be done "soon" :)
[16:09] <tseliot> didrocks: yep, except for Tuesday
[16:09] <didrocks> oh, sounds excellent then! Will bother you ;) Thanks!
[16:10] <tseliot> :)
[17:22] <pitti> wow -- the s390x builders rock
[17:22] <pitti> they went through 8 hours of buildd backlog in < 1 hour!
[17:23] <cjwatson> it is nice to have fast and pretty stable builders for a new arch, for once
[17:23] <cjwatson> only one kernel problem so far
[17:25] <TJ-> could someone take a look at this affecting Vivid>Wily upgrades  'dpkg --configure' returns 10 - looks like someone forgot the .postinst runs with 'set -x' but needs confirming that's the correct fix: bug 1495302
[17:25] <ogra_> can you still call it a 8h backlog then ?
[17:26] <cjwatson> ogra_: buildd queue lengths are a guesstimate based on package sizes estimated on 2010 x86 hardware
[17:27] <ogra_> ah, a metric then :) (despite an old one)
[17:27] <cjwatson> ogra_: at least in the case where we have no historic build data, as with a new arch
[17:27] <ogra_> yeah
[17:28] <cjwatson> the fallback estimate is: if we know the package size, then 6KB/second plus a minute for general overhead; if we don't, then five minutes
[17:28] <cjwatson> we prefer the duration of the most recent successful build, though
[17:29] <ogra_> wow, so there is actual math behind it
[17:29] <cjwatson> it's not *complete* lies
[17:29] <cjwatson> just frequently
[17:29] <ogra_> :)
[17:30] <cjwatson> anyway, they are definitely very nice builders, they've built 2/3 of their backlog and 27/28 of them have only been operational for about a day
[17:31] <cjwatson> bodes well for generally keeping out of people's way
[18:59] <ThiagoCMC> hey guys! Any plans to upgrade InfluxDB to 0.9.5 for Xenial ?
[18:59] <ThiagoCMC> I'm planning to build a InfluxDB Cluster with it, when ready...
[19:23] <botato> is there something for ubuntu that will make sure someone who has access to your machine won't have access to certain files. and when they try to access those certain files, a prompt will show up that will ask for a special password whcih isn't the same as the password they used to ssh into the machine?
[19:28] <infinity> smoser: Soon.  I've been on vacation most of the week (and still am), only popping in for s390x bootstrapping.
[19:28] <infinity> doko: Oops.  Will fix.
[19:29] <doko> infinity, take -0ubuntu2
[20:00] <infinity> doko: Should be happier now.
[20:08] <dobey> botato: samba, vsftp, or something else, that only allows access via some other protocol. bug #ubuntu is the place to ask ubuntu support questions like that
[20:09] <botato> ok thanks
[20:36] <chiluk> pitti: I think it was you who was thinking about helping out by syncing findutils from debian-unstable to xenial.. so I checked and debian has 4.5.14, which does contain the fix for https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1347788
[21:20] <ancaemanuel> Hi devs
[21:21] <ancaemanuel> I sent an email to ubuntu-devel but is waiting for moderation
[21:23] <dobey> ok
[21:23] <ancaemanuel> My comment is about the current algorithm for the builders
[21:24] <dobey> your question is about PPAs?
[21:25] <ancaemanuel> I will post it here
[21:25] <ancaemanuel> The current algorithm for building 12000 packages for an new architecture is:
[21:25] <ancaemanuel> For a* to z* try build.
[21:25] <ancaemanuel> Of course you will need lib* and *dev first, and you will waste a lot
[21:26] <dobey> i doubt it
[21:26] <ancaemanuel> of time trying to compile things.
[21:26] <ancaemanuel> My proposal: try to find an algorithm for dependencies.
[21:26] <dobey> new architectures don't get added often
[21:26] <ancaemanuel> If package A depends on package B to be build, B gets an +1 for priority.
[21:27] <ancaemanuel> there is mips ...
[21:28] <dobey> ubuntu supports mips again?
[21:28] <dobey> or you're talking about debian?
[21:29] <ancaemanuel> No, jut an ideea
[21:29] <ancaemanuel> just
[21:30] <dobey> well there are lots of architecutres that ubuntu doesn't support
[21:30] <ancaemanuel> am Im talkinh about https://launchpad.net/ubuntu/xenial/+builds?build_text=&build_state=built&arch_tag=s390x
[21:30] <dobey> eh, the s390x hardware is incredibly fast
[21:30] <stgraber> ancaemanuel: the problem is that to know what a package needs to be built, you need to unpack the source and run it through the package resolver in a chroot of the right architecture
[21:31] <dobey> exactly
[21:31] <stgraber> which is why we can't resolve and prioritize the right build ordering ahead of time, well, we could, but it'd be just as painful as just trying to build the damn thing
[21:31] <stgraber> so instead we add build records for everything, typically starting with main which we know can be built in a self-contained manner and is typically what's used for the rest of the packages
[21:32] <ancaemanuel> And when you build it, you can record the dependencies
[21:32] <ancaemanuel> save for later
[21:32] <stgraber> when something fails to build, Launchpad figures out why it failed to build (parses that from sbuild) and makes the package depwait
[21:32] <stgraber> then attempts to build again once that package the depwait package is published
[21:34] <stgraber> no you can't because we've got that thing called alternatives, a package may depend or build-depend on one out of a set of packages, the final one being picked depending on avaibility (whether it's built and available in an allowed component), the ordering matters there, the first being favored, so when bootstrapping an arch, less favored ones may be picked, but on a rebuild, you'd want the first to be picked
[21:35] <stgraber> anyway, the effort of even trying to encode all of the resolver logic outside of the chroot, parsing all source packages at upload, ... would far exceed the average cost of just retrying a build
[21:35] <stgraber> yes, a new arch bootstrap is a bit of a special case as the first packages to build have a high chance of failing to build, but we usually have done some manual bootstrapping outside of LP first so already know what the bootstrap stages are
[21:36] <stgraber> so those build records can be created in the right order and then we can throw the rest at the buildds and wait a couple of days
[21:36] <stgraber> which is never a real issue since we usually start building the distro way before anyone has hardware they can use it on, so nobody is actually waiting on those packages as they're still busy getting access to hardware to do their bits (most important one being setting up image builds)
[21:37] <ancaemanuel> I am talking about dumb trying to build from a* to z* packages without *dev first
[21:38] <dobey> that is your opinion, yes
[21:38] <JanC> I guess stuff like glibc gets uploaded first anyway  :)
[21:38] <stgraber> I know, I'm just saying that even with that, the cost of adding the logic to figure out those things without throwing them at a buildd far exceeds that of just throwing them at a buildd
[21:38] <dobey> and it's not simply a-z. it's first-queued
[21:38] <stgraber> In average that is. If we were to bootstrap a new architecture every week, that'd be different
[21:40] <dobey> bootstrapping is hard (TM)
[21:40] <dobey> let's go to pub
[21:40] <stgraber> dobey: well, when we add a new arch, it's effectively what is done, we just create new build records for everything that exists in the archive. Except that we already have a minimal functional chroot that was pre-built by hand ahead of time (so the very low level stuff already exists) and that main builds before universe so we take care of a ton of libs that way.
[21:40] <Unit193> s/hard/fun/
[21:40] <dobey> stgraber: exactly. that was my point :)
[21:41] <dobey> not like you can build a compiler without a compiler to compile it, either
 so those build records can be created in the right order and then we can throw the rest at the buildds and wait a couple of days | <dobey> let's go to pub → so that's what you do after starting the build? :P
[21:43] <stgraber> JanC: pretty much
[21:43] <dobey> JanC: you're assuming we're not in the pub when we start the build :)
[21:43] <JanC> and that's why you don't want it to go too fast...
[21:43] <stgraber> this time around, it'd be a question for cjwatson, wgrant and infinity :)
[22:34] <ben___> any advice on debugging these "dpkg-shlibs: warning ... contains an unresolvable reference to symbol" issues? http://paste.ubuntu.com/13681422/


[23:02] <dakedres_> Hello, I installed Xubuntu Minimal recently and I realized it doesn't come with a Bluetooth manager. I tried Blueman, but I'm not too impressed. Came to ask what managers you guys use/recommend and which one is included in the full installation if any
[23:04] <Unit193> Desktop ships with blueman and libspa-0.2-bluetooth


[08:58] <SpecialK|Canon> jelmer: nice loggerhead MPs!
[08:59] <cjwatson> Oh right, I didn't notice those somehow
[09:00] <cjwatson> jelmer: How did you make python3 work without porting away from simpletal, since simpletal is py2-only at present?
[09:01] <cjwatson> jelmer: Or wait, I see that simpletal 5 is py3, I guess I missed that because they don't have a bilingual version
[09:10] <tomwardill> no YUI!
[09:21]  * tomwardill mutters about ahead-of-time COW filesystems and ownership
[09:21] <tomwardill> (everything fails if it's owned by root)
[10:32] <tomwardill> none of the directories are consistent
[10:32] <tomwardill> there's about 4 different checkouts in the image afaics
[10:32] <SpecialK|Canon> :(
[11:53] <tomwardill> ah, nope, it's just a documentation / set of code 1 / set of code 2 mismatch
[14:35] <tomwardill> "buildbot❌112:116:Buildbot system user,,,:/var/lib/buildbot:/bin/false"
[14:35] <tomwardill> yeah, a shell of /bin/false would do it
[14:35] <tomwardill> you're not getting a shell to execute commands in that case!
[15:04] <tomwardill> IT'S DOING A THING
[15:05] <tomwardill> I can tell, all my CPU just went away somewhere
[15:14] <SpecialK|Canon> :D
[16:07] <tomwardill> blergh, lxc-start-ephemeral has been deprecated in favour of lxc-copy and no longer appears to work
[16:08] <cjwatson> lxc-copy --ephemeral should do it, give or take
[16:19] <tomwardill> lxc-start-ephemeral works, unless you give it a command to run,t hen it fails
[16:19] <tomwardill> lxc-copy fails with what looks like an apparmour type failure (my host is a container, so may be related)
[16:25] <tomwardill> "overlayfs cannot be stacked on top of zfs"
[16:25] <tomwardill> "default/containers/buildbot-worker on / type zfs (rw,xattr,posixacl)"
[16:25] <tomwardill> well.
[16:25] <tomwardill> poop
[16:26] <cjwatson> lxd vm to the rescue?
[16:26] <tomwardill> yeah, guess so
[16:26] <cjwatson> Probably simplest ...
[16:27] <tomwardill> sigh... so close


[15:00] <bac> #startmeeting
[15:00] <MootBot> Meeting started at 09:00. The chair is bac.
[15:00] <bac> me!
[15:00] <sinzui> me
[15:00] <abentley> me
[15:00] <EdwinGrubbs> me
[15:01] <mars> me
[15:01] <bac> rinze: ping
[15:01] <mars> bac, gary is away today
[15:01] <noodles775> me
[15:01] <henninge> me
[15:02] <leonardr> me
[15:02] <bac> deryck sent his regretss
[15:02] <bac> s
[15:02] <bac> bigjools: ping
[15:02] <bigjools> me
[15:03] <bac> adeuring: ping
[15:03] <adeuring> me (sroyy...)
[15:03] <bac> [topic] agenda
[15:03] <MootBot> New Topic:  agenda
[15:03] <adeuring> sorry
[15:03] <bac>  * Roll call
[15:03] <bac>  * Agenda
[15:03] <bac>  * Outstanding actions
[15:03] <bac>  * New topics
[15:03] <bac>    * Lots of unlanded, approved branches [bac]
[15:03] <bac>  * Peanut gallery
[15:03] <bac> [topic] outstanding actions
[15:03] <MootBot> New Topic:  outstanding actions
[15:04] <bac> * bac and abentley  to define new doctest policy regarding what is "testable documentation".
[15:04] <bac> good news
[15:05] <bac> i spent some time yesterday going throught the TestStyleGuide trying to 1) bring it up-to-date wrt the post-apocalyptic directory layout and 2) try to define 'testable documentation' and spell out our expectations
[15:05]  * noodles775 has a meeting conflict this week. Sorry bac.
[15:05] <bac> i've asked abentley and sinzui to look it over and give feedback.  but i'm removing this albatross from the todo list
[15:05] <rinze> me
[15:05] <bac> * Bjornt to set a policy on what can live in lib/lp, lib/services, and lib/coop
[15:05] <jtv> me
[15:05] <abentley> bac, it looks pretty good to me.
[15:05]  * bac wonders who this rinze person is...
[15:05] <abentley> bac, detailed results to come.
[15:05]  * bac and what he's done with jelmer
[15:06] <rinze> bac: I'm jelmer :-)
[15:06] <bac> i guess BjornT probably won't get to that item before he departs.
[15:06] <bac> perhaps we should give it over to jml
[15:07] <bac> * *Everyone* read lib/canonical/launchpad/doc/db-policy.txt
[15:07] <bac> a final reminder to look at that documentation.
[15:07] <bac> * Sinzui to replace pylint
[15:07] <sinzui> blocked
[15:07] <sinzui> I can resume work when lp builds my package
[15:07] <bac> sinzui: you're now working on this during the workday, though.  that's good news.
[15:08] <sinzui> That is because I am in the lp tree now
[15:08] <sinzui> waiting for a dep
[15:08] <bac> [topic] Lots of unlanded, approved branches [bac]
[15:08] <MootBot> New Topic:  Lots of unlanded, approved branches [bac]
[15:08] <bac> we talked about this two weeks ago and bigjools suggested we revisit.
[15:09] <bac> the list of approved-but-unlanded old branches has been driven down to 8
[15:09] <bac> only three owned by people here.
[15:09]  * mars hides
[15:10]  * adeuring hides too
[15:10] <bac> so, please either land those branches or mark the MP something other than 'approved', if appropriate
[15:10] <bac> i was sure my gimp elephant picture would spur some to action
[15:10] <bac> [topic] peanuts
[15:10] <MootBot> New Topic:  peanuts
[15:10] <bac> anyone have something not on the agenda?
[15:11] <bac> i have nothing else.
[15:11] <bac> thanks for coming to a very brief meeting.
[15:12] <bac> #endmeeting
[15:12] <MootBot> Meeting finished at 09:12.
[15:12] <mars> thanks bac
[15:13] <rinze> thanks bac
[15:47] <bigjools> bac: I have an item to put on the meeting agenda next week, will it remain when you update the agenda page?
[15:54] <bac> bigjools: sure
[15:56] <bigjools> ta


[00:38] <afiestas> ScottK: taht would be nice yes, in kde-core-devel and kde-hardware-devel
[04:31] <ScottK> xnox: We can put it in python3-pyqt4.  As long as the .so file is ABI tagged, it should be recognized by python3 before the python one.
[04:31] <ScottK> xnox: I did similar with kpythonpluginfactory in pydke4.
[07:13] <micahg> shadeslayer: ok, pushed transmission to raring, will push the rest tomorrow
[07:14] <shadeslayer> \o/
[07:14] <shadeslayer> thx micahg
[07:28] <soee> good morning
[07:39] <shadeslayer> soee: ho
[07:39] <shadeslayer> *hi
[08:30] <shadeslayer> ScottK: what do you suggest we do about amarok stuck in -proposed?
[08:30] <shadeslayer> it failed to build on arm
[08:34] <shadeslayer> due to popular demand I'm going to try and build KDE 4.10 on Precise
[08:34] <shadeslayer> will just put everything in ninjas and see if that works
[09:02] <yofel> shadeslayer: if you do, at least write some backport rules for boost, otherwise it's A LOT of work - and don't backport pykde
[09:10] <shadeslayer> good point
[09:18] <shadeslayer> yofel: do you think this will be enough http://paste.kde.org/639338/
[09:20] <yofel> no, you'll need that, but there's a few boost-python deps and other stuff too
[09:21] <yofel> we also used 1.46 in precise so far, not sure if we should keep that or go with 1.48
[09:25]  * yofel wonders what else needs to be changed
[09:26] <yofel> at least one package needs libtiff4, a few need the symbol files deleted and you'll need kgapi and kolab from backports
[09:30]  * yofel realizes that the script doesn't really support backporting different kde releases to one series
[09:30] <yofel> not that it matters much now as we're done with 4.9
[09:30] <Riddell> shadeslayer: who's demanding it?
[09:31] <yofel> users, I got some requests too but was reluctant about it as it's a bit of a support mess
[09:32] <Riddell> ah, users, we'd have an easy time if it wasn't for them
[09:32] <Riddell> :)
[09:32] <yofel> true, but that would be boring :P
[09:34] <shadeslayer> ^
[09:35] <shadeslayer> hmm .. why do we want to delete the symbols files?
[09:35] <yofel> precise has gcc 4.6, so you'll get missing symbols
[09:35] <yofel> and a few packages fail on that
[09:36] <yofel> feel free to fix that differently, but it also causes them to be red on the status page from something we don't care about
[09:39] <shadeslayer> how about I just change boost for now and then we work out symbols and the boost stuff we missed in the PPA?
[09:40] <yofel> go ahead, just please write rules for them as you fix those so we don't have to do that again for RC3
[09:40] <shadeslayer> and I'm building with 1.48
[09:40] <shadeslayer> right
[10:05] <shadeslayer> any ideas how binary:Version is computed?
[10:06] <shadeslayer> hmph
[10:42] <Riddell> shadeslayer, ScottK: I'll take a look at amarok
[10:42] <shadeslayer> \o/
[10:45] <shadeslayer> Riddell: oh and we also need a way to ship nepomuk with ffmpeg
[10:46] <shadeslayer> one way is to split the plugin into a package that does not get shipped on the CD
[10:48] <Riddell> shadeslayer: yep
[10:48] <shadeslayer> another is via dlrestrictions
[10:48] <Riddell> but I also need to tackle me 1852 unprocessed e-mails that have built up over the new year :)
[10:48] <shadeslayer> No idea how that works and JontheEchidna hasn't replied yet
[10:52] <shadeslayer> Riddell: whoa
[10:52] <shadeslayer> There's a button called "Mark all as read" :P
[10:53] <Tm_T> shadeslayer: poor Mark
[10:54] <shadeslayer> heh
[11:34] <shadeslayer> hah
[11:34] <shadeslayer> yofel: http://bazaar.launchpad.net/~kubuntu-packagers/+junk/kubuntu-automation/revision/101
[11:34] <shadeslayer> I was going to do that
[11:36] <shadeslayer> Just about to upload the RC for precise
[11:38] <xnox> ScottK: I am doing final tests & uploading. At this point I reverted py3 designer plugin. I will look at how kpluginfactory is packaged. I just want to test Qt Creator before uploading, in case it freaks out with both 2.7 & 3.3 simultaniously =)
[11:53] <Riddell> what is PAE?
[11:54] <yofel> in kernel meaning physical address extension
[11:54] <Riddell> as in http://paste.kde.org/639488/
[11:54] <yofel> ah yeah, we don't have any non-PAE kernels anymore
[11:54] <yofel> (IIRC)
[12:02] <Riddell> hmm, not quite sure how to reply to that without essentially saying "sorry tough luck"
[12:03] <xnox> Riddell: install precise, or whatever last non-pae supported release is.
[12:05] <Riddell> ok that'll do for an answer, thanks
[12:15] <yofel> shadeslayer: your backport attempt is missing kdegames from what I see. Did you use the 4.9 package list?
[12:16] <shadeslayer> hmm ....
[12:16] <shadeslayer> sec, my install is all broken after reboot
[12:16] <shadeslayer> no backlight control no hardware acceleration
[12:17] <shadeslayer> and now the electricity has gone, so I can only be here for a couple of minutes
[12:20] <shadeslayer> yofel: seems so, I guess the script used the kdesc-precise-backports.txt ?
[12:20] <shadeslayer> lemme fix
[12:20] <yofel> yeah, I didn't take stable-1 backports into account when writing this
[12:20] <shadeslayer> :P
[12:21] <shadeslayer> hey, precise is still stable :P
[12:21] <yofel> argh, you know what I mean ;P
[12:21] <yofel> anyway, here: https://yofel.dyndns.org/kubuntu/build_status_4.9.97_precise.html
[12:22] <shadeslayer> yay
[12:22] <shadeslayer> "Battery 0: Discharging, 20%, 00:25:53 remaining"
[12:22] <shadeslayer> yofel: ^ Can you do kdegames?
[12:22] <yofel> I'm at work, so not for a few hours
[12:24] <shadeslayer> k, I'll try
[12:34] <shadeslayer> good thing I didn't delete the upload dir
[12:48] <afiestas> is there anyway of getting the patches from: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=vbox-kcompat-3.6-3.7.patch;att=1;bug=696011
[12:49] <afiestas> and applying them to the dkms?
[12:49] <afiestas> I need to use virtualbox on the kernel I'm using (which comes from a ppa)
[12:49] <Mamarok> claydoh: JFYI: I put the posts to that topic on hold now, they should just shut up
[12:53] <shadeslayer> afiestas: er, I don't understand, aren't those patches for vbox? how would you apply them to dkms?
[12:56] <afiestas> shadeslayer: virtualbox dkms
[12:56] <afiestas> lunch
[12:56] <shadeslayer> ok
[12:59] <shadeslayer> afiestas: https://launchpad.net/ubuntu/+source/virtualbox/4.1.22-dfsg-0ubuntu1 < raring already has the fix
[13:48] <shadeslayer> dantti: print manager ping
[14:06] <Quintasan> \o
[14:14] <shadeslayer> yofel: https://yofel.dyndns.org/kubuntu/build_status_4.9.97_precise.html
[14:14] <yofel> seen
[14:14] <shadeslayer> "Error multiple versions of the same package" ?
[14:15] <yofel> lp sends data the script can't handle
[14:15] <yofel> not sure what though
[14:16] <Quintasan> good news
[14:16] <shadeslayer> everyone
[14:16] <yofel> I added the package name to the error, let's see
[14:16] <shadeslayer> okay
[14:17] <Quintasan> ScottK, Riddell: turns out installing anthy ins jp_JP locale did the ibus configuration magic itself
[14:18] <Quintasan> Therfore ScottK's proposed solution of making each langpack depend on ibus is the best solution imo
[14:18] <Quintasan> I would even go a step ahead and pull the module for ex. ibus-pinyin for chinese langpack
[14:19]  * yofel notes that lp feels esp. slow today
[14:20] <Riddell> Quintasan: good good
[14:20] <Riddell> do you know how to edit the langpacks?
[14:20] <Quintasan> Riddell: Absolutely no idea.
[14:21] <shadeslayer> yofel: today? hah, it's been like that for the last couple of days for me
[14:21] <yofel> didn't notice anything there, but usually the script runs for ~1min, now it's ~4
[14:22] <yofel> ok, no error this time
[14:23] <shadeslayer> I uploaded kdegames btw
[14:23] <yofel> good, I uploaded backend stuff (soprano, aknoadi, kgapi, cmake, attica, ...)
[14:24] <shadeslayer> awesome
[14:25] <yofel> oh, rekonq 2.0 is out
[14:25] <Riddell> whee!
[14:25] <Quintasan> Riddell: Aron Xu told me he will be trying to bring over the change from ibus to fctix in Ubuntu, he is one of most active members in Debian's pkg-ime
[14:26] <Riddell> I want to know why input methods needs all this faffy setup, why isn't it just a config value that can be controlled by a GUI?
[14:28] <Quintasan> Riddell: it seems ibus doesnt automatically enable input methods for certain languages unless your locale is that certain language
[14:28] <Quintasan> i.e. when you run jp_JP.UTF8 locale installing ibus-anthy will do the magic itself
[14:28] <Riddell> yeah, nuts
[14:29] <Quintasan> but when you use for eg. pl_PL.UTF8 installing ibus-anthy will just pull all the required stuff but not configure ibus to use the Anthy input method
[14:29] <shadeslayer> wheee http://www.zdnet.com/amazons-top-selling-laptop-doesnt-run-windows-or-mac-os-it-runs-linux-7000009433/
[14:29] <Riddell> nuts
[14:29] <Quintasan> so to fix it I just need to modify langpacks deps
[14:30] <Quintasan> But I'm still interested in making the change to fctix
[14:31] <Quintasan> it has Qt4 module
[14:31] <Quintasan> there is  input-method panel plasmoid
[14:31] <Quintasan> plus KCM
[14:31] <shadeslayer> fun
[14:31] <shadeslayer> cups is broken http://paste.kde.org/639692/
[14:32] <Quintasan> Riddell: The only drawback I see is lack of Japanese input module
[14:33] <Riddell> Quintasan: no japanese with fctix? that seems like a big drawback no?
[14:33] <Quintasan> Yeah, but since it's modular it seems like it's only a matter of time
[14:34] <Quintasan> I will try contacting appropriate people and see how is that going to work
[14:34] <yofel> shadeslayer: reading the changelog entry for that I wonder what "Ubuntu for Android" is... and OS for an OS o.O?
[14:34] <shadeslayer> ah
[14:34] <shadeslayer> it's basically that :P
[14:34] <yofel> "fun"
[14:34] <shadeslayer> you can run Ubuntu ontop of Android
[14:34] <shadeslayer> Mark demoed it at UDS
[14:34] <yofel> reminds me of wubi
[14:34] <shadeslayer> haha
[14:35] <Quintasan> >wubi
[14:35] <Quintasan> yofel: get out
[14:35] <Quintasan> :P
[14:35] <yofel> why? I actually managed to isntall kubuntu precise with wubi
[14:35] <Quintasan> wat
[14:35] <Quintasan> it worked?
[14:35] <yofel> I never saw ubiquity, but it did install
[14:35] <yofel> magic
[14:35] <Quintasan> omfg
[14:36] <yofel> script runtime is now at 6min...
[14:40] <shadeslayer> fun
[14:48] <BluesKaj> Hiyas all
[14:54] <shadeslayer> yofel: http://bazaar.launchpad.net/~kubuntu-packagers/+junk/kubuntu-automation/revision/104
[14:55] <shadeslayer> should cover everything from what I can see on the build status page
[14:55] <shadeslayer> but then again, half the stuff hasn't been built
[14:56] <yofel> rocs needs the actual lib substituted
[14:56] <shadeslayer> heh true
[14:56] <shadeslayer> I wonder why it depends on the lib though
[14:57] <yofel> because the -dev package SUGGESTS the lib
[14:57] <yofel> no comment
[14:57] <shadeslayer> wat
[14:58] <shadeslayer> yofel: seems fixed in 1.49
[14:58] <shadeslayer> Depends: libboost1.49-dev (= 1.49.0-3.1ubuntu4), libboost-date-time1.49-dev (= 1.49.0-3.1ubuntu4), libboost-thread1.49.0 (= 1.49.0-3.1ubuntu4)
[14:58] <yofel> \o/
[14:59] <shadeslayer> now the tricky part
[15:00] <yofel> from what I see, okular needs a rule for tiff
[15:00] <shadeslayer> if we drop it, it might cause an issue in precise
[15:00] <yofel> and someone needs to backport indi
[15:00] <yofel> shadeslayer: if that's the case  just add a rule to add it back
[15:02] <yofel> shadeslayer: errr, you were looking at the deps of libboost-thread1.49-dev
[15:02] <yofel> graph has
[15:02] <yofel> Recommends: libboost-graph1.49.0 (= 1.49.0-3.1ubuntu1.1)
[15:02] <shadeslayer> derp
[15:02] <shadeslayer> wel
[15:02] <shadeslayer> better than suggests :P
[15:02] <yofel> true, but IIRC sbuild installs with --no-install-recommends
[15:03] <shadeslayer> ah
[15:03] <yofel> correct me if I'm wrong though
[15:03] <shadeslayer> dunno, I use pbuilder :P
[15:04] <yofel> libmusicbrainz5 copied from backports...
[15:35] <yofel> does print-manager intentionally have a not-versioned build-dep on kdelibs?
[15:36] <yofel> since it built I guess it doesn't matter, but it built with kdelibs 4.8 now
[15:44] <shadeslayer> hmm
[15:44] <shadeslayer> yofel: I can't seem to load that link anymore
[15:44] <shadeslayer> apart from the fact that it's giving me an invalid cert error :P
[15:44] <shadeslayer> ah there we go
[15:44] <yofel> yeah
[15:45] <yofel> better
[15:45] <shadeslayer> *nod*
[15:57] <shadeslayer> yofel: yay, kde4libs seemed to build fine
[15:57] <shadeslayer> well almost
[15:57] <shadeslayer> it's stripping out stuff from what I can tell
[15:58] <yofel> if it's at that point it won't fail
[15:58] <yofel> there's missing symbols if anything
[15:59] <yofel> amd64: Failed to build - no reason
[15:59] <yofel> thanks LP *-.-
[15:59] <yofel> retried
[16:12]  * Riddell jumps on rekonq 2.0
[16:40] <shadeslayer> wtf?
[16:40] <shadeslayer> yofel: kde4libs failed again with no build log
[16:40] <shadeslayer> I guess I'll retry it
[16:40] <yofel> and i386 seems stuck
[16:40] <yofel> LP is having a bad day
[16:40] <shadeslayer> ...
[16:40] <shadeslayer> yeah
[17:01] <JontheEchidna> shadeslayer: had you pinged me?
[17:35] <Laney> hey KDE dudes
[17:35] <Laney> Does anyone on Raring feel like testing ktp-call-ui from ppa:ubuntu-desktop/gstreamer1.0? I split up telepathy-farstream into a parallel installable package that means Ubuntu can move on with the GStreamer 1.0 transition without being held back by Kubuntu
[17:36] <Laney> Would be good to know if it works and doesn't, for example, crash due to mixed linkage
[17:36] <Riddell> hi Laney
[17:36] <Riddell> sorry for the lack of reply on your gstreamer mail
[17:37] <Laney> np
[17:37] <Laney> I found upstream bugs about it and it seems like there's real movement towards porting
[17:37] <Laney> s/real/no real/
[17:37] <kubotu> Laney meant: "I found upstream bugs about it and it seems like there's no real movement towards porting"
[17:39] <Riddell> however I can't say I've ever used ktp-call-ui
[17:39] <Riddell> shadeslayer: are you able to test it?
[17:40] <Laney> I suppose if it's going to be broken after this upload then it'll already be busted now
[17:40] <Laney> (deps stay the same)
[17:45] <soee> hiho
[17:50] <xnox> ScottK: python-qt4 build and published.
[17:51] <xnox> all of it should go into experimental, cause experimental also has both pythons multi-arched
[17:59] <Riddell> xnox: great thanks
[18:00] <xnox> Riddell: way python-kde4 next in the stack to fix against multiarched python2.7? is there some new version to merge or simply get what's in the archive to build?
[18:04] <Riddell> xnox: yes new upstram version
[18:04] <Riddell> http://download.kde.org/unstable/4.9.97/src/pykde4-4.9.97.tar.xz
[18:04] <Riddell> just grab the packaging from pykde4 in raring
[18:07] <xnox> I think I am going to call it pub time =)
[18:12] <Riddell> happy drinking
[18:12] <Riddell> nepomuk-core-ffmpegextractor ok as a package name?
[18:15] <allee> afiestas: when loading the kscreen module, kded4 crashed immediately http://paste.kde.org/639902/
[18:16] <allee> afiestas: did before christmas, and now with a fresh git checkout (1 hour ago) too.
[18:16] <afiestas> allee: pls check if that crash is not reported
[18:16] <afiestas> if it is not, report it
[18:16] <allee> afiestas: okay.
[18:16] <afiestas> and add kscreen-console and xrandr --verbose output
[18:16] <afiestas> thx
[18:16] <Riddell> allee: packages or self compiled?
[18:18] <allee> Riddell: both :-)   I've created pkgs (dh-make template almost) and build them
[18:18] <allee> Riddell: are there already pkgs available (did find something in this channel)
[18:19] <afiestas> allee: make sure to have qjson > 0.8.1
[18:21] <allee> afiestas: yes,   I've backported the r pkg to q.  So I use 0.8.1: ii  libqjson0:amd64                  0.8.1-1~ubuntu12.10~p
[18:21] <Riddell> allee: no I don't think so, it's on my todo list, maybe tomorrow
[18:22] <Riddell> shadeslayer: nepomuk-core-ffmpegextractor made and added to kubuntu-restricted-addons, should keep vHanda happy
[18:36] <allee> afiestas: https://bugs.kde.org/show_bug.cgi?id=312836   can you fix product and compnent of the bug?  Or tell me?
[18:39] <Riddell> Laney: here's the changelog about adding libcanberra-gstreamer to kde-runtime http://paste.kde.org/639926/
[18:40] <Riddell> Laney: it's an optional recommends so easily removed, is libcanberra-gstreamer now incompatible with something?
[18:44] <Laney> Riddell: well, canberra-gstreamer is now using gst 1.0 so you may find that your application crashes when you try to use it
[18:44] <Laney> the pulse one should be ok
[18:47] <Riddell> Laney: I just got ktp-call-ui working and it's fine
[18:47] <Laney> sweet, thank you
[18:47] <Laney> i will upload that stuff soon then
[18:55] <Riddell> random e-mail du jour http://paste.kde.org/639944/
[18:55] <Riddell> punch line is at the end
[19:00] <Riddell> apachelogger: what do you know about what needs to be done to port to gstreamer1.0?
[19:00] <Riddell> presumably phonon, qtgstreamer and qtmultimediakit would all need it?
[19:13] <soee> we can set window menu to be showe at the top of the screen
[19:14] <soee> here on my machine desktop effects dont work for this element
[19:44] <allee> afiestas: false alarm.  bug closed (was my fault. missing KSC_* plugins :-( ).   Sorry.
[19:45] <allee> ^^ I've no 2nd monitor right now.  Will test tomorrow ...
[19:48] <allee> Riddell: Should one upload  the bzr repo of new pkgs (debian/...  only) directly to kubuntu-packages or first to  my account and later clone it?
[19:54] <yofel> allee: if it's not there just add it
[19:54] <allee> yofel: okay. first polishing then uploading.  But now first  some salsa dancing :-) ... bbl
[19:54] <yofel> enjoy :)
[20:00] <soee> what would be the easiest way to calibrate colors ?
[20:24] <Riddell> allee: kubuntu-packages is fine, are you packaging kscreen?
[22:44] <Riddell> cor, just had a person phoning me for help with kubuntu, not unusual except this is the first time I've had it from someone who expected me to speak spanish
[22:44] <Riddell> I didn't tell her I'm half Chillian
[22:52] <xnox> Riddell: ScottK: i did a test rebuild of pykde4 and existing package builds fine against the fixed python-qt4. So i think i fixed the multiarch fallout and the kde ninjas can proseed with the rest now =)
[23:21] <allee> Riddell: yes, I've alpha quality pkgs of (lib)kscreen.  Still need to replace dh-make template, get rid of *.ex files and add  dependencies


[02:20] <duflu> Hey RAOF, is there a schemas package I should be targeting for https://bugs.launchpad.net/ubuntu/+source/colord/+bug/1785764/comments/9 ?
[02:25] <RAOF> There is not a schemas package, no.
[02:25] <RAOF> The default profile is generated at first use.
[02:26] <duflu> Cool, ta
[02:27] <duflu> RAOF: Is that auto-generated from EDID data?
[02:28] <RAOF> If available, yes.
[02:29] <RAOF> You know what would be nice? A Canonical Matrix homeserver.
[03:15] <jamesh> RAOF: from the sound of it, the Synapse server has some scalability problems
[03:16] <RAOF> jamesh: Yeah, but that's scalability to tens-of-thousands of users.
[03:17] <jamesh> you also end up with an ever growing database that can't be trimmed or archived
[03:23] <RAOF> That is a bit of an issue ☺. How does the matrix.org homeserver handle that?
[03:29] <jamesh> RAOF: apparently by being really big
[03:29] <RAOF> That seems like maybe a thing to fix?
[04:26] <tsimonq2> ~morning.
[04:26] <tsimonq2> I don't know enough about GTK 3 to sponsor this, but it's been sitting in the queue for a while: bug 1714518.
[04:27] <tsimonq2> jbicha, Laney, Trevinho ^
[08:02] <Laney> hello
[08:03] <Mirv> hello
[08:12] <duflu> Hullo Laney, Mirv
[08:16] <Nafallo> o/
[08:17] <duflu>    \o
[08:31] <duflu> Laney, Trevinho, FYI upstream mutter slightly broke for us recently. One of us will need to fix bug 1787325
[08:32] <duflu> I've just been using an older version of master to work around it
[08:33] <Laney> hi duflu Mirv Nafallo
[08:33] <Laney> duflu: don't you build that yourself in jhbuild when you need a newer one?
[08:34] <duflu> Laney, I'm a purist. I use the native build system of each project so that I understand how things work and don't rely on extra tools
[08:34] <Laney> Right then. Sounds like it makes your life hard when you need new dependencies.
[08:35] <Laney> Anyway, maybe if we ask tjaalton nicely he could upload that into Debian.
[08:35] <duflu> Laney, it's fairly rare, and very rarely not already packaged
[08:35] <duflu> Hi tjaalton, my buddy/friend
[08:35] <Laney> Trevinho: is there a branch for that extra change you did to ubuntu-settings?
[08:36] <duflu> Laney, he was on early/late I think so expect him late
[08:36] <Laney> Sure, it's not that urgent anyway
[08:36] <Laney> Trevinho: And we got our new glib release thanks to mclasen!
[08:40] <tjaalton> duflu: new w-p in debian? can do
[08:40] <duflu> Thanks tjaalton
[08:40] <tjaalton> np
[08:41] <duflu> I felt I was doing too many things depth-first so was hesitant to stop and do it myself
[08:47] <Laney> slashd: hey, I just pushed part of dgadomski's branch to gdm3 ubuntu/bionic - do you want to check/upload that one maybe?
[09:46] <k_alam> Trevinho: Hi, I just saw your patch, Yaru as default in ubuntu-themes,....
[09:46] <k_alam> Can we keep Ambiance as default for Unity? Because Yaru doesn't have unity specific styles.
[09:50] <Laney> k_alam: Do you have a GSettings defaults package for unity stuff?
[09:50] <Laney> Is it that part which is changing it for you? ubuntu-settings?
[09:52] <k_alam> Laney: Yes, setting the theme under unity-specific-session (in ubuntu-settings) will work.
[09:53] <Laney> k_alam: ok, would you be able to do a merge proposal for that please?
[09:53] <Laney> what's XDG_CURRENT_DESKTOP under unity7? /me forgot
[09:54] <k_alam> Unity:Unity7:ubuntu
[09:55] <Laney> ah yes, so you get the :ubuntu rules
[09:56] <Laney> alright, if you could try a Unity/Unity7 one that'd be great
[10:03] <k_alam> Laney: sorry got disconnected.......I have proposed unity-settings (https://launchpad.net/unity-settings) before.....but it hasn't gone into universe yet.....for the time being we need to set the theme in ubuntu-settings......
[10:03] <k_alam> I need to open a mr against ~ubuntu-desktop/ubuntu/+source/ubuntu-settings...right?
[10:04] <Laney> k_alam: that looks right, yeah
[10:07] <k_alam> I will do that. Thanks.
[10:35] <Mirv> btw I found out the culprit for my translations problem yesterday - enabling workrave GNOME extensions breaks those certain translations
[10:35] <Mirv> filed bug #1787542
[10:36] <Mirv> now if only someone would tell me why "Trash" on the desktop is not translated even though it has the translation in every translation domain the string exists in
[13:28] <Laney> YARUUUUUUUUUUU
[13:46] <Laney> done I think
[13:48] <Laney> haha
[13:48] <Laney> thanks jbicha for sponsoring glib-networking for me 🤝
[14:43] <Trevinho> Laney: yaru update itself no?
[14:43] <Trevinho> it was in the ppa
[15:23] <Laney> ok, didn't see that on the bug
[15:23] <Laney> or rather, I saw a fix released task
[15:32] <Laney> which revision corresponds to 18.10.2?
[15:33] <Laney> might want to use gbp dch on yaru in future
[15:33] <Laney> the upstream changes aren't documented at all in the debian/changelog, it looks like it's just packaging stuff
[15:50] <Trevinho> Laney: yeah, I noticed it in the .deb -_- i did that locally in the git
[15:50] <Trevinho> but I didn't want to trigger another build as it took ages
[15:51] <Trevinho> Laney: so, it's new upstream release 0.17 + git changes, and yes... using gbp dch could be actually nice to use here
[15:51] <Trevinho> want me to prepare that?
[15:51] <Laney> that would be nice, but note that I'm going soon™
[15:52] <Laney> 1h10
[15:52] <Laney> but I can just grab from git if you push there, that'll be quicker
[15:52] <Laney> is there a special procedure to make tarballs or do you just gbp buildpackage?
[15:56] <Trevinho> Laney: gbp buildpackage
[15:56] <Laney> ok ♥
[15:56] <Trevinho> Laney: yes I can push to git, so let me do that
[15:56] <Laney> sweet
[15:56] <Laney> it's probably going to be super verbose, might want to cut things down a bit
[15:57] <Laney> for future you can educate the guys to add Gbp-Dch: Ignore to things that shouldn't end up in the debian/changelog
[16:01] <Trevinho> Laney: done https://github.com/ubuntu/yaru
[16:02] <Laney> 😘
[16:02] <Laney> there's multiple sections for c-lobrano, can those be merged please?
[16:03] <Trevinho> ack
[16:03] <Laney> and fecht thingy
[16:03] <Trevinho> dch fault :)
[16:03] <Laney> not sure gbp dch should do that
[16:03] <Laney> dunno if it's on purpose or an oversight
[16:03] <Trevinho> is that because it's by time?
[16:03] <Laney> guess it does them in order and never merges
[16:04] <Laney> I think normal dch (non gbp) does merge though
[16:04] <Laney> like it finds a sectino with the same name and adds there
[16:04] <Trevinho> eh, exactly
[16:09] <Trevinho> Laney: it's there now
[16:13] <Laney> nice
[16:13] <Laney> ok /me builds
[16:28] <Laney> I'll remove block-proposed from the bug
[16:28] <Laney> someone will need to upload k_alam's MP when it comes in to unbreak them
[17:01] <Laney> think I'll disconnect from IRC this time :-)
[17:02] <Laney> first time I'll have deilberatly been off IRC for many years
[17:02] <Laney> see you !
[17:45] <jbicha> Trevinho: the yaru package names are backwards, I'm used to ____-gtk-theme, etc. 😐
[17:45] <jbicha> not a big deal, just a bit surprising
[17:46] <Trevinho> jbicha: I didn't decide those, Didier MIR'ed them way earlier
[18:06] <Trevinho> aaaaand... have a nic weekend!
[22:34] <tsimonq2> From #ubuntu+1:
[22:34] <tsimonq2> 05:27:43 PM < hcaley> hey, got a problem with Cosmic Cuttlefish.  Today when I did an update I got a conflict between gnome-session and ubuntu-session, and now gnome is hosed.
[22:34] <tsimonq2> 05:28:30 PM < hcaley> dpkg: error processing archive /var/cache/apt/archives/ubuntu-session_3.29.90-1ubuntu1_amd64.deb (--unpack):
[22:34] <tsimonq2> 05:28:30 PM < hcaley>  trying to overwrite '/usr/share/gnome-session/sessions/ubuntu.session', which is also in package gnome-session 3.29.90-1ubuntu1


[13:55] <jpetersen> https://code.launchpad.net/~jpetersen/indicator-application/actions-notify-workaround contains a patch for the "updating action label does not update menu item" bug
[14:02] <Nafai> Good morning
[14:04] <jpetersen> Hey Nafai
[14:04] <Nafai> Hey jpetersen
[14:10] <Nafai> Hrm.  I wonder if your fix takes care of my gnome-bluetooth bug
[14:11] <jpetersen> Nafai, it should
[14:12] <Nafai> I'll check it out and find out
[14:32] <Nafai> jpetersen: With some preliminary testing it appears that it would fix the problem
[14:32] <jpetersen> Nafai, cool
[14:33] <Nafai> I'm going to try a bit more to make sure
[14:33] <jpetersen> Nafai, yeah
[14:36] <jcastro> good morning!
[14:39] <Nafai> good morning jcastro!
[15:53] <Nafai> jcastro: I finally got around to pushing my g-c-c changes to github.  Also, my gnome-bluetooth bug seems to be fixed by Jan's latest branch.
[15:53] <jcastro> \o/
[15:54] <Nafai> Should I go back to trying to fix the app-indicator/python bug?  Or what should I work on?
[15:54] <jcastro> yeah
[15:54] <jcastro> Nafai: which bug was it again?
[15:55] <jcastro> we should fix that bug so marc can finish virt-manager.
[15:55] <Nafai> Yes, that one
[15:55] <jcastro> he's already done the work so it'd be a shame to lose it
[15:55] <Nafai> Definitely
[15:55] <Nafai> Time for me to fire up gdb to figure out what is going on
[15:55] <jcastro> did jan submit his branch to ted so we can get it into lucid?
[15:56] <jcastro> jpetersen: ^^
[15:56] <Nafai> not sure :)
[15:56] <jpetersen> tedg, https://code.launchpad.net/~jpetersen/indicator-application/actions-notify-workaround
[15:57] <jpetersen> tedg, that fixes a bug when the label of a GtkAction is updated
[15:58] <jcastro> hah, typical
[15:59] <Nafai> nice
 tedg, https://code.launchpad.net/~jpetersen/indicator-application/actions-notify-workaround
 tedg, that fixes a bug when the label of a GtkAction is updated
[16:13] <tedg> Nafai: jpetersen: Cool.
[16:13]  * tedg looking
[16:18] <djsiegel> tedg: when I click on a message notification from pidgin in the messaging menu, pidgin crashes
[16:19] <tedg> djsiegel: I just noticed and update, I'm guessing it got rebuilt without fixing the signal handlers.
[18:34] <jcastro> hey tedg
[18:34] <jcastro> can you review jan's branch today? I would like to finish off app indicators!
[18:40] <tedg> jcastro: The one from this morning?
[18:40] <jcastro> yeah
[18:40] <tedg> jcastro: It's merged :)
[18:40] <jcastro> \o/
[18:40] <jcastro> tedg: ok so how's it work from now on, you guys just roll out updates during the thursday thing or do I just poke seb when we need fixes uploaded?
[18:41] <tedg> jcastro: Depends, your choice.  We typically just do releases on Thursday, but seb and ken will cherry pick changes as well.
[18:41] <jcastro> tedg: I am for whatever ensures we don't lose fixes from now until release.
[18:41] <tedg> jcastro: It's all Bazaar now, so we have crazy revision histories :)
[18:42] <jcastro> heh
[18:42] <tedg> jcastro: Bazaar solves that problem.
[18:42] <tedg> jcastro: It really is a time vs. importance thing really.
[18:42] <jcastro> tedg: ok so really the only one left is that one that Nafai is looking at
[18:48] <Nafai> Yeah, hoping I figure that one out soonish :)
[19:14] <Nafai> Why isn't there a libappindicator-dbg package?
[19:16] <jcastro> Nafai: https://bugs.edge.launchpad.net/ubuntu/+source/upower/+bug/432598
[19:16] <ubot4> Launchpad bug 432598 in upower (Ubuntu Karmic) (and 13 other projects) "Do not show suspend/hiberate related UI if suspend is disabled in polkit (affects: 38) (dups: 1)" [Medium,Won't fix]
[19:16] <jcastro> jono wants us to look at the app indicator bits of this
[19:17] <qense> good evening
[19:18]  * Nafai looks
[19:19] <Nafai> So it needs to check gconf whether or not to show the menu items?
[19:20] <jcastro> Nafai: I am trying to figure out which merge did what
[19:21] <Nafai> ok
[19:21] <jcastro> Nafai: mail pitti referencing this bug, tell him you have cycles to fix it for him, and then fix it up so Ted can merge it
[19:21] <jcastro> would be the way to go there
[19:22] <Nafai> ok, sounds good
[19:22] <jcastro> Nafai: maybe that will free him up to do your vino review, hah
[19:23] <jcastro> Nafai: he's on German time fyi
[19:24] <Nafai> k, I'll mail him as soon as I get off the phone right now
[19:24] <jcastro> tedg: now that Nafai and jpetersen are mostly done with the porting we should have them fixing low hanging indicator fruit don't you think?
[19:29] <vish> mpt: hi... do you want this bug fixed? > Bug 530751
[19:29] <ubot4> Launchpad bug 530751 in gnome-power-manager (Ubuntu) (and 2 other projects) ""Battery Discharging" is a horribly worded message (affects: 4)" [Low,Triaged] https://launchpad.net/bugs/530751
[19:29] <vish> mpt: only last cycle we changed the wording according to the specs
[19:30] <tedg> jcastro: Uhm, I'm not sure what would be good things there.  I guess the number one thing for me would be fixing documentation so that it reflects everything they now know (and I didn't tell them :) )
[19:30] <vish> mpt: either the notify-osd specs need updating ,or the bug needs to be invalidated ;)
[19:31] <mpt> vish, yes, but it's too late for Lucid unfortunately
[19:31] <mpt> vish, afaik the old spec was just excising the interactivity, not worrying much about the wording
[19:31] <vish> mpt: ok , ty :)
[19:49] <Nafai> jcastro: Mail sent, and I'm looking at the branch
[19:50] <jcastro> <3


[10:58] <brobostigon> good morning veryone,
[21:19] <markjones> ImgBurn is *so* powerful, disks burning in under 2 minutes means I will have burned 50 disks in under an hour :P
[21:19] <markjones> ^ cgriff
[21:28] <cgriff> markjones: Cool, do you know how to translate an 0845 number to a normal landline?
[21:29] <markjones> saynoto0870.com
[21:29] <cgriff> Nuber isn't listed there
[21:38] <markjones> Nuber?
[21:38] <cgriff> Number...
[21:38] <markjones> for whom?
[21:39] <cgriff> A Civil Enforcement company


[12:33] <Chevek> Hi, I would like to propose a patch for #lp2057792  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2057792 . It is a simple text file to add to the systemd package for /etc/sysctl.d/. I cannot find useful documentation on how to proceed. https://canonical-ubuntu-packaging-guide.readthedocs-hosted.com/en/latest/tutorial/ is mostly empty and
[12:33] <Chevek> older version I could find are obsolete. I'm reaching you for help on this.
[12:33] -ubottu:#ubuntu-devel- Launchpad bug 2057792 in linux (Ubuntu) "Some Games are crashing linked to a vm_max_map_count too low" [Undecided, Confirmed]
[12:35] <Chevek> I would like to build a systemd package with the patch on my ppa to provide the bug report some testing about the change.
[15:30] <tsimonq2> Chevek: I can follow up in a bit, otherwise I'd recommend<EMAIL_ADDRESS>[15:30] <tsimonq2> We're working on enhancing this documentation but we're also busy with Noble. :)
[15:30] <tsimonq2> !dmb-ping | Gooooood morning
[15:31] <tsimonq2> We have two pending packageset updates, and I've had to play sponsor lately.
[15:32] <tsimonq2> vorlon volunteered to write some scripts to make this view clearer but I haven't heard about progress on that front yet.
[15:32] <tsimonq2> https://lists.ubuntu.com/archives/devel-permissions/2024-March/002466.html
[15:33] <tsimonq2> https://lists.ubuntu.com/archives/devel-permissions/2024-March/002483.html (he neglected to mention this is for Jammy *and* Noble)
[15:33] <tsimonq2> We also have https://lists.ubuntu.com/archives/devel-permissions/2024-February/002458.html
[15:34] <tsimonq2> Please at least review these requests.
[17:04] <vorlon> tsimonq2: backburnered due to time_t; someone else could take a stab at it
[17:04] <vorlon> it's "germinate Ubuntu, germinate Kubuntu, set subtraction"
[17:41] <Chevek> tsimonq2 It should be easy, I just want to add a file with this line "vm.max_map_count=1048576" (and some comments to explain the situation), with name "10-vm-max-map-count.conf", which should be located in /etc/sysctl.d/. This should be achieved in the systemd package, e.g. here
[17:41] <Chevek> https://code.launchpad.net/~git-ubuntu-import/ubuntu/+source/systemd/+git/systemd/+ref/ubuntu/mantic-updates in order to test this on mantic with a PPA.
[18:50] <juliank> FWIW I've done anki appmenu-gtk-module aqemu atomes caribou
[18:53] <juliank> cegui-mk2
[18:53] <juliank> chatty
[18:55] <juliank> clearlooks-phenix-theme
[18:58] <juliank> cpupower-gui
[19:01] <juliank> cqrlog
[19:06] <dbungert> looking at wiipdf
[19:08] <juliank> deepin-movie-reborn
[19:08] <juliank> I'd have expected it to be a leaf, but it is not apparently?
[19:09] <juliank> ah it is
[19:09] <juliank> vorlon: please remove-package -b -a armhf deepin-movie libdmr-devlibdmr0.1
[19:09] <juliank> vorlon: please remove-package -b -a armhf deepin-movie libdmr-dev libdmr0.1 (fixed)
[19:10] <dbungert> looking at xbase64
[19:15] <juliank> Yeah no, not fixing deepin-movie, this is silly
[19:15] <juliank> * dhcp-probe
[19:20] <juliank> emacs-pdf-tools
[19:23] <juliank> emerald
[19:30] <juliank> exaile
[19:31] <juliank> fastdds
[19:33] <dbungert> unity-gtk-module
[19:36] <juliank> Turns out libfastcdr1t64 has wrong symbols file still saying libfastcdr1, hence fastdds got wrong dep
[19:36] <juliank> Updating Debian NMU and syncing
[19:37] <juliank> So fastdds is going to need another no-change rebuild once fixed fastcdr has been built
[19:43] <dbungert> telepathy-mission-control-5
[19:43] <juliank> vorlon: in the meantime while we get new fastcdr built; remove-package -b -a armhf fastdds-tools libfastrtps-dev libfastrtps2.11 fastddsgen sounds reasonable (fastddsgen is a leaf afaict, script doesn't show it, and is reverse-testsuite-trigger)
[19:43] <juliank> not sure this blocks anythging
[19:43] <juliank> freeipa
[19:50] <dbungert> rapid-photo-downloader
[19:53] <juliank> dbungert: You went a bit wrong there with telepathy-mission-control5, libmission-control-plugins0t64 is the right library, the depends was correct, the culprit is the libmission-control-plugins0 dependency
[19:53] <juliank> ▸   dh_installdocs -plibmission-control-plugins-dev \
[19:53] <juliank> ▸   ▸   --link-doc=libmission-control-plugins0
[19:54] <juliank> This creates it and needs to be adjusted, not debian/control
[19:54] <juliank> dbungert: The global-ben.rebuild-for.txt shows you the library name that we want, not the broken one :)
[19:58] <dbungert> juliank: thanks for looking.  I'll check again.
[19:58] <juliank> Should I add versions to the report?
[19:58] <juliank> Not sure
[19:59] <juliank> Ah no, then rebuild-for picks up the old version even if somebody uploaded a newer one
[19:59] <juliank> that would be silly
[20:02] <jbicha> Chevek: I believe properly fixing #2057792 at the distro level should be done through the kernel configuration and not through adding a file to /etc/sysctl.d/
[20:02] <jbicha> bug 2057792
[20:02] -ubottu:#ubuntu-devel- Bug 2057792 in linux (Ubuntu) "Some Games are crashing linked to a vm_max_map_count too low" [Undecided, Confirmed] https://launchpad.net/bugs/2057792
[20:02] <jbicha> kernel's build configuration
[20:05] <dbungert> juliank: ok, double checking telepathy-mission-control5, I made a legit change to reduce hardcoding but I'll revisit the doc part
[20:06] <juliank> dbungert: I don't agree fwiw, libmission-control-plugins0t64 is in the same source package, the dependency is there to enforce a = relationship on the same binary version, probably due to use of private APIs
[20:07] <juliank> be careful :)
[20:08] <juliank> It just gets sed at ABI bumps anyhow :)
[20:09] <juliank> I'll sign out, it's 9pm on a Saturday, but of course IRC pings go to my phone so be careful :)
[20:09] <juliank> I should eat some dinner
[20:12] <doko> nice, the list is half the size now
[20:15] <doko> looking at keybinder
[20:16] <dbungert> I'm double checking all mine based on Julian's feedback above
[20:18] <vorlon> juliank: happy to - appreciate it if you point to the reason as well though for completeness
[20:19] <vorlon> juliank: (in part because I open proposed-migration bugs for packages where appropriate for tracking, and tag them time-t)
[20:19] <juliank> vorlon: reason: depends on lots of hardcoded libs and too lazy to fix for leaf package
[20:20] <vorlon> juliank: for deepin-movie-reborn?
[20:20] <vorlon> fwiw it showed as a candidate on https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output_notest.txt
[20:20] <doko> looking at ibus
[20:20] <vorlon> but maybe broken only on armhf
[20:22] <juliank> vorlon: yeah for deepin-movie-reborn
[20:22] <vorlon> ack
[20:22] <juliank> I think the fastdds has explanation
[20:23]  * juliank is busy cooking spaghetti with Beyond meatballs
[20:23] <vorlon> juliank: just because it bothers me, can you say why fastcdr's .symbols file was wrong? was this a case of multiple libraries in the same package? (early versions of the script unfortunately only fixed the dependency for the first one)
[20:24] <juliank> vorlon: sorry I'm afraid I don't know, I think there's only lib in there
[20:25] <vorlon> juliank: and yeah, I'll file a bug on the deepin-movie-reborn one - just because deps on the old package name are satisfiable doesn't mean we want to ship with them around, as you well know that can make the resolver angry on upgrade
[20:30] <vorlon> juliank: removed fastdds binaries, but fastddsgen seems to only have a test dep?
[20:31] <juliank> Yeah
[20:31] <juliank> Can keep it and force-badtest it?
[20:31] <vorlon> badtest which?
[20:31] <juliank> fastddsgen/armhf if it is passing now
[20:32] <juliank> Otherwise removed test dep would be a regression
[20:32] <juliank> I'm on my phone tossing pasta I haven't checked
[20:33] <vorlon> I'll migration-proposed/0 it
[20:37] <vorlon> LocutusOfBorg: libfm built, trying the copy again
[20:39] <dbungert> juliank: OK, I understand what you're saying now on telepathy-mission-control-5.  Reverting previous upload and fixing libmission-control-plugins-dev
[21:58] <Chevek> jbicha: One could change this line https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/include/linux/mm.h?h=v6.2.12#n203  but I wonder if there is a value that fits all use cases. Having a file in /etc/sysctl.d/ seems a better way for people to adjust the value to their needs, don't you think ?
[22:05] <Chevek> This value seems hardcoded in the kernel source. I'm not aware of a possible configuration for this value, except patching the source file directly.
[22:09] <Chevek> AFAICT either you add a file to /etc/sysctl.d/, either you patch the kernel like this https://aur.archlinux.org/cgit/aur.git/tree/max_map_count.patch?h=linux-steamos
[22:12] <Chevek> Fedora choose the /etc/sysctl.d/ way : https://src.fedoraproject.org/rpms/systemd/blob/f39/f/10-map-count.conf
[22:32] <juliank> File probably ought to be shipped in procps
[22:32] <juliank> procps is what ships almost all sysctl.d files
[22:33] <juliank> our systemd only ships /etc/sysctl.d/99-sysctl.conf
[22:33] <juliank> Chevek: So you want to add a task for procps package, do one of (1) apt source procps, patch it to add the file, generate a debdiff, and attach it to the bug (2) git ubuntu clone procs, patch it, submit merge request
[22:34] <juliank> Chevek: Or just attach the sysctl.d file and hope someone picks it up; if you attach a patch, well a debdiff (and subscribe ubuntu-sponsors) or open a merge proposal, it lands in the sponsoring queue
[22:35] <juliank> But then I'm not sure this could get sponsored easily
[22:35] <juliank> This needs coordination from like kernel team, desktoop team, and possibly product management
[22:39] <juliank> Chevek: So I subscribed desktop team; added tasks for procps and gamemode - gamemode is supposed to enable specific game modes, so it could just set the sysctl when running games I suppose
[22:41] <doko> qutebrowser, but not so cute dependencies ...
[22:44] <juliank> doko: Seems you inadvertently dropped various deltas in libcanberra
[22:45] <juliank> At the very least pipewire-pulse | pulseaudio became pulseaudio | pipewire-pulse again which it shouldn't be
[22:46] <juliank> This causes germinate to seed wrong
[22:47] <juliank> OK I think the rest is reasonable, but the ubuntu changelog also got lost in the merge
[22:47] <juliank> -02_disable_login_sound.patch
[22:47] <juliank> -04_nodisplay_autostart.patch
[22:47] <juliank> oh these patches are missing now too
[22:48] <doko> hmm, ok, looking
[22:48] <juliank> The last ubuntu upload was 0.30-10ubuntu7 , I think you may have accidentally? pulled the Debian source
[22:49] <juliank> But yeah I think these three parts need to be reinstated or desktop will shout at you :)
[22:50] <juliank> So we'll have a bunch of libcanberra rebuilds to do later then, they should show up on https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.rebuild-for.txt eventually
[22:51] <juliank> no-change rebuilds would be taken care by my run tomorrow morning fwiw
[22:53]  * juliank just did `rebuild-for "libfastcdr1t64" fastdds` now that the new fastcdr has been built
[22:53] <juliank> (well manually but still counts :D)
[22:56] <doko> yes, Debian. sorry.
[22:57] <juliank> It's good sort of, we needed to merge it, but forgot
[22:57] <juliank> We didn't do t64 transition on it apparently
[22:58] <doko> ´jbichaplease could you have a look at the libcanberra merge? no t64 upload yet ... :-/
[22:58] <juliank> vorlon: We need a KPI for current count of failed tests per architecture
[22:58] <doko> jbicha: ^^^
[22:58] <doko> too tired now
[23:00] <juliank> I'm probably happy to keep misbuilt libcanberra on armhf for now maybe and sort this out after everything else migrated
[23:01] <juliank> I don't expect we have lots of tests exercising it
[23:01] <juliank> Not sure which symbols changed there tbh
[23:02] <juliank> back to KPIs
[23:02] <juliank> Debian has really nice dose-distcheck report in https://qa.debian.org/dose/debcheck/unstable_main/index.html
[23:02] <juliank> including historical view
[23:03] <juliank> they also have number of uninstallable dependencies graphs
[23:03] <vorlon> why does purple-lurch consistently break the test bed
[23:03] <juliank> seems fitting for the name?
[23:04] <vorlon> it's only a no-change rebuild too
[23:04] <juliank> armhf and s390x autopkgtest queues are empty again
[23:04] <juliank> amd64 is at 17k tests now
[23:05] <juliank> i386 at 8k
[23:05] <juliank> arm64 at 3k
[23:05] <doko> shlibs.local, fixing
[23:05] <vorlon> doko: which one?
[23:06] <doko> purple-lurch. uploaded
[23:13] <juliank> I changed my cron job to run global-ben and removal-candidates first before it spends the ~15 mins on dose-distcheck
[23:17] <juliank> So you should get results at like 1-2 minutes past the hour now, as fresh as possible :)
[23:17] <doko> vorlon: purple-lurch ftbfs on armhf, implicit ... I can look at that tomorrow, but not now
[23:22] <Chevek> @juliank: Thank you for pointing me to the right package and for your participation to #2057792. I'll try to patch procps.
[23:25] <juliank> https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.log has a bit nicer log messages now
[23:25] <juliank> Lots of missing proposed builds; or old proposed builds
[23:25] <juliank> Rebuilding log messages like the following are useful for context:
[23:25] <juliank> # Rebuilding gst-plugins-good1.0 due to gstreamer1.0-plugins-good 1.24.0-1ubuntu4 depending on {'libsoup2.4-1'} - should be {'libsoup-2.4-1'}
[23:26] <juliank> These are issued for every `rebuild-for` command in the `global-ben.rebuild-for.txt` report
[23:26] <juliank> that one seems buggy though
[23:27] <juliank> vorlon: libsoup2.4-1 maps to libsoup2.4-1 (itself) in your https://people.canonical.com/~vorlon/armhf-time_t/ftp-override-map.txt
[23:28] <juliank> as does libsoup-gnome-2.4-1
[23:28] <juliank> Does this mean no change needed?
[23:29] <juliank> oh there is a new dash in there
[23:29] <juliank> sorry!
[23:30] <juliank> I *think* global-ben only logs "missing proposed build" for binaries that exists in armhf release pocket
[23:31] <juliank> God polishing up these tools will be messy but I think they are all useful
[23:32] <juliank> Probably shipping them in like apt-archive-reports in apt-team on salsa because lolz
[23:38] <juliank> oof 00:38
[23:38] <juliank> smell you later, as some would say :)
[23:41] <vorlon> juliank: yes those dashes :)
[23:42] <vorlon> doko: purple-lurch> thanks, removing from release pocket then and filing a bug


[01:13] <mboman> Has anyone tried Ubuntu ME on the Asus EEE PC?
[01:13]  * The_PHP_Jedi shivers at 'ME'... why not call it UM or something :-/
[01:13] <The_PHP_Jedi> and no, I don't own an eeePC
[01:18] <mboman> but I should be able to install it on a SD card and boot form that, right? (if you assume that the EEE can boot from SD cards)
[01:19] <The_PHP_Jedi> well, in theory it would, since it can boot OSes from an SD card.
[01:19] <The_PHP_Jedi> maybe tested devices are in the FAQ somewhere
[01:41] <cgregan> The_PHP_jedi, mboman: I believe the Canonical Mobile Solutions Group has a Eee and is actively testing on it. Lemme poke my head over into the Canonical internal irc to see if anyone can confirm.
[01:41] <mboman> cgregan: that would be great!
[01:41] <The_PHP_Jedi> nice
[01:50] <cgregan> Sorry folks, Canonical does have a Eee, but not in the MSG.
[01:52] <cgregan> I believe the standard desktop team is the one working with it.
[05:31] <rdvon> what devices will this work for?
[06:51] <dholbach> good morning
[06:52] <aristocrat> can anybody help me understand the "Acceptance Criteria" for Ubuntu Mobile ?
[06:53] <dholbach> aristocrat: what exactly are you after?
[06:54] <aristocrat> dholbach, i beleive there is some document which specifies an "Acceptance Criteria" , its some document required as part of any project..
[06:55] <dholbach> accept what? I'm not sure what you're looking for?
[06:55] <aristocrat> I think it discusses what the final product has to be and bla bla.. some project management information ..
[06:56] <dholbach> phew.... no idea - is nothing on https://wiki.ubuntu.com/MobileAndEmbedded and in the blueprints tracker?
[06:56] <aristocrat> dholbach, didnt find one there... this is a hard doc to find ..:)
[06:57] <dholbach> https://blueprints.launchpad.net/~ubuntu-mobile is what the mobile team is working on
[06:57] <dholbach> that's all I know
[06:59] <aristocrat> dholbach, i'll have go through it.. ur help is appreciated
[06:59] <dholbach> no problem :)
[06:59] <dholbach> I'm not intimately familiar with the mobile project, just lurking here :)
[07:00] <aristocrat> hey if you accidently fall upon aything that states "acceptance criteria" or related.. send me a msg..
[20:02] <bspencer> is hardy stable enough for production system?
[20:02] <bspencer> I'd like to start using it on one of my systems so I can validate the hardy ppa images, but I don't want to spend the day debugging unrelated issues
[20:23] <pat_mcgowan> bspencer, you still there?
[20:24] <pat_mcgowan> bspencer, many folks have switched to Hardy, although regressions can still happen
[20:24] <pat_mcgowan> bspencer, if you have multiple systems, for sure its ok
[20:36] <\sh> lool: just found bug #198861 with the hildon patch against claws-mail 3.3.0...can you test if this patch applies cleanly to 3.3.1, which hit hardy earlier on?
[20:36] <ubotu> Launchpad bug 198861 in claws-mail "There's no flag to enable hildon interface when building for lpia" [Undecided,New] https://launchpad.net/bugs/198861
[21:20] <pat_mcgowan> GrueMaster, testing question for you
[21:20] <pat_mcgowan> GrueMaster, have you run Cheese on a D0 or D1 lately?
[21:26] <GrueMaster> No, but I can.
[21:26] <GrueMaster> I have a D1 fired up now.
[21:32] <GrueMaster> I'll have to reboot.  Apparently Moblin doesn't support uvcvideo
[21:39] <lool> \sh: I'll try to
[21:39] <lool> Don't have the choice
[21:40] <\sh> lool: I'll port the diff now to 3.3.1
[21:40] <\sh> lool: we just need an FFe for it, because it introduces a new feature ;)
[21:40] <GrueMaster> pat_mcgowan:  Looks ok.  taking a picture shows my ugly mug no problem.  Video record seems semi-smooth (~15-20 FPS).
[21:41] <GrueMaster> I can't playback the video because of the moblin-media docking bug.
[21:41] <\sh> lool: and if you have an idea, how to emulate such a device (I think it's those nokia n8xx series, right?) I'm happy to test those things too :)
[21:42] <pat_mcgowan> GrueMaster, thanks, what build do you have? and what docking bug, no FAT partition?
[21:43] <GrueMaster> This is the Ubuntu Hardy Beta2 from 20080228 with <IP_ADDRESS>L.0010 PSB video.
[21:44] <GrueMaster> I saw an email thismorning on the moblin media issue, but rusty's solution didn't work for me.
[21:48] <pat_mcgowan> GrueMaster, I see, he's saying to undefine the mount point so moblin-media ignores it
[21:49] <pat_mcgowan> The problem we had was we disabled the FAT partition creation and all heck broke loose, then we had to do a similar thing
[21:49] <pat_mcgowan> GrueMaster, thanks for the test, something has broken in the last two weeks of upgrades and changes, trying to narrow it down
[21:49] <GrueMaster> ok, it still doesn't seem to fix my side.  I'll root around a bit.
[21:50] <GrueMaster> Is this in ubuntu or your "other" image?
[21:59] <pat_mcgowan> GrueMaster, other
[22:01] <GrueMaster> I'll give it a whirl in a little bit.  I have 20080313.
[22:11] <pat_mcgowan> GrueMaster, one more thing, our camera uses v4l2 and that seems to be part of the issue
[22:25] <\sh> lool: it looks like that adilson forgot to include ./configure in his patch after he ran aclocal -I m4 ; automake --gnu ; autconf ...
[22:28] <GrueMaster> pat_mcgowan: Not sure what mine uses, but I'll check.  I know it uses the uvcvideo driver.
[22:33] <pat_mcgowan> GrueMaster, if you lsmod it should show the chain
[22:34] <GrueMaster> I did.  It shows uvcvideo, compat_ioctl32, videodev, v4l1_compat, and v4l2_common.
[22:35] <GrueMaster> uvcvideo is the actual hardware driver.  It's for the newer "Vista" ready web cams.
[22:43] <pat_mcgowan> GrueMaster, thats our output too
[23:03] <\sh> lool: I'll attach a debdiff to the bug report for you guys to test build and test run it...
[23:58] <virtuald> hey, are there any experimental repositories for ubuntu-mobile?
[23:58] <virtuald> specifically, the media player