[08:21] <didrocks> popey: hey, when will the new unity version released?
[08:22] <didrocks> popey: remember that Thursday is beta2 freeze, we need to upload the whole stack and have all UIFe/FFe sorted
[08:22] <didrocks> popey: I would suggest making the release tomorrow so that we have enough time before thursday
[08:32] <didrocks> jasoncwarner_: ^
[08:32] <didrocks> jasoncwarner_: FYI as I think you are really interesting in ubuntu releases :)
[08:32] <didrocks> and unity ones :p
[08:34] <popey> didrocks, if we can find someone to help Mirv with the session migration issue..?
[08:34]  * popey is chasing down FFe/UIFe
[08:35] <didrocks> popey: I gave him some new guidances on debugging
[08:35] <didrocks> popey: sorry, already crowded with the +1 team, desktop team bug tracking for features and bugs, session management and helping you guys
[08:36] <didrocks> popey: I can't add a new task to myself to help you debugging something that started 2 weeks ago and still no resolution
[08:36] <popey> I wasn't suggesting you do it
[08:37]  * didrocks returns on the evolution stack NBS
[09:09] <didrocks> popey: FYI, doing the indicator backports so that you can concentrate on the release
[09:10] <popey> k
[10:39] <didrocks> popey: on the rls-q-incoming, as told the other days, there are some components that are PS related, like account-plugins
[10:40] <didrocks> popey: can you 1. sort them, and 2. talk to skaet to know how to have the right team subscribed?
[10:40] <didrocks> thanks
[10:40]  * popey looks
[10:48] <popey> didrocks, what's your expectation of "sort them"
[10:48] <didrocks> popey: migrate them to the rls-q-tracking or rls-q-notfixing
[10:49] <didrocks> as you are supposed to do for the "dx" components on the same page
[10:49] <popey> ah ok
[10:50] <didrocks> popey: still need in the future to be in right set I guess
[10:50] <didrocks> popey: can you get skaet migrating that one + evolution-indicator
[10:50] <didrocks> (that's the 2 I spotted right now)
[10:50] <popey> yup yup
[10:51] <didrocks> thx :)
[14:58] <tsdgeos> kenvandine: ping
[15:01] <kenvandine> tsdgeos, pong
[15:01] <kenvandine> make
[15:01] <kenvandine> whoops
[15:01] <tsdgeos> kenvandine: :D
[15:02] <tsdgeos> kenvandine: was speaking with agateau (that says hi) and saw you seem to be the distro packager of overlay-scrollbar/ayatana-scrollbar, i have this patch https://code.launchpad.net/~aacid/ayatana-scrollbar/qt_no_overlay_scrollbar/+merge/124697 are you the person to review it or Cimi is a better candidate?
[15:02] <kenvandine> cimi
[15:02] <kenvandine> but i would love to look at it :)
[15:04] <tsdgeos> kenvandine: well, the patch is there, it's quite small, doesn't mean it hasn't taken almost all my day to create
[15:53] <davidcalle> didrocks, hey
[15:57] <didrocks> hey davidcalle
[15:59] <davidcalle> didrocks, I've a new photos lens release, which depends on icons in the big Unity UIFE, do you think it's ok to land it before the new Unity, even if it breaks a few icons in the lens for a day or two?
[16:01] <davidcalle> didrocks, knowing that it doesn't affect the look of the lens : I was providing these icons in the package, now, it's Unity that provides them.
[16:01] <didrocks> davidcalle: is the UIFe accepted?
[16:02] <davidcalle> didrocks, hmm, good point, it's not. I thought it was, as all the Unity & other lenses branches are being merged today.
[16:08] <davidcalle> didrocks, thanks
[16:09] <didrocks> davidcalle: so, as soon as it's accepted, no worry to upload it :)
[16:09] <didrocks> davidcalle: yw ;)


 bazhang: he said he could not find a release, so I assumed he was on 1004, precise will not show up till there is  a point releace
[02:51] <bazhang> thats right? you have to wait for 12.04.1 to LTS---->LTS?
[02:51] <Unit193> Yes, unless you use -d
[02:51] <bazhang> how absurd
[02:53] <bazhang> simplew seems to be either confused or deliberately obtuse
[03:56] <bazhang> l49-18-203.cn.ru    LINT?
[03:58] <bazhang><EMAIL_ADDRESS>  yep
[04:03] <bazhang> tired of his always trolling #ubuntu with Ubuntu is just broken etc etc
 wylde: I'm not installing spyware like apport in my system
[04:17] <bazhang> some reason I should let this continue?
[05:12] <Tm_T> bazhang: no reason
[05:18] <bazhang> Tm_T, ok. he stopped/left most of the helpers id'd him as being a troll though
[07:58] <Jordan_U> Was that mass quit in #ubuntu a freenode network problem, an exploit, or something else?
[11:28] <IdleOne> Morning Lipu. Anything I can help you with?
[11:29] <Lipu> no thanks
[15:16] <bazhang> yeah it's him. the wisdom committee guy
[15:16] <ikonia> ?
[15:16] <bazhang> nomadhar
[15:16] <ikonia> I've never seen him before
[15:17] <bazhang> different nick when he was removed/quieted iirc
[15:17] <bazhang> same exact points, and style
[15:17] <ikonia> what was his other nick ?
[15:17] <bazhang> checking the bt now
[15:17] <bazhang> he was disrupting -classroom-chat with his ranting
[15:18] <ikonia> yes,
[15:42] <Myrtti> bazhang: if he's letting go of the subject finally, why do you want him to go on?
[15:42] <Myrtti> ah, too late
[15:42] <Myrtti> nevermind
 hey everyone... i am on ubuntu 12 ARM
[15:57] <bazhang> on his phone!
 if i want to complain about a OP who do i talk to
[16:54] <tsimpson> you could just direct them here, or to the council
[16:55] <bazhang> someone already did
[19:09] <LjL> [21:07:49] <Fyodorovna> madsj, I was not speaking to you and welcome to my ignore. :)
[19:09] <LjL> i don't suppose we have a policy on announcing ignores i could slam on their face? ;(
[19:10] <Tm_T> LjL: it's rude, so it's ok to let them know not to do that
[20:12] <guntbert> hi, I suggested removing  "#ubuntu-at" from !de because that channel is no support channel now and probably will not be one for a long time ™
[20:55] <EvilResistance> i sense a potentially-explosive situation in -offtopic, emphasis on *potentially*
[20:55] <EvilResistance> is anyone able to keep an eye there?
[20:56] <Myrtti> I'd suggest reductio ad felis domesticus
[20:56] <Fuchs> mmh, cats
[21:00] <Myrtti> works every time


[01:36] <thumper> wallyworld_: ah, removed that
[01:37] <thumper> wallyworld_: any reference there now is by mistake
[01:37] <wallyworld_> ah ok :-)
[01:37] <wallyworld_> i'll let you fix that and take another look after i finish this bit of work i'm doing
[01:39] <thumper> kk
[01:57] <thumper> I'm beginning to realise that my mental model of the state stuff is just plain wrong
[02:03] <wallyworld_> at least you had a mental model
[02:04] <davecheney> ooooooooooooh, juju totally doens't work with the mongodb we ship with raring
[02:04] <davecheney> that is a slight problem
[04:13] <thumper> davecheney: plz fix, kthxbye
[04:13] <thumper> :)
[05:40] <thumper> dimitern: hey there
[05:41] <thumper> dimitern: for the tasks you are doing or done, put your launchpad id in square brackets at the start
[05:41] <dimitern> thumper: heyhey
[05:41] <dimitern> thumper: in the blueprint?
[05:41] <thumper> dimitern: yeah, the work items
[05:41] <dimitern> thumper: ok, will do
[05:42] <thumper> so like this: [thumper] doing foo: INPROGRESS
[05:42] <thumper> dimitern: I'm just touching up the last part of plugins, using text/template etc
[05:42] <dimitern> thumper: ah, cool!
[05:43] <dimitern> thumper: my point (not that i explained it properly i think) with time.duration vs. floats is you can convert one to the other when generating the script
[05:44] <dimitern> thumper: and still have a nice to read code rather than floats
[05:44] <thumper> hmm... yeah, perhaps for a public thing, but really worth it for a test?
[05:44] <thumper> also, with some refactoring on the templates, things are more obvious
[05:44] <dimitern> well, tests are people too :)
[05:46] <dimitern> i mean we need to read and maintain them as well as other code, and readability helps (with that i'll leave it to your discretion, i don't absolutely insist on it)
[05:50] <dimitern> thumper: wrt to api authorization, who do you think should be allowed to call machine.Series(), m.Constraints() and m.Status() - everyone, only admins or only the environment manager node?
[05:52] <dimitern> thumper: the cli will need to use all of these in different commands, so maybe restrict them to whoever can use the cli and stop there?
[05:52] <thumper> dimitern: sorry, not thought too much about api auth, so not much help here
[05:54] <dimitern> thumper: np. how's it going in containerland?
[05:54] <thumper> dimitern: emailed people earlier
[05:55] <dimitern> thumper: ah, missed that, thanks
[05:55] <dimitern> thumper: have you seen my mail about the copyrights headers?
[06:01] <dimitern> thumper: reading the containers page you wrote, and i remember a discussion we had with william on the way back from oakland about nesting:
[06:03] <dimitern> thumper: the idea basically was to expand machine-id to contain a "path" like <root-id>/<type>:<child-id>/<type>:<child-id>/... where all ids are still numbers, and the type is the container type used (lxc, kvm, etc.) e.g. "0/lxc:1/kvm:2"
[06:05] <dimitern> thumper: this has some advantages: (1) scoping/namespacing, (2) ability to "move" up the "tree" when needed (e.g. set an ip address request going down from root to most deeply nested level, then back up (setting up networking on each level, etc).
[06:06] <thumper> yeah, I remember the discussion, but we also talked about having the machine namespace flat
[06:08] <dimitern> thumper: not sure it's the same discussion (i wasn't there on the one you mention, we talked about this later), but william seemed to like the idea; anyways just mentioning lest i forget
[06:10]  * dimitern bbiab
[06:18]  * thumper is away now
[06:19] <thumper> dimitern: if I have time.Duration in the struct instead of a float, how do I get the Seconds in the template?
[06:19] <thumper> with a float {{.Seconds}} works
[06:19] <thumper> sorry, with a float {{.Sleep}} works
[06:19] <thumper> but I need Sleep.Seconds()
[06:19] <thumper> can't see how to do that in the template
[06:19]  * thumper now away to eat
[07:19] <dimitern> thumper: well, i suppose something like this should work: http://play.golang.org/p/5g5fsv-3zn
[07:21] <dimitern> thumper: btw sleep(1) also supports arguments like "1m 23s"
[07:26] <thumper> dimitern: that isn't inside the template {{ ... }} bits
[07:26] <dimitern> thumper: look at {{printf}}
[07:26] <TheMue> *: morning
[07:27] <thumper> dimitern: nm {{.Sleep.Seconds}} works
[07:29] <dimitern> TheMue: hiya
[07:33] <dimitern> wallyworld_: consistency isn't everything you know :)
[07:33] <thumper> dimitern: last proposal updated, I'm signing off for the night now
[07:33] <thumper> ciao everyone
[08:09] <rogpeppe1> mornin' all
[08:27] <TheMue> rogpeppe1: morning
[08:29] <dimitern> rogpeppe1: morning
[08:32] <dimitern> rogpeppe1: i have a question already
[08:32] <dimitern> :)
[08:32] <rogpeppe1> dimitern: ok
[08:34] <dimitern> rogpeppe1: so in order to implement state.AllMachines() -> []*state.Machine, error
[08:34] <dimitern> rogpeppe1: what should I put in AllMachinesResults.Machines? []params.Machine or params.MachineInfo? the client expects to have actual machine objects there
[08:35] <rogpeppe1> dimitern: []params.Machine
[08:35] <rogpeppe1> dimitern: as long as we're keeping Machine separate from MachineInfo
[08:35] <dimitern> rogpeppe1: ok
[08:35] <rogpeppe1> dimitern: or []*params.Machine if it's more convenient
[08:35] <dimitern> rogpeppe1: and then the user can do like machines[0].Id() right?
[08:36] <rogpeppe1> dimitern: api.State.AllMachines should look just as it does in state
[08:37] <rogpeppe1> dimitern: so you'll need to map the slice, making a *api.Machine for every params.Machine
[08:37] <dimitern> rogpeppe1: wait.. actually params.Machine is not right - I need apiclient.Machine
[08:37] <dimitern> rogpeppe1: oh yeah
[08:37] <dimitern> rogpeppe1: thanks
[08:37] <rogpeppe1> dimitern: np
[08:38] <dimitern> rogpeppe1: already implemented LifecycleWatcher and EnvironConfigWatcher - no trouble so far
[08:38] <rogpeppe1> dimitern: cool
[08:40] <dimitern> rogpeppe1: hmm.. params does not import api though - will there be a problem if I import it?
[08:40] <rogpeppe1> dimitern: yes
[08:41] <rogpeppe1> dimitern: why do you want to import api into params?
[08:41] <dimitern> rogpeppe1: to define the slice of machines
[08:41] <dimitern> rogpeppe1: in AllMachinesResults
[08:41] <rogpeppe1> dimitern: that must be []params.Machine, no?
[08:42] <dimitern> rogpeppe1: ah, it'll be api.Machine at client side, i see
[08:42] <rogpeppe1> dimitern: yup
[08:46] <dimitern> rogpeppe1: do you think it's worth having if len(machines) == 0 { return params.AllMachinesResults{}, nil } (or maybe Machines: make([]*params.Machine, 0) is better) ?
[08:47] <rogpeppe1> dimitern: i don't mind. whatever is easiest.
[08:47] <dimitern> rogpeppe1: wasn't sure how to convey best the case "empty slice"
[08:48] <dimitern> rogpeppe1: but it's up to the client I guess anyway
[08:48] <rogpeppe1> dimitern: i think it may be better to always return an empty slice. that way the json representation is [] not nil.
[08:49] <dimitern> rogpeppe1: yeah, that what i was thinking
[08:49]  * rogpeppe1 wishes a nil slice encoded as json [] anyway
[08:53] <dimitern> rogpeppe1: strictly speaking a nil slice should be either null or undefined in json
[08:54] <rogpeppe1> dimitern: i'm not sure. the difference between a nil slice and an empty slice in Go is a subtle one that really isn't that useful to leak out into json.
[08:55] <rogpeppe1> dimitern: i can't see a particular use case for allowing a slice to encode as null
[08:55] <dimitern> rogpeppe1: yeah actually json doesn't have such a distinction
[08:56] <rogpeppe1> dimitern: well anything can be null in json
[08:58] <dimitern> rogpeppe1: i'm thinking it's worth having some helper to convert from state.Machine to params.Machine, so we have it at once place, right?
[08:58] <rogpeppe1> dimitern: definitely
[09:05] <dimitern> rogpeppe1: so can we assume all places using state.IsNotFound(err) will be changed to use api.ErrCode(err) == api.CodeNotFound?
[09:05] <dimitern> rogpeppe1: or we need a helper for each such case
[10:06] <dimitern> rogpeppe1: ping
[10:06] <rogpeppe1> dimitern: pong
[10:06] <dimitern> rogpeppe1: ^^
[10:06] <rogpeppe1> dimitern: ah, sorry, i didn't see that
[10:06] <rogpeppe1> dimitern: yes, we should assume that
[10:07] <dimitern> rogpeppe1: cool
[10:07] <rogpeppe1> dimitern: although we could add a help too if we wanted
[10:07] <rogpeppe1> helper
[10:07] <dimitern> rogpeppe1: let's see how it'll work when we start changing the agents
[10:07] <rogpeppe1> dimitern: +1
[10:08] <dimitern> rogpeppe1: i'm having difficulty with state.AllMachines at the client side - what should I put in the objType arg of call() ?
[10:09] <rogpeppe1> dimitern: i think we probably need a srvState type
[10:10] <dimitern> rogpeppe1: ok, will add it then
[10:10] <rogpeppe1> dimitern: and srvRoot.State(id string) (*srvState, error)
[10:10] <rogpeppe1> dimitern: then you'll use State as the obj type
[10:10] <dimitern> rogpeppe1: yeah, like the other objects
[10:10] <rogpeppe1> dimitern: yup
[10:11] <dimitern> rogpeppe1: but what about st.id ?
[10:11] <dimitern> rogpeppe1: i can add it but how shoud i initialize it?
[10:11] <rogpeppe1> dimitern: st.id ?
[10:12] <dimitern> rogpeppe1: st.call("State", st.id ...
[10:12] <rogpeppe1> dimitern: ah, i think we should enforce it as blank
[10:13] <dimitern> rogpeppe1: in srvRoot State(id string) ?
[10:13] <rogpeppe1> dimitern: at some point in the future, we'll potentially be able to connect to several states through the API, and then the id will be useful
[10:13] <rogpeppe1> dimitern: yes
[10:13] <dimitern> rogpeppe1: ok
[10:13] <rogpeppe1> dimitern: same as with Client
[10:18] <danilos> whoops, forgot about OCR :)
[10:19] <rogpeppe1> danilos: hiya
[10:19] <danilos> rogpeppe1, heya
[10:19] <dimitern> danilos: yo
[10:23] <dimitern> rogpeppe1: actually AllMachinesResults now will have Machines []string instead (ids) and client-side I'll range over it and call st.Machine(id) for each, right?
[10:23] <rogpeppe1> dimitern: i don't think you should do that
[10:24] <rogpeppe1> dimitern: i think you should return all the info
[10:24] <dimitern> rogpeppe1: I only need the id to wrap it with a api.Machine
[10:24] <dimitern> rogpeppe1: but that I don't have in params.Machine
[10:24] <rogpeppe1> dimitern: i don't think you want an extra n round trips
[10:25] <rogpeppe1> dimitern: ah, well params.Machine should have it
[10:25] <dimitern> rogpeppe1: all details?
[10:25] <dimitern> rogpeppe1: or only the ones I need right now
[10:25] <rogpeppe1> dimitern: just what you need right now
[10:27] <dimitern> rogpeppe1: ok, this also means changing srvMachine.Get() to return the Id (now both this and the range loop in AllMachines use the same helper: stateMachineToParams(stm *state.Machine) *params.Machine)
[10:27] <rogpeppe1> dimitern: that seems fine. it should only affect stateMachineToParams, right?
[10:27] <dimitern> rogpeppe1: yeah
[10:28] <dimitern> rogpeppe1: and I'll have the reverse helper in apiclient: paramsMachineToAPI(?)
[10:29] <rogpeppe1> dimitern: sounds reasonable.
[10:29] <dimitern> rogpeppe1: except I can't do it that
[10:29] <rogpeppe1> dimitern: no?
[10:30] <dimitern> rogpeppe1: ah, no sorry api.Machine has doc which is params.Machine
[10:30] <rogpeppe1> dimitern: yu
[10:30] <rogpeppe1> p
[10:37] <dimitern> rogpeppe1: who should be able to call m.Constraints() and m.Status() wrt permission checks? everyone (deny: "user-admin", "user-other") ?
[10:39] <rogpeppe1> dimitern: i think allow: "machine-0", "machine-1"
[10:39] <dimitern> rogpeppe1: how about juju status?
[10:39] <rogpeppe1> dimitern: that wil be part of the client API
[10:40] <dimitern> rogpeppe1: really? that simplifies things then ok
[10:41] <rogpeppe1> dimitern: yeah, we already have an isAgent check in srvRoot.Machine, i think
[10:41] <dimitern> rogpeppe1: strictly speaking only the environ manager uses these two now
[10:41] <dimitern> rogpeppe1: so allow "machine-0" to be as restrictive as possible
[10:41] <rogpeppe1> dimitern: i think it's reasonable that a machine can get its own info
[10:42] <dimitern> rogpeppe1: it *sounds* reasonable but we never cared about this in the machiner
[10:43] <rogpeppe1> dimitern: i'm ok if you want to deny access to everything but the environ manager
[10:43] <dimitern> rogpeppe1: let's do that for now, we can expand it later when we get to the MA itself and the other tasks
[11:01] <jam> wallyworld_: is there anything particularly in your chain of branches that I can unblock. I've reviewed a bunch of stuff, but I don't have the knowledge of the thread that you do.
[11:03] <wallyworld_> jam: thanks for asking. just one more :-) https://codereview.appspot.com/9606046/
[11:03] <wallyworld_> thanks very much. you and dimitern have been very awesome in doing all the reviews
[11:03] <jam> wallyworld_: yeah, I was looking at that one now
[11:03] <jam> though it seems not in-the-critical-path to getting the others landed
[11:04] <wallyworld_> it needs to be done so that https://codereview.appspot.com/9603044/ can land
[11:30] <jam> danilos: poke
[11:33] <wallyworld_> danilos: if you want a review to do https://codereview.appspot.com/9545045/
[11:33] <wallyworld_> it's an easy one
[11:45] <danilos> wallyworld_, you've got conflicts in there (or at least the conflict markers)
[11:46]  * wallyworld_ checks
[11:59] <wallyworld_> jam: i got permission denied trying to add you/mark etc as a watcher on my rt #61613
[11:59] <_mup_> Bug #61613: Can't run liferea with main window hidden <Dapper Backports:Fix Released> <liferea (Ubuntu):Fix Released> <https://launchpad.net/bugs/61613>
[12:01] <jam> wallyworld_: I get an error as well.
[12:02] <wallyworld_> :-(
[12:02] <dimitern> rogpeppe1, TheMue: sorry guys I'll have to skip kanban today - i did move all my cards accordingly
[12:02] <jam> wallyworld_: try just replying to the ticket, and then including<EMAIL_ADDRESS>in a CC field
[12:02] <rogpeppe1> dimitern: np
[12:04] <jam> wallyworld_: I just sent an email to derykc
[12:04] <jam> deryck
[12:04] <wallyworld_> i just cc'ed
[12:04] <jam> wallyworld_: I saw the email
[12:04] <wallyworld_> that was quick
[12:04] <wallyworld_> i only *just* hit send
[12:04] <jam> wallyworld_: though it just puts me in a one-time message
[12:04] <jam> vs the default CC
[12:05] <jam> so we want someone to update it.
[12:05] <wallyworld_> better than nothing i guess
[12:18] <TheMue> dimitern|afk:ok
[12:37] <hazmat`> mgz, ping
[12:56] <TheMue> rogpeppe1: btw, I know found on my own what I wanted to ask by digging into the whole coudinit stuff
[12:56] <rogpeppe1> TheMue: cool
[13:00] <jam> mgz: I figured out the bug for tarmac
[13:00] <danilos> jam: btw, the roundtrips to mongo are 70ms? that sounds like a lot: is that on the unix socket or over tcp/ip?
[13:01] <jam> danilos: that is running from the client sitting in the hotel in Oakland
[13:01] <jam> stuff like 'juju status' is evaluated client-side ATM
[13:01] <danilos> jam: oh, right, I see
[13:01] <jam> mgz: It turns out that Tarmac uses launchpad's API to find "bzr_identity" for a given branch.
[13:01] <danilos> jam: if it went through api server it would have gone much quicker, understood
[13:02] <jam> so if you say [lp:~go-bot/goose/trunk] tarmac connects to lp, but then tries to load the config item for lp:goose
[13:02] <jam> (the canonical name)
[13:02] <jam> and since that doesn't have any config, it just says "ok, everything Approved is ready to land"
[13:02] <jam> danilos: presumably the api server has much lower overhead, yes.
[13:02] <jam> mgz: which also explains why everything worked in testingb
[13:03] <jam> because it *wasn't* lp:goose yet
[13:04] <danilos> jam: ack, thanks for explaining it
[13:05] <rogpeppe1> danilos, jam, mgz, TheMue: i'd appreciate a review of this: https://codereview.appspot.com/9643043
[13:05] <danilos> rogpeppe1, taking a look
[13:06] <TheMue> rogpeppe1: *click*
[13:22] <TheMue> rogpeppe1: done
[13:22] <rogpeppe1> TheMue: thanks
[13:32] <rogpeppe1> TheMue: responded
[13:33] <TheMue> rogpeppe1: *clickAgain*
[13:39] <niemeyer> Heya
[13:40] <niemeyer> rogpeppe1: We have a meeting in ~50
[13:40] <rogpeppe1> niemeyer: ah, thanks - i hadn't seen an invite
[13:41] <rogpeppe1> niemeyer: anything you want to chat about prior to it?
[13:41] <niemeyer> rogpeppe1: You seem to be there in the event
[13:41] <niemeyer> rogpeppe: Hmm.. given it's still a preliminary meeting, we can probably exchange ideas during it
[13:42] <niemeyer> rogpeppe: Have you read that document + comments?
[13:42] <rogpeppe> niemeyer: not ye
[13:42] <rogpeppe> t
[13:43] <TheMue> rogpeppe: replied again
[13:43] <niemeyer> rogpeppe: That might be good to have a quick look before the call
[13:43] <rogpeppe> niemeyer: i definitely will do
[13:58] <rogpeppe> danilos: responded
[14:36] <danilos> rogpeppe, LGTM, worker.Runner/worker.Worker does sound better, but ultimately your call (this might make it easier to extract in the future)
[15:32] <allenap> bac: Eyup lad. Are you using anything like socket.io in juju-gui?
[15:34] <bac> allenap: no
[15:35] <allenap> bac: Just plain websocket, or something in YUI? Btw, "eyup lad" is a greeting in gmblish.
[15:36] <allenap> In case you didn't know whether to feel insulted or not.
[15:37] <bac> allenap: i always default to insulted until proven otherwise
[15:38] <bac> allenap: we use the reconnecting-websocket.js package
[15:42] <allenap> bac: Was there a conscious decision to use that over something else, or was it just convenient and close to hand? (Wow it's small; that's neat.) Would you recommend it?
[15:43] <bac> allenap: i wasn't in on that decision.  you may want to quiz hazmat
[15:44] <hazmat> allenap, its a very thin layer over websocket.. to you know reconnect ;-)
[15:45] <hazmat> allenap, we're basically using a raw  websocket, the gui has several abstractions built on that.. the gui itself while yui.. focuses mostly on the backbone app framework style of yui
[15:46] <hazmat> allenap, socket.io is basically just particular conventions around websocket,  pub/sub .. chatrooms, etc.  most of which aren't relevant here.
[15:48] <allenap> hazmat: Have you had any issues with websockets that might have been dealt with by something like socket.io, or does the reconnecting logic cover it?
[15:48] <hazmat> allenap, none
[15:49] <allenap> hazmat: Brilliant, thanks, and thank bac too.
[15:49] <allenap> s/thank/thanks
[15:50]  * hazmat relocates
[17:28]  * rogpeppe is done for the day. see y'all tomorrow.
[20:18] <dpb1> jam: any way to get some action on #1182224  I think it should be quite easy, at least from the outside looking in?
[20:18] <_mup_> Bug #1182224: relation-list returns null with json-output <juju-core:New> <https://launchpad.net/bugs/1182224>
[21:11] <thumper> good morning juju folks
[21:21] <kyhwana> Wait, it is actually morning somewhere else!
[21:21] <thumper> sure...
[21:21] <kyhwana> thumper: oh, that's because you're in the same country as me
[21:21] <thumper> 9:21am in NZ
[21:21] <thumper> kyhwana: where are you?
[21:22] <kyhwana> The 'tron
[21:22]  * thumper doesn't know where the 'tron is
[21:22] <kyhwana> O.o
[21:23] <kyhwana> Hamiltron?
[21:23] <thumper> oh...
[21:23]  * thumper is in Dunedin, so not up with all that north island slang
[21:24] <kyhwana> ahh
[22:15] <thumper> kyhwana: what do you do for work, and what's your interest level with juju?
[22:15]  * thumper is curious
[22:15] <kyhwana> thumper: I'm a "systems engineer" for a uh, company that makes "packet acquisition and generation" cards+appliances.
[22:16] <kyhwana> and interest in juju is mostly personal admin stuff
[22:16]  * thumper nods
[22:17] <kyhwana> though, I bet I could use it to deploy build environments. Hmm
[22:34] <sidnei> thumper: re https://launchpad.net/bugs/1182224 seems the problem is in json.Marshal, it should marshall an empty list to [] not nil: http://play.golang.org/p/QIMUVJMVPR
[22:34] <_mup_> Bug #1182224: relation-list returns null with json-output <papercut> <uniter> <juju-core:Triaged> <https://launchpad.net/bugs/1182224>
[22:34] <thumper> sidnei: it does
[22:34]  * sidnei just wrote his first go program :)
[22:34] <thumper> sidnei: it isn't bein given an empty slice
[22:35] <thumper> sidnei: it is a nil
[22:35] <thumper> which relates to null in json
[22:35]  * thumper is fixing the code
[22:35] <sidnei> sure it's a nill not an empty slice?
[22:35]  * sidnei staring at uniter/context.go
[22:36] <thumper> sidnei: I did
[22:36] <sidnei> UnitNames starts with units []string, and returns that at the bottom, i would expect it to be an empty slice or whatever that's called
[22:37] <thumper> sidnei: it starts with an uninitialized slice
[22:37] <thumper> which is nil
[22:37]  * thumper is adding one line of code
[22:37] <sidnei> i see, uninitialized
[22:37] <thumper> 	units = []string{}
[22:37] <thumper> append can handle a nil to append to
[22:38] <thumper> and interestingly, if you have 'var value []string'
[22:38] <thumper> v := reflect.ValueOf(value)
[22:38] <thumper> v.Len() == 0
[22:38] <thumper> v.IsNil() -> true
[22:39] <thumper> v.Kind() -> "slice"
[22:39] <thumper> so the HasLen matcher succeeds with 0 on nil
[22:39] <thumper> I've changed the tests to be "DeepEquals, []string{}"
[22:39] <sidnei> thumper: so why this results in nil: http://play.golang.org/p/6T6mLG2FY0
[22:40] <thumper> oh poos
[22:40] <sidnei> phew, so im not crazy
[22:41]  * thumper pokes it with a stick
[22:42]  * sidnei goes drink a beer
[22:47] <thumper> hmm..
[22:52] <thumper> sidnei: you are crazy
[22:52] <thumper> sidnei: it just took me some time to work it out
[22:53] <thumper> sidnei: http://play.golang.org/p/xHa0rd-0cn
[23:07] <mwhudson> has there been any progress with juju-core deploying to armhf recently?
[23:11] <thumper> mwhudson: I believe it is being looked at actively
[23:11] <thumper> mwhudson: particularly as with go 1.1, it fixes some things
[23:11] <thumper> we are pushing to get go 1.1 in the repos, and arm is kinda dependent on that
[23:11] <mwhudson> ok
[23:11] <mwhudson> i think that was going to be my next question :)
[23:11] <thumper> we are getting arm deployments into a CI system for us
[23:12] <mwhudson> is there a ppa with go 1.1 in it yet?
[23:12] <thumper> probably
[23:12] <thumper> look for ~gophers
[23:13] <mwhudson> ... for armhf
[23:13] <thumper> hmm... I think PPAs still need special tweaking to build for armhf don't they?
[23:13] <thumper> as it isn't a default target (ISTR)
[23:13] <mwhudson> yeah
[23:14] <mwhudson> is go mostly written in go?
[23:14] <mwhudson> i can imagine there are bootstrapping issues looming
[23:14] <thumper> possibly
[23:14] <thumper> I think davecheney has tested arm locally
[23:14] <thumper> and it is all good
[23:14] <thumper> but for what value of good, I don't know
[23:31]  * thumper is spending time considering jam's comments


[15:56] <jcw4> rick_h_: trivial PR : https://github.com/juju/juju-gui/pull/605 -  I believe websocket protocol is always wss:// now, never ws://
[16:50] <rick_h_> jcw4: yea, that looks like it's configured via the config-debug.js "socket_protocol" now thanks
[16:51] <rick_h_> jcw4: will be on a plan soon so afk for a bit. Sorry for the lack of response if you need anything
[16:52] <jcw4> rick_h_: no worries, thanks for the info, safe travels


[01:21] <callmepk> good morning
[02:56] <KGB-0> gnome-shell signed tags e242b25 Marco Trevisan ubuntu/40.5-1ubuntu2 * gnome-shell Debian release 40.5-1ubuntu2 * https://deb.li/sKtG
[02:56] <KGB-0> gnome-shell ubuntu/master 6e18ad3 Daniel van Vugt debian/patches/ series ubuntu/main-Avoid-meta-finalize.patch * debian/patches: Avoid full meta context finalization * https://deb.li/3nmBM
[02:56] <KGB-0> gnome-shell ubuntu/master b312dc1 Marco Trevisan (Treviño) debian/changelog * Update changelog * https://deb.li/cGw1
[02:56] <KGB-0> gnome-shell ubuntu/master c905fe2 Marco Trevisan (Treviño) debian/changelog * Upload to impish * https://deb.li/394YN
[02:57] <KGB-0> gnome-shell Marco Trevisan 271305 * commented merge request !57 * https://deb.li/3wNrV
[03:34] <KGB-0> gnome-shell-extension-appindicator tags 9ca66c5 Marco Trevisan upstream/41 * Upstream version 41 * https://deb.li/36dui
[03:35] <KGB-0> gnome-shell-extension-appindicator upstream/latest b98ee86 Marco Trevisan * pushed 18 commits (first 5 follow) * https://deb.li/6TXy
[03:35] <KGB-0> gnome-shell-extension-appindicator upstream/latest 4463b84 Marco Trevisan (Treviño) (9 files in 3 dirs) * build: Use meson to configure, test and install the extension * https://deb.li/ixhd4
[03:35] <KGB-0> gnome-shell-extension-appindicator upstream/latest 3a4a046 Ivan Mironov metadata.json * Add support for GNOME 41 * https://deb.li/49aU
[03:35] <KGB-0> gnome-shell-extension-appindicator upstream/latest 9af5266 Marco Trevisan (Treviño) prefs.js * prefs: Add ability to run it as standalone app with both Gtk 3 and 4 * https://deb.li/3WUHF
[03:35] <KGB-0> gnome-shell-extension-appindicator upstream/latest 4878539 Andreas Angerer appIndicator.js prefs.js schemas/org.gnome.shell.extensions.appindicator.gschema.xml * appIndicator: Add option to change indicator icons with a custom icon * https://deb.li/3KfkN
[03:36] <KGB-0> gnome-shell-extension-appindicator upstream/latest 02d7cd1 Marco Trevisan (Treviño) locale/ (13 files) * Locale: Update PO files as per new strings * https://deb.li/vh5V
[06:14] <oSoMoN> good morning desktoppers
[06:21] <duflu> Morning oSoMoN
[06:24] <oSoMoN> hey duflu
[06:27] <jibel> Good morning all
[06:33] <duflu> Morning jibel
[06:36] <oSoMoN> salut jibel
[06:36] <oSoMoN> jibel, I gladly accept your offer to review/merge https://code.launchpad.net/~osomon/ubiquity/+git/ubiquity/+merge/409584 :)
[06:36] <seb128> goood morning desktopers
[06:36] <oSoMoN> salut seb128
[06:36] <seb128> hey jibel duflu oSoMoN
[06:43] <ricotz> good morning :)
[06:44] <jibel> salut duflu oSoMoN seb128 ricotz
[06:45] <duflu> Hi seb128
[07:01] <jpnurmi> good morning
[07:03] <didrocks> good morning
[07:04] <duflu> Hi jpnurmi and didrocks
[07:06] <didrocks> hey duflu, jpnurmi
[07:11] <jibel> salut didrocks
[07:15] <didrocks> salut jibel
[07:18] <jpnurmi> hey duflu didrocks jibel
[07:18] <jibel> hi jpnurmi
[07:45] <seb128> didrocks, thx for the libportal MIR followup !
[08:01] <didrocks> yw seb128
[08:41] <jibel> oSoMoN, LGTM, but what do you think of moving the helper to misc.py?
[08:47] <duflu> juergh, bug 1945842 suggests the proposed raspi kernel still has no display (?!)
[08:51] <ricotz> seb128, thank you for dealing with vala :)
[08:52] <ogra> duflu, using the kms overlay instead of fkms is insane ... there is one thing the Pi is really good at and that is HW video decoding, the kms overlay forces all decoding in teh driver off ...
[08:53] <duflu> I've been away from Pi for a while, but last I checked everyone had stopped using fkms
[08:53] <ogra> we'd lose a lot of customers in IoT if Ubuntu Core did such a switch
[08:54] <duflu> ogra, it happened in 21.04 already AFAIK
[08:54] <ogra> (wheer the Pi is mainly used in digital signage ... mainly for video playback ...)
[08:54] <ogra> duflu, yes, for desktop and it is awful ... cant use kodi anymore, can't play vlc video without eating all cores etc etc
[08:54] <duflu> and is what the Pi Foundation does and recommends. So if there's a problem then it should be reported... that said I am about to cancel the next meeting because it clashes too much
[08:55] <ogra> well, it is a known fact ... and afaik the foundation tells so as well
[08:55] <ogra> oh, and it makes the Pi camera interface unusable too
[08:55] <ricotz> oSoMoN, seb128, https://ftp.mozilla.org/pub/thunderbird/candidates/91.2.0-candidates/build1/
[08:57] <duflu> Oh, actually it doesn't clash so doesn't need cancelling.
[08:58] <ogra> duflu, it isnt like decoding doesnt work at all, the Pi4 has enough CPU boom to do it in SW ... but this is not what most people expect from it (since you can play video without any CPU utilization with fkms)
[08:59] <duflu> ogra, sounds worse than I expected and decoding is something I've never looked at. I suggest you get waveform to add you to the meeting with Pi Foundation on 21 October to get answers
[09:01] <ogra> duflu, you can test with my vlc-pi snap, it is linked against the pi libs and runs find on our desktop for me (i also have a GBM based kodi-pi-standalone snap but that wont work with desktops (GBM completely claims the graphice HW here)
[09:02] <ogra> *fine
[09:03] <ogra> it works with and without fkms but you will find 60-80% utilization for all 4 cores on the device when using kms
[09:04] <duflu> Kodi is not something I would recommend making part of formal discussions because it's usually associated with piracy... unless the Pi guys also care about it
[09:04] <ogra> kodi is just a player 😛
[09:04] <duflu> Yeah I know
[09:05] <ogra> (and given the foundation offers a patches version in their PiOS archive i guess they care about it too 🙂 )
[09:05] <ogra> *patched
[09:05] <ogra> (i'm using their patches in my snap)
[09:30] <seb128> ricotz, great
[10:07] <oSoMoN> ricotz, ack
[10:20] <oSoMoN> jibel, done
[10:32] <waveform> duflu, ogra, just to weigh in here: the pi foundation are generally recommending we move to kms as that's the supported stack for the future; fkms is considered legacy and (eventually) won't be supported. However, with the current issues we're experiencing with the impish kernel I'm strongly considering switching the image (and upgraders) to fkms at least until things are stabilized under kms
[10:32] <ogra> waveform, 👍
[10:33] <waveform> That said, in experiments with the current upstream kernel (to determine whether kms was fully working there), we did note that fkms didn't boot at all (and we have been warned there is likely to be breakage with fkms in the near future)
[10:34] <waveform> I'm well aware that kms doesn't operate with the picamera interface; likewise that's considered legacy and libcamera is considered the future there (although at the time of writing there's no equivalent "high level" library on top libcamera available -- if I ever get the time it's something on my list to correct)
[10:36] <waveform> as for hardware H.264 decoding that's something I need to quiz the foundation about -- they *do* care about kodi (and video playback generally, as demonstrated by their recent move regarding distribution of libwidevine), but it's not their core business, and I'm not sure whether the lack of GPU-accelerated decode (given the CPU decode works, albeit with CPU load) would be enough to divert them from their current course of pouring resources
[10:36] <waveform> into kms (which also opens up the vast majority of the graphics stack)
[10:36] <waveform> anyway, enough waffle from me :)
[10:37] <duflu> Aside from decoding, if you want smooth graphics without tearing KMS, not fake KMS, is the solution that seemed to work for 21.04. I would be sad if we regressed to FKMS but also my work here is done, so do what you gotta do
[10:39] <waveform> indeed -- tearing is an issue with FKMS, but at the moment the impish kernel with KMS results in crashes of the video stack (display freezes; everything else keeps running happily, you can SSH in, but obviously a frozen display is a big deal on the desktop!). Upstream appears equally afflicted, and we almost certainly don't have time to implement a fix before release, hence why I'm considering the (admittedly not ideal) move to FKMS at least
[10:39] <waveform> until we can get the kernel issues sorted
[10:44] <duflu> o/
[11:22] <Trevinho> seb128: hey
[11:22] <Trevinho> I've some bugfix release for appindicator extension at https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-appindicator
[11:22] <Trevinho> I'm undecided whether I should sync it or no :)
[11:27] <seb128> Trevinho, hey, the changelog mentions new strings, it can probably wait for next cycle, probably better to cherry pick specific fixes if you think there is anything important for impish (but it doesn't sound like?)
[11:40] <Trevinho> seb128: ok, strings are mostly used by the settings which are quite advanced usage (not the extension itself), but I'm fine to wait for the same reason
[11:42] <ogra> waveform, my personal fear is that we switch to kms on Ubuntu Core too early ... there h264 decoding is a main reason for most customers to go for the pi ... as long as MMAL (or any future replacement) doesnt work with kms we should clearly refrain from switching ... (i also see (well, hear) audio issues when switching to kms on UC20 ... pulse doesnt find any devices anymore (fkms works just fine))
[11:47] <waveform> ogra, my understanding is there's no plan to migrate MMAL to kms (it's also seen as a broadcom-specific legacy API), though I'm not 100% clear on what the future APIs are there beyond v4l. For audio, we've had no (kms specific) issues on the desktop under hirsute, so I'm not sure what's happening there, but there are no plans to switch core20 over to kms. Core22 though is up for debate (and will likely depend on what happens during the impish
[11:47] <waveform> cycle with the kernel and kms)
[11:49] <ogra> waveform, yeah, i dont particulary care for MMAL, as long as there is any other way to have accel and make use of the one feature the Pi is really good in 🙂
[11:50] <ogra> if they do some sgtreamer integration that allows using the HW codecs, provide their own libs or whatnot, would be fine ... the point is that UC is a paid for product and we can not/should not regress there
[11:50] <ogra> *gstreamer
[11:51] <ogra> (particulary for that feature)
[11:51] <ogra> i doubt Pi desktops are used a lot commercially 🙂
[11:57] <waveform> I agree we shouldn't regress, but if fkms is going to have support issues going forward (and it's looking that way from our experiments with the upstream kernel) we'll have to make a choice sooner or later
[11:59] <ogra> waveform, well, i assume people like popcornmix have a plan going forward ?
[12:05] <GunnarHj> Hi oSoMoN! Am I on the right track at <https://discourse.ubuntu.com/t/24210/116>, or is there any secret with snaps and fonts that I haven't figured out yet?
[12:05] <oSoMoN> seb128, do you reckon uploading thunderbird 91.2.0 to impish is reasonable at this stage? (taking into account that it's a RC, but it should become a proper release before impish is released)
[12:06] <seb128> oSoMoN, yes, attach a bug reference in case the release team wants to keep it as 0 day SRU instead
[12:08] <seb128> GunnarHj, it would help if you opened bug reports with specific of something not working as intended, reading your post it's not clear to me what issue you are trying to adress
[12:13] <GunnarHj> seb128: The background is that I started to look at bug #1945817, and discovered that the Firefox snap seems to ignore the extra font configs provided by language-selector-common. It means that neither those files not config files shipped with additional fonts packages installed by the user will work.
[12:14] <oSoMoN> GunnarHj, reading your post, I think you have a much deeper understanding of fontconfig than I do :) james_h has done quite some work on fonts and snaps, can you try tagging him in your post. We definitely want firefox to be using the right fonts.
[12:16] <seb128> it doesn't seem specific to firefox though, is it?
[12:16] <seb128> sounds a bit similar to https://forum.snapcraft.io/t/snap-package-cannot-read-fonts-conf
[12:17] <seb128> oSoMoN, though you suggested '<include ignore_missing="yes">/etc/fonts/conf.d</include> ' there but that seems a workaround rather than a fix? I mean it suggests that it's still going to ignore the configuration?
[12:18] <GunnarHj> oSoMoN: Ok, I'll tag james_h.
[12:18] <seb128> please move to a new topic, probably best on forum.snapcraft.io
[12:18] <GunnarHj> seb128: Yes, indeed it affects snaps in general. But Firefox is most urgent to deal with ATM, right?
[12:18] <seb128> we can't discuss every single snap issue in the same past as we are doing on that firefox one
[12:19] <seb128> GunnarHj, well, my point is that the fix is probably not be in firefox
[12:19] <seb128> so if it's snapd or the desktop helper that the fix is needed we should post in a place where the right people will see it
[12:19] <seb128> which is not in the ubuntu discourse in an endless discussion about firefox
[12:20] <seb128> it's fine cross referencing to the new post though
[12:24] <GunnarHj> seb128: One theory is that it can be fixed in fonts.conf in gnome-x-xx-xxxx. But I'll read the forum.snapcraft.io thread you pointed at to start with.
[12:24] <seb128> ack
[12:52] <GunnarHj> kenvandine: I see that you merged https://github.com/ubuntu/snapcraft-desktop-helpers/commit/ec861254 very recently. Is there a way yet to test if that is effective for the Firefox snap?
[13:09] <seb128> GunnarHj, firefox doesn't use the helper, unsure how the extensions are synced with such changes though
[13:13] <GunnarHj> seb128: Then I'm lost. :(
[13:14] <seb128> GunnarHj, my recommendation would be for you to start providing an example of what isn't workin
[13:15] <seb128> like a website you browse which is rendered wrongly, and pointing out what config should make it work and isn't read
[13:17] <GunnarHj> seb128: Sure, that's precisely what I did yesterday before posting to discourse. I can document some Chinese or Arabic example for instance.
[13:21] <oSoMoN> seb128, what was the workaround for running `snap pack` on impish? running mksquashfs?
[13:23] <GunnarHj> seb128: Just for my understanding: Is the helper something else than gnome-3-38-2004?
[13:24] <seb128> oSoMoN, they suggested refreshing snapd to edge, but otherwise what I did was to call /snap/snapd/current/usr/bin/mksquashfs
[13:24] <oSoMoN> ack, thanks
[13:24] <seb128> GunnarHj, right, your post explain your conclusion but now what you tried so it's difficult to try locally
[13:25] <seb128> GunnarHj, yes, the helper was a standalone script which could be used as a part before that was adding to snapcraft as extensions
[13:25] <seb128> GunnarHj, I think https://github.com/snapcore/snapcraft/blob/master/extensions/desktop/common/desktop-exports is the modern equivalent
[13:27] <GunnarHj> seb128: Ok, thanks. I'll edit my discourse post (again) and include a step by step description how to reproduce the problem.
[14:02] <seb128> kenvandine, hey, ready for another round of rls triaging?
[14:02] <kenvandine> seb128: yes
[14:03] <seb128> great
[14:03] <seb128> jibel, ^
[14:03] <jibel> o/
[14:03] <seb128> should I drive?
[14:03] <kenvandine> please do
[14:03] <jibel> yes
[14:04] <seb128> alright, let's go
[14:04] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ii-incoming-bug-tasks.html
[14:04] <seb128> only triaging to do there
[14:05] <seb128> the gstreamer one is fixed, the others are assigned and being worked on
[14:05] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ii-tracking-bug-tasks.html
[14:06] <seb128> those are assigned
[14:07] <seb128> kenvandine, note that jibel added some content to bug #1933828 since last week
[14:07] <seb128> unsure if you want to revisit
[14:08] <seb128> it still feels like that's not a rls issue for impish, we can SRU a fix there as we target focal
[14:08] <seb128> still would be nice to see progress so maybe to check with hellsworth where we stands?
[14:08] <jibel> yeah, it's too late for impish anyway
[14:08] <jibel> but I'd like to have it done sooner than later when jj opens
[14:09] <kenvandine> i think hellsworth has her test environment setup for that
[14:09] <kenvandine> so yeah, should be able to do it early in jj
[14:09] <seb128> alright
[14:09] <seb128> moving to hh
[14:09] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-hh-incoming-bug-tasks.html
[14:09] <seb128> no desktop one
[14:10] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-hh-tracking-bug-tasks.html
[14:10] <seb128> either assigned or being worked on
[14:10] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html
[14:10] <seb128> no desktop ones
[14:10] <jibel> seb128, https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1922839 is assigned to laney
[14:10] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-tracking-bug-tasks.html
[14:10] <jibel> should it be reassigned?
[14:11] <kenvandine> I'm sure laney still wants to fix that :)
[14:12] <seb128> we should probably fix it by updating to the current 3.38
[14:12] <seb128> GunnarHj, maybe you would be interested to check that one? ^ you had been dealing with g-t or vte in past cycles, it's jut a patch to cherry pick
[14:13] <seb128> k, moving on meanwhile
[14:13] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-tracking-bug-tasks.html
[14:14] <kenvandine> i have a bug on there i should really re-assign :)
[14:15] <seb128> bug #1933168 unsure why I nominated it, doesn't seem important for focal
[14:16] <seb128> I'm going to wontfix, it's a non default gsettings, would be nice to fix but not a rls tracking one
[14:16] <GunnarHj> seb128: I can look at it, but probably only tomorrow. I.e. under one condition: That the FF fonts issue gets the priority it deserves. :)
[14:16] <seb128> GunnarHj, alright :)
[14:17] <kenvandine> FF fonts?
[14:17] <seb128> firefox fonts, see backlog
[14:17] <seb128> the snap isn't reading the language-selector config snippets needed for arabic or other languages
[14:18] <seb128> kenvandine, Gunnar pinged you earlier about https://github.com/ubuntu/snapcraft-desktop-helpers/commit/ec86125 , wonder if we need something similar for firefox
[14:18] <seb128> or rather in the snapcraft extensions
[14:18] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-incoming-bug-tasks.html
[14:18] <seb128> no desktop entry
[14:18] <seb128> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-bb-tracking-bug-tasks.html
[14:19] <seb128> nothing unassigned (we still don't track that things are being working on once assigned but that's not a new issue)
[14:19] <seb128> and that's it for rls I think?
[14:20] <kenvandine> GunnarHj: ah, yes the same fix needs to be made in snapcraft then firefox needs to be rebuilt with that version of snapcraft
[14:21] <kenvandine> seb128: yeah, that's it
[14:26] <kenvandine> GunnarHj: https://github.com/snapcore/snapcraft/pull/3586
[14:32] <ricotz> please retry https://autopkgtest.ubuntu.com/packages/a/automake-1.16/impish/s390x for vala/0.52.6-0ubuntu1
[14:32] <GunnarHj> kenvandine: That sounds promising. Any chance it can be accomplished before the 21.10 release?
[15:15] <seb128> ricotz, retried
[15:54] <ricotz> seb128, thanks, could you check if you actually retried it?
[15:54] <ricotz> https://autopkgtest.ubuntu.com/running#pkg-automake-1.16
[16:05] <seb128> ricotz, it went to a authpage I think, should have worked now
[16:08] <ricotz> seb128, there is it now, thanks :)
[18:35] <hellsworth> seb128: kenvandine ack. i'll update the nm bug today.
[18:36] <seb128> thanks


[01:03] <FrozenFire> Is there a way to have my screenshots automatically uploaded to imgur, and a link placed into my clipboard (or made easily accessible on-screen)?
[01:03] <FrozenFire> I don't mind scripting a bit to make it happen, but I don't even know where to start.
[01:04] <FrozenFire> gnome-screenshot seems maybe to be the utility that handles it?
[01:18] <darkxst> FrozenFire, I think in theory pastebinit might be able to do that
[01:18] <darkxst> I don't know if it has imgur support though
[01:19] <FrozenFire> Well, the thing would be to have some sort of post-screenshot script hook
[01:19] <FrozenFire> I could handle the rest
[01:45] <darkxst> FrozenFire, does the shell does screenshots now btw
[01:46] <darkxst> s/ does the shell/The shell/
[01:47] <FrozenFire> Perhaps an important clarification is that I'm on Ubuntu 12.04 with Gnome-Shell 3.4.1
[01:47] <FrozenFire> Not sure if gnome-screenshot had been dropped for that release.
[01:48] <darkxst> ah right, yeh still gnome-screenshot then
[01:50] <darkxst> FrozenFire, http://sirupsen.com/a-simple-imgur-bash-screenshot-utility/
[01:51] <FrozenFire> Hrmm, each example I've seen has used a different utility than gnome-screenshot
[01:51] <darkxst> probably because gnome-screenshot has no hooks
[01:52] <darkxst> although you could launch gnome-screenshot from a script in non-interactive mode
[01:52] <darkxst> and change the screenshot key binding
[01:53] <FrozenFire> True
[10:32] <jaysonr> darkxst: i forgot to follow back up with you, but everything is working fine now.
[10:33] <jaysonr> darkxst: i had the same issue w/ another user; wound up just re-installing since it was a pretty fresh install, and everything has worked fine since.
[10:33]  * jaysonr shrugs
[10:33] <darkxst> jaysonr, ok cool
[10:33] <jaysonr> darkxst: thanks again for your time helping.
[10:33] <darkxst> np
[10:37] <dupondje> who can I bug for some issue ? :)
[10:37] <dupondje> https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/1175582 https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/1177833 https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/1176757 https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/1174208 https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/1173472 https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/1163961
[10:37] <dupondje> Empathy seems quite broken :(
[10:50]  * darkxst is going to hide now ;)
[14:23] <SonikkuAmerica> clear
[20:47] <FrozenFire> Blegh. Grumble grumble. Can't get a script working as a keyboard shortcut, which works flawlessly from the terminal
[21:25] <jjmarin_> FrozenFire: what's the problem ?
[21:28] <FrozenFire> http://pastebin.com/VyXGzajx
[21:28] <FrozenFire> Basically, it's supposed to take a screenshot using gnome-screenshot, then upload that screenshot to imgur and put the link into my clipboard using xsel.
[21:29] <FrozenFire> imgurbash.sh does the uploading and clipboard manipulation
[21:29] <FrozenFire> And it works on the terminal, where it presumably has a DISPLAY reference
[21:29] <FrozenFire> I've tried setting the DISPLAY for the script, but no dice
[21:31] <FrozenFire> Wondering if the keyboard shortcut thing has a different environment than my session
[21:34] <jjmarin_> So you are calling the script using a Custom Keyboard Shortcut ?
[21:35] <jjmarin_> And you set using Settings > Keyboard > Shortcuts > Custom Shortcuts
[21:35] <FrozenFire> Yeah. bash -c "/home/me/bin/screenshot.sh"
[21:36] <FrozenFire> It definitely calls the script
[21:36] <FrozenFire> The screenshot happens
[21:36] <FrozenFire> It just never ends up in my clipboard, and I don't know if it actually uploads to imgur
[21:36] <FrozenFire> Though I suspect it does
[21:37] <jjmarin_> are you using gnome-screenshot -f ?
[21:38] <FrozenFire> Sfaik, there's no -f on my version of gnome-screenshot
[21:39] <FrozenFire> Gnome-shell 3.4.1
[21:41] <jjmarin_> I don't have a gnome-shell 3.4 avalaible to test it here :/
[21:45] <FrozenFire> I should probably upgrade, but meh. :P
[21:45] <jjmarin_> :)
[21:46] <jjmarin_> I usually enjoy with the lastest versions :)
[21:46] <jjmarin_> even when alphas or betas go wrong
[21:47] <FrozenFire> As do I. I've definitely been pleased with the newer GS versions in 12.10 and 13.04
[21:47] <FrozenFire> Just can't be assed to do-release-upgrade my workhorse box
[21:47] <darkxst_> FrozenFire, if it works from a terminal, but not keyboard launcher then presumably its missing some env variable
[21:48] <FrozenFire> Yeah. Just can't for the life of me figure out which
[21:48] <FrozenFire> I've tried putting DISPLAY=:0 at the beginning of the script
[21:48] <darkxst_> it wont be DISPLAY
[21:48] <FrozenFire> It's likely to be something with xsel
[21:48] <FrozenFire> But I don't know what it'd be
[21:48] <darkxst_> try XAUTHORITY
[21:49] <darkxst_> http://paste.ubuntu.com/5652591/
[21:49] <darkxst_> try adding that to the top of your scripts
[21:50] <FrozenFire> No dice
[21:57] <darkxst_> FrozenFire, do you get any output in ~/.cache/gdm/session.log?
[21:57] <FrozenFire> Might if I had such a log :)
[21:58] <FrozenFire> I had thought I was using gdm, but apparently not.
[22:02] <darkxst_> ~/.xsession-errors then
[22:04] <FrozenFire> Not present. Now I'm curious what desktop manager I'm actually using. :P


[20:48] <compengi> hi Armageddon
[20:48] <compengi> have you tried ubuntu 12.04
[20:51] <Armageddon> no
[20:51] <Armageddon> but I hear they fixed a lot of stuff
[20:52] <Armageddon> and I hear it still has a lot of problems
[20:55] <compengi> i see
[21:20] <compengi> Armageddon, are you using mint?
[21:28] <Armageddon> compengi, Gentoo
[21:28] <Armageddon> :p
[21:29] <Armageddon> I'm a contributor remember ?:
[21:32] <compengi> nice!
[21:33] <compengi> and what are you enrolled into?
[21:43] <Armageddon> architecture testing
[21:43] <Armageddon> I also have my own overlay now
[21:43] <compengi> hmm.. and what do you test there?
[21:44] <compengi> and nice about the overlay
[21:52] <Armageddon> I test packages for amd64 for stabilization
[21:52] <Armageddon> if I feel it's stable enough to become stable I give it my acceptance
[21:53] <Armageddon> 2 people testing a package will make it eligible to become stable, that's when the dev makes it stable and people have new updates :D
[22:25] <compengi> ah, cool
[22:25] <compengi> :)
[22:27] <compengi> gentoo packges used to be mostly outdated and lag few versions behind. what's the state now
[22:27] <compengi> are you a general 64bit tester or for specific packages
[22:28] <Armageddon> general
[22:28] <Armageddon> and no, gentoo packages were never outdated
[22:28] <Armageddon> the stable ones are but you have the choice of using unstable packages which are very up to day
[22:28] <Armageddon> date*
[22:29] <compengi> yep
[22:29] <Armageddon> so you can't really complain that they are not up to date
[22:29] <Armageddon> if you want them stable you have to use stables one, if you don't care for stability go unstable
[22:30] <Armageddon> I prefer hybrid systems, most of its components are stable and some applications that I want to be newest I have them unstable and latest
[22:36] <compengi> i used todo that with pidgin
[22:37] <compengi> are there still sometimes issues when you update core packages?
[22:37] <Armageddon> I do it with a lot of packages
[22:37] <Armageddon> there are never issues with updating, I never had any in 2 years now
[22:38] <Armageddon> but sometimes you have to issue commands which are usually given to you by messages
[22:38] <Armageddon> if you don't read the news/messages given to you by portage your system will most probably break
[22:40] <compengi> yeah, like the old days :)
[22:41] <compengi> sadly, i don't have spare time to play with linux anymore
[22:41] <compengi> i only have little time for me
[22:42] <compengi> i've been sitting on windows 7 for around 2 years now
[22:43] <compengi> i need it for work, so even there i don't have a chance to use linux
[22:44] <Armageddon> not cool at all
[22:49] <compengi> yeah, just not much interest anymore
[22:51] <compengi> so how are you doing overall