[17:21] <h00k> twopoint718: yo
[17:31] <Cheesehead> Ah, perhaps I'm finally getting the hang og irssi settings and screen usage.
[17:32] <Cheesehead> og not. Hasn't helped my spellng.
[17:33] <h00k> Cheesehead: I saw you....logged in as root earlier!
[17:33] <Cheesehead> Yup.
[17:33] <Cheesehead> Did I learn for that experience?
[17:34] <Cheesehead> /for/from
[17:34] <h00k> Hah
[17:34] <Cheesehead> Perhaps I will do *everything* as root for a day or two. With my fumbly fingers, what could go wrong?
[17:35] <h00k> O.O good idea.
[17:35] <h00k> it's okay, you have backups...
[17:35] <h00k> yes?
[17:35] <Cheesehead> What's a backup?
[17:39]  * Cheesehead washes his car AS ROOT muah ha ha ha
[17:44]  * Cheesehead pyas the eclectric bill AS ROOT muah ha ha ha
[17:44] <Cheesehead> Dang. That typo just cost me $40.
[17:44]  * Cheesehead goes back to being an ordinary user.
[17:46] <Cheesehead> Hooray! Just tried detaching irssi screen, logout of ssh session, log back in, re-attach irssi screen.
[17:47] <Cheesehead> At last, my announced presence in this channel is irrelevant!
[17:47] <Cheesehead> Well, slightly more irrelevant.
[17:52] <h00k> :D
[19:12] <twopoint718> running as root: http://www.theregister.co.uk/2006/02/24/bofh_2006_episode_8/ (funny)
[20:51] <mikeputnam> "So of course I'm sporting a headache that measures 'Kurt Cobain' on the pain scale and instead of easing it with some hair of the dog I have to sit through the inane drivel of a man who knows as much about linux as Princess Grace did about mountain driving..."
[20:55] <mikeputnam> "It seems you were right after all"
[20:55] <mikeputnam> "What do you mean?"
[20:55] <mikeputnam> "About a silly typing error causing problems"
[20:55] <mikeputnam> "How"
[20:55] <mikeputnam> "Well I logged in as root earlier and I was just going to try that ps thing you mentioned, but instead I accidentally typed in 'nohup cd /; rm -rf * > /dev/null 2>&1 &' "
[20:57]  * Cheesehead hates when he types that by accident
[20:58] <mikeputnam> especially with that dangling carrot of nohup
[20:58] <Cheesehead> I figured out that I *can* do most things as root. Just not on the computer.


[07:00] <dholbach> good morning
[07:03] <Tm_T> good morning
[07:14] <davidcalle> Morning o/
[08:39]  * dholbach relocates, brb
[08:48] <czajkowski> aloha
[09:31] <popey> dpm: would you mind if we pushed out meeting back 30 mins?
[09:31] <popey> no worries if not.
[09:41] <dpm> popey, sure
[09:41] <popey> thanks
[09:41] <dpm> done
[09:42] <popey> ta
[12:02] <popey> dpm: got any other example pages which have a 'call to action' button I can copy?
[12:12] <dpm> popey, the main d.u.c page
[12:12] <popey> ta
[12:13] <dpm> or ubuntu.com has got one atm too
[12:13] <dpm> http://www.ubuntu.com/server
[12:16] <popey> sorted, ta
[12:16] <popey> dpm: https://developer.ubuntu.com/en/community/coreapps/music
[12:56]  * popey is afk for a couple of hours
[13:55] <dholbach> balloons, davidcalle, dpm, mhall119, popey: LoCo Council (José) confirmed for tomorrow's Community Q&A.
[13:56] <dpm> \o/
[14:00] <mhall119> \o/
[14:33]  * popey returns
[14:42] <czajkowski> popey: WB
[14:44] <czajkowski> popey: you know there is some musical event in farnborough this weekend ?
[14:44] <popey> nope
[14:47] <czajkowski> popey: http://picnictomusicinthepark.co.uk/
[14:48] <popey> oh that, yeah.
[15:26] <dholbach> mhall119, I have a quick question - we'd like to maintain a list of branches we'd like to import into the dev site and mark one of them default. what would your preference be? 1) in the code, 2) in the db (use admin interface or mgmt command), 3) separate branch which contains just the "config"
[15:29] <mhall119> dholbach: 2 would probably be the most ideal, but will require more coding work on your part
[15:29] <mhall119> 1 is likely easiest, and less complicated than 3
[15:29] <dholbach> mhall119, how would you do changes to the data in the db?
[15:30] <mhall119> dholbach: create a new Model to hold this data, and make a ModelAdmin for it
[15:31] <dholbach> mhall119, sure - we'll do that then
[16:02] <dholbach> all right my friends - have a great rest of your day and see you tomorrow!
[16:17] <balloons> dholbach.. no!
[16:17] <balloons> I had a question for you :-)(
[16:37] <dpm> ok, calling it a day, see you all tomorrow!
[18:36] <balloons> mhall119, http://unity.ubuntu.com/autopilot/index.html has been resurrected. Can you kill it off again?
[18:37] <balloons> basically anything with autopilot on that subdomain should be killed
[19:30] <mhall119> balloons: not sure what brought it back, do you know if it was setup on a cron or something?
[19:39] <balloons> mhall119, no.. I have an old rt where IS got rid of it
[19:39] <balloons> but since you did whatever, I see it's all back
[19:46] <mhall119> balloons: all I did was update the WP theme
[19:49] <balloons> lol.. I know, it's coincidental I noticed I'm guessing
[19:54] <balloons> mhall119, I followed up with IS :p
[20:06] <mhall119> balloons: what did they say?
[20:07] <balloons> mhall119, it's via RT. They will sort it I'm sure
[21:33] <jcastro> hey mhall119
[21:33] <jcastro> or balloons
[21:33] <jcastro> is it possible to snappy on a typical x86 box like say a NUC?
[21:34] <balloons> jcastro, you can always use kvm to install
[21:34] <jcastro> yeah
[21:34] <balloons> but you would want just snappy right?
[21:34] <jcastro> so let me tell you what I think is cool, and then you tell me how to do it.  I'm totally down with that
[21:37] <jcastro> oh I know it's a good idea, heh
[21:37] <jcastro> I was just wondering if it's possible to install snappy like on a NUC
[21:39] <balloons> obviously I guess it's possible.. I'm wondering the best way to do it
[21:39] <balloons> I know ogra would have an opinion hah
[21:39] <jcastro> I wonder if dustin has tried this
[21:39] <jcastro> I am sure if I got an rpi2 this would be doable, but I don't have one
[21:39] <balloons> they key would be to get as close to baremetal as possible
[21:40] <balloons> that's the bit I'm not sure of.
[21:40] <balloons> jcastro, I would try flashing an amd64 image onto a nuc and see what happens
[21:41] <balloons> you should have ssh access to the box, and it should *just work*
[21:41] <jcastro> yeah
[21:41] <balloons> especially if you go the nuc route.. keep it all intel, upstream stuff, but not too new
[21:42] <balloons> I can't imagine it would be missing support for anything


[09:41]  * willcooke high fives Saviq
[09:42] <willcooke> Saviq: I might be in your neck of the woods in the new year.
[15:16] <jhodapp> hey willcooke
[15:17] <willcooke> Hey jhodapp!!
[15:17] <willcooke> How's it going dude?
[15:18] <jhodapp> willcooke, hey man, really well (except having caught a bad cold)
[15:18] <jhodapp> willcooke, are you tracking Ubuntu Touch on any local devices of your own?
[15:19] <willcooke> Doesn't run on iPhone :D
[15:20] <jhodapp> oh right, I forgot that's what you have
[15:20] <jhodapp> that's what I have as well, wish it would run on Apple hardware
[15:20] <willcooke> So I bought an Apple TV
[15:20] <willcooke> man, that thing is a bag of crap
[15:21] <willcooke> it does NOTHING
[15:22] <jhodapp> lol, yeah I know
[15:22] <jhodapp> and the filler apps are just fluff
[15:22] <jhodapp> I use it for 2 things: renting movies on iTunes and watching Netflix
[15:23] <ogra_> stop complaining, it has an apple logo on the case
[15:23] <jhodapp> ogra_, lol
[15:23] <ogra_> :)
[15:26] <jhodapp> willcooke, so you don't have access to Netflix, right?
[15:27] <willcooke> I use an alternative to netflix
[15:28] <willcooke> you might have heard of it
[15:28] <willcooke> ;)
[16:01] <jhodapp> :)
[17:10] <willcooke> get well soon jhodapp|sick
[18:10] <jhodapp|sick> thanks willcooke


[17:01] <snwh> I did a little tweaking of the messaging menu icons; thought it might be something to share with the design team ;) https://dl.dropbox.com/u/7027392/status-spheres-screenshot.png
[17:12] <snwh> probably more specifically: mpt


[00:21] <Makyo> AUGH
[00:21] <Makyo> I can't reproduce these CI errors at all locally.
[00:39] <hatch> Makyo you are creating an environment then doing nothing with it in one of your tests
[00:39] <hatch> maybe that's it?
[00:39] <Makyo> Oh?  Hmm..
[00:40] <hatch> line 1001 in test_environment_view.js
[00:41] <Makyo> Oh, right.  Hmm.  I got yelled at by jshint for that.
[00:41] <Makyo> Er, for assigning it to a variable I never used.
[00:41] <Makyo> But I bet I can find a way around that.
[00:42] <Makyo> Oh, there's already a global x.x
[00:42] <Makyo> If this works, I owe you.
[00:43] <hatch> haha, guess we'll see
[00:44] <Makyo> Damn, I bet that's it, too.  Just causing weird cascading issues.
[00:50] <Makyo> ...
[00:50] <Makyo> ... ... ...
[00:50] <Makyo> Disregard that, I'm an idiot.
[00:51] <Makyo> It worked locally because of untracked templates.
[00:51] <hatch> lol
[00:51] <hatch> hey, at least you can now reproduce it locally
[00:51] <Makyo> That'll teach me to use commit -a
[00:52] <hatch> ahh yeah I always do git add -A
[00:53] <hatch> ran into the same issue with untracked files
[00:53] <Makyo> Yep.
[00:53] <Makyo> It was that.
[00:53] <Makyo> I'm an idiot.
[00:54] <Makyo> SIGH
[00:55] <Makyo> Would appreciate a review/QA tomorrow, if you get a chance, hatch
[00:58] <hatch> Makyo yeah no problem
[02:04] <hatch> Makyo are you still around?
[02:08] <Makyo> Yep ^^
[02:08] <Makyo> What's up?
[02:09] <hatch> QA OK
[02:09] <hatch> buuuut
[02:09] <hatch> I keep getting relation change errors
[02:09] <Makyo> Huh?
[02:09] <hatch> it happens in trunk, just wondering if you noticed them too?
[02:09] <Makyo> I get them with simulator on, yeah.
[02:10] <hatch> ok so you think it's a simulator bug? I haven't been able to pin down the trigger
[02:12] <Makyo> I thought we had intentionally added them to the simulator for testing the inspector.
[02:14] <hatch> well only if relations are created
[02:14] <hatch> so maybe the change is coming in thinking the relation is still there
[02:14] <hatch> ok well that at least makes some sense :)
[02:14] <hatch> it doesn't appear to have any effect on the app so I was just trying to pin it down
[02:14] <Makyo> Oh, hmm.
[02:14] <Makyo> Alright, yeah.,
[02:15] <Makyo> I mean, I'm in there plenty, of late, I'll keep an eye out,
[02:15] <hatch> sounds good, well review and qa are done
[02:16] <hatch> now I'm thinking on how to add databinding to the viewlet manager
[02:16] <hatch> I'm thinking composition of some how
[02:16] <hatch> it just wasn't written with that in mind
[02:17] <hatch> anywho...
[02:17] <hatch> just sitting on the couch with my laptop....probably a mistake hah
[02:17] <hatch> what work/life balance
[02:18] <Makyo> Hah!
[02:18] <Makyo> Go away!
[02:18] <Makyo> Go away.
[02:18] <Makyo> I have gin, that's my sign to go away.
[02:18] <Makyo> Will get to review tomorrow.
[02:24] <hatch> haha sounds good, have a good night
[09:33] <rick_h_> frankban: ping, have you seen Import from "ghost-charm-master.zip" failed.<br/>invalid request: invalid YAML contents: unacceptable character #x0003: special characters are not allowed in "<unicode string>", position 2
[09:34] <rick_h_> in deploying a local charm? It souded like gary_poster|away had tested the ghost charm but hitting that and not seeing any unicode chars in the config/metadata files?
[09:34] <rick_h_> oh bah, I didn't use the latest core in this env
[09:34] <rick_h_> ignore me, will rebuild the env and try again
[09:35] <frankban> rick_h_: never seen. ok. FWIW, I am trying to release the charm
[10:02] <frankban> rick_h_: in manage heartbeat the Last ingest job seems to just return datetime.utcnow or similar
[10:14] <frankban> rick_h_: charm released
[10:29] <rick_h_> frankban: oooh cool I'll try that first then thanks
[10:35] <frankban> rick_h_: worked here with the ghost charm and core trunk revno 2295: juju boostrap && juju-deploy juju-gui && juju expose juju-gui && juju set juju-gui juju-gui-source=https://github.com/juju/juju-gui.git
[10:48] <rick_h_> frankban: thanks, just back from lunch and working on starting it now
[10:48] <frankban> rick_h_: cool
[10:49] <frankban> rick_h_: the local charm deployment is awesome
[10:49] <rick_h_> frankban: yea, I'm excited to show it off.
[10:49] <rick_h_> I've got let hatch know it worked out well because the field guys gave a talk on "juju and tools issues"
[10:50] <rick_h_> and one thing that came out was lack of local charm deployment support and I got to say "We've got it this week"
[10:50] <frankban> :-)
[10:50] <rick_h_> which lead to Mark S saying "...you should ask for a unicorn in a month"
[10:50] <frankban> great
[10:50] <rick_h_> was cool to have that ready to go/say in front of everyone
[10:51] <rick_h_> now we just need a better offline/not connected story
[10:51] <rick_h_> but those were the two issues they mentioned
[10:53] <frankban> rick_h_: it would be cool to have the deployer file accept URLs to zip files and/or git branches, and the deployer to download the file (e.g. from git) and to use the API to upload and deploy the local charm
[10:53] <rick_h_> frankban: interesting. We had a talk on new symantics added to bundles today that would be useful info for.
[10:54] <rick_h_> I think there's a mission to try to keep the deployer simple, so not sure that the git thing would work, but zips seems like something we could do.
[10:56] <frankban> rick_h_: yeah, that would allow people to deploy their topology even if they are launchpad allergic
[10:59] <rick_h_> frankban: can you file that as a bug/feature request on the deployer?
[11:00] <rick_h_> hazmat: expressed some interest in getting feature requests to help discuss/go through use cases and I think it's a good one
[11:01] <frankban> rick_h_: sure
[11:10] <rick_h_> frankban: for that source you can just do "develop" got the source and it'll pull that repo like you had in your command
[11:10] <rick_h_> frankban: just fyi
[11:11] <frankban> rick_h_: so  juju set juju-gui juju-gui-source=develop ?
[11:12] <rick_h_> frankban: rgr
[11:12] <frankban> rick_h_: that's cool
[11:12] <rick_h_> it's the replacement for the idea of 'trunk'
[11:12] <frankban> rick_h_: filed bug 1276532
[11:12] <rick_h_> as a shortcut
[11:12] <rick_h_> frankban: awesome thanks
[11:12] <frankban> np
[11:28] <rick_h_> frankban: heads up, going to add #1276541 to the board regarding the recent password text updates
[11:32] <rick_h_> frankban: you're supposed to just drop it on the cavas right? To deploy the local charm?
[11:32] <rick_h_> I'm getting Import from "bookie-charm-master.zip" failed. invalid charm archive: bundle file not found: metadata.yaml
[11:39] <frankban> rick_h_: are you using trunk?
[11:40] <rick_h_> frankban: yes, 2205
[11:40] <rick_h_> 2295
[11:40] <rick_h_> and the charm's version.js is trunk of the gui
[11:41] <rick_h_> well so juju --version shows 1.17.3-trusty-amd64
[11:42] <rick_h_> I went into the GOPATH/src/launchpad.net/juju-core folder to check the bzr rev
[11:42] <frankban> rick_h_: I'll try to reproduce
[11:42] <rick_h_> frankban: what charm did you deploy?
[11:42] <frankban> the ghost zip from github
[11:42] <frankban> rick_h_: where do I find yours?
[11:42] <rick_h_> I tried https://github.com/hatched/ghost-charm with the 'download zip' and https://github.com/bookieio/bookie-charm the same
[11:43] <frankban> rick_h_: uhm... weird
[11:44] <frankban> rick_h_: output from /var/log/upstart/guiserver.log?
[11:44] <rick_h_> getting 400 Bad Request from tornado
[11:44] <rick_h_> looking
[11:44] <rick_h_> [W 140205 11:43:41 web:1635] 400 POST /juju-core/charms?series=precise (<IP_ADDRESS>) 358.62ms
[11:44] <rick_h_> [W 140205 11:43:47 web:1635] 400 POST /juju-core/charms?series=precise (<IP_ADDRESS>) 350.50ms
[11:45] <rick_h_> is all it says
[11:45] <frankban> rick_h_: if you set builtin-server-logging=debug it will show the whole requests/responses
[11:46] <rick_h_> frankban: rgr, updating
[11:46] <frankban> deploying the charm now
[11:48] <rick_h_> frankban: http://pastebin.ubuntu.com/6878648/ is my updated log
[11:50] <frankban> HTTP error before end of send, stop sending
[11:50] <rick_h_> yea
[11:50] <rick_h_> 400
[11:50] <rick_h_> :/
[11:50] <frankban> interesting, so you are on ec2
[11:50] <rick_h_> right
[11:51] <rick_h_> what are you on?
[11:51] <rick_h_> just local?
[11:52]  * rick_h_ wanted to get an ec2 setup all prepped for the demo running and can leave it overnight ready to go for the morning
[11:53] <frankban> rick_h_: lxc yes
[11:53] <rick_h_> frankban: hmm, I created an lxc to build core in so didn't want to try to do lxc in lxc
[11:53]  * rick_h_ wonders if that'll work :/
[11:54] <rick_h_> frankban: ok, will add a card to investigate ec2 error. If you get time can you see if you can replicate?
[11:54] <frankban> rick_h_: sure
[11:55] <rick_h_> thanks, just to make sure I'm not doing something wrong. Will see if I can get a lxc env setup with juju trunk and try again
[11:55] <frankban> rick_h_: FWIW your bookie charm works well here in a local env
[11:55] <frankban> trying ec2
[11:55] <rick_h_> frankban: ok yea must be provider I guess
[11:56] <frankban> rick_h_: are you using quickstart to deploy the GUI?
[11:56] <rick_h_> frankban: no, I didn't
[11:56] <frankban> rick_h_: ok
[11:56] <rick_h_> I've got to setup that demo as well. When I tried to use qiuckstart in lxc I ended up with two machines still
[11:57] <rick_h_> had figured it might work on lxc since it's not sudo enabled now
[11:57] <frankban> rick_h_: asking because quickstart uses /usr/bin/juju, so it always uses stable juju
[11:57] <rick_h_> frankban: ah, no I did juju bootstrap && deploy juju-gui
[11:57] <frankban> rick_h_: yes qs + lxc installs the gui on a new machine, because the bootstrap node in that case is localhost
[11:58] <frankban> rick_h_: right, that's the same I am doing
[11:58] <rick_h_> frankban: ah that's right
[11:58] <rick_h_> frankban: ok, yea it's less impressive demo since it takes a bit to setup the second machine but maybe will do a bundle with the quickstart/gui part already running.
[11:59] <frankban> rick_h_: to demo quickstart you might want to use juju-core 1.16 (the new version with "sudo" changes for newer revisions is not yet released
[12:00] <rick_h_> frankban: well I'll probably just 'show off' the -i and that it does bundles from a url.
[12:00] <rick_h_> I've only got a couple of mins for that and for the local charm deploy
[12:01] <frankban> rick_h_: cool
[12:10] <frankban> juju-core trunk definitely improves debug-log readability
[12:11] <frankban> rick_h_: e.g. http://pastebin.ubuntu.com/6878732/
[12:14] <frankban> rick_h_: what's the output of your ec2 "juju status"?
[12:15] <rick_h_> frankban: ah sorry, destoryed it. Give me a sec
[12:15] <frankban> rick_h_: ok, so could you please try to bootstrap it with --upload-tools?
[12:16] <rick_h_> frankban: ah will do
[12:16] <frankban> rick_h_: I see agent-version: 1.17.2, and that could explain the errors
[12:16] <frankban> (recursive zip inspection is on 1.17.3 IIRC)
[12:17] <rick_h_> frankban: yea I had <IP_ADDRESS>
[12:17] <rick_h_> rebootstrapping with upload tools
[12:18] <frankban> me too
[12:18] <rick_h_> gotta love living on the bleeding edge
[12:20] <frankban> It's what we're always here to do
[12:21] <rick_h_> oh yea, I mean glad we're finding this stuff and working it out now vs later
[12:22] <frankban> rick_h_: FWIW for the demo, given connection oddities etc. I'd feel more comfortable using lxc
[12:22] <rick_h_> frankban: yea, I just have to resetup juju-core on the base machine vs an lxc container. I wanted to be able to blow it away when I was done
[12:22] <frankban> rick_h_: cool
[12:22] <rick_h_> my mistake
[12:23] <rick_h_> the setup is annoying with the gopath trying to get it to match where I want my src/etc
[12:23] <rick_h_> as it creates directories where it wants and does it's own source checked out and all
[12:24] <rick_h_> so     agent-state: started agent-version: <IP_ADDRESS>
[12:24] <rick_h_> working on getting gui up and running
[12:24] <rick_h_> frankban: the other thing for the demo is that the charm network stuff can happen over ec2's network vs mine if I use ec2
[12:25] <rick_h_> change of getting the charm/up/running quickly seems better that way, but then there's the 'can you connect/upload the charm' issue
[12:25] <frankban> rick_h_: that's right
[12:26] <frankban> rick_h_: re core trunk vs stable versions, I ended up using stable and using the brutal script in http://pastebin.ubuntu.com/6878807/ when required
[12:26] <frankban> rick_h_: I am sure there is a better way, but that does the switch job
[12:26] <rick_h_> frankban: ah cool, thanks that's helpful
[12:27] <rick_h_> yea, my first time getting trunk and just getting a feel for some sort of workflow
[12:28] <frankban> rick_h_: exec /bin/bash there is brutal, but I preferred it rather than having to do the source/eval thing each time
[12:38] <rick_h_> frankban: ooh, that worked
[12:38] <rick_h_> frankban: with --upload-tools
[12:39] <frankban> rick_h_: cool, so that's solved, weird that if you use a local env --upload-tools is not required
[12:39] <rick_h_> yea :/
[12:40] <frankban> rick_h_: so the steps are http://pastebin.ubuntu.com/6878853/
[12:42] <frankban> rick_h_: I presume tools are always copied over in lxc containers
[12:43] <frankban> rick_h_: I confirm I was able to deploy both bookie and ghost from local charms on ec2
[12:44] <frankban> this thing is beautiful
[12:46] <rick_h_> frankban: woot
[12:48] <rick_h_> hah, got ghost up and exposed and hit the page
[12:49] <frankban> rick_h_: heh http://ec2-54-195-51-213.eu-west-1.compute.amazonaws.com:2368/
[12:49] <rick_h_> yay
[12:50] <rick_h_> now to delete service and see if I can dupe it. Wonder if that works
[12:50] <frankban> rick_h_: it should, I remember it is possible to upload the same charm multiple times
[12:51] <rick_h_> cool
[12:51] <rick_h_> yea, I'll leave this up and running. Looks like demo moved to friday so will keep it up for a couple of days and work on lxc setup and have room for something to go boom
[12:52] <frankban> sounds good
[12:54] <frankban> rick_h_: http://ec2-54-220-72-34.eu-west-1.compute.amazonaws.com:6543/ ;-)
[12:54] <rick_h_> frankban: :) surprised it's ready to go already. Long install time on that one
[12:55]  * rick_h_ needs to get support for a bundled release/offline-cache in the charm
[12:55] <rick_h_> that's sweet to see someone deploying that :)
[12:56] <frankban> :-)
[12:56] <frankban> rick_h_: so, it's sqlite by default?
[12:57] <rick_h_> frankban: yes
[12:58] <rick_h_> frankban: sqlite, whoosh, served with waitress
[12:58] <rick_h_> the goal is to introduce elasticsearch or solr for fulltext, use charms for that, get the charm to support pgsql (bmark.us is postgres)
[13:00] <frankban> rick_h_: cool, grabbing some food, see you later
[13:00] <rick_h_> have fun, thnks for the help!
[13:19] <bac> trusty has not earned my trust
[13:19] <gary_poster> rick_h_: hey. glad demo prep is going well.  per "now we just need a better offline/not connected story": you can also announce that today's charm that frankban released (assuming it includes the newest GUI as well) fixes the Google font issue for offline environments if you `juju set juju-gui cached-fonts=true`.  This is connected with work we already did this period to make the charm build by default without any
[13:19] <gary_poster> access outside the Juju network.  The only remaining bits that we know of to improve this story are to build proxy support for the charm, which frankban prototyped in CA, and to have a juju-local charmworld, which is a bigger topic than the GUI and already discussed at Capetown.
[13:20] <rick_h_> gary_poster: cool, will add it to the demo notes.
[13:20] <gary_poster> Also, per local fonts, I suggest having an answer worked out with Wm Reade about local charm icons before the demo, because I strongly suspect that will be a question.
[13:20] <gary_poster> Finally...
[13:23] <gary_poster> rick_h_: finally, it might be worth reviewing page 6 of the old Juju GUI plans doc for the local charm demo.  Specifically, you can mention the folder drag-and-drop, and the drag-and-drop-local-charm-on-service-to-upgrade
[13:23] <gary_poster> since I siad that maybe you don't need to review page 6 :-)
[13:25] <gary_poster> hey frankban, when you get back: does the new charm have a new GUI release also?
[13:26] <gary_poster> I suspect it doesn't, since latest release of GUI in LP os 0.15.1
[13:27] <gary_poster> which is great: I know this release was about fixing the broken instruction bug
[13:27] <gary_poster> for login
[13:30] <gary_poster> the non FIFO queue still has quickstart in there... https://launchpad.net/ubuntu/trusty/+queue
[13:30] <gary_poster> but there's action at least
[13:35] <rick_h_> gary_poster: cool thanks for the heads up.
[13:36] <gary_poster> welcome
[13:39] <frankban> gary_poster: I confirm the new charm release doesn't include the new GUI. new charm is 1) improved login help, 2) imrpoved bundle deployments feedback, 3) support for local charms deployments and 4) cached fonts. 3) and 4) are only effective if you switch juju-gui-source to develop.
[13:39] <gary_poster> cool thank you frankban
[13:47] <frankban> gary_poster: I am looking for a next card, the charmworld proxy you mentioned could be one, local charms on the fake backend is another.
[13:47] <gary_poster> frankban: let's not do the proxy right now--let's help get the current features out the door
[13:48] <frankban> gary_poster: sounds good
[13:49] <gary_poster> frankban: there's a new card in local charms project ("Investigate failing on ec2...").  That's resolved (it just needs --upload-tools), right?
[13:49] <frankban> gary_poster: yes, that's invalid
[13:49] <gary_poster> cool thx deleted
[13:50] <gary_poster> frankban: also bug 1276541 is annoying but real-ish
[13:50] <_mup_> Bug #1276541: password instructions fails to scroll or fit on laptop screen <juju-gui:Triaged> <https://launchpad.net/bugs/1276541>
[13:50] <gary_poster> I'm not sure if we support screensizes that small officially
[13:51] <gary_poster> but it is true that the current instructions go on for days (my fault, kinda, because ISTM we need to say all that stuff!)
[13:52] <gary_poster> maybe the right thing to do is to ask Rick to get an opinion from luca on the right approach, frankban?
[13:54] <frankban> gary_poster: yes we need all those instructions, but they are displayed only to users of the old-juju new-charm configuration, which can be considered transient IMHO. yes I agree Luca can help there
[13:54] <gary_poster> cool frankban.  rick_h_, do you think you and Luca have time to talk about his opinion here on the bug you filed, given the transient nature etc.?
[13:56] <frankban> rick_h_: transient nature because the message if you use juju >=1.17.3 the message is shorter, and should fit your screen
[13:58] <frankban> gary_poster: another card is quickstart 1.0.1, but that's not urgent, it just needs to be released before 1.18.
[13:59] <gary_poster> frankban: <shrug> if that's what you feel like doing, it needs to be done. :-)
[14:00] <gary_poster> to rephrase: it needs to be done, so if that's what you feel like doing, go for it.
[14:00] <frankban> gary_poster: :-) I think I'll start investigating the fake backend stuff. never worked on that code so: am I right assuming we need to open the zip and parse all the metadata and config we need to simulate we have that charm in the store?
[14:02] <gary_poster> frankban: yes, exactly.  We'd plan to use a zip JS library, of which there are at least one and maybe two.  I'd suggest treating this initially as an investigation.  If it looks like it will take more than a couple of days to implement, we should re-evaluate priority.
[14:06] <frankban> gary_poster: ack, http://gildas-lormeau.github.io/zip.js/ seems cool
[14:07] <gary_poster> cool, frankban.  other one was http://stuk.github.io/jszip/ , as I suspect you also found
[14:08] <frankban> gary_poster: a first card could be just re-organizing the code so that we have a xhrHandler passed to the environment, and implementing a real one and the base structure of fake one
[14:12] <gary_poster> frankban: sounds reasonable.  I spoke briefly about this with Jeff, so he may have some thoughts.  We'll certainly need to share the fakebackend instance with the one used by the websocket.  I think I said that one approach would be to have the websocket wrapper that we already have for prod and sandbox grow a "PUT" API--so it could grow xhr methods or an extra xhr object or they could be completely separate.  That's
[14:12] <gary_poster> maybe a bit odd, so if there's a better way +1.  AFAIK the only state is in the fakebackend, so as long as you are sharing that instance you are good.
[14:14] <frankban> gary_poster: ack thank you
[14:14] <gary_poster> welcome
[14:58] <rick_h_> bac: benji can either of you review https://code.launchpad.net/~rharding/charmworld/demo-icons/+merge/204970 please? I'm having lbox issues, but it's a small branch.
[14:59] <bac> rick_h_: sure
[14:59] <rick_h_> bac: ty much sir. If it's ok, can you land it? I'm going to EOD in 10min
[14:59] <rick_h_> and busy tomorrow and hate to leave it hanging
[15:02] <bac> rick_h_: will do.  any reason you chose "None" instead of "False" for default?
[15:03] <rick_h_> bac: no, not really
[15:03] <rick_h_> just tend to go None for kwargs but could be changed without issue
[15:03] <bac> rick_h_: ok, i may change that if you don't mind.
[15:03] <rick_h_> bac: yep, wfm thanks
[15:03] <bac> rick_h_: otherwise code looks good and doing qa.  have a good evening!
[15:04] <rick_h_> bac: thanks, have a good day all
[15:50] <gary_poster> hey hey jujugui call in 10
[15:54] <benji> we should change our "team ping" phrase to "hey hey"
[15:55] <hatch> or how about 'engage'
[15:56] <benji> I think that would be "bridge to away team"
[15:56] <hatch> Ooo that's a good one
[15:57] <hatch> bridge to away team call in 10
[15:57]  * gary_poster had to watch a youtube of hey, hey, hey it's fat albert
[15:57]  * gary_poster is back now
[15:57] <hatch> haha
[15:57] <benji> Bill Cosby is in talks to reboot Fat Albert
[15:57] <hatch> nowadays that show would never make it on air again
[15:57] <benji> (I kid you not.)
[15:58] <hatch> it would be considered racist and insensitive
[15:58] <gary_poster> I had to google it to see if you were joking
[15:58] <gary_poster> 'course that reboot thing goes back to 2004 on imdb
[15:58] <hatch> it's new name would be 'Degrassi'
[15:58] <gary_poster> bridge to away team jujugui call in 2
[15:59] <hatch> lol
[15:59] <hatch> love it
[16:01] <gary_poster> hatch you coming?
[16:22] <Makyo> benji, http://www.youtube.com/watch?v=MYP56QJpDr4
[16:29] <hatch> jujugui FYI benji is quite a bit better than a rubber duck
[16:30] <gary_poster> lol
[16:30]  * benji updates his resume
[16:30] <gary_poster> I always suspected as much...
[16:31] <bac> benji: good news is you can no longer accidentally 'lbox submit' on charmworld.  bad news is it gives you an incomprehensible, red herring error message when you try.
[16:31] <benji> heh
[16:34] <hatch> since the end of 2012 we have removed 157,713 lines of code from the GUI :-O
[16:34] <hatch> not sure if that's depressing or not
[16:34] <gary_poster> s/removed/removed or rewritten or otherwise touched/
[16:35] <hatch> ohhh kay
[16:35] <hatch> :)
[16:35] <gary_poster> :-)
[16:35] <hatch> acording to github my blog has referred 1 person to our repo
[16:35] <hatch> lol
[16:35] <hatch> go blog go!
[16:36] <hatch> so my mouse was going all over the place and clicking things.....dog was sleeping on my mouse in the other room....lol
[16:37] <gary_poster> heh
[16:39] <hatch> Makyo is it cold there now?
[16:39] <Makyo> -23C
[16:39] <hatch> -24C here lol
[16:39] <hatch> I win!
[16:39] <Makyo> Hah!
[16:40] <hatch> 82% humidity (somehow)
[16:40] <Makyo> For certain definitions of "winning", sure.
[16:40] <hatch> lol
[16:40] <hatch> after about 15C the dogs no longer like to run around outside it seems
[16:43] <gary_poster> Hey Makyo, the icons Spencer gave us were ongs, not svgs.  Is that ok?
[16:43] <gary_poster> pngs
[16:43]  * gary_poster thinks "not really"
[16:43] <Makyo> gary_poster, they should be fine.  If we run into issues later, though, swapping them out is a 30 second branch.
[16:43] <gary_poster> ok fair enough
[16:43] <Makyo> gary_poster, I suggest asking for the SVGs, yes, but the swap will be easy.
[16:44] <gary_poster> Makyo: ok, will do.  So I should keep these pngs separate from the once that we sprite-ify, right?  'cause I'll want to add them as images, not classes
[16:45] <Makyo> gary_poster, yep. They should go with the exposed/landscape/etc indicators.
[16:45] <gary_poster> ack thanks
[17:05] <gary_poster> bac charmworld icons appear to be down?
[17:05] <gary_poster> no
[17:05] <gary_poster> sorry
[17:05] <gary_poster> must be something weird locally
[17:06] <gary_poster> oh, I still have that annoying demo=true thing turned on locally
[17:10] <gary_poster> Makyo, ok, so I have a small change that always shows the green icon (http://paste.ubuntu.com/6880180/).  Where's the best place to look to see if I should show green red or grey?
[17:12] <hatch> OO now that's the big question
[17:12] <gary_poster> :-)
[17:12] <hatch> gary_poster you can see how I did it in the inspector
[17:13] <hatch> one sec I"ll find the right place
[17:13] <gary_poster> I think he has it stashed away somewhere already
[17:13] <Makyo> gary_poster, the email I sent huw, though it looks like he didn't get to it.  that attr() call would take a function as the second argument.
[17:13] <hatch> ohh ok
[17:13] <Makyo> The first argument to the function is the relation, and you can get relation.aggregatedStatus.
[17:13] <hatch> Makyo did you hook up aggregatedStatus already?
[17:14] <Makyo> If we name the files relation-icon-{healthy,error,subordinate}.png, then we can just return "relation-icon-" + relation.aggregatedStatus + ".png"
[17:14] <Makyo> hatch, no, that was the email I sent to huw.
[17:14] <gary_poster> Makyo: ack thanks sounds perfect
[17:14] <hatch> in viewlets/service-relationi.js:38 I generate that, so if we are adding it to the relation model then we should fix it there as well
[17:15] <hatch> just FYI
[17:15] <Makyo> hatch, this is the RelationCollection wrapper, but that'll be helpful for the aggregatedStatus attribute.
[17:16] <hatch> yeah - we should keep the aggregate status up to date in the relation
[17:16] <hatch> the issue is that each side of a relation could be bad/good
[17:16] <Makyo> hatch, this is not a relation, this is potentially several relations.
[17:16] <Makyo> But if that gets set once, cool.
[17:17] <hatch> right, but wouldn't it be easy to go relation.get('status') :)
[17:18] <Makyo> Sure, but this isn't a relation, is all I'm saying, it's an array of relations.  If you want to move that to an attribute on relations, then RelationCollection.aggregatedStatus can take that into account, but they're separate models.
[17:18] <hatch> agreed
[17:21] <hatch> ugh somehow my changes to viewlet manager are causing other tests to fail :/
[17:30] <Makyo> This whole torrents as legitimate distribution channels is great until you forget to throttle.
[17:30] <hatch> haha
[17:30] <Makyo> Got this humble bundle through torrents and brought my network to its knees.
[17:31] <hatch> yeah I've found when I upload my network goes to crap
[17:31] <hatch> probably the ISP's stickin it to us
[17:32] <gary_poster> Makyo: I was confused why aggregatedStatus always was healthy even when there were rel errors until I found the code and associated XXX :-) .  So, my entire branch is http://paste.ubuntu.com/6880301/ .  Is there a precedent/pattern for tests of this, or should we be happy with tests of aggregatedStatus, and I should propose?
[17:33] <Makyo> gary_poster, I think that's good; the tests will be around aggregated status, don't think we need a test for the image element existing.
[17:34] <gary_poster> cool.  proposing
[17:38] <gary_poster> Makyo: https://github.com/juju/juju-gui/pull/108 fwiw
[17:38] <Makyo> LGTM :)
[17:39] <gary_poster> :-)
[17:43] <benji> hatch: I'm looking at the "Create dialogue for selecting series when dropping charm archive" card.  I assume the best way to construct the dialog is as shown here: http://stage.yuilibrary.com/yui/docs/panel/dialog.html Right?
[17:43] <hatch> benji that's actually what I was working on before this viewlet manager card
[17:43] <hatch> so it's going to be blocked until then because it needs to render a new inspector
[17:43] <hatch> sorry I should have marked it as blocked
[17:44] <benji> ah; ok
[17:44] <hatch> I don't really have any cards to do now that frankban picked up the fakebackend one
[17:44] <hatch> I'm very close to being done the one I'm on now
[17:45] <hatch> but then I was going to continue the branch I was working on before this
[17:45] <hatch> actually...
[17:45] <hatch> you may be able to do the zip lib
[17:45] <hatch> because frankban  will need to set up the fakebackend infrastructure first
[17:45] <hatch> before he needs it
[17:45] <hatch> what do you think of that?
[17:45] <hatch> ^ benji
[17:46] <hatch> or of course you could pick something else entirely :)
[17:46] <gary_poster> git power: If I make a PR, then discover I have to make a change, and then make the change and do a rebase with squash, how do I push it back to the PR?  the rebased/squashed branch does not match up with the remote branch
[17:46] <benji> hatch: sounds good to me; what does "do the zip lib" mean exactly?
[17:47] <gary_poster> the only thing I know to do is push with :, which seems to delete the branch and close the PR, and then push again
[17:47] <hatch> benjihttps://plus.google.com/hangouts/_/76cpim786onei1vh0evrn2ds30?authuser=1&hl=en
[17:47] <hatch> blah
[17:47] <hatch> benji https://plus.google.com/hangouts/_/76cpim786onei1vh0evrn2ds30?authuser=1&hl=en
[17:47] <gary_poster> which I will do unless someone stops me soon
[17:47] <frankban> gary_poster: push -f?
[17:47] <hatch> gary_poster `git push -f`
[17:47] <gary_poster> frankban: yes thanks
[17:48] <frankban> yw
[17:48] <gary_poster> hatch ^^^ thanks also :-)
[17:54] <hatch> :)
[17:55] <hatch> gary_poster you can also `git push origin <yourbranch> -f` then assuming you have your branches set up properly you can be more-sure that it's pushing to the proper place
[17:56] <hatch> gary_poster you can find out if you have it set up properly by running `git remote show origin` and make sure the urls point to your fork
[18:08] <hatch> Y.mix() I'll never remember your syntax
[18:26] <hatch> jujugui looking for a review https://github.com/juju/juju-gui/pull/109
[18:26] <hatch> easy qa!
[18:26] <hatch> :)
[18:26] <gary_poster> I will take it in 15 or 20 if there are no takers by then
[18:27] <hatch> sounds good, I'll go grab some lunch now then
[18:28] <gary_poster> cool
[18:33] <bac> gary_poster: i've been getting lots of churn on the calendar for daily standup.  are those real changes or is my calendar screwy?  i don't see any real changes.
[18:34] <gary_poster> bac, i hain't done nothin.
[18:34] <bac> huh
[18:35] <hatch> bac yeah I get those too
[19:25] <Makyo> I want my clock widget back :(
[19:36] <Makyo> gary_poster, ping.  Np if not worth it today, don't have anything except cards.
[19:39] <gary_poster> Makyo: hey.  I got my clock widget back after software update and reboot fwiw
[19:39] <Makyo> gary_poster, Oh, okay.  Will try reboot soon.
[19:39] <Makyo> Just did update.,
[19:39] <gary_poster> I don't have anythingto talk about if you don't.  I'm lame duck manager, Makyo :-)
[19:39] <Makyo> It's a sign of a smooth week, I say :D
[19:39] <gary_poster> heh ok
[19:55] <gary_poster> hatch :shipit:
[19:55] <hatch> :) thanks
[19:56] <hatch> hey benji any progress on the zippyness?
[19:56] <hatch> i'm very curious :)
[19:56] <benji> hatch: notthing significant; it looks like it'll work
[19:56] <hatch> *phew*  :)
[20:05] <rick_h_> cool, looks like we'll want the zippyness for bundles in the not so distand future as well
[20:07] <hatch> rick_h_ shouldn't you be sleeping? :)
[20:07] <rick_h_> hatch: not yet, only 9pm
[20:07] <rick_h_> just got back from team dinner
[20:07] <hatch> ohh I thought it was a bigger difference
[20:07] <rick_h_> so it go through today's notes/email the family time
[20:07] <rick_h_> 7hrs
[20:07] <rick_h_> well, from est
[20:08] <rick_h_> oh sorry, it's 10pm
[20:08] <rick_h_> I can't do math...tired. Guess I should be in bed
[20:08] <hatch> haha
[20:09] <hatch> have you done the Table Mountain trip too?
[20:09] <rick_h_> no, I don't think I'll get out to it.
[20:09] <hatch> aww darn, the pictures look awesome
[20:09] <hatch> is it far away?
[20:10] <rick_h_> yea, it's like 45min and you've got to arrange a car to drive you out/back
[20:10] <rick_h_> and the last gondola leaves around 7pm or someting
[20:11] <hatch> ahh so not very convenient with work and stuff
[20:11] <rick_h_> yea, unless you bail right at 5pm which some folks did
[20:11] <hatch> so does the area feel safe?
[20:12] <hatch> the internet is awash with "oh it's so dangerous there"
[20:12] <rick_h_> well, we're in groups. All the houses have walls and spikes with electic fence tops on top
[20:12] <rick_h_> so it's a bit 'wtf'
[20:13] <hatch> yeah that's a little crazy
[20:17] <hatch> rick_h_ are you going to have any time this week to chat about the left panel (browser area) ?
[20:18] <rick_h_> hatch: should be able to.
[20:18] <hatch> cool just let me know whenever, I'll be available
[20:18] <rick_h_> hatch: ping me when you get in and I'll try to find a slow
[20:18] <rick_h_> I don't usually have something every half hour
[20:19] <hatch> I start at....4PM your time
[20:20] <rick_h_> hatch: hmm, got time and konw what yuo want now?
[20:21] <hatch> yep
[20:21] <rick_h_> hatch: because I've got a design thing at 4pm tomorrow right now and think we'll be closing up by 4pm on friday
[20:21] <hatch> cool sec I'll grab a link
[20:21] <hatch> maybe....
[20:22] <hatch> https://plus.google.com/hangouts/_/7ecpj6psm7t3stjt2p0o8v2n9s?authuser=1&hl=en
[20:22] <hatch> there we go
[20:22] <rick_h_> k, we'll see how the mifi does
[20:27] <Makyo> jujugui one more review (no QA needed) would be nice: https://github.com/juju/juju-gui/pull/107
[20:28] <bac> Makyo: i'll do it
[20:28] <Makyo> bac, cheers, thanks
[20:35] <hatch> rick_h_ yeah the stream tanked
[20:35] <hatch> but I got what you were saying
[20:38] <rick_h_> hatch: sorry, yea tanked and mifi needed a charger
[20:38] <rick_h_> hatch: cool, appreciate your input on that. It may not work out and be crazy, but think it's worth a look
[20:48] <hatch> yeah no problem
[20:59] <bac> Makyo: done
[21:03] <Makyo> bac, thanks
[21:18] <Makyo> jujugui got gaierror: [Errno -3] Temporary failure in name resolution in functional tests
[21:18] <Makyo> On CI, sorry.
[21:18] <Makyo> Any ideas?
[21:18] <hatch> try it again, see how temporary it really is :)
[21:19] <gary_poster> heh +1
[21:19] <Makyo> I forget, did we figure out a way to re-trigger tests?
[21:20] <gary_poster> yes, was getting it for you 1 sec
[21:20] <gary_poster> https://github.com/juju/juju-gui/blob/develop/docs/continuous-integration.rst#manually-running-a-build
[21:20] <gary_poster> Makyo: ^^^
[21:21] <Makyo> cool, thanks!
[21:21]  * gary_poster <3 github doc rendering
[21:21] <hatch> yeah it's pretty isn't it
[21:21]  * gary_poster thinks github > git
[21:22] <hatch> github made git :)
[21:22] <gary_poster> did not
[21:22] <hatch> *popular
[21:22] <gary_poster> ah ok :-)
[21:22] <hatch> haha yeah
[21:27]  * Makyo blasts Britten's War Requiem to make Jenkins console watching a little more dramatic.
[21:51] <Makyo> Tests passed that time, but the PR didn't pick up on it.  Alright if I just link the passing tests in a comment?
[21:52] <Makyo> jujugui ^^^
[21:53] <hatch> yeah that should be fine
[21:53] <hatch> it'll rerun the ci on shipit
[21:53] <hatch> anyways
[21:53] <Makyo> Yep
[21:59] <huwshimi> Morning
[22:05] <hatch> hey huwshimi
[22:20] <hatch> huwshimi I assigned you a card (which is blocked until tomorrow) to style the new 'select series' inspector for local charm. Will you have time to do it tomorrow?
[22:21] <huwshimi> hatch: I can
[22:21] <hatch> awesome thanks, when you get in tomorrow we can have a quick chat so I can show you what it is
[22:22] <huwshimi> hatch: Great, that'd be handy :)
[22:22] <hatch> haha, I was trying to get it done for today but no luck, too much typing :P
[22:24] <huwshimi> :)
[22:24] <huwshimi> hatch: Have you used the GUI on Safari?
[22:24] <hatch> I have
[22:24] <huwshimi> hatch: Have you noticed many problems?
[22:24] <hatch> it's a little borked
[22:25] <hatch> looking again
[22:26] <huwshimi> hatch: Care to elborate? :)
[22:26] <huwshimi> Ah thanks :)
[22:26] <hatch> hah sorry just need to switch modes
[22:26] <huwshimi> I've noticed some minor presentation issues, but nothing major
[22:27] <hatch> hmm
[22:27] <hatch> I could have sworn there were issues
[22:27] <hatch> well bundle export is broken
[22:27] <hatch> but you know about that one I think
[22:28] <huwshimi> yeah
[22:28] <hatch> somehow I got all of the charms to show at the top of the screen
[22:28] <hatch> trying to repro
[22:29] <hatch> ok I can't get that one to repro but I have another
[22:29] <hatch> Click a charm in the charmbrowser and look at the tabview content slide down, click another charm, see it again
[22:30] <hatch> ^ huwshimi  can you reproduce that one?
[22:30] <hatch> there is also a mask of some sort that's rendered in the middle of the window when switching between charms in this regard
[22:30] <hatch> oh that happens in chrome too
[22:30] <hatch> but the sliding down bit is only in safari
[22:30] <hatch> I'll create two bugs
[22:31] <huwshimi> Yeah, I see the sliding down.
[22:32] <huwshimi> The tabview is the most broken thing in Safari it seems
[22:33] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1276844
[22:33] <_mup_> Bug #1276844: Switching charm details views in Safari causes details to scroll <juju-gui:Triaged> <https://launchpad.net/bugs/1276844>
[22:33] <hatch> tabview bug
[22:33] <huwshimi> Thanks
[22:34] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1276845
[22:34] <_mup_> Bug #1276845: Switching between charms renders modal mask in center of window <juju-gui:New> <https://launchpad.net/bugs/1276845>
[22:34] <hatch> other chrome modal mask bug
[22:35] <hatch> yeah other than that safari bug and the bundle export I can't see anything wrong on sandbox
[22:36] <huwshimi> Thanks
[22:56] <hatch> ...well Rachael Ray what are we making for supper...
[23:03] <hatch> huwshimi https://www.evernote.com/shard/s219/sh/8c0f1d1f-31ad-4da0-a1bf-ac30ad178306/a843eb38ae9cf7eb188094ac6c0b3065 this is what you're going to be left with :) sorry
[23:11] <huwshimi> lovely
[23:12] <huwshimi> hatch: Do we have designs for this bit?
[23:12] <hatch> huwshimi nope
[23:12] <huwshimi> Yay!
[23:12] <hatch> haha, yep
[23:16] <hatch> yuss it works....ok I'm off, will write tests and get this landed for you for tomorrow huwshimi
[23:16] <huwshimi> hatch: Thanks, have a good evening
[23:16] <hatch> have a good day
[23:16] <hatch> cya
[23:19] <huwshimi> bye


[00:19] <johnnywhite> boas
[01:19] <pain> Ola!!
[01:19] <pain> Alguem!!!
[19:19] <BUGabundo> bRoas o/


 Is there a power saver in kubuntu 20.04
 Yeah (re @Oov: Is there a power saver in kubuntu 20.04)
[12:34] <BluesKaj> Hi all
 Guys, do you know how to manage sound profiles?
 https://irc-attachments.kde.org/5555216a/file_56376.jpg
 My device only has one HDMI port, the "analogue surround" options either won't produce sound or will echo noise repeatedly. I tired uninstalling pulse effects for now as I'm still unable to get it to work with anything other than the default laptop speakers.
[13:32] <BluesKaj> @Diogo, install pavucontrol and configure youe audio output device there, same goes fo system settings/audio. Also make sure automute is disabled in alsamixer
[13:33] <BluesKaj> 'scuse the poor spelling ;-)
[13:36] <BluesKaj> gotta reboot...brb
[14:57] <kubuntu> Hi everyone. Here is my setup: triple monitor, gpu rtx 3080 driver version 510.73.05 os kubuntu 22.04 LTS Linux kernel 5.15.0-33-generic x86_64
[14:57] <kubuntu> My mistake is the following: every time the computer and the monitors go to sleep at my next access something does not work in the main screen, for example: the menu skips the background is no longer present nor the possibility to right click to restore it . Speaking around it seemed to me that this is due to the fact that my monitors are via DisplayPort and that this can be solved through the DPMS option in the x configuration file. I
[14:57] <kubuntu> entered the DPMS parameter in x but the problem still occurs here is my xorg.conf file -> https://pastebin.com/066A1D91 maybe something wrong?
[14:58] <kubuntu> thanks in advance to those who want to give me a hand :-)
 lots of sound devices....have you tried digital stereo hdmi output + analog stereo input (re @Diogo: Guys, do you know how to manage sound profiles?)
 I know "hmdi 2 output" works if I want the sound out of my monitor, analog output for the headphone jack. But then if I unplug either of these, the main speakers of the laptop screech (re @Djordje: lots of sound devices....have you tried digital stereo hdmi output + analog stereo input)
[21:29] <dreamon> hello. using xfce. by pressing alt+space it pops up krunner menu. how can I remove this shortcut?
[21:29] <dreamon> in xfce there is no configured shortcut for this.
[21:32] <cbreak> dreamon: you can look at pstree's output to see how it's started. Maybe by systemd? You can then make it not get started.
[21:33] <dreamon> pstree | grep krunner → |-krunner---14*[{krunner}]
[21:47] <cbreak> hmm... better way: find out the pid of krunner, then ask systemd about it: systemctl status 108590 (for example). This lead me to /usr/lib/systemd/user/plasma-krunner.service
[21:47] <cbreak> seems like the thing is started by systemd via dbus on behalf of something
[21:51] <dreamon> cbreak, how can I stop it forever?
[21:52] <cbreak> without uninstalling it? :)
[21:53] <dreamon> I have no issue uninstalling it.
[21:53] <dreamon> searched in synaptic without luck. only libkf5runner..
[21:54] <cbreak> it's part of plasma-workspace
[21:54] <cbreak> you could try systemctl stop --user plasma-krunner.service
[21:55] <cbreak> if that stops it to your satisfaction, you could try disable instead of stop
[21:55] <dreamon> do I need plasma-workspace for running okular in xfce?
[21:56] <dreamon> systemctl stop plasma-krunner.service → Failed to stop plasma-krunner.service: Unit plasma-krunner.service not loaded.
[21:59] <genii> You could just bruteforce sudo chmod -x /usr/bin/krunner
[21:59] <dreamon> maybe I can change alt+space kombination. I need it using blender.
[21:59] <cbreak> dreamon: the --user is important
[22:00] <dreamon> already did. this prevents from starting it. but it looks like keystroke is gone lost by it.
[22:01] <dreamon> my fault, I started as root..
[22:01] <dreamon> this worked. cbreak Thanke you very much!
[22:02] <cbreak> neat
 I am missing some of the status icons, for example i cannot change the keyboard layout any more there...
 also I cannot connect to wifi any more since the 22.04 update


[00:32] <poolie> hi, can anyone here help with launchpad comment spam?
[00:32] <poolie> spm: are you home?
[00:32] <poolie> in https://bugs.edge.launchpad.net/bzr/+bug/215674
[00:32] <thumper> poolie: he is, but was looking for fud
[00:37] <poolie> ahah
[00:37] <poolie> fooled again by bug 277352 - it looks like that user has not placed any comments
[01:09] <spm> poolie: hi, yes - will fix
[01:15]  * wgrant is glad to see geographically-distributed LOSAs.
[01:15] <mwhudson> yes, hooray for that
[01:15] <spm> poolie: removed, and user suspended.
[01:16] <spm> technically I think it fair to say that last week we 3 *were* geographically distributed.
[01:16] <spm> relative to our homes... ;-)
[01:16] <wgrant> True.
[01:17] <NCommander> wgrant, launchpad issues?
[01:17] <wgrant> NCommander: A few times during the week.
[01:17] <NCommander> wgrant, hrm, seems all the icons disappeared off the main page, and on my team page
[01:18] <wgrant> NCommander: That's just a bug, which is filed.
[01:18] <NCommander> pretty serious bug
[01:18] <wgrant> Why?
[01:19] <wgrant> Custom branding vanishing could not in any way be regarded as serious.
[01:21] <Zanko> hi
[01:21] <Zanko> i have a litte question about translation:
[01:22] <Zanko> i have imported a .po file for the french version of my project, however launchpad says that 18 of 18 strings are untranslated in french
[01:23] <Zanko> also the .po file is still marked as "need review" in the import queue
[01:23] <Zanko> can someone help me ?
[01:23] <Zanko> how to make launchpad to use my po file ?
[01:25] <wgrant> Zanko: The strings are shown as untranslated because the file hasn't been imported yet - 'Needs Review' indicates that it needs manual review by one of the Launchpad Translations people.
[01:25] <wgrant> Once they approve it, the strings should show as translated.
[01:25] <Zanko> ok thanks
[01:27] <Zanko> this is a bit strange no ? I mean, I am the creator of the project, I have added the translation to the bzr repo, why review it ?
[01:28] <poolie> thanks spm
[01:29] <Zanko> if i'm not trusted to add translation to a project i created, why should i be trusted to add code to it ?
[01:30] <wgrant> Zanko: Possibly because translations affect the whole of Launchpad, as suggestions are shared between projects. But I don't know for sure.
[01:31] <Zanko> you're probably right, i had'nt think to this
[01:31] <mwhudson> Zanko: have you seen https://help.launchpad.net/Translations/ImportPolicy ?
[01:32] <Zanko> no thanks i will read it
[01:33] <Snova> The OpenSourcing page says that Code hosting will not be released publicly- how much does this encompass?
[01:41] <poolie> hm that's odd
[01:47] <poolie> Snova: it's to-be-announced
[01:47] <poolie> i think at least the web ui relating to code will be released
[01:48] <Snova> Ok. There are some neat features that would be nice to have in a local installation, I'm just wondering what scope of them will remain. (Assuming I can set it up :P)
[01:48] <poolie> what kind of thing?
[01:50] <Snova> Honestly, I can't name anything specific.
[01:52] <Snova> The code section, now that I look closely at it, has little on the surface that I would need in a private installation. I suppose I'm simply curious what will be missing.
[01:53] <thumper> Snova: what is your rationale for running a local copy?
[01:55] <Snova> thumper: Mostly just to mess with it. I don't do anything serious, and if it becomes too much effort, I probably won't.
[01:56] <Snova> I tend to start a lot of little personal projects and having a Launchpad around would be handy- but they're never large/involved enough to justify an actual project on LP.
[01:56] <poolie> hm
[01:56] <poolie> it's kind of an interesting observation
[01:56] <poolie> if running your own copy seems easier then the work to make a project on lp is probably too high
[01:57] <poolie> or if not work, the degree of emotional commitment or something
[01:57] <poolie> degree of publicity
[01:57] <wgrant> A few people have made this point in the past couple of weeks.
[01:57] <wgrant> Projects are pretty permanent, I guess.
[01:57] <Snova> It's not a lot of work. They just don't merit being made public, what you said about sums it up.
[01:57] <poolie> mm
[01:57] <poolie> there's a big jump between +junk and a real project
[01:57] <poolie> comes back to this idea of a nursery or something
[01:58] <Snova> Occasionally I'll produce something I wish to share with a few people, but a simple +junk branch serves me well enough. Any "bugs" people report I either write down or fix immediately.
[01:58] <wgrant> But running one's own Launchpad seems like utter overkill.
[01:59] <Snova> Yes... lately I've been happy to find how easy it is to create a Trac instance, and I can tear it down in a heartbeat. launchpad.net would require filing an answer... so I tend not to.
[02:00] <poolie> does it really, to make a new project?
[02:00] <poolie> that's definitely too slow
[02:00] <wgrant> No, it requires one to *remove* a project.
[02:00] <wgrant> Creation takes seconds.
[02:01] <thumper> hmm...
[02:01] <thumper> a project owner should be able to remove it if there is no third part contributions I guess
[02:01] <Snova> To remove it later.  I have one "official" project on LP that I grew bored with quite some time ago.
[02:01] <thumper> it is hard to decide when to allow something to be made "unpublic"
[02:01] <wgrant> What do other hosting sites do?
[02:01] <thumper> Snova: someone may take it up though...
[02:02] <Snova> Also, I tend to do most coding after I can't use the internet, and thusly LP...
[02:02] <thumper> Snova: if you are just wanting to share code, loggerhead does that pretty well
[02:03] <wgrant> Snova: DVCSes solve that problem.
[02:04] <poolie> someone should write this up...
[02:06] <Snova> So they do, but only the code part.
[02:06] <thumper> Snova: what exact problem are you trying to solve?
[02:07] <Snova> I don't have a problem. This started when I inquired as to what elements of LP Code weren't going to be published, and I found my answer almost immediately (that it isn't specified). :)
[02:07] <thumper> :)
[02:08] <wgrant> I would have expected the private bits to have be determined by just weeks before the code is released...
[02:08] <wgrant> s/be/been/
[02:10] <Snova> Perhaps the reason I want to create a local LP installation is to use it as something like a staging area... a place I can keep track of my little projects before they are large enough to consider publishing "officially". Once they get somewhere I don't mind using LP, but until then I find myself writing todo/bug lists.
[02:13] <cody-somerville> I see plenty of rationale for private instances of launchpad but not for local instances. By the time I get to the point where I need a bug tracker, I've probably made an initial release.
[02:13] <cody-somerville> And by rationale, I mean personal rationale
[02:13] <thumper> well...
[02:13] <Snova> How do you define "private" and "local"? The terms are synonymous to me, both meaning "on my laptop, for me".
[02:13] <thumper> anyone attempting to contribute should be able to run a local launchpad
[02:13] <spm> Snova: if you just need a personal bug tracker etc; why not use eg flyspray?
[02:13] <thumper> at the very least to test it :)
[02:14] <thumper> `make run` will work :)
[02:14] <wgrant> spm: Because most other bugtrackers suck.
[02:14] <thumper> (with enough initial setup)
[02:14] <Snova> spm: I've been making some use of those recently, actually, I just like Launchpad and don't mind trying to install it. :)
[09:38] <SiDi> Hello
[09:39] <SiDi> Is it please possible to change the exemple project in https://help.launchpad.net/Answers/AskingForHelp ?
[09:39] <SiDi> The Exaile devs are bored of having offtopic questions apparently :)
[09:40] <intellectronica> SiDi: sounds like a reasonable request to me. can you please file a bug on the launchpad documentation project? you're of course welcome to make the change yourself too
[09:44] <SiDi> I dont have the rights to edit it, gonna fill a bug
[09:45] <intellectronica> SiDi: really? you should be able to edit after logging into the wiki (using your LP credentials)
[09:45] <SiDi> intellectronica: ok, found the edit button :d
[09:46] <SiDi> intellectronica: any idea of a suitable project ? :p
[09:47] <intellectronica> SiDi: how about https://edge.launchpad.net/null ?
[09:47] <SiDi> hm yeh
[09:47] <intellectronica> SiDi: also, it would be better to link to staging.launchpad.net, so that whatever actions users might do won't interfere with normal launchpad data
[09:48] <SiDi> intellectronica: but then they might take the uri and replace the project name and not notice they're in the staging platform
[09:48] <intellectronica> hmmm .... right
[09:49] <intellectronica> so let's use null for now
[09:49] <SiDi> changed : https://help.launchpad.net/Answers/AskingForHelp
[09:49] <intellectronica> SiDi: we can discuss with mrevell when he's next online and see if he has a better suggestion
[09:49] <SiDi> thanks intellectronica :)
[09:49] <SiDi> yeh. I guess we should avoid any non-lp non-ubuntu project anyway
[09:49] <SiDi> its not nice for the chosen project :p
[10:10] <wgrant> To increase the SNR across Launchpad, maybe link them to a project where asking a question suspends their account!
[10:14] <intellectronica> wgrant: SNR?
[10:15] <wgrant> intellectronica: Signal-to-noise ratio.
[10:15] <intellectronica> ah of course
[10:17] <SiDi> wgrant: it sounds a bit *drastic* for newbies
[10:18] <wgrant> SiDi: Ah yes, but they'd be newbies who clearly can't read.
[10:19] <wgrant> But yes, using null sounds like a reasonable solution.
[10:49] <\sh> dear launchpadlib devs, please look at bug #81689 and remove the symlink so I can do some work for LP on windows, too ;)
[10:51] <magcius> \sh, that looks like a bug in bzr, not LP
[10:51] <\sh> magcius: well...lifeless writes: This is the key: contact the launchpadlib developers and ask them to not
[10:51] <\sh> use symlinks.
[10:51] <SiDi> \sh: what is windows ?
[10:52] <\sh> magcius: but yes it's also a bug in bzr ;)
[10:53] <SiDi> It's a bug in NTFS imo :) Do you have the bzr plugin that simulates symlinks in windows ?
[10:54] <\sh> SiDi: tbh I don't care...but I would like to use lplib on windows (because I want to have leonov very OS independend) I just need this bug fixed, one way or the other
[10:55] <SiDi> \sh: do you have that plugin simulating symlinks in windows ?
[10:55] <\sh> SiDi: nope...regarding the plugin description it only works until bzr 0.9x
[10:55] <SiDi> Well, you should at least test it
[10:56] <SiDi> and if it doesnt work, report a bug against bazaar asking for the plugin to be ported
[10:56] <SiDi> You can't reasonably ask developers not to use symlinks just for windows.
[11:00] <\sh> SiDi: if the software is declared as OS independend which means it should run on un*x and non un*x OS, then I would think that we don't use any os dependent functionality, no?
[11:02] <SiDi> \sh: not FS indenpendant, though (this was a troll \o/). File against launchpadlib too then
[11:05] <\sh> SiDi: that was the plan :)
[11:05] <SiDi> \sh: :D
[12:09] <Saviq> hi all, guys, is there a way to migrate translations between a project series?
[12:14] <noodles775> danilos: ^^^
[12:15] <danilos> Saviq: yeah, just upload a new POT file with exactly the same name to a new series, and translations will be migrated automatically once it's imported
[12:15] <danilos> Saviq: new POT might need manual approval if you are not using bzr imports, but feel free to ping us about it
[12:16] <Saviq> yeah that won't work since we already have changed our template names
[12:16] <Saviq> I'll need to download and upload the POs by hand, will they be fuzzy-matched?
[12:17] <danilos> Saviq: what do you mean?
[12:17] <danilos> Saviq: in general, you should try to use the same names if they are same templates
[12:18] <Saviq> danilos: yeah they were wrong before
[12:18] <danilos> Saviq: if you do that, translators will be able to translate multiple series at the same time
[12:18] <danilos> Saviq: right, but we can easily fix them
[12:18] <danilos> Saviq: what's the project?
[12:18] <Saviq> lp:elisa
[12:18] <Saviq> 0.5 vs 1.0
[12:19] <danilos> Saviq: right, and into what series do you want to migrate translations? into trunk or from 0.5 into 1.0?
[12:19] <Saviq> from 0.5 into 1.0
[12:19] <Saviq> the template names in 1.0 are 'correct'
[12:19] <Saviq> the ones in 0.5 lack 'elisa-plugin-' in them
[12:20] <danilos> Saviq: right, do you want me to fix them? (fwiw, I was looking into this recently, since we are planning on doing database migration soon to share translations, and I've got some notes on Elisa and what we need to do about it :) If we can solve it right away, even better :)
[12:21] <Saviq> yeah that would be great
[12:24] <Saviq> and if there's anything else we could do to improve the experience, please tell as we're in the process of making Elisa / Moovida as translator-friendly as possible
[12:29] <danilos> Saviq: sure, I am looking at it right now
[12:29] <danilos> Saviq: so, all template names should be as in 1.0?
[12:29] <Saviq> yes
[12:30] <Saviq> the 'i18n' one isn't there in 0.5
[12:30] <danilos> Saviq: ok, cool
[12:30] <Saviq> it actually shouldn't be in 1.0 either as it's a test-case, but that's a small problem
[12:30] <danilos> Saviq: oh, I can remove it as well, if that's what you want :)
[12:30] <Saviq> it will get imported from bzr on next commit anyway, no?
[12:31] <Saviq> no way to 'blacklist' a templte
[12:32] <danilos> Saviq: ah, right, it will... we can mark them as "Blocked", but won't work with bzr imports
[12:32] <Saviq> never mind that
[12:32] <danilos> Saviq: do you want translation domain (i.e. path it's exported as) changed as well?
[12:32] <robin_> jml: hi. Is there any change in bug 382795?
[12:33] <Saviq> no, leave them as they are, we'd have to backport some changes into 0.5 for that to work
[12:33] <danilos> Saviq: ok, sure
[12:37] <danilos> Saviq: ok, names should match between 0.5 and 1.0 now; however, actual sharing between them will happen properly only once we do the migration (this is a relatively recent feature, and I'd love to make sure it works fine for Elisa as well)
[12:38] <jml> robin_, remind me where we were at with that
[12:38] <danilos> Saviq: it will take us a few days to test it all out before we can actually do it; do you mind filing a request to share translations between 0.5 and 1.0 in elisa on answers.launchpad.net/rosetta so we can keep track of it?
[12:38] <Saviq> danilos: great, thanks - I will
[12:38] <robin_> jml: I try what you said, but it failed
[12:39] <danilos> Saviq: thank you as well :)
[12:39] <jml> robin_, ok. did you ask a Question on Launchpad?
[12:40] <robin_> jml: No. I am focus on my code these days. My branch is banned again several days ago.
[12:40] <jml> robin_, ok. so, that bug is now fixed in production
[12:40] <jml> robin_, your core problem though is that somehow bzr is behaving badly.
[12:41] <robin_> jml: it means?
[12:42]  * jml thinks
[12:42] <jml> robin_, I mean that you can push that branch to Launchpad, but something in your local config or some thing that you are doing is causing it to fail (I think)
[12:43] <jml> robin_, but I don't know what that is.
[12:43] <robin_> jml: May be I should upgrade bzr to 1.17-dev?
[12:43] <jml> robin_, that's certainly one thing to do.
[12:44] <robin_> jml: ok, I try it.
[12:44] <jml> robin_, but even more important than that is to go here -- https://answers.edge.launchpad.net/launchpad-code/+addquestion -- and describe exactly what you are doing, and what you see, and what you expect to see
[12:45] <robin_> jml: got it
[12:46] <jml> robin_, thanks.
[12:46]  * jml -> lunch
[12:57] <Saviq> danilos: while I have you around - I was asked about Austrian (de_AT) that isn't available in LP, is there a way to add additional languages? what would happen if we'd commit a de_AT.po file?
[12:59] <danilos> Saviq: if it's imported, it will show up; but in general, people should not have such translations (i.e. bigger projects such as GNOME disallow them)
[13:00] <danilos> Saviq: in the future, we might do more than just not show them before there's any translation, so I wouldn't count on any behaviour unless we are convinced it's the right thing to do
[13:00] <Saviq> ok, thanks
[13:02] <bullgard4> What is meant by "official tags" in https://bugs.launchpad.net/ubuntu/jaunty/+source/ekiga?
[13:08] <wgrant> bullgard4: Official tags are those that the project or distro's maintainers have declared as official. They are more prominent on bug pages and appear in the tag autocomplete list.
[13:10] <bullgard4> wgrant: Thank you.
[13:23] <resolve> hi folks. i have a couple of questions about the translations section
[13:23] <resolve> i see that launchpad can automatically import files from a bzr repo
[13:24] <resolve> as items are updated on launchpad, will launchpad automatically commit those changes to the repo? or does it require downloading the po files and applying them to the repo manually?
[13:28] <Saviq> danilos: one more thing, we have a file structure like so:
[13:28] <Saviq> i18n/<domain>.pot
[13:28] <Saviq> i18n/<locale>.po
[13:28] <Saviq> but downloaded files are
[13:28] <Saviq> i18n/<domain>.pot
[13:28] <Saviq> i18n/<domain>-<locale>.po
[13:29] <Saviq> will <locale>.po renamed to <domain>-<locale>.po be picked up automatically, too?
[13:32] <danilos> Saviq: it should, but in general, it's a bug in our export code (it should export paths just like you import them, which is a much better layout)
[13:33] <Saviq> ah ok we'll leave it as-is then
[13:36] <danilos> Saviq: it will currently require you to rename files when you export them from Launchpad, but we definitely want to fix this bug asap :)
[13:36] <Saviq> yup
[13:36] <Saviq> it's not a big issue
[13:37] <resolve> to answer my own question, it seems automatic export into branch is not implemented yet
[13:39] <resolve> my other question - i've been waiting a few days for the initial import to be improved. is there any way to clear the import queue so I can try again? the latest tarballs I uploaded a few days ago were in the launchpad-preferred dir/<locale>.po format, so they should have been automatically improved, but I suspect my previous attempts have stopped that from working
[13:39] <resolve> in the mean time one of my users uploaded an update to a single po file, and that went through quickly. do i have to resort to manually uploading each file in turn to expediate the process?
[13:51] <resolve> if there's a more appropriate place for these questions, please let me know. :-)
[13:52] <wgrant> resolve: This is the right place.
[13:52] <wgrant> Maybe danilos can help you.
[13:52] <danilos> resolve: approvals happen automatically only if you use bzr imports, or if we have already approved your previous templates manually (using same paths in tarballs)
[13:53] <danilos> resolve: in general, you should be using the same set-up as initially for it all to work correctly
[13:53] <resolve> danilos: i started with a bzr import but the directory structure was not the launchpad-preferred way, so it blocked awaiting approval
[13:54] <resolve> i marked all those files as deleted, changed the directory structure in bzr, and then clicked 'request one time import' again
[13:54] <danilos> resolve: and, no, automatic export to branches is not ready yet (we are in the process of QAing it, so it should be ready next month)
[13:54] <resolve> (actually i went through this process 2-3x before getting it just right)
[13:54] <danilos> resolve: and they are still not imported? what's the project you are trying to import?
[13:54] <resolve> anki
[13:55] <danilos> resolve: this can happen if you've got a number of different templates where it's hard for system to pick up which is which; I'll look at your project now
[13:55] <resolve> thanks - appreciated
[13:57] <danilos> resolve: are you talking about translation files?
[13:57] <danilos> resolve: I can see your POT file as being imported, but for around 24 languages you are using what is not well coped with in Launchpad
[13:57] <resolve> the templates appear to have been approved, but the translation files are blocked
[13:58] <resolve> hmm, it should be about 12 languages - there are two domains
[13:58] <danilos> resolve: i.e. instead of using "de_DE.po" you should use "de.po", and only add country code where it's actually relevant (i.e. "pt_BR.po")
[13:58] <danilos> resolve: right, 24 files
[13:59] <danilos> resolve: if you just rename them to "de.po", "es.po", "fi.po", "fr.po"... it will all be fine and  they'll be auto-approved as well
[13:59] <resolve> okay, i'll give that a go, thanks
[13:59] <danilos> resolve: np, sorry it's so confusing
[14:00] <resolve> i realise it's still in an active state of development :-)
[14:01] <danilos> resolve: software is always in active state of development or dead, but hey :)
[14:01] <danilos> resolve: everything can always be improved :)
[14:02] <resolve> i don't suppose you know off the top of your head where I can find out which codes require the country qualifier?
[14:02] <resolve> i guess I could just change all the ones that blocked in launchpad.. :-)
[14:04] <danilos> resolve: there are only a few, where languages/scripts actually differ; out of your list, none do
[14:04] <danilos> resolve: i.e. pt_BR does, zh_CN, zh_TW, zh_HK as well, can't think of any other ones myself
[15:25] <resolve> danilos: okay, i've got the new files in the import queue, and i'm just waiting for the automatic approval script to reach them. i'll have a check in the morning. thanks a lot for the help!
[15:35] <danilos> resolve: it should all be fine by the looks of it (they should be auto-approved in the next few hours and then imported shortly afterwards)
[15:37] <resolve> i'm just trying to figure out the best workflow for future updates. my app is actually in a git repo, so i split the po and pot files out from that and put them in a separate bzr repo, simply for the sake of syncing with launchpad
[15:38] <resolve> i guess i'll need to write a script to pull the latest translations from launchpad periodically and reapply them to the bzr branch
[15:38] <resolve> and a script to update the template from the source and update bzr
[15:39] <resolve> one question: do I need to msgmerge each of the individual translations when I update the template? or can I rely on launchpad doing that after a new translation is uploaded?
[15:46] <radix> did bug-branch link whiteboards disappear, or am I confused?
[15:48] <jml> yes, they did.
[15:49] <jml> but ought they be regarded as mutually exclusive options?
[15:50] <SamB> jml: I think he was hoping he was just confused
[15:50] <SamB> and that they were really still somehow there, right under his nose
[15:51] <jml> SamB, yes, I detected that nuance.
[15:52] <oubiwann> hey guys, radix and I noticed that launchpad (edge) no longer seems to have the whiteboard for branches
[15:52] <radix> oubiwann: I already mentioned that :)
[15:52]  * oubiwann scrolls up...
[15:52] <radix> like, 6 lines ago :)
[15:53] <oubiwann> heh
[15:53] <radix> jml: ok. that's too bad. we used those.
[15:53] <oubiwann> yeah, like a *lot*
[15:53] <oubiwann> for annotating multiple parent branches
[15:53]  * SamB stocks up on sharpies so he can write on the branches anyway
[15:54]  * oubiwann cries
[15:56] <zirpu> maybe it was getting spammed.  i'd email the ubuntu lp ops/support and ask them directly.
[15:56] <jml> radix, what for?
[15:56] <oubiwann> jml: where do we sign the petition to bring back "Classic Whiteboard"
[15:56] <jml> oubiwann, beuno's face.
[15:56] <oubiwann> hehe
[15:56] <radix> jml: mostly what oubiwann just said. we would specify which parent branch a branch is based on.
[15:56] <radix> or to indicate other things that should be known to a reviewer or whatever.
[15:56]  * beuno goes find a mask
[15:57] <zirpu> isn't that in the meta data w/ the working copy?
[15:57] <radix> like, "you'll need to install the genchi package to review this"
[15:57] <oubiwann> jml: what was the reason for removing the whiteboard?
[15:57] <beuno> radix, we have branch descriptions, no?
[15:57] <jml> radix, to me, those seem to be properties of the branch or of the merge proposal
[15:57] <jml> not information about the link between the branch and the bug.
[15:57] <radix> beuno: I think those are gone, too? but even so, the bug-branch link was very convenient to edit and view, since it was right on the bug page.
[15:58] <radix> and we do everything with bugs.
[15:58] <jml> branch descriptions aren't gone.
[15:58] <radix> ok
[15:59] <radix> jml: anyway, that may be true, but the merge proposal system is still basically not as good as using bugs for us.
[15:59] <jml> wow.
[15:59] <radix> jml: it's getting really close, but I think one of the biggest blockers is that thing that came up on launchpad-users recently (IIRC), about tracking review-responses
[16:00] <radix> that is, knowing when someone has fixed all the issues in our last review.
[16:00] <radix> so that we can re-review
[16:00] <jml> how is bugs any better for that?
[16:00] <radix> jml: well, the author puts the review tag back on the bug.
[16:00] <jml> I see.
[16:00] <oubiwann> jml: and that was something else we used the whiteboard for ;-)
[16:01] <oubiwann> jml: e.g., "+1 count: 2"
[16:02]  * jml feels slightly demoralized
[16:04] <radix> развитие!
[16:04] <jml> I feel that using the bug/branch whiteboard in this way is something of a happy abuse
[16:05] <jml> rather than a feature.
[16:05] <radix> well, I'm not sure what that whiteboard was originally for.
[16:05] <radix> it was pretty useful as a stopgap for other unimplemented features.
[16:05] <jml> yeah...
[16:06] <jml> who was it that said most wiki pages are prototype web applications?
[16:06] <jml> I don't know what the whiteboard was originally for either.
[16:12] <jml> radix, I don't know what else to say.
[16:15] <radix> that's okay. I think we can deal with it by using bug comments, which is what we used to do.
[16:16] <jml> radix, do you feel that these are things that the code review system should do?
[16:17] <radix> jml: I'm not sure if it's possible for the code review system to automatically figure out what the parent of a branch is.
[16:17] <radix> although, hm, I guess that's what "target branch" is.
[16:17] <jml> radix, what precisely do you mean by 'parent'?
[16:18] <radix> probably the wrong word for it. I mean the branch that you should review the branch-for-review against.
[16:18] <radix> we often have a branch A, which isn't yet merged, and which the same or another developer will create a branch from to continue some work that depends on it.
[16:18] <jml> radix, because the code review system _is_ intended to handle the case of 'branch A will land on branch B but it was branched from branch C'
[16:19] <radix> oh, nice.
[16:19] <radix> does it already handle that?
[16:19] <jml> radix, it just fails to match that intent with execution.
[16:19] <radix> ok. :)
[16:19] <jml> radix, due also to UI simplification. :)
[16:19] <radix> jml: code review requests have a description, though, right? so we could use that barring any other feature.
[16:19] <jml> radix, yes, they do.
[16:20] <jml> radix, that's what we do (although it makes the generated diff suck)
[16:21] <radix> ah. right.
[16:21] <radix> jml: although I guess we can also just set the target of B to A.
[16:22] <jml> radix, I tried that once. it has one or two minor negative consequences.
[16:23] <jml> radix, branch B won't be marked as merged automatically until it is merged into A (which might never actually happen), and branch A will always appear as a suggested target branch on the web ui for whoever proposes that merge.
[16:23] <radix> ah, yeah.
[16:36] <resolve> danilos: i had a ee_EE file which was an estonian translation, but ee.po came up as 'ewe' rather than estonian. i've renamed the file in bzr (and I assume it will be automatically picked up in the next few hours). is there any way to delete the ewe translation?
[16:37] <danilos> resolve: we'll have to remove it manually, please file a request in answers.launchpad.net/rosetta and we'll get to it one of these days
[16:37] <resolve> thanks
[16:37] <danilos> resolve: please give a direct link to a translation so it's easier for us to do it
[16:37] <resolve> will do
[16:37] <danilos> resolve: thanks :)
[16:44] <resolve> danilos: and sorry, just to confirm - if I update the template then export the .po files, they will have been message merged to the latest template, right?
[16:45] <danilos> resolve: that's right, as soon as updated template has been imported
[16:45] <resolve> so when I get the email from launchpad, i know it's safe?
[16:48] <resolve> apologies for all the questions - I did read the docs first :-)
[16:50] <resolve> i'll create another question on launchpad so that others can see the answer too
[17:01] <resolve> ah, exporting sends an email with the location to download. that makes scripting an export a bit hard
[17:58] <kb9vqf_> Anyone here willing to rescore a PPA build?  This one https://launchpad.net/~ubuntu-389-directory-server/+archive/ppa/+build/1097734 and related were affected by bug 392104 , but it will be many hours before the build is retried with a score of 0!
[18:31] <kb9vqf_> Anyone here willing to rescore a PPA build?  This one https://launchpad.net/~ubuntu-389-directory-server/+archive/ppa/+build/1097734 and related were affected by bug 392104 , but it will be many hours before the build is retried with a score of 0!
[18:54] <bigjools> kb9vqf_: done
[18:54] <kb9vqf_> Thanks! :-)
[18:55]  * bigjools is glad of tab completion on nicks
[18:56]  * kb9vqf_ wonders if the build farm is completely overloaded today
[18:56] <resolve> danilos: thanks for the reply on answers
[18:57] <danilos> resolve: np :)
[18:57] <danilos> anyway, I am out, see you all
[19:58] <shaw> hi! cody-somerville sent me over here to ask about PPA trouble.
[19:59] <shaw> I'm trying to build ARM, and I see some PPAs can do it and some can't.
[19:59] <nhandler> shaw: Unless you have a "special" PPA (which only a handful of people have), you can't build for ARM in your PPA
[20:00] <shaw> nhandler: ah. so mcasadevall/ppa and doko/toolchain (from https://launchpad.net/builders) are special?
[20:00] <nhandler> shaw: Yes
[20:01] <shaw> nhandler: any idea who I can beg to be special too?  :P
[20:02] <nhandler> shaw: Michael was doing a lot of work on porting packages to ARM. Doko also has done some porting work (and some other stuff). Unless you are involved with porting to ARM, you are probably out of luck
[20:02] <shaw> nhandler: well, that's actually what I was trying to do (port a specific tool to ARM).  is there some place to find the ARM porters and talk with them?
[20:08] <shaw> nhandler: ah, found #ubuntu-arm, I'll go bug people there.  thanks!
[22:46] <waldo323>  is there a way to transfer a team membership from one launchpad account to another? (realized I have 2 launchpad accounts)
[22:51] <waldo323> nm, I found you can merge accounts


[01:54] <pieq> Hi!
[02:55] <callmepk> good morning
[04:45] <jibel> Good morning all
[05:15] <duflu> Hi jibel, and pieq and callmepk
[05:15] <callmepk> hey duflu jibel pieq
[05:58] <didrocks> good morning
[06:13] <luna_> hey
[07:09] <didrocks> Laney: hey! can you update oem-qemu-meta so that the diff between what the oem team wants to sponsor and the reference package is smaller? For instance, on https://bugs.launchpad.net/oem-priority/+bug/1888764, there is a bunch of stuff (gbp.conf and so on) which introduces noise, but also some of the things you are more appropriate than us to see if this relevant like
[07:10] <didrocks> XB-Ubuntu-OEM-Kernel-Flavour: oem that they now add
[07:10] <didrocks> also, they remove debian/tests/meta and such
[07:10] <didrocks> if I keep strict, I would just reject so that we have a smaller diff :p
[07:20] <didrocks> also, even the main reference package has Public License version 2 can be found in "/usr/share/common-licenses/GPL-3".
[07:20] <didrocks> some new ones are fixed, some not
[07:21] <didrocks> quite painful :/ I wonder if a better approach would be to only have one source package, and generates all of them via a reference file at build-time
[07:21] <didrocks> this way, no source to NEW each time, just binary NEW
[07:21] <didrocks> I guess there was a reason to not do that? (but then, have a lot of differences between packages, which was my initial fear and seems to happen)
[07:28] <RikMills> what is the planned gnome-shell version for groovy?
[07:29] <didrocks> RikMills: should be latest GNOME once released, so 3.38
[07:30] <RikMills> didrocks: thanks!
[07:31] <RikMills> just pondering whether to FFe the new pipewire in unstable, which would make gnome-remote-desktop need 3.38
[07:32] <didrocks> I don’t see https://bugs.launchpad.net/oem-priority/+bug/1882347 in focal though… /me puzzled
[07:33] <RikMills> plasma developers are starting to do things that require pipewire >= 0.3
[07:36] <marcustomlinson> morning desktoppers
[07:37] <didrocks> hey marcustomlinson
[07:37] <marcustomlinson> hi didrocks
[07:42] <duflu> Morning didrocks, luna_, marcustomlinson, Europe
[07:42] <duflu> and UK
[07:42] <didrocks> hey duflu
[07:46] <marcustomlinson> hey duflu
[07:47] <didrocks> (in some, also, oem just rename tests/meta and some others, they don’t)
[08:04] <Laney> morning
[08:05] <didrocks> hey Laney
[08:05] <Laney> didrocks: they have a script to generate these, I gave some "helpful" "feedback" on all of these deltas already, should be better in future when they fix that ...
[08:05] <Laney> the test renaming is the most annoying one
[08:06] <Laney> and unnecessary
[08:06] <didrocks> should I reject the packages then until they fix the deltas ?
[08:06] <didrocks> where there anything against having a single source package and generating them at build time?
[08:07] <Laney> yes, that was discussed, pretty much everything possible was :p
[08:07] <Laney> it means all of the packages get updated when you update any of them
[08:07] <Laney> I'd rather they got accepted and fixed next time
[08:08] <didrocks> well, a small no-op update (we already have so many updates in term of packages) rather than hundreds of diffs everywhere
[08:08] <didrocks> I don’t think we can ensure "next time" will be better and that the diff will magically disappear
[08:08] <Laney> ok
[08:08] <Laney> thanks for the help anyway
[08:09] <Laney> I'll just do all 30 myself
[08:09] <didrocks> I think it’s still time to reevaluate and help so that we don’t have the pain on us in the future
[08:09] <didrocks> as we have possibilities for this
[08:10] <didrocks> which is my suggestion, but if you don’t take it, *g*
[08:10] <Laney> Come to the next meeting we have if you want to re-open all this stuff
[08:10] <didrocks> happy to
[08:10] <Laney> fine
[08:10] <Laney> I'll invite you
[08:10] <didrocks> thanks
[08:11] <Laney> will you help now or is it all back on me?
[08:11] <didrocks> if we go to one single source package, happy to help
[08:11] <Laney> no then, ok, thanks
[08:11] <didrocks> *shrugh* that’s not helpful and positive discussion trying to find solution
[08:12] <Laney> We can change things for *future*, but these are updates that need to happen now, they represent enablements that the OEM team has done and need to get out there
[08:12] <Laney> we can't block on finding a different solution
[08:13] <Laney> so they have to be done, so I will do it
[08:13] <didrocks> so, let’s approve everything and not looking at the annoying diff, this is what you suggest?
[08:13] <didrocks> let’s not update the qemu meta package which reference in the same file GPL-2 AND GPL-3?
[08:14] <didrocks> I don’t even know if XB-Ubuntu-OEM-Kernel-Flavour: oem is desirable or not as the reference package doesn’t have it
[08:15] <Laney> I'm happy to address that kind of comment if it helps you to do the review you want to do
[08:16] <Laney> but I'm not happy to stop, chuck everything out, go back to the drawing board - I just don't think we can do it this way around
[08:17] <didrocks> I don’t want to stop, but it seems that getter things easier to deal with is even off the table with this attitude
[08:17] <didrocks> so, in the end, I warned about this situation already, it was dismissed, we are now in, and the pain is on everyone
[08:17] <didrocks> which is why I think it’s important to at least acknowledge there is something to fix
[08:17] <didrocks> then, we can unblock painfully those
[08:18] <didrocks> and reevaluate what to do
[08:18] <didrocks> but certainly a "ok, thanks for the help anyway, I’ll just do all 30 myself" seems to point to not wanting getting things in a better position in the future nor wanting to ack there is a pb
[08:19] <Laney> We've already been working on the process so that the distro team is out of the loop of this completely, except for an AA (me) accepting the packages
[08:19] <Laney> It's just not quite there with the DMB having the packageset ready and stuff yet
[08:20] <didrocks> I don’t see how the pakageset ready will help avoiding differences in packages, the same issue will happen again in the MIR review with the diff anyway
[08:20] <Laney> They get accepted straight to main, there is no separate MIR review
[08:21] <Laney> So, get the team uploading with a sensible diff (I have fed back already), accepting AA runs the script and accepts to main
[08:21] <didrocks> what is blocking them regenerating sensible diff right now?
[08:22] <didrocks> we will always have diverges if from the first set of package, we already have some
[08:23] <Laney> I guess that was probably me giving that indication that it was OK to fix for next time
[08:23] <Laney> but we can go round again I guess, maybe that's not too bad to do
[08:23] <Laney> it would avoid a negative diff between the two updates next time
[08:24] <didrocks> indeed
[08:26] <Laney> Yeah that sounds sensible to me, I have asked!
[08:26] <Laney> OK hold for a bit until we get feedback on that
[08:26] <didrocks> thanks Laney, keep me posted :)
[08:27] <didrocks> and please invite me to next meeting, happy to push for a single source package and work on automating the generation of those (and as we already have a bunch of example packages, we can have it working in the different cases like foo.bar, foo-bar-baz and such)
[08:29] <Laney> I'm happy for you to discuss it, but the current situation is what was agreed after many MANY meetings on all this stuff before, so don't get your heart set on changing it
[08:29] <Laney> my focus has been on getting the distro team out of it all completely except for the SRU approvals
[08:29] <Laney> with the idea that they handle it in the way they prefer
[08:30] <Laney> *opens window* *sound of chainsaw* *closes window completely*
[08:30] <didrocks> but we see that it’s not really scalable
[08:31] <didrocks> or at least, they should ensure the diff is small and we bindly reject otherwise
[08:31] <Laney> yeah that's why we had that script, maybe I should have been more strict in enforcing it
[08:32] <didrocks> I think there is no incentive in updating the reference package, which we should work on (hence the idea of a single source one), but if they don’t want it, they should help us then in easing our side as well
[08:33] <didrocks> and ensure what they file is scalable
[08:34] <Laney> I guess a couple of rejections will help with that :p
[08:35] <didrocks> yep :)
[08:35] <Laney> what's the GPL-2 thing with the metapackage?
[08:38] <Laney> don't see it, but it should be fixed, so a pointer is welcome
[08:39] <didrocks> Laney: http://launchpadlibrarian.net/490676356/oem-qemu-meta_20.04~ubuntu4_20.04~ubuntu5.diff.gz is fixed in groovy (see d/copyright), but not in focal. It seems *some* (not all) oem metapackage are generated from 20.04~ubuntu3 package in focal, and some other have it fixed, but the diff was made on focal…
[08:40] <Laney> ah, I made oem-qemu-metapackage-check use pull-lp-source so it always comes from the dev series
[08:40] <didrocks> the diff should always be done against latest devel I think that was your intention?
[08:40] <Laney> fml
[08:40] <didrocks> unsure why some of the diff have the previous version, maybe they came before the fix, I didn’t check
[08:40] <Laney> oem-metapackage-mir-check
[08:59] <cpaelzer> do we ahve any video edit alternative in main - I looked at kdenlive, openshot, pitivi but none is. I could go on checking but maybe someone just knows?
[09:36] <Laney> cpaelzer: not afaik
[09:51] <cpaelzer> ok, thanks
[09:55] <KGB-2> mutter tags 46f3af6 Simon McVittie upstream/3.36.6 * Upstream version 3.36.6 * https://deb.li/31UWh
[09:56] <duflu> \o/
[10:04] <Laney> didrocks: Rex says they will re-generate those packages using the script, so wait for that, I will let you know when that's done
[10:04] <Laney> thanks for that bit of push back, I think it was a good idea ;-)
[10:07] <didrocks> Laney: happy to have contribued, keep me posted once we can do the rereview :)
[10:29] <GunnarHj> Hi all!
[10:29] <GunnarHj> A few days ago "Ubuntu Software" became "Software Install" in groovy, but last night it seemed to be back to "Ubuntu Software". Is there a name change in pipeline? Asking since I'm about to take a look at the install part of the desktop guide.
[10:43] <jibel> I used latest groovy image installed the updates which included ubuntu-dock, after reboot, no dock
[10:43] <jibel> can someone have a look?
[10:43] <jibel> Trevinho, ^
[10:44] <Laney> was going to say, suggest pinging the uploader ;-)
[10:44] <Laney> GunnarHj: Not that I know of
[10:46] <jibel> Trevinho, from the journal
[10:46] <jibel> sept. 11 12:42:50 mp390185 gnome-shell[1309]: JS ERROR: TypeError: method Clutter.Actor.set_allocation: At least 2 arguments required, but only 1 passed
[10:46] <jibel>                                               vfunc_allocate@/usr/share/gnome-shell/extensions/ubuntu-dock@ubuntu.com/docking.js:83:14
[10:47] <duflu> Ugh, we fixed that in desktop-icons. Didn't check ubuntu-dock
[10:53] <Laney> I assume it works with 3.37?
[10:54] <Laney> if we're ready, I could kick out those broken extensions
[10:54] <Laney> migrating gnome-shell/3.37.91-1ubuntu1/amd64 to testing makes gnome-shell-extension-bluetooth-quick-connect/13-1/amd64 uninstallable
[10:54] <Laney> migrating gnome-shell/3.37.91-1ubuntu1/amd64 to testing makes gnome-shell-extension-caffeine/35-2/amd64 uninstallable
[10:54] <Laney> migrating gnome-shell/3.37.91-1ubuntu1/amd64 to testing makes gnome-shell-extension-easyscreencast/1.1.0-2/amd64 uninstallable
[10:54] <Laney> that will presumably make gnome-shell migrate
[10:54] <Laney> migrating gnome-shell/3.37.91-1ubuntu1/amd64 to testing makes gnome-shell-extension-top-icons-plus/27-1/amd64 uninstallable
[10:56] <Laney> Trevinho: let me know !
[10:57] <duflu> Instead of looking I will try to EOW :)
[10:59] <duflu> I assume Marco has it sorted already since he mentioned ubuntu-dock and 3.37
[10:59] <duflu> So good night...
[11:03] <GunnarHj> Laney: Good. You ought to know I suppose. Unless some equivalent to bug #1570479 happens...
[11:03] <Laney> dunno, plenty happens that I don't hear about until later on :p
[11:03] <GunnarHj> ;)
[12:40] <Trevinho> jibel: so, I apparently didn't backport the commit I did to support 3.36 as well in the groovy branch... I did it on purpose not to include uneeded changes there, but... Well apparently I forgot when changing the control file.
[12:40] <Trevinho> jibel: however newer shell can be unblocked now
[12:45] <Laney> ok, done, hopefully it goes in a couple of hours
[12:46] <Trevinho> Laney: so yeah... I didn't see the question sorry..  Thanks :)
[15:14] <waveform> \o/
[15:15] <hellsworth> 🎉
[15:45] <Laney> shell 3.37 is going to go in now
[15:45] <Laney> for your dist-upgrade enjoyment
[15:45] <Laney> Trevinho:
[15:46] <luna_> gnome ?
[15:59] <Trevinho> Laney: lovely!
[15:59] <Trevinho> ... and jibel new bugs! 😊
[16:20] <jibel> I'll assume it's well tested and bug free :P
[16:38] <KGB-0> gnome-settings-daemon signed tags 767dc23 Iain Lane ubuntu/3.37.92-1ubuntu1 * gnome-settings-daemon Debian release 3.37.92-1ubuntu1 * https://deb.li/S7tV
[16:38] <KGB-0> gnome-settings-daemon ubuntu/master b3f73c7 Iain Lane * pushed 65 commits (first 5 follow) * https://deb.li/3b1Ag
[16:38] <KGB-0> gnome-settings-daemon ubuntu/master faedcdd Aurimas Černius po/lt.po * Updated Lithuanian translation * https://deb.li/3gCfN
[16:38] <KGB-0> gnome-settings-daemon ubuntu/master 3569ddd Jordi Mas i Hernandez po/ca.po * Update Catalan translation * https://deb.li/ix5ix
[16:39] <KGB-0> gnome-settings-daemon ubuntu/master 21014d5 Goran Vidović po/hr.po * Update Croatian translation * https://deb.li/k7Z2
[16:39] <KGB-0> gnome-settings-daemon ubuntu/master 58da95b Thibault Martin po/fr.po * Update French translation * https://deb.li/3W1oC
[16:39] <KGB-0> gnome-settings-daemon ubuntu/master 0c3875f Fran Dieguez po/gl.po * Update Galician translation * https://deb.li/eCqh
[17:09] <KGB-0> glib pristine-tar cbfa0bf Simon McVittie glib2.0_2.66.0.orig.tar.xz.delta glib2.0_2.66.0.orig.tar.xz.id * pristine-tar data for glib2.0_2.66.0.orig.tar.xz * https://deb.li/3V18h
[17:09] <KGB-0> glib upstream/latest a715f47 Simon McVittie * pushed 17 commits * https://deb.li/DY4n
[17:09] <KGB-0> glib tags 9092bb7 Simon McVittie upstream/2.66.0 * Upstream version 2.66.0 * https://deb.li/3L3q7
[17:17] <KGB-0> orca tags e04f148 Samuel Thibault upstream/3.38.0 * Upstream version 3.38.0 * https://deb.li/LCeg


[08:07] <nsi_e> hi
[14:05] <xu-irc18w> I try to help an friend with disablilities. He has a system with 32 bit, and I'm looking to install XUnuntu to it. Is there a current release of XUbuntu for 32 bit?
[14:05] <xu-irc18w> ```
[14:05] <xu-irc18w> CPU~Single core AMD Athlon II X2 250 (-UP-) speed~3000 MHz (max) Kernel~3.16.0-4-586 i686 Up~1:48 Mem~2037.8/3293.9MB HDD~2080.4GB(42.6% used)
[14:05] <xu-irc18w> ```
[14:11] <xu-irc18w> Sorry for the misspellings.
[14:12] <xu-irc18w> I am trying to help a friend with disabilities. He has a 32-bit system, and I am looking to install Xubuntu on it. Is there a current release of Xubuntu for 32-bit?
[14:12] <xu-irc18w> My friends old computer works with an "AMD Athlon II X2 250" as shown.
[14:13] <bluesabre> xu-irc18w: There is not. The last 32-bit release of Xubuntu was several years ago and it is out of support. You'll want to find another option, like Debian, instead.
[14:16] <xu-irc18w> Fuck. - sorry- I first wanted to use LUbuntu, but it's also no longer available for 32-bit. Also Linux Lite is no longer available for 32-bit since version 4.0.
[14:18] <xu-irc18w> I use Bodhi Linux, for example, for an older netbook, but it would be too obscure for my friend.
[14:23] <xu-irc18w> Ok, it seems, I have to look for something like antiX or Linux Mint Debian Edition (LMDE).
[14:23] <xu-irc18w> THX for your help! :-)
[14:33] <xu-irc18w> Bye
[14:34] <Zkyvy> :>
[19:23] <drei> hi together