[00:32] <thumper> davecheney: not yet... mostly knowledge transfer for cherylj, although I do have one problem I'm putting off today that would be good to do
[00:34] <cherylj> yessss, give me ALL THE KNOWLEDGE!
[00:38]  * perrito666 wants to know new zealand and thinks thumper should adopt him into his team temporarily
[00:38] <thumper> perrito666: happy to :)
[00:39] <thumper> perrito666: and... Air NZ now doing direct flights to Argentina
[00:39] <thumper> probably has something to do with rugby and the pumas :)
[00:39] <perrito666> thumper: price in bars of gold?
[00:40] <perrito666> last time I checked direct flight was somewhere in the 20k usd :p
[00:40] <thumper> probably going to get cheaper :)
[00:40] <perrito666> sweet
[00:40]  * perrito666 packs cooking gear
[00:43] <anastasiamac> perrito666: cooking gear?..
[00:45] <perrito666> anastasiamac: I am sure there is something nice to cook in new zealand and I dislike cooking without my own knife :p
[00:45] <perrito666> so who is OCR? http://reviews.vapour.ws/r/736/ this inlocks the critical bug
[00:46]  * perrito666 installs go cross compile to avoid having to go for a windows every time
[00:50] <perrito666> waigani: ?
[00:52] <menn0> davecheney: actually, wifi works, it just took an unusually long time connect after suspend. possibly nothing to do with the latest kernel.
[00:53] <perrito666> menn0: I have heard more people complain of things like that with latest kernel
[00:58] <davecheney> thumper: i plan to monopolise mwhudson 's time and grind through as many bugs as we can on our port
[01:02] <davecheney> perrito666: reviewed
[01:02] <davecheney> fix it, then ship it
[01:02] <perrito666> davecheney: td
[01:02] <perrito666> tx
[01:03] <perrito666> aghh I keep forgetting we are in 2015
[01:04] <davecheney> 2015, all year
[01:04] <anastasiamac> perrito666: aah... that would explain high prices on travel to nz
[01:05] <anastasiamac> perrito666: if everyone form argentine brings their ***cough*** cooking knives
[01:05] <anastasiamac> perrito666: u do know that Maories r peaceful pppl? not easily provoked? nor known for their aggression? .. :P
[01:06] <perrito666> anastasiamac: I dont know if you noticed this but there is no call where thumper doesn't have a bruise
[01:06] <thumper> perrito666: ha
[01:08] <anastasiamac> perrito666: rofl
[01:09] <perrito666> can we make the bot oblivious to the diff between - and _ ??
[01:12] <ericsnow> perrito666: I gave you a review on that restore fix
[01:12] <ericsnow> perrito666: is there a reason why you can't just add a restore_windows.go?
[01:13] <perrito666> right now the pressing time
[01:14] <perrito666> ericsnow: anyway, it was faster to stub Restore than to stub all of the methods that fail
[01:16] <wallyworld_> anastasiamac: standup?
[01:16] <perrito666> ericsnow: to be honest I am a bit curious on why do we build any of that in windows
[01:22] <davecheney> thumper: i'm not having anyluck getting someone on #is to look at that RT
[01:34] <davecheney> ericsnow: can you please close/delete this review http://reviews.vapour.ws/r/621/
[01:34] <davecheney> it's dead
[01:34] <ericsnow> davecheney: sure
[01:35] <ericsnow> davecheney: the PR should be closed too
[01:35] <thumper> davecheney: did as much poking as I could...
[01:35] <thumper> menn0: I have a bad feeling about this
[01:35] <menn0> thumper: about what?
[01:36] <thumper> menn0: someone elses upgrade step
[01:36] <thumper> that I don't think it does what they thought it did
[01:36] <thumper> I cribbed someone else's setp
[01:36] <thumper> step
[01:36] <thumper> and did things slightly differently
[01:36] <thumper> particularly about the assertions
[01:36] <thumper> perhaps it is working by side-effect
[01:36]  * thumper shrugs
[01:38] <menn0> thumper: which one?
[01:38] <thumper> menn0: the one in agentconfig.go
[01:38] <thumper> I'm also changing agent config
[01:38] <thumper> but I'm trying to see where it actually gets written to disk
[01:38] <thumper> and it isn't during the step
[01:40] <thumper> hmm... only have a ConfigSetter
[01:40] <thumper> there must be a reason why we don't write in the upgrade steps
[01:40] <menn0> thumper: not sure... looks like it's Dimiter's work
[01:46] <thumper> menn0: ah ha
[01:46] <thumper> menn0: the changes to the agent config are saved at the end of the upgrade steps
[01:46]  * thumper fixes his tests
[01:47] <menn0> thumper: of course.
[01:47] <menn0> thumper: the steps are run inside a ChangeConfig
[01:48] <thumper> yep...
[02:03] <wallyworld_> thumper: core meeting?
[02:03] <wallyworld_> menn0: also?
[02:03] <wallyworld_> davecheney: ditto
[02:21] <perrito666> anastasiamac: I trust you noticed the coloring in thumper 's right eye
[02:21] <thumper> perrito666: you are imagining things
[02:21] <thumper> not been hit for ages
[02:21] <thumper> as I've had to let my shoulder heal
[02:21] <perrito666> thumper: you live in a dangerous place, you have orcs for god sake :p
[02:22] <perrito666> I have senn it on tv
[02:22] <anastasiamac> perrito666: orcs r seasonal
[02:23] <perrito666> lol
[02:23] <anastasiamac> perrito666: only from Boxing Day onwards
[02:55] <thumper> menn0: fyi https://github.com/juju/juju/pull/1417/files
[02:56] <thumper> anyone game? http://reviews.vapour.ws/r/738/
[02:56] <thumper> wow, three pages of diff
[02:57] <thumper> $ git diff master | wc -l
[02:57] <thumper> 1792
[02:57] <thumper> sorry reviewer
[02:57] <thumper> most of that is real necessary
[02:57] <thumper> some of it isn't...
[02:57] <thumper> but most of it is
[03:46] <menn0> thumper: i'm having a look
[04:06] <thumper> menn0: how did you test upgrades before when the upgrade is listed against 1.23.0 and the version is 1.23-alpha1?
[04:11] <thumper> menn0: wondering because I have a running 1.22 environment and I thought I might as well test the upgrade
[04:11] <thumper> but since the upgrade steps are listed against 1.23.0... I don't think they'll run
[04:20] <wallyworld> axw: blake suggested in the maas doc using "/dev/disk/by-id/<foo>" as the block device identifier. I think this would work? Can you comment in the doc to confirm?
[04:21] <menn0> thumper: I changed things a while back so that upgrade steps for the final version are run when you upgrade to any alpha or beta of that version
[04:21] <menn0> thumper: the steps will run
[04:21] <thumper> menn0: oh nice
[04:21] <thumper> menn0: thanks
[04:22] <menn0> thumper: it was wallyworld's suggestion. that way we can test steps while working towards a final version.
[04:22] <thumper> makes sense
[04:26] <menn0> thumper: Fix it and ship it
[04:28] <thumper> menn0: confirmed that starting a new environment has all agents dialing the env uuid version
[04:29] <thumper> menn0: I wish we had a setting that could say "please restart after you have finished upgrading"
[04:30] <thumper> menn0: thanks for the timely review of this massive piece of work
[04:30] <thumper> menn0: but I think it should wait until monday to land
[04:30] <thumper> I still need to test upgrades and a few tweaks from the review, but running out of time today, need to pack
[04:32] <mattyw> davecheney, you still around?
[04:33] <davecheney> mattyw: ping
[04:46] <axw> wallyworld: will do.
[04:46] <wallyworld> ty
[06:42] <wallyworld_> jam: did we ever get a definitive yes/no on whether Openstack is in scope for storage? It's missing completely from the Provider Specific Tactics section of the spec, but is a line item in the "in scope" section
[07:44] <dimitern> jam, axw, PTAL http://reviews.vapour.ws/r/740/ - migrating goamz imports from LP to GH
[07:44]  * dimitern needs to step out for ~1h
[07:46] <axw> dimitern: lgtm
[07:47] <dimitern> axw, thanks!
[07:50] <axw> wallyworld_: can't read your pgpmail
[07:50] <wallyworld_> oh, ffs, stupid thunderbird
[08:02] <axw> wallyworld_: you have question, do you mean for 1:1 tomorrow?
[08:02] <axw> questions*
[08:49] <axw> wallyworld_: if you're around, https://github.com/juju/juju/pull/1420
[08:49] <axw> bot hasn't picked it up for some reason ...
[09:15]  * fwereade out for a bit
[10:03] <dimitern> TheMue, standup?
[10:58] <TheMue> dimitern: morning and sorry for missing the hangout
[10:58] <TheMue> dimitern: third bad night in a row, had to change clothes several times
[10:59] <TheMue> dimitern: at least in the morning hours I found some sleep
[11:00] <TheMue> dimitern: so will now work on the couch reading all the networking information and ask you each time there's something unclear :)
[11:02] <dimitern> TheMue, hey, morning!
[11:02] <dimitern> TheMue, sorry to hear that :/ I hope you'd start feeling better!
[11:03] <dimitern> TheMue, sure - sgtm, there's a lot to read :)
[11:04] <TheMue> dimitern: I hoped so too, I seldom have something for more than one day. so I already canceled being at the Oldenburg English Club today :(
[11:04] <TheMue> dimitern: yeah, I thought that's a good opportunity, have to make the best out of the situation
[11:05] <mgz> perrito666: I have reopened bug 1411024 because the mac client still does not build with your change from last night
[11:05] <mup> Bug #1411024: Win client/agent cannot bug built because of backup deps <ci> <regression> <windows> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1411024>
[11:08] <dimitern> TheMue, +1
[11:08] <dimitern> TheMue, I wish you a quick recovery in any case
[11:09] <dimitern> mgz, ha!@
[11:09] <TheMue> dimitern: thanks, I wish it too. *lol*
[11:09] <dimitern> mgz, I though it might be a problem as in the fix the "_linux" suffix was used, rather than _unix
[11:10] <mgz> dimitern: well, it should be an easy fix to the fix then :)
[11:11] <dimitern> mgz, however I'm not sure whether we support backups on mac os?
[11:13] <mgz> dimitern: I think we clearly don't need to at the moment
[11:13] <mgz> there's probably no real reason it shouldn't work, but we just need the client to build for now :)
[11:14] <dimitern> mgz, yeah, but do you know if it *ever* worked on mac?
[11:14] <dimitern> mgz, because if it didn't the fix is a lot easier
[11:14] <mgz> dimitern: I suspect the old shell script hack would have, if anyone ever tried
[11:15] <mgz> it's certainly not something we signed up for supporting, or have been verifying works
[11:15] <mgz> (the backup/restore test jobs only use the client under ubuntu)
[11:15] <dimitern> mgz, cool, that's all the confirmation I need for now :)
[11:45] <dimitern> mgz, https://github.com/juju/juju/pull/1421 - that's the fix
[11:46] <dimitern> mgz, can you re-run the failing jobs after it lands manually to speed-up the unblocking?
[11:49] <dimitern> can anyone review this please? ^^ axw, fwereade, voidspace, ?
[11:49] <voidspace> dimitern: looking
[11:49] <dimitern> voidspace, ta!
[11:50] <voidspace> dimitern: LGTM
[11:50] <dimitern> for some reason a RB diff wasn't generated
[11:50] <fwereade> dimitern, LGTM too, I'm just a bit too slow
[11:50] <dimitern> voidspace, thank you, setting to merge to unblock trunk
[11:50] <mgz> dimitern: it should go straight through - the build jobs are early on as well
[11:52] <dimitern> mgz, cool!
[12:01] <perrito666> mgz: tx
[12:02] <perrito666> dimitern: and tx to you too
[12:03] <dimitern> perrito666, np, I'm opening a beer tab ;)
[12:03] <perrito666> you won it :p will have to wait until apri though
[12:04] <dimitern> hehe it's closer than you think ;)
[12:05] <perrito666> dimitern: we can go have beer and sausages with sauerkraut
[12:06] <dimitern> perrito666, great idea! we should definitely put it on the agenda
[12:07] <perrito666> well, it is on mine :p
[12:13] <mgz> ci is building the new rev
[12:25] <dimitern> mgz, it would be very useful if on pages like this http://reports.vapour.ws/releases/2232 "Last build" links *both* to the job in jenkins and the console log output (ideally not as application/octet-stream but text/plain, so it can be viewed in the browser directly)
[12:26] <mgz> dimitern: yeah, I'm working on tidying those last bits up now
[12:26] <dimitern> mgz, you rock!
[12:49] <dimitern> voidspace, please, take a look at the stub NetworkInterfaces - http://reviews.vapour.ws/r/742/
[13:02] <fwereade> wallyworld_, don't suppose you're around? wanted to ask about when we set StatusInstalling
[13:03] <wallyworld_> fwereade: give me 5
[13:09] <wallyworld_> fwereade: when ModeInstalling is called and also when ModeConfigChanged is called and state is not Starting
[13:10] <fwereade> wallyworld_, right, am confused about setting it at ModeConfigChanged time
[13:10] <wallyworld_> maybe that's not necessary - i think it was a s/Installed/Installing thing
[13:11] <fwereade> wallyworld_, ok cool
[13:11] <wallyworld_> but if we do get config changed and we are not set up yet
[13:11] <wallyworld_> then installing seems reasonable
[13:11] <wallyworld_> maybe the check just needs to be expanded
[13:12] <fwereade> wallyworld_, then we should surely still be in Installing state? ah-*ha*, we might have gone into hook error on install
[13:12] <wallyworld_> yup
[13:12] <fwereade> wallyworld_, I don't think it should be a config-changed-time check though, I think it's part of committing an installed state
[13:12] <fwereade> wallyworld_, does that sound sane?
[13:13] <wallyworld_> i think so, but am a little tired so will think properly tomorrow
[13:13] <fwereade> wallyworld_, or, hmm
[13:13] <fwereade> wallyworld_, no, actually, I think you're right
[13:13] <wallyworld_> which bit?
[13:14] <fwereade> wallyworld_, setting it at the start of config-changed
[13:14] <wallyworld_> that did seem reasonable
[13:14] <wallyworld_> at the time
[13:14] <fwereade> wallyworld_, it was judicious and forward-thinking, I appreciate it
[13:15] <wallyworld_> not sure if i put it there or adapted it or whatever
[13:15] <fwereade> wallyworld_, fwiw I think you set StatusInstalling in the wrong part of ModeInstalling but I'm touching that as I go
[13:15] <wallyworld_> could well do - i am a uniter novice
[13:16] <wallyworld_> be gentle with me, it's my first time
[13:16] <wallyworld_> doing stuff with uniter
[13:16] <fwereade> wallyworld_, no worries, it's just that ModeInstalling isn't the mode func, it *returns* the mode func
[13:17] <wallyworld_> yes, you are right. maybe i was thinkin that if it was at the point of setting up for install, it should be put in installing
[13:17] <wallyworld_> ie transition from allocating to installing sooner
[13:18] <wallyworld_> as by then clearly allocation had been done
[13:18] <fwereade> wallyworld_, anyway you don't need to do anything, I just wanted to check up/rubber duck what was going on
[13:18] <wallyworld_> np, ty
[13:18] <fwereade> wallyworld_, I dunno, I think the moment we start looking up the charm is a fine time to set the status
[13:18] <fwereade> wallyworld_, btw did we get an upgrading status?
[13:19] <wallyworld_> hmmm, no
[13:19] <wallyworld_> we should probs add that, after checking with john
[13:20] <fwereade> wallyworld_, we can manage fine without it but I think it's cleaner
[13:20] <wallyworld_> i think i agree
[13:21] <fwereade> wallyworld_, cool, I will assume that'll be the approach if I bump up against it
[13:21] <wallyworld_> ok
[13:30] <dimitern> mgz, got a link to the win/mac build jobs?
[13:33] <dimitern> mgz, ah, found them from the last curse message
[13:40] <perrito666> dimitern: any luck?
[13:42] <dimitern> perrito666, well - so far so good
[13:42] <axw> if anyone's got time for a quick review, that'd be great... may have slipped by unnoticed since the RB bot didn't pick it up: https://github.com/juju/juju/pull/1420
[13:43] <dimitern> perrito666, only the "revision results" job has to succeed
[13:44] <dimitern> perrito666, but afaics the win/mac builds passed
[13:47] <voidspace> dimitern: looks good
[13:47] <voidspace> dimitern: still reading
[13:48] <voidspace> dimitern: why the ++ changed to --
[13:48] <dimitern> voidspace, great
[13:48] <voidspace> dimitern: why the ++ changed to -- ?
[13:49] <dimitern> voidspace, well, it seemed more appropriate - releasing an address should decrement the maxAddr as it could be useful for tests like Allocate, Release, Allocate
[13:51] <voidspace> ah, ok
[13:52] <voidspace> at least you haven't claimed to do live testing on this one...
[13:54] <voidspace> Dummy implementation looks good/useful
[13:58] <voidspace> dimitern: if the -- change made no difference to any tests, or any code anywhere, then I'm sceptical it's needed at all...
[13:58] <voidspace> dimitern: other than that, LGTM
[13:58] <voidspace> dimitern: well, let me look at the dummy implementation one more time before I sign off
[13:58] <voidspace> lots of TODOs added as well
[13:59] <dimitern> voidspace, I agree we shouldn't plan too far ahead for what tests we *might* need
[13:59] <voidspace> dimitern: I dislike/distrust code written for imaginery future use cases.
[14:00] <dimitern> voidspace, that s/++/--/ seems like a good idea, but I don't mind reverting it if you disagree - it's just a detail anyway
[14:00] <dimitern> voidspace, +1, although I need to get better at judging this :)
[14:00] <voidspace> sure
[14:00]  * dimitern bbiab
[14:01] <voidspace> balancing future planning with that is difficult
[14:01] <voidspace> no easy answers
[14:04] <voidspace> dimitern: yep, LGTM
[14:04] <voidspace> dimitern: my mortgage guy is due here any minute and I'm going to make coffee
[14:08] <anastasiamac> fwereade: o/
[14:08] <fwereade> anastasiamac, heyhey
[14:09] <anastasiamac> fwereade: how r u?
[14:09] <fwereade> anastasiamac, good thanks, and you?
[14:09] <anastasiamac> fwereade: m good but weary
[14:09] <anastasiamac> could I run smth by u?
[14:09] <fwereade> anastasiamac, ofc
[14:09] <anastasiamac> fwereade: about annotations...
[14:09] <fwereade> anastasiamac, go on
[14:10] <anastasiamac> fwereade: to meet kapil's requirments, we need to list charms
[14:10] <anastasiamac> fwereade: I've added API call to current client
[14:10] <anastasiamac> fwereade: bumping it's version but m not 100% sure it's good
[14:11] <anastasiamac> fwereade: not sure if 1 call warrants a separate API either
[14:11] <fwereade> anastasiamac, my gut would say to have a new facade
[14:11] <fwereade> anastasiamac, hot on its heels will, I suspect, be requirements that we delete charms
[14:11] <fwereade> anastasiamac, etc etc
[14:11] <anastasiamac> fwereade: excellent! will change tomorrow :)
[14:11] <fwereade> anastasiamac, and check the current api, there's a charm-info (or something) call
[14:12] <anastasiamac> fwereade: shall i move it?
[14:12] <fwereade> anastasiamac, which would be happy on that facade I think
[14:12] <fwereade> anastasiamac, yes please
[14:12] <fwereade> anastasiamac, which is to say don't *move* it, leave it where it is too, and then we don't need a version change on client
[14:12] <anastasiamac> fwereade: purrrfect :) wallyworld_ and I were wondering but u've cleared it all up ;)
[14:13] <fwereade> anastasiamac, cool
[14:13] <anastasiamac> fwereade: thnx for ur time and insight :)
[14:13] <fwereade> anastasiamac, np
[14:50] <dimitern> anastasiamac, you've got a review on the ListCharms PR
[14:52] <dimitern> wtf?! ERROR juju.cmd supercommand.go:411 failed to bootstrap environment: dial tcp <IP_ADDRESS>:22: ConnectEx tcp: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
[14:52] <dimitern> mgz, is the job itself flaky? http://juju-ci.vapour.ws:8080/job/win-client-deploy/1298/console
[14:53] <mgz> dimitern: sinzui has been wrangling with it
[14:54] <dimitern> mgz, cool
[14:54] <sinzui> dimitern, ssh on that machine sucks
[14:55] <dimitern> sinzui, :/
[14:56] <dimitern> well, I hope there's still a chance to unblock master later today
[14:57] <mgz> dimitern: build-osx-client passed, so your fix was fine
[14:57] <dimitern> voidspace, thanks for the review
[14:58]  * dimitern sings the happy dance ;)
[14:58] <dimitern> or dances the happy song lol
[14:58] <mgz> eheheh
[15:30] <dimitern> BLESS!
[15:30] <dimitern> oh joy
[15:31] <mgz> dimitern: yeay! unblocked
[15:31] <perrito666> dimitern: thank youuuuu
[15:32] <dimitern> perrito666, mgz, cheers guys!
[16:52] <katco> wwitzel3: ericsnow: did either of you do a write-up on how you broke up your branch? i'm coming up on a large-ish change.
[16:52] <ericsnow> katco: we haven't gotten there yet :)
[16:52] <katco> ericsnow: doh!
[16:53] <katco> i suppose there must be something out there on google when the time comes
[16:55] <ericsnow> katco: but the idea I had is to remove everything I don't want in the review and commit that on the branch and then create the PR (and review request)
[16:55] <ericsnow> katco: then add back in the stuff for the next patch and commit in a new branch (and use rbt --parent)
[16:55] <ericsnow> katco: then repeat until it's back up to where it was before you started splitting things up
[16:56] <ericsnow> katco: that way you don't lose all your git history
[16:56] <katco> ericsnow: i think my general hunch was the inverse: create a new branch and begin merging in certain files
[16:56] <ericsnow> katco: where to split things up is a different question
[16:57] <ericsnow> katco: though keeping each review request a manageable size is one key objective
[16:57] <katco> ericsnow: yeah, that's the only reason i am doing it
[16:57] <ericsnow> katco: the problem with that is the loss of history
[16:57] <katco> ericsnow: very true
[16:58] <ericsnow> katco: right now our branch has over 100 commits in it (I think)
[16:58] <katco> ericsnow: wow that's awesome
[16:58] <ericsnow> katco: and most of that is valuable information
[16:58] <wwitzel3> yeah, I'd like to avoid losing our commit history
[16:58] <ericsnow> katco: wwitzel3 and I have taken the approach of keeping commits focused
[16:59] <katco> ericsnow: i aspire to be that diligent, but i always get trapped in the "gosh can this really be an atomic commit"
[16:59] <katco> ericsnow: as in, could this functionality stand alone
[16:59] <ericsnow> wwitzel3: one alternative is to manually generate the patches and create the review requests manually and then merge the whole branch when *all* the requests get a ship-it
[16:59] <ericsnow> wwitzel3: but that seems like more work
[16:59] <katco> ericsnow: i think i need to shift my thinking on that somehow
[17:00] <ericsnow> katco: sometimes you can and sometimes you can't :)
[17:00] <ericsnow> katco: usually, though, you can :)
[17:00] <katco> ericsnow: :)
[17:00] <ericsnow> katco: try using the "-p" option to git add
[17:00] <wwitzel3> yeah -p for the win
[17:01] <ericsnow> katco: we've used it to great effect when we've made changes that we want to split into multiple commits
[17:01] <wwitzel3> ericsnow: yeah, honestly, I think we could probably, in most cases just do file and file_test as a commit.
[17:01] <katco> ericsnow: ah cool, so you're picking out bits of files?
[17:02] <wwitzel3> ericsnow: not commit, review
[17:02] <wwitzel3> katco: yeah, we just select the bits that make up an atomic commit
[17:03] <wwitzel3> katco: I've found it much easier to do when you have all of the context, instead of trying to do with with forsight
[17:04] <wwitzel3> ericsnow: anyeay, I agree it is more work, but I think we've done a good enough job of file seperate that it is probably the best approach
[17:06] <katco> wwitzel3: i agree. i cannot with any reliability land slices of the stack without having first coded the entire stack. there's just too much back and forth as the design emerges.
[17:50] <perrito666> does anyone know how to prevent google chrome from popping those notifications before meetings??
[17:51] <dimitern> perrito666, in the calendar - edit the event and uncheck reminders
[17:51] <perrito666> dimitern: What I actually want is to stop chrome from breaking the 4th wall
[17:51] <dimitern> perrito666, Notifications -> [ Pop-up ] [ 10] [minutes] (x)
[17:52] <dimitern> perrito666, whaa? :)
[17:52] <perrito666> dimitern: I dont want to be able to pop notifications into my window manager
[17:52] <perrito666> I mean chrome
[17:54] <perrito666> There is a small bell that shows in the indicator and a pop up thing tells me that I have a meeting, I dont want chrome to do that , it is invasive and also clashes with my ubuntu calendar
[17:54] <dimitern> perrito666, aah!
[17:55] <dimitern> perrito666, those .. I knew how at some point and managed to turn them off, but I forgot how
[17:55] <perrito666> it is not obvious in the ui
[18:07] <perrito666> rick_h_: there is a nice lady talking in yourbehalf in the call
[18:15] <voidspace> dimitern: decorator fail : http://maas.ubuntu.com/docs/api.html
[18:37] <dimitern> voidspace, I can't see anything unusual :)
[18:39] <voidspace> dimitern: :-)
[18:42] <dimitern> voidspace, all my branches merged, finally
[18:43] <voidspace> dimitern: great
[18:44] <voidspace> dimitern: I got sidelined into mortgage applications - didn't make as much progress as I should have
[18:44] <voidspace> dimitern: but for once I have nothing planned this evening so might do some more in front of the TV
[18:44] <voidspace> dimitern: I got the signatures changed, but not much on the implementation for MAAS / EC2
[18:44] <dimitern> voidspace, no worries, I wanted to unblock you before I go today
[18:44] <voidspace> dimitern: easy stuff though
[18:44] <voidspace> dimitern: yeah, thanks
[18:45] <voidspace> ah, and the new goamz branch
[18:45] <voidspace> cool
[18:45] <dimitern> voidspace, yep - shiny and squeaky
[18:45] <voidspace> Nice :-)
[18:45] <dimitern> :)
[18:46] <voidspace> dimitern: so, I already had booked a "geek dinner" in London of the Thursday that we're together in London
[18:46] <dimitern> ok, I'll be off then - a long day that was
[18:46] <voidspace> dimitern: you'd be welcome
[18:46] <voidspace> dimitern: go have a break
[18:46] <dimitern> voidspace, nice!
[18:46] <voidspace> yeah, saves me a trip if I'll already be in London...
[18:46] <dimitern> voidspace, awesome :)
[18:47] <voidspace> I'm signing off for now
[18:47] <voidspace> going jogging
[18:47] <voidspace> g'night all
[18:47] <dimitern> voidspace, enjoy
[19:25] <rick_h_> perrito666: who da what?
[19:25] <rick_h_> perrito666: nice lady?
[19:28] <perrito666> rick_h_: on the call we where hearing an operator voice
[19:29] <rick_h_> ah lovely
[19:29] <rick_h_> what a mess
[20:14] <sinzui> perrito666, do you have a few minutes to review http://reviews.vapour.ws/r/744/
[20:16] <sinzui> abentley, jog: I have my lull. I will review abentley's branch first
[20:17] <jog> sinzui, that's fine, abentley, said he'd look at mine
[21:15] <perrito666> katco: hey, what was the magic invocation to get different output formats in juju?
[21:15] <perrito666> and which version is that in?
[21:16] <katco> perrito666: juju status --format
[21:16] <katco> perrito666: juju help status will give you all the options
[21:16] <katco> perrito666: and i believe it's in >= 1.22
[21:24] <anastasiamac> didmitern: r u still around?
[21:26] <perrito666> katco: tx a lot
[21:27] <katco> perrito666: np, enjoy :)
[21:29] <sinzui> perrito666, do you have a minute to review  http://reviews.vapour.ws/r/744/
[21:30] <perrito666> sinzui: sure
[21:30] <perrito666> anyone local provider savvy?


[00:00] <mlankhorst> ah so its just a coverup for a bet
[00:00] <mlankhorst> made while drunk ;P
[00:33] <slangasek> Mirv: I'm confused by the SRU for bug #1056743.  Why is this done as a new upstream version instead of just a distro patch... and why did the version number jump from 5.12.0 to 5.18.0?
[00:46] <infinity> Packages to change from priority required to important
[00:46] <infinity> ------------------------------------------------------
[00:46] <infinity> libexpat1
[00:46] <infinity> libpython3.3-minimal
[00:46] <infinity> python3-minimal
[00:46] <infinity> python3.3-minimal
[00:46] <infinity> I win.
[01:19] <slangasek> bryce: the xorg-server in the precise-proposed queue was uploaded with the wrong -v option, so is missing refs to bugs #1070481 and #1010794.  Could I trouble you to reupload with the -v option?
[01:28] <bryce> slangasek, done.
[01:28] <slangasek> bryce: ta
[01:29] <robert_ancell> @pilot in
[03:06] <mspencer> I've recently started working on a launchpad project called Ubuntu Contributor Console, based off a spec on wiki.ubuntu.com. Is the ubuntu-devel-announce mailing list a good place to announce it and to get people interested in contributing to it?
[03:09] <micahg> no, maybe ubuntu-devel if it's related to Ubuntu Development
[03:10] <mspencer> Here's the wiki page: https://wiki.ubuntu.com/ContributorConsole
[03:12] <mspencer> micahg: So is it okay to announce it on that mailing list and list some things I don't know how to do and would like others to help on?
[03:14] <micahg> depends what you're asking for help wiht
[03:14] <micahg> *with
[03:16]  * micahg isn't sure....maybe someone else can answer this
[03:20] <mspencer> I don't really mean asking for help, I mean more like listing things that people could contribute if they are interested. Some things that I'm not good at/don't know how to do are designing an icon, coding the Updates panel (the ability to install and test SRUs).
[04:35] <pitti> Good morning
[04:35] <highvoltage> hello pitti
[04:43] <Mirv> slangasek: it's just a habit of that multi-personality of acting as a normal upstream project, making a new release when there are worthy commit(s). version bump because the idea of releasing eg. all "SRU-3" stack components at the same time with the same version number
[04:44] <Mirv> but for lenses, there are usually only single commits so distro patching would make sense as well
[04:44] <Mirv> but thanks for approving it already
[05:54] <slangasek> Mirv: you're welcome :)
[06:08] <doko> what's the state of the -compat package?
[06:08] <doko> infinity, ^^^
[06:28] <abogdan> I'm developing my first ubuntu app usig Quickly (python + gtk). I want to use some files and folders in my app. Do you know how to pack them together?
[06:31] <ScottK> abogdan: I think you want #ubuntu-app-devel.
[07:32] <dholbach> good morning
[09:13] <pitti> ev: WDYT about http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/509 ?
[09:15] <ev> pitti: looking
[09:15] <pitti> ev: with this, make check succeeds for me
[09:30] <ev> pitti: yeah, that looks entirely reasonable
[09:30] <ev> thanks for that!
[09:30] <ev> feel free to merge
[09:30] <pitti> ev: pushed
[09:30] <ev> thanks
[09:31] <pitti> ev: I didn't get much further with the test suite as I don't want to require root for it; but I need to figure out the system identifier
[09:31] <ev> ah, right
[09:31] <pitti> ev: so my idea was to finish the whoopsie branch to be able to start as normal user if you set a custom report dir and id
[09:31] <pitti> ev: such as
[09:31] <pitti> $ CRASH_DB_URL=http://localhost:8080 CRASH_DB_IDENTIFIER=TESTSUITE APPORT_REPORT_DIR=/tmp/x src/whoopsie -f
[09:31] <pitti> which I have working already, just cleaning up a bit
[09:32] <pitti> ev: does that sound ok to you?
[09:32] <ev> yes, as it also means we could someday use that to generate a known identifier that we could filter out server-side
[09:32] <pitti> ev: it would also allow us to drop the "sudo stop whoopsie" bits from run-from-juju
[09:33] <ev> woo
[09:33] <ev> I was initially startled by that second password prompt :)
[09:38] <pitti> ev: hm, do you know that locking is broken without -f?
[09:39] <ev> I did not know that, no
[09:39] <pitti> ev: the foreground process closes the lock fd as soon as it terminates
[09:39] <ev> eep
[09:39] <pitti> no biggie, it just caught my eye; works fine with -f
[09:49] <pitti> ah, very good; all working now
[09:55] <ev> awesome
[09:57] <pitti> ev: I tested this now with both the default "run as root" case, as well as running as user: http://paste.ubuntu.com/1425021/
[10:10] <pitti> ev: some cleanups and commit msg: http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/510
[10:11] <pitti> ev: oh, this includes the packaging, sorry; I'll re-do the commit to update debian/changelog
[10:11] <ev> thanks
[10:11] <ev> ah excellent on opportunistically fixing the APPORT_REPORT_DIR bug
[10:13] <pitti> ev: changelog pushed for previous commit
[10:14] <ev> yay
[10:14] <pitti> ev: http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/511
[10:33] <pitti> ev: while I was at it, I also fixed all compiler warnings in http://bazaar.launchpad.net/~pitti/whoopsie/fixes/revision/512
[10:33] <pitti> ev: I'll push that once 511 gets reviewed and can land
[10:33] <ev> wow, you're on a roll!
[10:34] <ev> fwiw, I'm making it so that we can mock out the openid provider in lp:errors and adding decent error pages for authentication failures, so it doesn't just confusingly loop back to the openid login page
[10:34] <pitti> ev: my goal for the day is to get the ARM retracing running; prerequisite for this is a working test suite, which again depends on being able to get reports out of the API, which in turn depends on predictable system IDs, which depend on those whoopsie changes :)
[10:34] <ev> oh, I'll also chase up that ticket for getting openstack credentials
[10:34] <ev> so we can get tarmac in place
[10:34] <ev> :D
[10:35] <ev> turtles all the way down
[10:36] <pitti> ev: do you want to give this some deeper eyeballing, want an MP, etc?
[10:36] <ev> I'm looking over it now - no need for an MP
[10:37] <ev> looks excellent
[10:37] <ev> this reminds me that I want to get the gcov stuff in the Makefile working again
[10:38] <ev> feel free to merge
[10:39] <pitti> ev: pushed (for cleaner history); mind if I send this raring-wards? or do you want to do further changes?
[10:39] <ev> https://bugs.launchpad.net/whoopsie/+bug/1088847
[10:39] <ev> please do
[10:39] <pitti> yeah, that sounds useful indeed
[10:39] <pitti> with pygobject I was really surprised how easy that was to set up, and how useful it its
[10:39] <pitti> s/its/is/
[10:40] <ev> pitti: by the way, if you have good ideas on how to do mocking in C, I'm all ears. There's obviously a few options: function pointer arguments, splitting code more into libraries where you drop in a testing version, etc.
[10:41] <pitti> ev: the standard way known to me is to overwrite functions with an LD_PRELOAD library
[10:41] <ev> pitti: so define all the mock functions with the same function signatures as their non-mock counterparts in a library, then use LD_PRELOAD?
[10:41] <ev> makes sense
[10:42] <pitti> right
[10:42] <pitti> not very elegant for sure, but unless you design the code in the way you mentioned I don't know another way
[10:43] <cjwatson> And indirecting everything through function pointer arguments is pretty un-C-like; I suspect it also has performance penalties
[10:44] <pitti> or you use GObject more, and thus get the function pointes that way (through the vtable)
[10:44] <ev> cjwatson: yeah, that was very much a strawman
[10:44] <pitti> ev: what do you want to mock in whoopsie?
[10:44] <ev> I don't like having to bust out cdecl to understand a function prototype
[10:44] <pitti> ev: (I guess you are talking about whoopsie, as all the other bits are py)
[10:45] <cjwatson> typedefs help a lot, but yes ...
[10:45] <ev> pitti: for example, if we wanted to test handle_response
[10:45] <ev> pitti: when we start getting a number of different potential responses from the server
[10:46] <ev> it either needs to take a function argument to delegate to, or we need to mock out upload_core and friends
[10:46] <pitti> ev: wouldn't it be better to whip up a mock server in python and have whoopsie talk against that?
[10:47] <ev> hm, I suppose. I come from two conflicting schools of thought. The "test things in isolation" (previous python projects) and "test all the way down the stack" (lifeless' test harness for oops-repository, which requires a running cassandra)
[10:47] <ev> but I guess the later is going to give far more interesting results
[10:47] <lifeless> ev: I'm actually a mix of both
[10:48] <pitti> if you want to test for responding to server answers, this is already an integration test
[10:48] <lifeless> for my current thinking, see the ServiceRequirements stuff on dev.launchpad.net
[10:48] <lifeless> where I suggest having a python mock server that supports error injection, starts up in a jiffy etc.
[10:48] <pitti> so I think a mock server and running the actual whoopsie thing is better, as it avoids mocking over test code that you actually want to test
[10:49] <lifeless> the reason oops-repository runs all of cassandra is simple; the low level api wasn't stable when I did it, and mocking unstable APIs is a terrible idea.
[10:50] <ev> understood, to both of your points
[10:53] <pitti> ev: hm, if I make use of this feature in integration-test and run-juju-daisy, we depend on a raring-only version of whoopsie; would that be ok?
[10:54] <pitti> ev: not much trouble for a developer, but I guess we might want to run this for nagios at some point? we could run whoopsie out of bzr for that, of course
[10:54] <ev> pitti: I believe so. We can always stick it in a PPA for other releases if it becomes necessary.
[10:54] <ev> pitti: indeed we do want to run it for nagios
[11:03] <pitti> ev: oops, the kill command in run-juju-daisy doesn't kill the test whoopsie daemon (so it doesn't restore to sending to errors.u.c); fixing that along
[11:03] <ev> cheers
[11:07] <vibhav> win 18
[11:07] <vibhav> oops
[11:07] <vibhav> Sorry people
[11:25] <Laney> kirkland: do you still maintain manpages.ubuntu.com?
[11:34] <xnox> Laney: are you also longing for recent releases?
[11:35] <xnox> Laney: I think we just should fork the config: add/remove releases and file RT to get it redeployed.
[11:35] <xnox> https://code.launchpad.net/ubuntu-manpage-repository
[11:37] <Laney> sure, that was the secret intent behind the ping
[11:39] <siretart> RAOF: do you have a second to discuss bug #985202 with me?
[11:39] <Laney> xnox: making it dynamic would be even better ;-)
[11:40] <xnox> Laney: true.... not sure if IS will like dynamism =) anyway, not sure if it will let me push back due to acient bzr repo format.
[11:40] <Laney> well, using distro-info
[11:41] <xnox> Laney: is that installed?
[11:41]  * xnox goes to talk to webops/is.
[11:42] <Laney> i'm sure it could be
[11:47] <xnox> Laney: why is distro-info --supported listing raring as supported release?
[11:47] <xnox> Laney: should I filter out --devel from --supported, or do we want manpages early?
[11:48] <Laney> does it always take the latest as the default?
[11:48] <Laney> and I dunno, sounds like a bug
[11:48] <Laney> bdrung: is that a bug?
[11:50] <Laney> debian-distro-info --supported looks similarly fishy
[11:53] <Laney> xnox: note there is python-distro-info for the python part
[11:53] <xnox> Laney: sure, but manpages.ubuntu.com is a pile of shell & perl scripts with config file sourced as shell.
[11:53] <xnox> Laney: so... DISTROS=`distro-info --supported` works just fine =)
[11:54] <Laney> there's at least search.py with a list of versions
[11:54] <Laney> dict
[11:54] <xnox> Laney: and some javascript as well =(
[11:54] <Laney> unlucky
[11:55] <xnox> Laney: do we SRU distro-info or does it fetch data over the interwebz?
[11:55] <Laney> the former
[11:55] <Laney> distro-info-data
[11:58] <Laney> (so IS has to take that SRU for the site to know about new releases, which is still easier than a full deployment)
[12:02] <bdrung> Laney: that depends how you define supported.
[12:02] <Laney>        --supported
[12:02] <Laney>               list of all supported stable versions
[12:03] <bdrung> "stable" is the issue here.
[12:04] <bdrung> maybe it should be able to retrieve all supported stable version and all supported (not released) versions
[12:05] <xnox> bdrung: well --devel says raring, maybe it should somehow exclude devel from --supported.
[12:30] <xnox> Laney: filed RT, just a static update.
[12:30] <Laney> alright
[12:30] <Laney> ty
[12:30] <xnox> Laney: we have ~ a year to port this webapp to distro-info-data.
[13:06] <hrw> how to debug system where dbus is running but all dbus related tools say that it is not? where networkmanager is running (as a process) but there is no dbus so all tools say that NM is not running...
[13:19] <israeldahl> anyone know much about using imagemagick in the debian/rules file to draw the icon?  is it possible?
[13:25] <OdyX> israeldahl: what do you want to achieve ?
[13:26] <OdyX> israeldahl: create an icon from an upstream image ?
[13:27] <israeldahl> OdyX: the icon looks awful when it gets installed and I want it to look correct. this is for lmms
[13:29] <sil2100> doko: ping!
[13:31] <israeldahl> I have had to resort to linking to a different file in the lmms.desktop, but I want to fix it the right way
[14:03] <Laney> @pilot in
[14:04] <robert_ancell> @pilot out
[14:04] <Laney> :-)
[14:04] <micahg> Laney: how did you cross that continent so fast :)
[14:05] <xnox> Laney: cheat.
[14:05] <Laney> collapsars
[14:44] <didrocks> barry: hey, around?
[14:47] <barry> didrocks: hi!
[14:47] <didrocks> sil2100: maybe sum up what the issue you discovered to barry (which is making compiz and a lot of other build-deps failing) ^
[14:48] <sil2100> barry: hi!
[14:48] <barry> sil2100: hi :)
[14:49] <sil2100> barry: ok, so, compiz builds are failing on raring due to missing pyconfig.h in the python2.7 packages - in the past it was installed by python2.7-minimal
[14:49] <sil2100> But since the latest version (uploaded yesterday?) the file is missing from all the python packages
[14:49] <sil2100> I traced down the problem, and found which revision of the packaging branch removed it
[14:49] <sil2100> Maybe by accident? SInce I'm not sure if it's intended
[14:49] <sil2100> http://bazaar.launchpad.net/~doko/python/pkg2.7-debian/revision/93
[14:50] <sil2100> Here in the diff of debian/rules, around line 732 in that file
[14:51] <sil2100> I saw some debian/rules cleanup there, so I though that maybe this one line got removed by accident
[14:51] <sil2100> barry: do you know anything about this ;) ?
[14:52] <didrocks> cyphermox: I think the indicator issue you got yesterday is maybe linked to that as well ^
[14:52] <barry> sil2100: yes.
[14:53] <barry> sil2100: this change is for multiarch, and it's really a bug in your builds :)  you should be using `python-config --includes` to find the include paths to things (and --libs, etc.)
[14:53] <xnox> sil2100: it's the same change as with python3.3 - there are now two include locations.
[14:53] <sil2100> barry: but hm, then which package installs pyconfig.h then?
[14:53] <sil2100> Since it's not in python2.7-minimal anymore, neither is it in -dev and libpython2.7-dev
[14:54] <xnox> sil2100: one of dependencies of python-dev
[14:56] <seb128> sil2100, dpkg -S pyconfig.h
[14:56] <xnox> sil2100: i still should be libpython2.7-dev
[14:56] <seb128> sil2100, it's installed, just in /usr/include/<arch>/...
[14:56] <xnox> sil2100: the point is that python multi-arch now uses 2 include locations /usr/include/python2.7 and /usr/include/<arch>/python2.7 and you need both includes.
[14:57] <sil2100> xnox: ah, indeed, it's in libpython2.7-dev
[14:57] <barry> libpython2.7-dev
[14:57] <sil2100> xnox: thanks! See it now
[14:57] <barry> oops, yeah
[14:57] <barry> :)
[14:57] <sil2100> We'll update the dependencies then!
[14:57] <sil2100> I couldn't find it due to multiarch ;)
[14:57] <barry> it's a brave new world
[14:57] <sil2100> seb128: thanks as well!
[14:57] <xnox> sil2100: can I see your build-log? as I did patch ~20 packages to find both include locations, when I was transitioning packages to python3.3 (which also uses multiarch locations)
[14:57] <sil2100> didrocks: I'll make a merge request for that
[14:58] <sil2100> xnox: https://launchpadlibrarian.net/125437610/buildlog_ubuntu-raring-i386.compiz_1%3A0.9.9~daily12.12.05bzr3522pkg0raring0_FAILEDTOBUILD.txt.gz
[14:58] <didrocks> sil2100: excellent! Thanks a lot for digging in :)
[14:59] <xnox> sil2100: thanks. well the build-record, such that I can grab source? e.g. which ppa is this for? =)
[14:59] <seb128> xnox, get compiz from raring I guess it will have the same issue
[14:59] <xnox> nevermind see it: unity-team/staging
[14:59] <sil2100> xnox: https://launchpad.net/~unity-team/+archive/staging/+build/4055447
[14:59] <xnox> sil2100: thanks.
[14:59] <sil2100> xnox: just pull lp:compiz and you're done ;)
[15:00] <sil2100> But I'm preparing a merge request for the change right now anyway, so we'll have it fixed soon
[15:00] <Laney> @pilot out
[15:00] <xnox> sil2100: ok, can you pastebin a patch such that I can review it?
[15:00] <xnox> sil2100: or point to merge proposal?
[15:01] <didrocks> xnox: we do merge proposal for everything in our world :)
[15:01] <didrocks> (with peer reviews)
[15:01] <xnox> ok =)
[15:01] <xnox> didrocks: bzr diff | pastbin & comments on irc is also "peer review" =)))))
[15:01] <sil2100> xnox: I'll post the link to the merge proposal here ;)
[15:02] <didrocks> xnox: right, but the merger won't care about your comment on IRC :)
[15:02] <xnox> sil2100: it's just CMake's FindPython is broken, and instead I was using PkgConfig which will find python2.7 libs & includes correctly.
[15:05] <seb128> xnox, shouldn't cmake by fixed in that case?
[15:05] <sil2100> didrocks, xnox: I'll just test-build it quickly
[15:05] <didrocks> sil2100: "quickly"? aren't you talking about building compiz? :p
[15:05] <sil2100> ...;p
[15:06] <xnox> seb128: that would be lovely, but FindPython cmake module is a bit over-engineered and I didn't manage to find an easy way to hook a second include directory check in it.
[15:06] <seb128> xnox, compiz uses cmake so it's likely going to be the same cmake bug? we will need to fix cmake anyway rather than workaround in each component...
[15:09] <xnox> seb128: yes, and now. FindPython returns a single include path, this change requires that it now returns a list & uses an include list, so unsuspecting CMakeLists will still be broken =/ for python3.3 i fixed something like 3 packages which used CMake python detection incorrectly. Only one of them used CMake's module, the others had "embedded copies with changes".
[15:10] <xnox> seb128: e.g. even compiz kind of overrides and does stuff to the cmake's findpython module. so although fixing cmake would help, but is not guaranteed to fix all cmake packages....
[15:11] <xnox> e.g. I don't understand why so many packages use "custom" python detectors instead of using pkg-config.
[15:11] <xnox> same story applies to all the autoconf stuff which also missdetects python in different ways.
[15:11]  * xnox finished ranting about build systems.
[15:12] <seb128> xnox, yeah, I don't know, people tend to just copy build tools snippet around so errors and weird stuff got copied as well
[15:12] <xnox> =`(((((
[15:12] <xnox> clearly everyone should switch to waf build system.
[15:12]  * xnox hides =)
[15:12] <seb128> lol
[15:15] <doko> barry, xnox: maybe I'll just include a fake header for all know multiarch tuples
[15:16] <barry> doko: not sure what that means
[15:16] <xnox> doko: please don't. we should just fix stuff. When are we having a rebuilt to spot all of these? Or shall we upload into py2.7 ppa.
[15:16] <xnox> doko: also I think I finally did figure out & CMake has knoweledge of debian's multiarch triplets. I just need to find time to dig into cmake again.
[15:17] <xnox> doko: plus it's probably my fault, in some packages e.g. boost/blender I only applied python haz multiarch locations for py3 builds only. I didn't know we will have py2.7 multiarch in raring as well later on.
[15:35] <barry> didrocks: how do you maintain the packaging branch for oneconf?  i think i can do a quick update of debian/ if the latest trunk is merged in (but i don't want to break things)
[15:43] <doko> xnox, barry: something like http://paste.ubuntu.com/1425505/
[15:43] <barry> doko: oh wow, yeah.  maybe put that in a new python2.7-your-build-is-broken binary package? :)
[15:44] <didrocks> barry: it's a native package, just a quick update of debian/changelog, I'll push to trunk for you and please upload :)
[15:45] <xnox> doko: is that going into "multiarch-support" package? :P
[15:45] <barry> didrocks: some changes will be needed for d/control d/rules
[15:51] <barry> didrocks: shall we bump the version to 0.3? :)
[15:52] <didrocks> barry: I'm fine with that :)
[15:52] <barry> didrocks: cool :)  i'll push an mp after some local testing
[15:52] <didrocks> barry: sounds perfect! :)
[16:06] <doko> seb128, what was the source package for the python autoconf test. there was one, but I can't remember which one ...
[16:07] <mfisch> mhall119: FYI, singlet has some warnings about deprecated methods when run in raring
[16:07] <mfisch> mhall119: I think the fix is safe in Q as well: PyGIDeprecationWarning: MainLoop is deprecated; use GLib.MainLoop instead
[16:07] <Laney> @pilot in
[16:09] <xnox> doko: autoconf archive?
[16:09] <doko> no, autoconf doesn't have such kind of macro themself
[16:10]  * dholbach hugs Laney
[16:11] <xnox> doko: I meant autoconf-archive package, a package of extra autoconf macros, e.g. it has a broken /usr/share/aclocal/ax_python_devel.m4
[16:18] <rbasak> ogra_: around? I'm having trouble reproducing bug 1079185 for SRU verification.
[16:18] <rbasak> ogra_: it's holding up landing the fix for bug 1084106
[16:20] <xnox> doko: python-2.7.pc file has "-I${includedir}/x86_64-linux-gnu/python2.7m" while the include dir shipped is just -I${includedir}/x86_64-linux-gnu/python2.7 (no abiflag m)
[16:21] <xnox> doko: it's inconsistent, and which way should it be? shipping 2.7m includedir as well or declare 2.7 includedir as "/before/"?
[16:23] <mvo> didrocks: I get a error when trying to build compiz (trunk) on raring, it python3.3m/Python.h complains that pyconfig.h is not found - is that a known issue? it looks like fallout from the include moving from /usr/include/python3.3m to /usr/include/x86_64-linux-gnu/python3.3m
[16:23] <didrocks> mvo: see the discussion we had here 1h30 ago ^
[16:23] <didrocks> mvo: new python changed and is multiarch, sil2100 works on a fix
[16:24] <mvo> didrocks: aha, nice. then I will not duplicate this effort
[16:24] <didrocks> no need! :)
[16:25] <sil2100> mvo, didrocks: we're working on it, but the fix hm, doesn't work, since (if I understand xnox's analysis correct) there might be a bug in the new python packaging
[16:26] <xnox> yes.
[16:28] <arges> is there a wiki on how to setup sbuild to build ddebs? I've looked through this: https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment but am not sure if I need to add certain DEB_BUILD_OPTIONS to get it working.
[16:29] <xnox> arges: if you create sbuild with mk-sbuild, you auto-get ddebs.
[16:30] <seb128> doko, dunno for python autoconf test...
[16:30] <arges> xnox, in precise? or does it need to be a newer sbuild host?
[16:30] <xnox> arges: alternatively you need to install pkg-create-dbgsym inside the sbuild. Note a package can override & skip building ddebs (e.g. e2fsprogs)
[16:31] <xnox> sil2100: filed bug 1088988
[16:32] <xnox> arges: I don't run precise, but I thought that feature was around forever. Did you create chroots with mk-sbuild or manually / some other way?
[16:32] <arges> xnox, with mk-sbuild...
[16:32] <arges> xnox, mk-sbuild --arch=amd64 --distro=ubuntu lucid
[16:32] <arges> xnox, not sure if there si something special I need to add to .mk-sbuild.rc
[16:33] <xnox> arges: schroot into it and check if pkg-create-dbgsym package is installed, if not install it in the golden / source image and you should start generating ddebs.
[16:33] <arges> xnox, ok and those ddebs will get placed in the same location as the .debs  then after a build?
[16:33] <xnox> arges: which you can reconfirm by reading the buildlog - it will announce redirecting dh_strip / generation of ddebs.
[16:34] <xnox> arges: yes.
[16:34] <arges> xnox, ok i'll investigate, I looked at the buildlogs and I saw it was installing pkg-create-dbgsym
[16:34] <sil2100> didrocks, mvo, xnox: after this would get fixed, I think this merge request could be considered?
[16:34] <sil2100> https://code.launchpad.net/~sil2100/compiz/fix_python_find_package/+merge/139256
[16:38] <sil2100> hmm, strangely, I can't link a branch to a bug
[16:39] <sil2100> https://bugs.launchpad.net/compiz/+bug/1088996
[16:39] <sil2100> Here's the FTBFS bug, but I'm unable to link my branch to it ;p
[16:40] <sil2100> Ok, finally I was able
[17:56] <arges> xnox, so I rebuild the schroot with no special .mk-sbuild.rc . I tried to sbuild with no options (no ddebs andI see dh_strip), I tried DEB_BUILD_OPTIONS=debug,nostrip,noopt and still doesn't build the ddeb
[17:57] <arges> and I also still see the dh_strip ... so not sure if its particular to the package... I tried using 'hello' then 'ispell' (just to see if it works)
[18:00] <xnox> arges: well, it works for me on quantal/raring. i'll try against on precise and will let you know.
[18:00] <arges> xnox, ok, I'll try on raring here as well... trying to target precise
[18:00] <xnox> arges: have you tried installing pkg-create-dbgsym in the golden/source image as I suggested earlier?
[18:01] <arges> xnox, so I see it pulled in the buildlog
[18:01] <xnox> arges: 1 second - what does your machine run & what do you build for?
[18:01] <xnox> arges: can you pastebin the buildlog?
[18:01] <arges> xnox, running precise amd64, schroot is lucid amd64
[18:02] <arges> xnox, sure one second
[18:02] <arges> xnox, pastebin.ubuntu.com/1425766
[18:03] <xnox> arges: i don't think ddebs existed in lucid.
[18:03] <xnox> arges: but I might be wrong.
[18:03] <arges> xnox, there is a release directory in ddebs.ubuntu.com
[18:04] <arges> xnox, for lucid
[18:04] <Laney> @pilot out
[18:04] <seb128> xnox, you are wrong ;-)
[18:06] <xnox> arges: in that particular case pastbined 2322-2328 it says that it didn't create ddeb, because all binaries were already stripped: no debug symbols - no ddeb for you.
[18:07] <xnox> arges: apart from that it is working "correctly"
[18:07] <seb128> xnox, https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-November/000355.html
[18:08] <seb128> xnox, it was well before lucid ;-)
[18:08] <arges> xnox, ok so I need to pick another package that has ddebs...
[18:08] <xnox> seb128: ok =0)))
[18:09] <arges> xnox, i picked that one because it was small and I did find the -dbgsym in the ddebs archive
[18:09] <arges> for lucid though
[18:09] <arges> xnox, also pkg-create-dbgsym is in the golden master image
[18:10] <arges> it was already created by default
[18:10] <arges> s/created/installed
[18:11] <xnox> arges: pitti is probably the best person to ask about dbgsym. but he might be offline already.
[18:12] <xnox> it recent releases "it just works" & i never did dbgsym packages for lucid.
[18:12] <arges> xnox, ok i'll hack on it
[18:12] <arges> xnox, i'll try a precise schroot next . thanks a ton for your help!
[18:12] <xnox> arges: no worries, but it's not like i solve the problem for you =/
[18:14]  * arges lunches
[18:32] <mhall119> mfisch: did you file a bug and submit a patch?
[18:40] <mdeslaur_> barry: is there a mailman command to get a list of the lists I'm subscribed to?
[18:58] <barry> mdeslaur_: from the command line, or email command (or via web)?
[19:14] <mdeslaur_> barry: from the web
[19:15] <mdeslaur_> barry: or email
[19:15] <mdeslaur_> barry: ie: I don,t have access to the command line
[19:26] <mfisch> mhall119: will do so
[19:30] <barry> mdeslaur_: the way to do it from the web is to log in to any list you know you're a member of, then on the options page look for "List my other subscriptions"
[19:30] <barry> @pilot in
[19:32] <arges> xnox, ok precise schroot on precise behaves as expected building the .ddebs properly , but lucid schroot on precise doesnt' build ddebs.
[19:32] <mdeslaur_> barry: ah, cool...thanks!
[19:33] <barry> np!
[19:34] <micahg> arges: are you doing xz debs?
[19:35] <arges> micahg, hi. there isn't xz compression in the debian/rules file for the package I am building. essentially I want to be able to get ddebs from a package in general when building in a lucid schroot
[19:36] <micahg> arges: ok, sorry, was missing some context, I know xnox was trying to get xz ddebs...
[19:36] <arges> micahg, I was following the security build environment wiki on setting this up actually.  But out of the box, precise schroot builds the ddebs, while lucid schroots do not
[19:36] <micahg> let me see if I have an ddebs from lucid builds locally
[19:39] <micahg> arges: which package are you trying?
[19:39] <arges> micahg, at this point I'm trying any package... I tried 'hello' then I tried 'ispell' since I saw that it had dbgsyms generated in ddebs.ubuntu.com for lucid
[19:40] <arges> micahg, i'd like to build a kernel with ddebs in a schroot, but rebuild/test cycle is pretty lengthy
[19:40] <micahg> TBH, idr if I get them or not
[19:40] <micahg> just kicked off a build to see if I do
[19:42] <arges> micahg, ok . did you add any DEB_BUILD_OPTIONS or add anything when you called mk-sbuild?
[19:44] <mfisch> mhall119: here you go: https://code.launchpad.net/~mfisch/singlet/fix_deprecation_warning/+merge/139301
[19:45] <mhall119> thanks mfisch
[19:45] <micahg> arges: nope, and I don't get them on lucid, even with pkgbinarymangler installed
[19:46] <arges> micahg, hmm ok.  is this a bug I should file? or am I missing something
[19:46] <infinity> micahg: pkg-create-dbgsym, you mean.
[19:47] <infinity> micahg: pkgbinarymangler doesn't make ddebs.
[19:47] <micahg> infinity: right..
[19:47] <arges>  infinity yea and I confirmed pkg-create-dbgsym is in the golden master lucid schroot by default
[19:47] <infinity> This reminds me that I need to recreate all my schroots after my great hard drive crash.  What a pain.
[19:48] <micahg> actually, with pkg-create-dbgsym I do get the ddeb :)
[19:48] <barry> mfisch: what's the deal w/cracklib2 2.8.20?  your branch is status merged into lp:ubuntu/cracklib2 but the source branch doesn't reflect that.
[19:49] <micahg> arges: want a build log?
[19:49] <mfisch> barry: I thought someone merged it this morning, let me look
[19:49] <arges> micahg, did you add it somehow? I entered the chroot and it said pkg-create-dbgsym was installed
[19:49] <micahg> arges: it wasn't in my chroot for some reason, I added it with --add-depends
[19:51] <mfisch> barry: looks like someone merged it to me: https://code.launchpad.net/~ubuntu-branches/ubuntu/raring/cracklib2/raring
[19:51] <arges> micahg, ok --add-depends , you are adding that to sbuild or mk-sbuild?
[19:51] <infinity> arges: pkg-create-dbgsym is pretty vocal about disabling itself.  Do you have a build log?
[19:51] <micahg> arges: sbuild
[19:52] <arges> micahg, ok i'll try that
[19:52] <arges> infinity, yea, I have a pastebin somewhere
[19:52] <infinity> "somewhere". :P
[19:53] <arges> infinity,  pastebin.ubuntu.com/1425766
[19:54] <infinity> arges: Right, so it's clearly installed and being triggered.
[19:55] <barry> mfisch: ah, bzr bd info is out of date
[19:55] <mfisch> barry: so In the bug I also added a debdiff and the bug still shows in the sponsor queue, whats the right change there?
[19:57] <infinity> arges: The binaries in all those packages are already stripped, there's nothing pkg-create-dbgsym can do there.
[19:57] <arges> infinity, ok so i need to choose another package then
[19:57] <SpamapS> jml: would you ever consider making undistract-me Expat licensed rather than PD?
[19:58] <SpamapS> jml: I'm packaging it for Debian and PD is.. less than desirable since it is a non-license.
[19:58] <barry> mfisch: looks like the bug was not closed by the changelog entry.  that's why adding (LP: # 1088110) is useful.  at this point, i think just manually closing the bug as fixed released is the way to go
[19:58] <micahg> arges: DEB_BUILD_OPTIONS=parallel=4 debug nostrip noopt
[19:58] <mfisch> barry: oh, sorry I forgot the LP in the changelog
[19:58] <arges> micahg, yea that's what I added
[19:58] <infinity> nostrip would likely do it.
[19:59] <barry> mfisch: no worries, i closed the bug
[19:59] <mfisch> thanks
[20:17] <arges> micahg, infinity : ok i figured it out... needed to use a package that actually build debug symbols properly. thanks for the help
[20:31] <jtaylor> doko: have you forwarded the scipy m-a patches?
[20:32] <jtaylor> doesn't look like it ..
[20:40] <jtaylor> doko: I hope you don't mind, I made a pull request to scipys git
[21:55] <doko> jtaylor, thanks!
[22:02] <GunnarHj> Riddell: ping
[22:03] <Riddell> hi GunnarHj
[22:03] <GunnarHj> Riddell: Hello!
[22:04] <GunnarHj> Riddell: Saw your comment on bug 1041126. Does it mean that you prefer that we keep language-selector-kde for the time being?
[22:04] <Riddell> GunnarHj: isn't ubuntu desktop dropping language selector as well?
[22:05] <slangasek> why would it?
[22:05] <GunnarHj> Riddell: Yes, but it will probably be postponed yet another dev. cycler
[22:05] <Riddell> it's been on the wish list to replace it with the gnome module for cycles
[22:05] <slangasek> ah
[22:06] <GunnarHj> Riddell: And other derivatives, Xubuntu and Lubuntu, want to keep using it.
[22:06] <Riddell> GunnarHj: mm well we've no plans to pick it back up again currently so you can quietly let it bit rot if needed
[22:06] <Riddell> s/derivatives/flavours/
[22:07] <GunnarHj> Riddell: Ok, that may be a better word. :)
[22:07] <GunnarHj> Riddell: Thanks for giving me free hands as regards l-s.
[22:11] <jml> SpamapS: the license is whatever the hell makes it easy to distribute as open source
[22:11] <jml> SpamapS: expat is fine
[22:14] <ricotz> cjwatson, hi :), is it possible to get something like this into raring? http://paste.debian.net/plain/215675
[22:16] <GunnarHj> slangasek: Hi Steve, will you have time soon to take a look at https://code.launchpad.net/~gunnarhj/ubuntu/raring/pam/encrypted-home/+merge/135021 ?
[22:16] <slangasek> GunnarHj: I'm expecting to get to it next week
[22:16] <GunnarHj> slangasek: Great, thanks for letting me know.
[22:19] <ricotz> cjohnston, sorry for the typos :\ http://paste.debian.net/plain/215676
[22:19] <ricotz> cjwatson, ^
[22:21] <Laney> the most incorrectly tab completed nickname in the universe
[22:23] <slangasek> LanaTurner: yeah, sucks to be them
[22:23] <infinity> slank: :P
[22:23] <ricotz> Laney, oh, if you insist you can take a look too ;P
[22:25] <Laney> you probably want sla<tab> to look at that :-)
[22:26] <infinity> ricotz: I assume this magical new libpango doesn't exist yet?
[22:26] <ricotz> Laney, ok ;)
[22:26] <infinity> (I still have 1.6.0 here...)
[22:27] <ricotz> infinity, it is a new upstream release which is available for quite some time, but probably won't find its way into raring
[22:27] <ricotz> https://launchpad.net/~ricotz/+archive/staging/+sourcepub/2835187/+listing-archive-extra
[22:27] <infinity> ricotz: Kay, so just prepping plymouth for the future?
[22:28] <ricotz> exactly, and for ppa users of course ;)
[22:28] <ricotz> this newer pango is a hard-dep for the current gtk+3.0 dev releases
[22:29] <infinity> I assume it's still libpango1.0-0?
[22:29] <infinity> ie: not coinstallable with the previous version?
[22:29] <ricotz> yes it is
[22:29] <infinity> Kay, maybe this can autodetect a bit more sanely, then.
[22:31] <ricotz> probably, either way i would be happy to get it supported
[22:33] <infinity> for i in $(find /usr/lib/x86_64-linux-gnu/pango/ /usr/lib/pango/ -name libpango1.0-0.modules 2>/dev/null); do if [ -e $i ]; then echo ${i%%/module-files.d*}; fi; done
[22:33] <infinity> Gives me /usr/lib/x86_64-linux-gnu/pango/1.6.0 here.
[22:33] <infinity> Does it give you what you'd expect there?
[22:34] <ricotz> /usr/lib/x86_64-linux-gnu/pango/1.8.0
[22:34] <ricotz> here ;)
[22:34] <infinity> Right, I'll clean that up and use something like that, then.  Hardcoding the versioned path seems suboptimal.
[22:34] <ricotz> that is fine, thanks!
[22:35] <infinity> We can probably ditch the pre-MA path too, depending on when that was introduced.  Let me check.
[22:35] <ricotz> it is in precise for sure, so i guess it can be dropped
[22:36] <infinity> Oh, is this code also in Debian's plymouth?  Might be better to change it there.
[22:36] <infinity> slangasek: *pokity*
[22:36] <slangasek> mm?
[22:37] <slangasek> infinity: oh, is this why there's a bug report about text not rendering in the initramfs in raring? :P
[22:37] <infinity> No, this should be fine in raring.
[22:37] <slangasek> oh
[22:37] <infinity> Unless someone's using ricotz's PPA.
[22:37] <infinity> Then, not so much.
[22:37] <slangasek> probably not, since it's an ISO tester
[22:37] <slangasek> infinity: please file a bug report then
[22:38] <infinity> slangasek: Sure.  I was going to JFDI in Ubuntu, but if this exists in Debian too, may as well tidy it up a bit.
[22:38] <slangasek> infinity: er, then please file a bug report against the Debian package too? :)
[22:38] <infinity> A nick hilight wasn't enough? :P
[22:38] <slangasek> rumors to the contrary notwithstanding, I am not Daniel Baumann
[22:39] <infinity> I could have sworn I'd seen your name in the Debian plymouth changelog before.
[22:40] <infinity> Could be that it's Crack Tuesday.
[22:40] <slangasek> you could well have!  My name is in lots of changelogs
[22:40] <slangasek> I like to change things
[22:40] <slangasek> but I don't maintain plymouth in Debian ;)
[22:42] <hallyn> is there a debhelper way to add a /etc/sysctl.d/ file from a package?
[22:43] <infinity> hallyn: echo foo /etc/sysctl.d > debian/package.install
[22:43] <infinity> hallyn: HTH.
[22:43] <ricotz> infinity, oh, btw did you get my pm?
[22:43] <hallyn> infinity: ok, thanks :)
[22:43] <infinity> hallyn: (In other words, no, I don't think there's a helper for it)
[22:43] <slangasek> hallyn: you might want >> though :)
[22:43] <infinity> slangasek: Nah, the rest of the package's files were crap anyway.
[22:43] <slangasek> but yes, there's no specific helper for sysctl
[22:44] <infinity> ricotz: Maybe.
[22:44] <hallyn> screw the rest of the pkg.  sysctl will do it all
[22:44] <infinity> ricotz: Was is ASCII porn?
[22:44] <infinity> s/is/it/
[22:44] <ricotz> infinity, heh, let me try again
[22:44] <infinity> ricotz: If it was glibc-related, I haven't forgotten you.
[22:49] <ricotz> infinity, yeah, that too, if you have a ppa to check feel free to share ;)
[22:49] <infinity> ricotz: No, I have a hard drive to recover, and an experimental upload to prepare after that.
[22:50] <ricotz> alright
[22:52] <infinity> slangasek: Of course, it could be that this initramfs hook is Ubuntu-specific anyway (it is), so nevermind.  I'll just fix it here and carry on
[23:23] <xnox> micahg: we have xz ddebs  for raring, not anything earlier.
[23:23] <xnox> arges: ping pitti about ddebs on lucid-sbuild with precise host.
[23:25] <arges> xnox, so I figured out how to get ddebs for some packages
[23:26] <arges> xnox, trying to figure out how to get ddebs for linux kernel now
[23:27] <infinity> arges: The kernel build is "special".
[23:27] <infinity> arges: And has nothing to do with pkg-create-dbgsym (at all).
[23:27] <infinity> arges: It does it all by hand in rules.
[23:28] <arges> infinity, is there a wiki that explains how to do this via dpkg-buildpackage and sbuild?
[23:28] <infinity> The kernel team doesn't use sbuild for kernel testbuilds, so unlikely.
[23:29] <arges> infinity, so how to PPAs accomplish building the ddebs?
[23:29] <arges> i thought they used buildd which used sbuild?
[23:29] <infinity> Different sbuild.
[23:29] <infinity> But also, not the same thing at all, since you want your ddebs to end up in .changes, which they don't on the buildds.
[23:30] <arges> infinity, ok
[23:32] <infinity> arges: See debian/rules.d/2-binary-arch.mk
[23:32] <infinity> arges: Basically, it checks a magic buildd-only file, and does magic things based on it.  Which won't work for you. :P
[23:32] <arges> infinity, yea i see hmm
[23:33] <infinity> arges: So, either fix the source to unconditionally do what it normally does in that Build-Debug-Symbols case, or don't auto-clean your sbuild chroots, so you can fish the ddebs out of chroot/build/
[23:33] <infinity> (And by "fix", I mean "fix locally", cause it's doing the right thing in the archive right now)
[23:34] <arges> infinity, ahh I think there was a hook to do that somewhere
[23:35] <infinity> arges: You mean an sbuild hook to set up CurrentlyBuilding to look kinda like a buildd?
[23:35] <infinity> arges: That would work too.
[23:35] <arges> infinity, https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Setting_up_and_using_Sbuild_with_ddebs
[23:36] <arges> infinity, which had the  /etc/schroot/script-get-ddebs script. I'll give that a shot and see if it works
[23:37] <infinity> That would do the trick.
[23:37] <arges> infinity, cool... i'll give that a shot.
[23:37]  * arges heads out
[23:48] <barry> @pilot out


[02:20] <OvenWerks> kubuntu uses it even less...
[03:12] <Eickmeyer[m]> OvenWerks: Well, that means it's a flaw in systemd in that the graphical target isn't being used yet. Chances are, it was never implemented in the systemd code.
[03:12] <Eickmeyer[m]> Hence why xdg/autostart is still in use.
[03:21] <OvenWerks> That still leaves us with processes that don't stop
[03:22] <OvenWerks> (leaves everybody with)
[03:26] <Eickmeyer[m]> Unless we have the daemon check for a keepalive somehow.
[03:26] <Eickmeyer[m]> OR, set a pid file somewhere that if it sees it, it kills the previous process and sets a new pid.
[03:26] <OvenWerks> Ya, which one?
[03:27] <OvenWerks> it won't see a previour pid if it a different user
[03:27] <Eickmeyer[m]> Why not if it's in /tmp
[03:27] <OvenWerks>  unless we start thinking sudo stuff
[03:28] <Eickmeyer[m]> And there's another idea. Why not a systemd daemon that watches for multiple instances of autojack and kills the first one spawned if another one launches?
[03:31] <Eickmeyer[m]> I'm just trying to think outside the box here.
[03:32] <OvenWerks> Ya, I know.
[03:32] <Eickmeyer[m]> Basically, anything we come up with might not be necessarily "correct", but we need to get the job done.
[03:35] <OvenWerks> I can make it work in xfce with no problem... it is the making de agnostic part that is hard.
[03:36] <Eickmeyer[m]> Yeah. I understand.
[03:36] <OvenWerks> It seems all the people who use ubuntu/debian/whatever never logout to login as another user.
[03:36] <OvenWerks> this is certainly why this bug has been around for years...
[03:41] <Eickmeyer[m]> I mean, there has to be a workaround, or something we can do.
[03:41] <OvenWerks> There will be
[03:42] <OvenWerks> We may have to generate our own target(s) to do it.
[03:43] <Eickmeyer[m]> Isn't that what that link was about?
[03:43] <OvenWerks> All of them so far at least get to default.target going one way... we may have to sense session end and send our own dbus signal to get rid of the rest of the session.
[03:45] <OvenWerks> this one? : https://superuser.com/questions/759759/writing-a-service-that-depends-on-xorg
[03:45] <Eickmeyer[m]> Yeah, that's what I was talking about.
[03:45] <OvenWerks> it is more about starting things than finishing
[03:45] <Eickmeyer[m]> Though, that's for starting something than for... yeah, that.
[03:53] <OvenWerks> I wonder if I can set up a *.path unit
[03:56] <Eickmeyer[m]> ¯\_(ツ)_/¯ idk
[04:02] <OvenWerks> I logged out and found I have three sessions going (according to longind)
[04:03] <Eickmeyer[m]> Oof
[20:43] <OvenWerks> Eickmeyer[m]: I am not sure if this is a logind, systemd (both are the same anyway) or DE bug,
[20:44] <OvenWerks> Once a DE allows itself to be run by logind, I think that DE should realize it's responceablity to inform logind/systemd when it is finished
[20:45] <Eickmeyer[m]> I'd think logind should be able to sense when a session is done and kill all processes started by that user in that session.
[20:47] <OvenWerks> On the other hand, depending on how the DE session is started... a process that is detached/backgrounded may not show up as a part of that session.
[20:48] <OvenWerks> if I use a display manager to start a session, that is a session. If I then login SSH to a tarminal (or even ssh -Y for a graphic session, that is another session already.
[20:49] <OvenWerks> And that second session should not get killed by the local session logging out.
[20:50] <OvenWerks> There are two ways of ending a session: Telling logind to exit... very harsh. Telling systemd to goto the exit.target... much more ordered shutdown.
[20:53] <OvenWerks> Eickmeyer[m]: I think that because the DE has decided to be responcible to call systemd:reboot,halt,poweroff, etc, the DE should also do the call to systemd to start target exit.target
[20:55] <OvenWerks> it is too bad that the systemd method for doing so is completely different for exiting a session that it is for poweroff or reboot but it does make sense.
[20:55] <Eickmeyer[m]> We just need to have autojack listen for a dmesg that the session is ending, if possible.
[20:56] <OvenWerks> autojack already does that
[20:56] <OvenWerks> That part is not hard
[20:57] <OvenWerks> even apart from Studio's problem with loosing access to sound devices, it is still a bug that after logging in and out a few times with no reboot, _all_ the sessions ever logged into are still running
[20:58] <OvenWerks> This is also bad from our point of view as we don't know what other bits of code are still running from a previous login (either our own or another).
[20:59] <OvenWerks> Eickmeyer[m]: in the mean time, we need to change the message after adding the user to the audio group from you need to logout and back in to you need to reboot.
[21:00] <OvenWerks> in fact we could even put up a dialog simial to a kernel install that says "reboot now?", "reboot later"
[21:00] <OvenWerks> *similar
[21:02] <OvenWerks> I am going to put in a pr the xfce project to fix xfce... it should be relatively easy and would just fix our problem
[21:03] <Eickmeyer[m]> Right, but how does that work for other DEs?
[21:03] <OvenWerks> I will put in bug reports to the other DEs with a pointer to the fix on xfce :)
[21:03] <Eickmeyer[m]> Ok, seems fair.
[21:04] <OvenWerks> It is not that hard.
[21:05] <OvenWerks> The other thing we could do, is to just come up with script to run on DE shutdown for each DE (they are all different) that runs the call to systemd...
[21:06] <OvenWerks> That would be even easier, but, it may not allow the DE to properly shut down
[21:06] <OvenWerks> That is the DE may run those scritps before they have done session save kinds of things (they shouldn't but...)
[21:07] <Eickmeyer[m]> When the app gets the SIGTERM signal, then it could be passed to a shutdown process.
[21:07] <OvenWerks> I suppose we could fork the shutdown script and add a delay :P
[21:08] <OvenWerks> I am not sure that systemd when it changes targets uses a sigterm.
[21:09] <Eickmeyer[m]> Something has to use a sigterm.
[21:09] <OvenWerks> autojack now catches all the signals it can and I have never seen any in the log file... so it may be that they jusy go kill -9
[21:10] <OvenWerks> if I send autojack a kill -sigint I see it in the logfile
[21:10] <Eickmeyer[m]> Possible, but I've had processes literally hold a DE open because they're still completing their SIGTERM-induced shutodown procedures. It could be that it's getting sigkilled because it's not listening for sigterm.
[21:10] <OvenWerks> that is the DE
[21:10] <Eickmeyer[m]> brb
[21:10] <OvenWerks> autojack seems to run outside of the DE
[21:30] <Eickmeyer[m]> That's a problem.
[21:33] <OvenWerks> Eickmeyer[m]: it's not the only thing.
[21:35] <OvenWerks> Eickmeyer[m]: for 2004 I thik we will add an /etc/xdg/autostart/sessionkill.desktop
[21:36] <Eickmeyer[m]> Yep, that should fix the issue. Yes, I know xdg/autostart is going away eventually, but that can't happen until systemd gets their S fixed.
[21:37] <OvenWerks> It will run a script with & and wait 10 sec (5 maybe/, an ssd run system only needs 1 sec) and then send a dbus message to systemd to hit the exit.target
[21:38] <OvenWerks> Eickmeyer[m]: how quick do you think someone can relogin?
[21:39] <OvenWerks> I am thinking with an ssd it may be as short as 3 sec
[21:40] <OvenWerks> though autojack does have a builtin delay before trying to do anything to wait for pulse to settle.
[21:42] <OvenWerks> Eickmeyer[m]: I think lubuntu uses a lot of xfce bits or at least follows xfce ways of doing things
[21:43] <OvenWerks> well they used to before qt
[21:44] <OvenWerks> plasma has another way of setting scripts to run at exit but it is different enough from anything else we can probably install a script there and it won't affect xfce
[21:45] <OvenWerks> I don't know how gnome does things, but I suspect a systemd unit would work in their case
[21:46] <OvenWerks> in gnome's case at least some units quit on session stop so set something up to see that go away and call exit target (again with a delay)
[21:47] <OvenWerks> I don't know which DEs this misses
[21:54] <Eickmeyer[m]> Budgie and Cinnamon, I think.
[21:56] <Eickmeyer[m]> OvenWerks: Budgie, Cinnamon, and MATE.
[22:02]  * OvenWerks is not knowing how they do things
[22:03] <OvenWerks> It seems to me they are all related to some version of gnome, either dirrectly or as a modified fork.
[22:04] <OvenWerks> gnome2 had no idea of systemd (lucky dogs)
[22:05] <Eickmeyer[m]> Cinnamon is a fork of Gnome 3, Budgie is a rebase on Gnome, and MATE is a fork of Gnome 2 that now uses GTK 3.
[22:06] <Eickmeyer[m]> Might have to ask #ubuntu-flavors how they do things, though I do see Wimpress lurking in here. He may be able to answer MATE questions.
[22:07] <Eickmeyer[m]> I might be able to get bashfulrobot in here to talk about how Budgie does stuff. That should cover the actual flavors as they are now.
[22:09] <OvenWerks> BTW, I have no problem with systemd, just the mess during switchover
[22:09] <Eickmeyer[m]> Yeah.
[22:10] <Eickmeyer[m]> I can probably get ItzSwirlz to talk about Cinnamon.
[22:11] <OvenWerks> Anyone who is using gnome3 probably does startup/exit in a similar way.
[22:11] <Eickmeyer[m]> Not necessarily. Cinnamon forked before systemd was in wide use.
[22:12] <OvenWerks> Eickmeyer[m]: for 2004 we just need to worry about xfce anyway.
[22:12] <OvenWerks> any other DE we can recommend no to logout but to reboot instead
[22:13] <OvenWerks> as we work on thing after 2002, backports will deal with it
[22:14] <Eickmeyer[m]> That's a good point.
[22:15] <OvenWerks> we can point out in our recomendation that the reason for reboot instead of logout is a bug in the way systemd is being used by "some" DEs (so we are not pointing fingers at any one)
[22:15] <Eickmeyer[m]> Though, it would be nice to get as much covered as possible.
[22:16] <OvenWerks> like evryone else, I have other fish to fry...
[22:17] <OvenWerks> For each DE I even send a bug report to, I have to dl the iso, install, test, create some text files that show the problem then I can file a BUG report
[22:18] <OvenWerks> That is a fair amount of time required
[22:25] <Eickmeyer[m]> Yeah, I get that. I think just covering KDE, Gnome, and Xfce, in terms of workaround, might be good enough.
[22:25] <Eickmeyer[m]> Not necessarily bug report because, lets face it, that's not going to get fixed in time for 20.04.
[22:26] <OvenWerks> right, but it is not right or fair to the DE to use a hack without at least filing a bugreport to show why
[22:28] <Eickmeyer[m]> Yeah. I say do the bug reports as you have time.
[22:54]  * RikMills checks the room for existence
[22:54] <RikMills> seems ok
[22:59] <Eickmeyer[m]> RikMills: Right??? bashfulrobot's client is off its rocker.
[23:01] <OvenWerks> Eickmeyer[m]: regarding kill signals, init (and maybe upstart?) seemed to have the idea that they would send a kill, wait for a timeout then kill -9 whatever was left. systemd does not seem to be set up that way... though it could just be a default setting in systemd.
[23:05] <Eickmeyer[m]> OvenWerks: You could be right.
[23:11] <bashfulrobot> Eickmeyer: hey
[23:11] <bashfulrobot> Looks like it was a line wrapping thing.
[23:12] <Eickmeyer[m]> Ah.
[23:13] <Eickmeyer[m]> bashfulrobot: How does Budgie handle terminating applications on exit? We have a daemon (autojack) that runs as part of Ubuntu Studio Controls that we need to have exit upon logout, but currently isn't for some unknown reason.
[23:13] <Eickmeyer[m]> OvenWerks has more details as he's working on it.
[23:15] <OvenWerks> bashfulrobot: after logout and back in loginctl list shows the old session is still running... and after yet another logout and in there are now three sessions running. In all the DEs we have tried so for this seems to be the case (xfce, plasma, lubuntu)
[23:16] <OvenWerks> we noticed this because, the sound device remains locked by the first session
[23:17] <OvenWerks> (jackdbus continues to run)
[23:17] <OvenWerks> it tends to go un-noticed because logou and in is not really a thing with most people
[23:19] <OvenWerks> we do have a solution at least for xfce4-session-manager. But would like to see the other flavours benefit as well.
[23:19] <bashfulrobot> I have asked to see if David can jump in. I honestly am not sure why that would happen.
[23:20] <OvenWerks> the why is very obvous
[23:20] <bashfulrobot> Hey fossfreedom. Thanks for jumping on.
[23:21] <fossfreedom> yw
[23:22] <OvenWerks> with regard to session start up and stop, logind does two things, it starts the DE and it starts a systemd --user instance or session
[23:23] <OvenWerks> when the DE quits, the systemd --user session persists
[23:23] <OvenWerks>  and the second login may loose access to resources the first session now own.
[23:24] <OvenWerks> using jouralctl --user -b shows the user session going through its targets to default (or beyond in some DEs) and then at de logout that session remains active
[23:25] <OvenWerks> using loginctl shows that all login sessions since boot are still active.
[23:26] <OvenWerks> we were wondering if Budgie has the same problem or if not how it has been avoided.
[23:27] <OvenWerks> we noticed this because the audio device ends up locked by the first session and not available on another session
[23:28] <fossfreedom> hmm - don't think we can be useful here.  We are using gnome-session to logout.  If its using systemd behind the scenes we aren't aware - gnome-session is handling it all for us.
[23:29] <OvenWerks> When I looked ast xfce4-session-manager, I can see that for reboot, halt, poweroff, etc. a dbus message is sent to systemd, but for logout no.
[23:29] <OvenWerks> fossfreedom: so you may have the same problem but be unaware of it.
[23:30] <OvenWerks> is the gnome session that you use the same as gnome 3?
[23:30] <fossfreedom> I'm missing the scrollback - so I'm not following what the issue is.
[23:30] <fossfreedom> yes - same as GNOME3
[23:31] <OvenWerks> good, if gnome3 gets fixed so would you.
[23:31] <Eickmeyer[m]> fossfreedom: TL;DR: We have a daemon (autojack) that runs as part of Ubuntu Studio Controls that we need to have exit upon logout, but currently isn't for some unknown reason.
[23:31] <OvenWerks> the problem is that logind sessions never exit
[23:32] <OvenWerks> the reason is because the systemd session does not end, because xfce doesn't tell it to.
[23:32] <fossfreedom> ok - understand.  thanks for the background
[23:34] <OvenWerks> to check logout->login in a terminal type loginctl (aka loginctl list) and you should only see one session listed
[23:34] <OvenWerks> if you see two, then the problem is there too.
[23:34] <OvenWerks> hmm that was not clear
[23:34] <OvenWerks> open the terminal after the second login :)
[23:37] <OvenWerks> a thrid login will show three sessions etc.
[23:38] <fossfreedom> on 20.04 UB logged out as one user - then logged into another user.  Ran loginctl list-sessions and it shows 1 session
[23:38] <OvenWerks> good.
[23:38] <Eickmeyer[m]> Ok, then that means that Budgie and Gnome run as intended.
[23:40] <OvenWerks> fossfreedom: thankyou for testing for us