[04:20] <carlj> Hi guys. I`m facing with a problem of resolution of gnome-shell. The problem is that the real resolution, dont reflect the defined (1366x768). The gnome with metacity or compiz work as well.
[06:08] <LinDol> hi all
[06:08] <LinDol> Heavensbus, hi
[06:10] <Heavensbus> LinDol: hi


[12:23] <stu-mc> jrib: sorry for loosing my kool.
[03:21] <m1r> hi all
[03:21] <m1r> /root/.setup5340: error while loading shared libraries: libgtk-1.2.so.0: cannot open shared object file: No such file or directory
[03:21] <m1r> The setup program seems to have failed on x86/glibc-2.1
[03:22] <nalioth> m1r: what are you trying to install? and what distro are you running?
[03:23] <m1r> ubuntu 7.04 , enemy teritory
[03:24] <nalioth> got a link?
[03:24] <m1r> link to ?
[03:25] <nalioth> enemy territory.
[03:25] <m1r> i dl from gaming site
[03:25] <m1r> used it on other machine with np
[03:26] <nalioth> ok. it seems it is wanting another version of glibc.
[03:26] <nalioth> i'm asking for the site, so i can look at it
[03:26] <m1r> second i give u link
[03:27] <m1r> http://www.gamershell.com/download_2355.shtml
[03:28] <m1r> last time i didnt have to install libgtk as i recall
[03:29] <m1r> ok is runing now, i got scared :)
[03:29] <m1r> 2 days infront pc dont make ppl feel good
[03:29] <nalioth> perhaps a nap is in order  :)
[03:31] <m1r> think that is good idea, but i want my full spectar of games run first :)
[03:32] <m1r> got used laptop with ati 9000x64mb /512ram/2660mhz p4
[03:32] <nalioth> sounds good :)
[03:32] <m1r> man, it is a beast :)
[03:33] <m1r> 1st time i managed to run 3d desktop
[03:33] <m1r> so i am filing it with every game i know for linux :)
[03:33] <m1r> do u know any good games u can recomend ?
[03:34] <m1r> i got open arena , nexuiz , torcs, et now
[03:34] <m1r> it is amaizing that all of them run with np :)
[03:35] <m1r> only problem is , i cant have anything ON desktop open if i want play, that part i dont get yet
[03:35] <nalioth> i'm not much of a gamer  :(
[03:35] <m1r> me neither :) but with this power ... :)
[03:35] <m1r> would be pitty not to see what can it do , at least :)
[03:35] <nalioth> yep :)
[03:36] <m1r> on 2nd boot, shit showed me my battery is 16h time left :D
[03:36] <m1r> but then after 1 min, it got to 1h :/
[03:36] <m1r> some damn nice bug would that be :)
[03:37] <m1r> *tnx lord for nescaffe 3in1*
[03:37] <m1r> i go seek some more games, tnx for help m8 :)
[03:38] <m1r> when did this chanell open btw ?
[03:38] <nalioth> it's been open for a long time
[03:38] <nalioth> i thought you were having compile issues, not install issues
[03:40] <m1r> ah :)
[03:44] <m1r> ah nice, found a site with list of games , wish me luck :P
[03:44] <m1r> http://doc.gwos.org/index.php/Native_Games


[04:07] <valorie> apachelogger: http://sparkle.pink/
[04:09] <dodger> wait
[04:09] <dodger> tacos?
[04:10] <dodger> i'd say that would be a good reason to change restaurants
[04:10]  * valorie is not responsible for that site!
[04:12] <dodger> well, i'll take anything remotely soothing at the moment, so i'll ignore the tacos for the other happy stuff :P
[04:13] <jose> unicorns are listed there!
[04:13] <dodger> unicorns are happy and soothing
[04:14] <dodger> at least in my imagination :P
[04:14] <jose> they should be utopic too
[04:14] <dodger> they are, especially pink ones!
[04:20]  * debfx thinks unicorn is redundant
[04:20] <debfx> we already had natty narwhal
[07:28] <apachelogger> it's interesting how muon doesn't have a -common/-data pacakge
[07:28] <apachelogger> most peculiar
[07:28] <apachelogger> Riddell: why do we need a meeting to discuss that someone from the council needs to organize elections?
[07:29] <apachelogger> valorie: fancy
[07:31] <lordievader> Good morning.
[07:50] <Riddell> apachelogger: why do we need a meeting at all? to coordinate etc
[07:54] <apachelogger> Riddell: just a hold up if you ask me
[08:03] <apachelogger> reviewer says: trusty crashes too much
[08:04] <valorie> speaking of mumble, where is our server, so I can test?
[08:06] <apachelogger> yofel: are we going to use your's? if so, please throw a mail out with data for testing if possible
[08:06] <valorie> ha, I meant to send that email but got lazy
[08:07] <yofel> apachelogger: checked yesterday, I need to set it up again (which is trivial, which makes me wonder whether we shouldn't just run it on the qa server)
[08:12] <apachelogger> yofel: qa also is supposed to power the new site, so I doubt that would be a long term solution either
[08:12] <apachelogger> but for the time being either is fine with me :)
[08:12] <apachelogger> maybe write a script for setup so we can easily deploy on other servers when necessary?
[08:13] <yofel> I think last time we ran on a complete vanilla config as I had to reinstall it, so for our use case that's probably overkill
[08:13] <yofel> go ahead though if you find it fun ^^
[08:17] <apachelogger> yofel: oh god no :P
[08:19] <apachelogger> shadeslayer: whatever happened to the discover screenshot stuff being broken etc?
[08:30] <apachelogger> bug #1025436
[08:31]  * apachelogger wonders what recommendation data is
[08:33] <agateau> Riddell: hi, friendly reminder for the fix to my brown-bag bug in ubiquity https://code.launchpad.net/~agateau/ubiquity/kde-fix-broken-sidebar-layout-on-greeter/+merge/216365
[08:37] <Riddell> agateau: eek sorry
[08:44] <apachelogger> software-properties-kde is the greatest shite ever
[08:46] <Riddell> oh?
[08:50] <apachelogger> completely out of date
[08:50] <apachelogger> also it implements gnome HIG rather than KDE one
[08:50] <apachelogger> much awesome
[08:51] <apachelogger> not that the gtk version is much better at not causing my eyes to pop out http://i.imgur.com/vgcUx0h.png
[08:55] <yofel> the gtk UI isn't much better, the backend implementation is though. The kde one is... horribly
[08:55] <yofel> someone that signed the CLA please rewrite that
[08:56] <apachelogger> roflmao
[08:56] <apachelogger> the ui files
[08:56] <apachelogger> the ui files
[08:56] <apachelogger> the flipping ui files
[08:57] <apachelogger> "I don't always set a qwidget size policy to fixed, but when I do, I make sure that it makes as little sense as possible"
[09:06] <apachelogger> there's something terribly wrong with main.ui, designer itself doesn't even manage to figure sensible spacing Oo
[09:16] <apachelogger> additionally there's also the problem that I don't see how the majority of updates options actually have impact on muon
[09:16] <apachelogger> black magic right there
[09:20] <Riddell> mitya57: shall I upload qt to utopic?
[09:22] <apachelogger> cyphermox: do we have a migration plan for bluez5 already?
[09:41] <shadeslayer> apachelogger: I thought I got that fixed ... mostly
[09:42] <shadeslayer> apachelogger: IIRC KDE SDK still doesn't have a screenshot, but atleast kdeconnect did
[09:42] <apachelogger> shadeslayer: I have not looked
[09:42] <shadeslayer> OTOH s.d.n does support trusty now ....
[09:42] <apachelogger> lol
[09:43] <apachelogger> everythings kaput
[09:43]  * apachelogger jumpst out the window
[09:43] <shadeslayer> apachelogger: http://imgur.com/IvdJuw0
[09:43] <shadeslayer> WFM
[09:45] <apachelogger> shadeslayer: and the sdk?
[09:45] <shadeslayer> kaput
[09:49] <apachelogger> oh
[09:50] <apachelogger> btw, we could totally rewrite software-props in c++ btw :P
[09:50] <apachelogger> cuz there was the property to a polkit dbus api
[09:51] <apachelogger> and actually I only wanted to fix untranslated strings
[09:52] <apachelogger> whenever I look into a bug it turns out that there's much bigger shittyness at work :'<
[09:56] <BluesKaj> 'Morning folks
[09:58] <apachelogger> sooooooo.... software-properties needs: a) port to dbus helper b) removal of kdesudo forcing crap c) UI resync with gtk d) complete feature check to assure all strings are subsequently localized e) porting to KCModule to stop having the gnome style on-change-apply f) organizational cleanup g) quite possibly a refactor of code layout as currently the main class looks a lot like it's a random pile of random code doing random things (that may
[09:58] <apachelogger> be the result of on-apply changery though)
[10:00] <shadeslayer> *nod*
[10:00] <shadeslayer> add a card
[10:01] <Riddell> apachelogger: oh and port to qt5/kf5
[10:01] <shadeslayer> depending on what we're shipping in 14.10 , alot of things will need tha :P
[10:01] <shadeslayer> *that
[10:02] <shadeslayer> apachelogger: https://bugs.launchpad.net/ubuntu/+source/kubuntu-driver-manager/+bug/1315670 < any thoughts on how to reproduce that?
[10:02] <shadeslayer> I tried removing /etc/init/nvidia-persistenced.conf , but I could still install the right driver /etc/init/nvidia-persistenced.conf
[10:03] <apachelogger> sure, break your system :P
[10:04] <apachelogger> shadeslayer: install nvidia, remove (do not purge!), remove the mentioned file, install nvidia again
[10:04] <shadeslayer> apachelogger: well, driver manager has debconf handling so it /should/ have shown a dialog
[10:04] <apachelogger> that's what I thought, maybe the handling is borked
[10:04] <apachelogger> though I think I took extra care to replicate the code paths for that
[10:04] <apachelogger> seeing as its so shitty to test
[10:05] <apachelogger> as I mentioned earlier last cycle
[10:05] <apachelogger> that's a general problem with driver manager
[10:05] <apachelogger> many things should work, there's no way to know because there's no testing facilities in place
[10:06] <shadeslayer> right
[10:06] <apachelogger> https://www.youtube.com/watch?v=6pOq4hyoX9g
[10:09] <shadeslayer> tsdgeos: fancy commenting on https://bugs.launchpad.net/ubuntu/+source/kde-workspace/+bug/1312806 about your kde-workspace upgrade experience?
[10:11] <apachelogger> shadeslayer: https://trello.com/c/DVqA9YfM
[10:11] <apachelogger> there's already so much stuff
[10:11]  * apachelogger sighs
[10:11] <shadeslayer> get on it then :P
[10:14] <apachelogger> shadeslayer: first I need to pull some more stuff out my nose
[10:14] <apachelogger> actually, perhaps we should look into ways to score importance
[10:15] <apachelogger> guess some stuff contributes more to the next LTS epic than to 14.10 in particular
[10:31] <apachelogger> hm
[10:31] <apachelogger> Riddell: are you sure moving the dependency graph to the new wiki is useful? wasn't updated since 4.11
[10:32] <Riddell> apachelogger: shrug, I still use it occationally
[10:32] <apachelogger> might just as well ditch it and if there's need in the future we can grab it from the ubuntu wiki
[10:32] <Riddell> don't bother if it's hassle
[10:32] <apachelogger> also on a random note: with kf5 we'll be able to generate that from the kdesrcbuild metadata anyway
[10:49] <apachelogger> Riddell, shadeslayer, others: do you want to keep https://wiki.ubuntu.com/Kubuntu/Council/Messages
[10:50] <Riddell> apachelogger: nah
[10:51] <apachelogger> https://wiki.ubuntu.com/Kubuntu/GettingInvolved/WhoWeAre
[10:51] <apachelogger> I did not even know we had such a thing :O
[10:52] <yofel> oh right, someone wanted to set that up, but then half the people didn't bother updating their details and it vanished into oblivion
[10:53] <apachelogger> shouldn't be on the wiki IMO
[10:53] <apachelogger> website page, with link to in the footer or something
[11:05] <apachelogger> :O
[11:05] <apachelogger> https://wiki.ubuntu.com/Kubuntu/Toolbox/Menu?action=raw
[11:05] <apachelogger> what the fish
[11:37] <apachelogger> shadeslayer: did you find out why we are still using eglibc btw?
[11:38] <apachelogger> shadeslayer: wrong board? https://trello.com/c/OrfBopyt
[12:01] <sgclark> Riddell: good morning, want to make sure you are not working on kxmlgui before I start
[12:01] <Riddell> sgclark: go for it
[12:02] <sgclark> k
[12:13] <shadeslayer> apachelogger: <ScottK> I assume infinity and the other GLIBC maintainers will sort it out.
[12:13] <shadeslayer> from yesterday
[12:13] <apachelogger> assumption is dangerous :P
[12:14] <apachelogger> let's listen to music first though https://www.youtube.com/watch?v=qXavZYeXEc0
[12:18] <shadeslayer> I like how https://wiki.ubuntu.com/Kubuntu/GettingInvolved/WhoWeAre?action=recall&rev=115 says " Expertise : Expertise" for some entries
[12:25] <sgclark> Riddell: kxmlgui ready
[12:28]  * Riddell looks
[12:28] <apachelogger> http://community.kde.org/Kubuntu/Links that needs some updatering in case someone wants to ;)
[12:29] <Riddell> sgclark: uploaded!
[12:29] <Riddell> apachelogger: or scrapping, most of the relevant ones should be on qa.kubuntu.co.uk
[12:35] <apachelogger> hm
[12:36] <apachelogger> Riddell: still leaves half of them though ^^
[12:36]  * apachelogger puts down a card
[12:59] <Quintasan> \o
[13:04] <shadeslayer> yo Quintasan
[13:05] <shadeslayer> get mergering
[13:24] <apachelogger> Riddell: what do we do with the getting involved wiki pages?
[13:24] <apachelogger> https://wiki.ubuntu.com/Kubuntu/GettingInvolved/Development e.g.
[13:24] <apachelogger> IMO the pages gotten somewhat overly texty
[13:25] <apachelogger> plus we only have one for development apparently
[13:28] <sgclark> Riddell: kbookmarks is ready
[13:29] <Riddell> sgclark: you forgot to bzr add libkf5bookmarks5-data I think
[13:29] <sgclark> oops
[13:30] <Riddell> apachelogger: put a bit "under construction" image on it?
[13:30] <apachelogger> Riddell: it's still not helpful I fear
[13:31] <sgclark> Riddell: added
[13:31] <apachelogger> Riddell: at the end of the day the overall recommendation is for someone to hop on irc and find a passion
[13:31] <sgclark> ^^ worked for me
[13:32] <apachelogger> yeah xD
[13:34] <Riddell> apachelogger: so edit up a shorter page which highlights that?
[13:34] <apachelogger> Riddell: yeah, and make it generic
[13:34] <apachelogger> i.e. not specific to development
[13:34] <apachelogger> the question is
[13:34] <apachelogger> should it be on the wiki
[13:35] <apachelogger> because I think simply throwing it up on the new website might be best, since apparently the new community page is going to be a worthwhile hub for information on the community anyway
[13:35] <Riddell> true
[13:47] <shadeslayer> why do we have ktouchpadenabler in kde-workspace-bin whereas debian has a split package?
[13:49] <shadeslayer> Riddell: ^^
[13:49] <shadeslayer> any clue?
[13:49] <shadeslayer> I can't find anything in the changelog
[13:50] <shadeslayer> I wonder if we've had  it this way from the beginning
[13:55] <shadeslayer> ah
[13:55] <shadeslayer> Riddell: your last merge did this
[13:57] <shadeslayer> Riddell: so, any reason why ktouchpadenabler shouldn't be it's own package?
[14:03] <Riddell> shadeslayer: no reason
[14:03] <shadeslayer> so can I go ahead and drop that delta with Debian?
[14:03] <Riddell> we had it as a separate source then when it went into the kde-workspace source I just put it in kde-workspace-bin but I guess debian kept it in separate binaries
[14:03] <Riddell> shadeslayer: yep
[14:03] <shadeslayer> awesome
[14:12] <sgclark> Riddell: not sure if you saw, I added the missing data install file in kbookmarks.
[14:13] <shadeslayer> apachelogger: http://paste.kde.org/pndbku6xr
[14:13] <shadeslayer> xD
[14:14] <Riddell> sgclark: yep, uploaded!
[14:16]  * apachelogger squints
[14:17] <apachelogger> shadeslayer: sounds like me
[14:17] <apachelogger> shadeslayer: better leave the comments in
[14:17] <shadeslayer> yeah yeah
[14:17] <apachelogger> you never know what apachelogger would do to you
[14:17] <yofel> stripes.png <3
[14:19] <shadeslayer> any thoughts on this http://paste.kde.org/pxb1nnos5
[14:19] <shadeslayer> just copy over what debian is doing?
[14:19] <apachelogger> kittens
[14:19] <shadeslayer> :3
[14:19] <shadeslayer> kittens
[14:19] <apachelogger> autoscroll ftw
[14:20] <apachelogger> shadeslayer: better check what common-session.pam contains for us
[14:20] <shadeslayer> all sorts of fun stuff here http://paste.kde.org/pub3xnrro
[14:21] <shadeslayer> so much fun that start-stop-daemon changed --pidfile to --pid in debian? :S
[14:21] <apachelogger> maybe for us too? :P
[14:21] <apachelogger> entirely possible that pidfile is deprecated
[14:22] <shadeslayer> anyone running utopic? :P
[14:31] <Riddell> not yet
[14:32] <kubotu> ::workspace-bugs:: [1317115] KDE Locale module support for changing language is incomplete @ https://bugs.launchpad.net/bugs/1317115 (by Tim Edwards)
[14:37] <shadeslayer> apachelogger: re pam session files, what needs checking?
[14:37] <shadeslayer> it doesn't have the lines indicated in the diff
[14:38] <shadeslayer> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664808
[14:39] <shadeslayer> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677438
[14:43] <apachelogger> ah
[14:43] <apachelogger> even so
[14:43] <BluesKaj> shadeslayer, yes
[14:43] <apachelogger> shadeslayer: check common-session.pam
[14:43] <shadeslayer> for what?
[14:43] <shadeslayer> BluesKaj: huh?
[14:43] <apachelogger> for those things
[14:43] <shadeslayer> BluesKaj: oh you're running utopic?
[14:44] <BluesKaj> utopic here
[14:44] <shadeslayer> BluesKaj: can you check the man page of start-stop-daemon, does it say --pid or --pidfile ?
[14:44] <shadeslayer> apachelogger: it does not
[14:45] <apachelogger> shadeslayer: then carry over those additions but make sure common-session is preserved as an addition on our side
[14:45] <apachelogger> oh, debian has that too, I think
[14:45] <shadeslayer> it does
[14:45] <apachelogger> right, then there's no diff anyway? :P
[14:45] <apachelogger> just adopt what debian has
[14:45] <BluesKaj> shadeslayer, it says pidfile
[14:46] <shadeslayer> apachelogger: yeah, but I was unsure about the selinux stuff
[14:46] <shadeslayer> I am a noob when it comes to pam
[14:46] <shadeslayer> all I know is, that stuff loads modules, those modules do magic
[14:46] <shadeslayer> if the incantations are wrong, your computer will explode into a million piece
[14:47] <shadeslayer> *pieces
[14:47] <shadeslayer> BluesKaj: cheers
[14:47] <apachelogger> you have a pro in the office :P
[14:48] <shadeslayer> he's busy with stuff
[14:48] <BluesKaj> shadeslayer, in the Matchu=ing options section the first line says: Check for a process with the specified pid. The pid must be a number greater than 0
[14:48] <BluesKaj> err Matching options
[14:50] <apachelogger> shadeslayer: ignore=ignore is equal to prefixing with a -, both of which make failure in the module non-fatal
[14:50] <apachelogger> IIRC at least
[14:51] <apachelogger> if yo want to go the safe route you can prefix the line with a - as well
[14:51] <shadeslayer> ack
[14:51] <apachelogger> that definitely makes the module optional
[14:51] <apachelogger> shadeslayer: man pam.d
[14:52] <apachelogger> http://manpages.ubuntu.com/manpages/trusty/en/man5/pam.d.5.html
[14:52] <shadeslayer> ohm
[14:52] <shadeslayer> apachelogger: <3
[14:52] <shadeslayer> I shall read it when I have time
[14:52] <shadeslayer> which means never
[14:53] <apachelogger> one reads that stuff on demand anyway :P
[14:53] <apachelogger> as long as one knows that there is something to read ;)
[15:04] <sgclark> Riddell: kwallet-kf5 ready
[15:05] <Riddell> yay!
[15:05] <Riddell> that looks like another blocker one
[15:05] <sgclark> hehe yep
[15:06] <Riddell> uploaded
[15:19] <Mamarok> dear Kubuntu devs, does anybody have an idea what is wrong here: http://forum.kde.org/viewtopic.php?f=115&t=120863&sid=63b1dadfd2ab36f00377805e5115c57d ?
[15:20] <Mamarok> FWIW, transcoding shows fine here for me, but I use Amarok from git
[15:22] <shadeslayer> yofel: ping
[15:23] <shadeslayer> yofel: why do we not install libkdeinit4_kwin_gles.so
[15:26] <shadeslayer> actually hmm
[15:26] <shadeslayer> it is installed, but also listed in not-installed ? 0.o
[15:27] <shadeslayer> \o/ http://paste.kde.org/p7m6uypxj
[15:29] <shadeslayer> actuall
[15:29] <shadeslayer> *actually
[15:30] <shadeslayer> I noticed a thing that might make apachelogger come after me when I'm sleeping
[15:32] <kubotu> ::workspace-bugs:: [1275584] Kubuntu 14.04 Kickoff Font Look Ugly / Jerky @ https://bugs.launchpad.net/bugs/1275584 (by j2snowden)
[15:46] <shadeslayer> looks like snowden uses Kubuntu :P
[15:47] <Riddell> oh?
[15:49] <dodger> i'd expect him to use tails or something like that
[15:49] <dodger> that's cool :)
[15:52] <Riddell> sgclark: kio needs your attention :)
[15:52] <sgclark> Riddell: on it ty
[16:29] <sgclark> Riddell: kio ready
[16:33] <xnox> yo people what's the plan for ubiquity-frontend-kde w.r.t. Qt5?
[16:33] <xnox> should i fork it to start qt5 frontend?
[16:34] <xnox> at the moment i'm looking at a straight port. If/when somebody will want to make it "ubuntu" and/or "ubuntu-ui-toolkit-qml" then i'd start a new frontend for that.
[16:39] <apachelogger> xnox: haven't talked about it yet, but from my experience a straight qt5 port should be fine, I reckon just about all kde classes we use have been retired in favor of qt5 versions anyway. you may want to check with agateau though
[16:39] <apachelogger> also we have a meeting next week, I guess we should discuss it there
[16:39]  * apachelogger adds to agenda
[16:40] <xnox> apachelogger: when is this meeting?
[16:40] <xnox> apachelogger: do you have any qt5 on the image yet?
[16:40] <apachelogger> xnox: monday 19 utc
[16:40] <apachelogger> xnox: I don't think we have right now
[16:41] <apachelogger> but at least with 15.04 we are probably looking at a migration towards qt5 tech, so we'll have to make space anyway ^^
[16:50] <shadeslayer> debfx: I don't suppose why you changed the recommends to suggests? http://paste.kde.org/pt5gxzqbl
[16:50] <shadeslayer> hm
[16:50] <shadeslayer> probably because it adds too much to the ISO would be my guess
[16:51] <yofel> shadeslayer: because libkdeinit* appears in list-missing even if installed because it's moved post-install
[16:51] <shadeslayer> yofel: ack
[16:51]  * shadeslayer nukes kde-workspace-data-extras
[16:52] <shadeslayer> kde-workspace has eaten my entire day :<
[16:54] <shadeslayer> did someone create the SRU branches btw?
[16:54] <yofel> no, and don't do it
[16:54] <shadeslayer> oh?
[16:55] <shadeslayer> do we want merged stuff from debian then? because I've dropped some Breaks/Replaces
[16:55] <yofel> you do not spin SRU's from bzr...
[16:55] <shadeslayer> wouldn't know, never used the SRU script
[16:55] <shadeslayer> yofel: so it just uses the packaging from what is in current stable?
[16:55] <shadeslayer> instead of bzr
[16:56] <ScottK> There's a some kopete changes we should pick up for the 4.13.1 SRU
[16:56] <yofel> yes. It did use sru branches for saucy, but those were more work than useful so that's gone again
[16:58]  * shadeslayer throws some stuff at kde-workspace
[16:59]  * shadeslayer afk
[17:17] <sgclark> Anyone available to review and upload kio in bzr? please
[17:21] <kubotu> ::runtime-bugs:: [1317199] Can not add printers in Kubuntu 14.04 @ https://bugs.launchpad.net/bugs/1317199 (by rmdegennaro)
[18:11] <shadeslayer> sigh http://paste.kde.org/pflfphlwr
[18:11] <shadeslayer> going mental with kde-workspace I am
[18:15] <crissi> hello. after upgrading from 12.04 to 14.04 the plasma network manager doesnt show any wireless networks. wifi cant enabled there, even the wifi device is there and works on terminal
[18:15] <crissi> any hints?
[18:17] <shadeslayer> crissi: not really, I'd report a bug upstream
[18:18] <shadeslayer> on bugs.kde.org
[18:25] <ScottK> shadeslayer: Probably make sure he has the right NM widget installed first.
[18:25] <shadeslayer> crissi: ^^
[18:25] <crissi> there is only one
[18:26] <crissi> plasma-widget-networkmanagement (<IP_ADDRESS>-0ubuntu1)
[18:27] <ScottK> How about plasma-nm
[18:27] <shadeslayer> ^^
[18:27] <shadeslayer> though I doubt you can have one but not the other
[18:27] <crissi> plasma-nm                                 <IP_ADDRESS>-0ubuntu
[18:29] <crissi> other things i can examine?
[18:33] <yofel> crissi: 'rfkill list' shows nothing as blocked?
[18:33] <crissi> rfkill list all
[18:34] <crissi> 1: phy0: Wireless LAN
[18:34] <crissi>         Soft blocked: no
[18:34] <crissi>         Hard blocked: no
[18:34]  * yofel notices the backlog in #kubuntu
[18:34] <yofel> hm
[18:37] <lordievader> crissi: Is the wireless nic configured in /etc/network/interfaces?
[18:38] <crissi> no
[18:41] <shadeslayer> could someone review kde-workspace?
[18:41] <shadeslayer> revs 885/886/887
[18:54] <cyphermox> crissi: nmcli nm
[18:55] <crissi> nmcli nm
[18:55] <crissi> RUNNING         STATE           WIFI-HARDWARE   WIFI       WWAN-HARDWARE   WWAN
[18:55] <crissi> running         connected       enabled         enabled    enabled         disabled
[18:55] <cyphermox> well, that's not it
[18:55] <cyphermox> crissi: nmcli dev wifi (but please don't paste that, could be a lot of lines of text)
[18:55] <cyphermox> that will list wireless networks in range that NM knows about
[18:56] <cyphermox> if it lists stuff, you know it's the applet's problem
[18:56] <crissi> yes it found networks
[18:57] <cyphermox> what wireless device do you use? Intel, broadcom, atheros? something else?
[18:57] <crissi> intel: iwlwifi
[18:57] <cyphermox> then again, that shouldn't matter to the applet
[19:12] <yofel> shadeslayer: why the changes of X-Debian-ABI for a couple packages?
[19:12] <yofel> also, ktouchpadenabler needs to break/replace the current version of kde-workspace-bin (kded_ktouchpadenabler.so)
[19:12] <yofel> why are you using kdmrc_defaults.diff and not kdmrc_defaults_kubuntu.diff?
[19:12] <yofel> the new breaks/replaces in plasma-dataengines-workspace are missing a  ~ at the end
[19:12] <yofel> and what the hell are .acc files @_@
[19:12] <yofel> otherwise a good job I think
[21:55] <shadeslayer> yofel: I thought about just reducing the delta, doesn't hurt us
[21:55] <shadeslayer> I thought I did break/replace stuff with ktouchpadenabler, if not, I can add it tomorrow
[21:56]  * yofel doesn't see the point in using symbol tables from debian. Not very sensible unless you have the exact same build setup...
[21:58] <shadeslayer> *nod*
[21:59] <Etriaph> What was the kubuntu-desktop security update about today?  Or is this better for #kubuntu
[22:01] <shadeslayer> yofel: yeah, I realized that after pushing, was thinking of reverting it on my way home :P
[22:22] <ScottK> Etriaph: It wasn't a security update.
[22:23] <ScottK> There may have been security updates in the same batch of updates, but the kubuntu-desktop one wasn't.
[22:23] <Etriaph> Oh, updater called it that is all.
[22:25] <shadeslayer> yofel: btw is there a difference between kdmrc_defaults_kubuntu.diff and kdmrc_defaults.diff ?
[22:25] <shadeslayer> maybe I missed something
[22:26] <yofel> there was the last time I merged, can't remember what it was though
[22:27]  * shadeslayer checks
[22:30] <shadeslayer> yofel: http://paste.ubuntu.com/7412930/
[22:30] <shadeslayer> ahh
[22:31] <shadeslayer> strings are slightly different
[22:31]  * shadeslayer makes a note to fix it tomorrow, off to sleep now
[23:30] <sgclark> Riddell: kdeclarative ready


[00:00] <bkerensa> dscassel: Thats a good question ;) I have never seen anything that says it is "Required" although it is using as a indicator for approval
[00:01] <bkerensa> dscassel: Technically all teams are encouraged to do them.... https://wiki.ubuntu.com/LoCoCouncil/TeamReports
[07:03] <dholbach> good morning
[07:23] <YoBoY> dscassel, don't see them as a requirement but as a good way to see what your loco is doing each month. It's helpfull to new commers and others who want to know what a team have done so far.
[07:23] <YoBoY> good morning here :)


[00:10] <RAOF> Hm. Dear Mir: I'm *pretty* sure that I don't want to drive my external panel at 23.91Hz.
[00:15] <kgunn> :))
[00:24] <RAOF> Sweet. That seems to work.
[00:34]  * robert_ancell -> lunch
[00:47] <RAOF> robert_ancell: Please test xorg-server_<IP_ADDRESS>1-2ubuntu3+xmirMM4 once it's built; that works for me.
[01:36] <robert_ancell> RAOF, will do
[01:45] <duflu> robert_ancell: Is it still qa-testing to use?
[01:45] <robert_ancell> duflu, yes
[01:46] <duflu> RAOF: Is there a tool for visually tweaking colour profiles?
[01:46] <RAOF> duflu: Not to my knowledge.
[01:48] <RAOF> Also worth noting that u-s-c won't apply any colour profile you might set, anyway.
[01:49] <duflu> RAOF: Yeah, wasn't for any test machine. Was just wondering in general.
[01:55] <duflu> RAOF: Is it possible to go above D65? I found profiles from Lenovo which claim to, but provided no visual change (not using Mir)
[01:57] <RAOF> duflu: As the target colour temperature? Sure.
[01:59]  * RAOF 's old CRT had two colour temperature presets: 6500K & 9000K
[02:00] <duflu> RAOF: Yeah, this particular display just seems to not change anything for the Lenovo profiles which claim to be higher
[02:00] <RAOF> Possibly it's not actually a display-correction capable profile?
[02:01] <RAOF> Stupid bloody flaky xvfb-run test!
[02:01] <duflu> RAOF: Fair point. Copied from Windows drivers...
[02:02] <RAOF> duflu, robert_ancell: amd64 packages have built in qa-testing, but you'll need to force install them as the i386 build that produces xserver-common has hung again.
[02:02] <robert_ancell> RAOF, yeah, watching that
[02:02] <olli> RAOF, is there something worth giving a shot?
[02:02] <robert_ancell> RAOF, did you just restart i386?
[02:02] <olli> or are you still building the xorg-server
[02:02] <RAOF> robert_ancell: I did indeed.
[02:02] <RAOF> olli: Yeah, this works for me¹
[02:03] <RAOF> ¹: Although I wasn't testing against a unity-system-compositor with multi-surface leak fix, so X rapidly became useless.
[02:03] <olli> RAOF, ok, I am about ready for bath & bedtime duty
[02:03] <olli> but will check back in ~1.5h
[02:03] <olli> exciting
[02:03] <RAOF> Everything should have built by then :)
[02:05] <kgunn> robert_ancell: RAOF ....so can't download amd64 until i386 finished either
[02:06] <robert_ancell> kgunn, you can, but you have to do it manually
[02:06] <robert_ancell> it's not published until both are built
[02:06] <robert_ancell> kgunn, i.e. click on each .deb and install them that way
[02:06] <RAOF> No, it's published, but apt will refuse to install it (as there's a strict dependency on xserver-common, which is only built by the i386 build)
[02:07] <kgunn> RAOF: right...that's what i experienced
[02:07] <kgunn> and there is no xserver-common yet
[02:07] <kgunn> scary...i am smart enough that i actually checked cache policy on boot...saw mm3 was installed, but mm4 was candidate
[02:08] <robert_ancell> RAOF, ah, that's annoying...
[02:08] <kgunn> tried to manually install then saw the complaining about common
[02:08] <robert_ancell> we really should build 'any ' packages on amd64 now
[02:08] <RAOF> kgunn: So, just downloading xserver-xorg-core, xserver-xorg-xmir .debs and dpkg --install --force-depends will work.
[02:08] <RAOF> ¹: Should ☺
[02:14] <kgunn> RAOF: mmmm...thanks...i'll just wait...would hate a false negative
[02:16] <kgunn> so curious...has anyone had any success with lttng on arm ?
[02:16] <kgunn> its installed and i can query kernel hooks...
[02:16] <kgunn> and i can create a log for mir..but it immediately throws an error for every command after that
[02:21] <robert_ancell> i386 built...
[02:31] <robert_ancell> and published!
[02:32] <RAOF> Hah. Seems like bypass might have broken it.
[02:33] <ricmm> kgunn: hey, still around?
[02:33] <kgunn> ricmm: yes
[02:33] <kgunn> RAOF: please tell me that's your crazy aussie humor :-/
[02:38] <kgunn> robert_ancell: RAOF ...i booted into X it seems
[02:39] <RAOF> kgunn: Well, on my dual-head test it ‘works’, but u-s-c only updates the display when I VT switch to it.
[02:39]  * RAOF is building the multi-surface fix branch minus bypass to see if that's a fix.
[02:40] <kgunn> hmmm....wait a minute...u-s-c not installed?
[02:40] <kgunn> oh...that's weird...updates on vt switch
[02:42] <robert_ancell> RAOF, the X package seems to have built against the system mir, not the one in the PPA - is that because the PPA is now behind the archive?
[02:42] <robert_ancell> Do PPAs not pin to themselves?
[02:42] <RAOF> robert_ancell: No, they do not.
[02:42] <robert_ancell> damn
[02:42] <kgunn> right....
[02:42] <robert_ancell> I'll update Mir, and we'll have to rebuild before main updates...
[02:43] <robert_ancell> kgunn, that  was blocking me from installing u-s-c - you probably have the same issue
[02:43] <kgunn> wait...so instead of waiting...i could try the --force-depends method right ??
[02:43] <RAOF> Oh, *that's* why it's broken!
[02:43] <robert_ancell> kgunn, maybe? It will still have built against the wrong Mir and without a stable ABI that's very dangerous
[02:44] <RAOF> Oh, actually, no, that's not it.
[02:44] <kgunn> robert_ancell used the word dangerous...i think i'll wait
[02:44] <RAOF> kgunn, robert_ancell: We *have* a stable ABI for mirclient, so it's harmless.
[02:44] <kgunn> dang it...i'm really running out of energy...
[02:44] <RAOF> We don't need to build XMir against the exact mir version.
[02:45] <robert_ancell> RAOF, oh, true. It just has a depends with a higher number than the one provided
[02:45] <robert_ancell> RAOF, what version of u-s-c are you running? The -cft one?
[02:45] <RAOF> yes
[02:46] <robert_ancell> So once we recompile Mir, we wont have to recompile X
[02:46] <RAOF> Oh, no. Sorry. Not using cft
[02:46] <RAOF> bah
[02:47] <robert_ancell> new mir uploaded...
[02:49] <kgunn> dude...how do we change the script to rid the i386 run for the time we're iterating
[02:50] <robert_ancell> I'm just asking the launchpad guys...
[02:51] <robert_ancell> previous builds indicate this will take ~45 mins
[02:51] <robert_ancell> Apparently that's the time to build all of android :)
[02:57]  * duflu wonders why apt-get upgrade wants to remove USC and xmir
[03:00] <robert_ancell> duflu, because it's built against libmirclient2 from the archive which is greater than the PPA version
[03:00] <robert_ancell> StevenK confirms it - i386 is hardcoded to be the "any" architecture so you can't drop it from a PPA
[03:00] <robert_ancell> duflu, we're rebuilding mir now..
[03:07]  * duflu now wonders why i915 is stuck around 90 wakeups/sec when compiz is less around 15
[03:08] <RAOF> The base-rate for i915 is going to be ~60Hz when there's been some form of activity.
[03:08] <duflu> And my fan/temperature is quite bad... This is with Mir though
[03:08] <duflu> *This is without Mir
[03:09] <duflu> RAOF: AFAIK, Intel will still clock down to 40Hz when it can
[03:09] <duflu> ... Just that you can't configure 40Hz modes any more. Is that intentional?
[03:12] <RAOF> duflu: Really? What monitors support a 40Hz refresh rate *and* support seamlessly changing between 40Hz and 60Hz?
[03:14] <duflu> RAOF: I haven't seen a physical 40Hz for a few years (Dell E4200 could do it). But the number of wakeups for i915 still drops to 40Hz when it can
[03:15] <RAOF> It *should* drop to 0 under conditions of no-load, but whenever output has occurred it'll pop back up to $REFRESH_RATE Hz as the vblank interrupts keep coming.
[03:16] <duflu> I remember that used to be a *feature* of Intel graphics, dynamically switching between 40/60Hz and Ubuntu did it no problem. Maybe intel dropped it in more recent chips
[03:17] <RAOF> Deliberately missing every third vsync?
[03:17] <duflu> RAOF: Something like that. Showed up as a mode you could fix in xrandr too
[03:19] <duflu> It appears i915 staying at 90 wakeups/sec is side-effect of multiple monitors. User processes are behaving though
[03:20] <RAOF> Oh, yeah. It'll be vsync interrupts.
[03:24] <robert_ancell> duflu, you got revision 1000!
[03:24] <duflu> Woo, I win, nothing
[03:26] <duflu> Weird, i915 seems to scale in multiples of 40/45 wakeups per second.
[03:28] <olli> is there anything to test
[03:34] <olli> RAOF, robert_ancell?
[03:34] <robert_ancell> olli, in progress..
[03:34] <olli> oki
[03:34] <robert_ancell> olli, just need u-s-c to rebuild
[03:35] <olli> ok, I guess I will bisect my kernel then for a while ;)
[03:35] <olli> also fun
[03:46] <kgunn> for the love of it all...even the publishing takes an eternity
[03:51] <RAOF> Hm. So, r985 + the client buffer tracking fix gets me something that's mostly working, but needs some damage region fixing in xmir
[03:54] <robert_ancell> published
[03:59] <duflu> Cool. Except I'll go to lunch first.
[04:01] <kgunn> rebooting...
[04:02] <robert_ancell> brb
[04:04] <kgunn> so i chose to hotplug, vga cable...looks like x crashed
[04:04] <kgunn> when i disconnected, it punted me back out ot the greeter
[04:10] <robert_ancell> hmm, not so good. Works fine without the second monitor, then flickers, mirrors for a bit (in greeter) then everything crashes
[04:11] <kgunn> hdmi - same computer...ends up with nothing on second...but "low gfx mode" on built-in
[04:11] <kgunn> altho...it has already crashed once...i should reboot to be fair
[04:13] <robert_ancell> this is VGA for me
[04:16] <kgunn> ok...i rebooted for hdmi, it does exact same thing as vga....which is 1st & second screen flicker & shows up (w/ purple feild...no unity....but a mouse cursor on both)
[04:17] <kgunn> and when i diconnect (both hdmi/vga) it flickers...punts me out to greeter
[04:17] <robert_ancell> RAOF, does this sound like the damage region issue you mentioned earlier?
[04:17] <RAOF> No; that didn't crash for me, it just only updated the display on VT switch.
[04:18] <robert_ancell> RAOF, it seems to be updating fine here, but unstable
[04:18] <RAOF> So, unity-greeter would come up and I'd see purple on each monitor ('cause that's the first thing that unity-greeter draws)
[04:20] <RAOF> Seems to work fine here in cloned mode, but not draw properly in non-cloned mode.
[04:20] <RAOF> And, yeah, a bit unstable on xrandr changes.
[04:22] <kgunn> RAOF: robert_ancell ...how to set mirror mode before connecting (at least the setting ui is greyed out until you connect the monitor)
[04:22] <RAOF> I started with both monitors attached :)
[04:23] <RAOF> So that defaults to clone on X startup.
[04:23] <robert_ancell> kgunn, X has a default that is hard-coded / set in the X config
[04:23] <robert_ancell> then an XRANDR client (e.g. gnome-setting-daemon) picks up the event and applies what it wants
[04:24] <kgunn> hmmm - i just booted with both monitors connected and it showed two purple fields/with 2 mice....but no ui after greeter login
[04:24] <kgunn> greeter login cloned just fine
[04:25] <robert_ancell> kgunn, no glitches while cloning?
[04:25] <kgunn> i should say my second screen is larger than my built in....
[04:26] <kgunn> don't know if that makes a diff
[04:26] <robert_ancell> I got flickering, especially in the top of the built-in and corruption on the bottom of the external
[04:26] <robert_ancell> same setup
[04:26] <kgunn> robert_ancell: i can't see a ui no matter how i connect the 2nd monitor vga/hdmi/boot/post-boot
[04:26] <robert_ancell> kgunn, oh, just purple?
[04:26] <kgunn> yep
[04:26] <robert_ancell> RAOF, what info can we get for debugging?
[04:27] <RAOF> kgunn: *That's* what I was seeing, and I'm pretty sure that's related to bypass.
[04:27] <RAOF> kgunn: If you get to all purple, VT switch away, then VT switch back, you should be able to see unity-greeter.
[04:28] <RAOF> duflu: What would be causing that ^^^
[04:28] <kgunn> RAOF: freaky....yes
[04:28] <duflu> RAOF: Never seen that
[04:28] <duflu> robert_ancell: What GPU?
[04:29] <RAOF> duflu: How much bypass testing did you do with multi-surface clients?
[04:29] <robert_ancell> duflu, Intel Corporation Core Processor Integrated Graphics Controller (rev 18)
[04:29]  * RAOF is likewise intel.
[04:29] <duflu> RAOF: None. We only have one multi-surface client and it doesn't trigger bypass. But shouldn't matter.
[04:29] <RAOF> We now have a second multi-surface client )
[04:29] <RAOF> :)
[04:29] <duflu> Yep
[04:30] <duflu> RAOF: Bypass has no visibility to clients. It only deals on a per surface basis
[04:31] <RAOF> *Something* between r985 and what's in the PPA broke updates on multi-head xmir.
[04:32] <duflu> I'm actually more concerned it sounds like no one has XMir+saucy+radeon/nouveau on a single machine. I know I don't.
[04:32] <kgunn> i don't get flickering...it like updates a frame or 2...then appears frozen (but its actually rendering...somwhere)
[04:33] <kgunn> if i keep vt switching back and forth....i see i've moved the mouse or launched an app....in the steady state i expect it
[04:33] <duflu> kgunn: What GPU?
[04:34] <RAOF> kgunn: Yeah. X clients are rendering, but it's not getting displayed by something in the XMir/unity-system-compositor stack.
[04:37] <duflu> Eventually my USC died with exception: Output has not associated crts
[04:37] <duflu> *crtc
[04:37] <duflu> That's after getting nowhere on login
[04:37] <kgunn> duflu: intel
[04:38] <robert_ancell> RAOF, should we expect improvement in MM5?
[04:38] <kgunn> this is freaky...i got youtube up...seeing if i can start a video
[04:38] <duflu> kgunn: If you can recover without rebooting or ssh in then check /var/log/lightdm/unity-system-compositor.log
[04:39] <robert_ancell> duflu, I have a fix to keep the old log on trunk, just don't want to make a lightdm release on a Friday...
[04:39] <kgunn> duflu: looks normal...dm_connection_start, set_active_session '0', set_active_session
[04:39] <RAOF> robert_ancell: Yes; it might be more stable, and in conjunction with the new xf86-video-intel it should render *both* heads in a non-cloned setup.
[04:40] <robert_ancell> RAOF, there's a new -intel MM4?
[04:42] <kgunn> wild...i got a youtube video playing (well i hear the audio...but obviously not playing on screen)
[04:42] <kgunn> ooo, and can vt switch really fast for stop motion video :)
[04:42] <RAOF> :)
[04:42] <RAOF> robert_ancell: Indeed there is.
[04:43] <RAOF> kgunn: Yeah. The problem is in the copying to Mir, not in the X client rendering.
[04:44] <kgunn> RAOF: so you gonna kick off the intel mm5 ?
[04:44] <kgunn> i'll stay up for one more round if so....but after that i'm cooked
[04:45] <duflu> That's annoying. We use the same exception message in multiple locations so I can't tell what really failed
[04:47] <duflu> robert_ancell: I'm going to try and do some more integration testing of bypass + MM. Where is the new MM stuff not on trunk yet? Any?
[04:47] <robert_ancell> duflu, it's the stuff in the ppa basically
[04:48] <duflu> robert_ancell: Yeah, but is there any MM functionality we're using not in lp:mir yet?
[04:48] <robert_ancell> duflu, the only unmerged branch is lp:~raof/mir/fix-multi-surface-buffer-tracking
[04:48] <duflu> ... there's none awaiting review
[04:48] <robert_ancell> it fails the tests on android
[04:48] <robert_ancell> but we don't care about that for this testng
[04:53] <duflu> OK, I'm going to take XMir out of the equation and try some integration testing of the constituent branches not on trunk yet
[04:56] <RAOF> https://code.launchpad.net/~raof/mir/fix-multi-surface-buffer-tracking/+merge/181259 is known-good
[04:57] <RAOF> In the sense that this is what I'm running now, and it fails in ways that should be fixed in xserver MM6 & xf86-video-intel MM4
[05:00] <duflu> RAOF: Yeah feels like integration issues, where each branch works fine by itself
[05:01] <RAOF> Entirely plausible.
[05:04] <duflu> If nothing else, bug 1211700 still scares me. And I do know that bypass makes that one worse.
[05:06] <tvoss_> good morning
[05:08] <duflu> Morning tvoss_
[05:17] <duflu> Note to self: Don't trust benchmarks while building on all cores
[05:17] <tvoss_> duflu, :)
[05:19] <robert_ancell> RAOF, are you building these changes locally before uploading? :)
[05:19] <RAOF> robert_ancell: I am now :)
[05:19]  * robert_ancell reads the debian/changelog entries
[05:19] <RAOF> The last couple were "obvious" changes :)
[05:23] <robert_ancell> btw the Mir build in ppa:mir-team/qa-testing2 is merged with trunk, because we need the version number bumped to be greater than archive. Do you think that would cause any issues?
[05:23] <robert_ancell> RAOF, ^
[05:25] <robert_ancell> I've got to do family jobs and dinner now so will keep popping back here to update builds and test things
[05:26] <duflu> Having per-session(client) monitor layouts is very confusing when I Alt-tab between clients :)
[05:26] <duflu> I Alt+Tab to a client and it's not there any more, it moves!
[05:27] <robert_ancell> duflu, heh, I think that's only meant to be allowed by the shell when they're full-screen
[05:27] <duflu> robert_ancell: Or rather "when the session is a login". We don't distinguish between client as a session, and login as a session
[05:28] <RAOF> robert_ancell: I don't think that will cause issues.
[05:35] <RAOF> Lets see if this does indeed give me multiple outputs...
[05:46] <duflu> I suspect Mir's hyper-sensitivity to the DRM state could become a problem. The slightest imperfection and it will die with an exception. We have managed to avoid such issues till now, but I wonder if XMir changing output configurations dynamically could affect that
[05:55] <RAOF> Woot.
[05:55] <duflu> ?
[05:55] <RAOF> Ok, so this mostly works; unity just doesnt' get the memon that the display config changed.
[05:56] <RAOF> Also there's some weird off-by-one-frame problem in the bit of the 2nd monitor that's not covered by both monitors.
[05:58]  * duflu thinks mir_demo_server_shell needs some key combos for manual testing of layout changes
[05:58] <RAOF> Yeah, that'd be fun.
[05:59] <duflu> RAOF: Merging both our branches with trunk and using two monitors works flawlessly. XMir must be doing something we don't or can't test yet. See previous comment
[06:00] <RAOF> Two fullscreen surfaces from one client?
[06:01] <duflu> RAOF: I shall hack together some testing for that
[06:02] <RAOF> I fiddled with mir_demo_client_accelerated to do that  recently. The patch should still be in backscroll
[06:04] <robert_ancell> RAOF, ppa:mir-team/qa-testing2 has mir+u-s-c ready - copy over the X packages when ready
[06:06] <duflu> RAOF: Actually I'm seeing a new regression with multi-win clients using plain old trunk :/
[06:07] <RAOF> duflu: :(
[06:08] <duflu> RAOF: Does demo_client_multiwin work for you any more?
[06:11] <kgunn> robert_ancell: RAOF amd64 xorg-intel failed due to wanting a new xmir...so i restarted it (guessing it was going out of order)
[06:12] <kgunn> i loaded the usc/mir on top of the last xorg....clone was ok-ish (still got punted to greeter)....and extended desktop was gnarly (eventual punt to greeter)
[06:13] <kgunn> i'm gonna head of to sleep...good luck guys
[06:13] <duflu> kgunn: OK bye
[06:13] <duflu> RAOF: There looks like a related issue on trunk, before either of the new branches: https://bugs.launchpad.net/mir/+bug/1215754
[06:28] <RAOF> duflu: Yup, confirmed.
[06:34] <duflu> Almost bisected...
[06:43] <duflu> RAOF: Bisected. Could bug 1215754 be relevant?
[06:44]  * duflu is presently rebuilding on a revision that *works* to try bypass with multi-surface clients
[06:46] <RAOF> duflu: Maybe? The symptoms are quite different.
[06:46]  * duflu is not aware of any symptoms with the PPA other than USC logging runtime_errors thrown about DRM
[06:47] <arsson> My both saucy installations is broke after todays updates, anyone else?
[06:47] <duflu> arsson: With PPAs or vanilla?
[06:47] <RAOF> v
[06:48]  * duflu goes back to no-PPAs for a sanity check of sauncy
[06:48] <duflu> *saucy
[06:49] <arsson> duflu: well i was having QA-testing on another ubuntu
[06:49] <duflu> arsson: Yes qa-testing is broken
[06:55] <arsson> But what happens to the other? There i was having xorg edgers, but i don't remember if it was enabled because i just needed that to take nvidia-325 driver.
[07:00] <dholbach> good morning
[07:10] <robert_ancell> RAOF, qa-testing2 is good to go now?
[07:10] <robert_ancell> RAOF, though I notice mir got out of date at some point
[07:14] <tvoss_> robert_ancell, which launchpad branch should I build?
[07:14] <robert_ancell> tvoss_, for multi-monitor?
[07:14] <tvoss_> robert_ancell, ack
[07:14] <robert_ancell> tvoss_, lp:mir + lp:~raof/mir/fix-multi-surface-buffer-tracking merged in
[07:15] <robert_ancell> tvoss_, or just use lp:~robert-ancell/mir/multi-monitor which is just that (and what is going into the PPA)
[07:16] <tvoss_> robert_ancell, ack
[07:18] <RAOF> robert_ancell: Yeah, it's got everything in it. It's more working, but still not all the way there.
[07:19] <duflu> OK, I think I might have found a bypass bug. But only reproducable with software surfaces, and lp:mir <=990 (because 991 and later is broken for other reasons)
[07:20] <duflu> RAOF: What's the pixelformat of XMir?
[07:20] <RAOF> rgbx_8888
[07:20] <RAOF> Or some permutation of that.
[07:27] <duflu> RAOF: How does XMir choose it? Or hardcoded?
[07:27] <RAOF> Hardcoded.
[07:28] <RAOF> It should expose the available formats to the XMir driver and then have that choose, but for the moment it's hardcoded.
[07:37] <RAOF> Aha!
[07:37] <RAOF> (Maybe)
[07:48]  * RAOF is the man who Creates all the Pixmaps!
[08:08] <duflu> Too many ideas, no time left.
[08:08] <asac> hi!
[08:09] <asac> so i am using unity-system-compository/xmir
[08:09] <asac> and it works great :)
[08:09] <asac> however, i have my x220 in a dock with external monitor and the resolution is not correct
[08:09] <asac> can i force this thing to use 1080p?
[08:11] <robert_ancell> asac, not yet, we're just testing multimonitor support
[08:12] <asac> robert_ancell: yeah... thought i might be able to force this thing somehow to take the resolution from this screen
[08:12] <asac> rather than automagic
[08:13] <robert_ancell> asac, at the moment it just uses the native resolution of the primary monitor
[08:13] <asac> yeah thats what i experience
[08:13] <asac> there is no brute-force way?
[08:13] <asac> :)
[08:13] <asac> no trick?
[08:13] <asac> :-P
[08:14] <robert_ancell> asac, the trick is to apt-get source, add support and recompile :)
[08:15] <robert_ancell> brb
[08:15] <asac> sounds eaasy
[08:15]  * asac doesa that
[08:16] <asac> wonder if thats the xorg mir thing or the compositor
[08:16] <asac> guess the former
[08:23] <robert_ancell> RAOF, I'm getting the same behaviour in ppa:mir-team/ppa-testing2 as I was in ppa:mir-team/ppa-testing
[08:27] <alan_g> ricmm: re session_lifecycle - you seem to have incorporated reverting recent changes into the MP.
[09:05] <RAOF> robert_ancell: Which behaviour was that again?
[09:16] <robert_ancell> RAOF, flickering, corruption on second screen
[09:16] <robert_ancell> RAOF, also, it appears unity crashes out when logging in
[09:39] <RAOF> robert_ancell: Ah, that's likely to be my "acutally resize the screen pixmap" bug that I'm fixing now.
[09:40] <RAOF> In other news: I've said this before, but ALWAYS #include <xorg-config.h> IN YOUR FILES, LEST YOUR STRUCTURES MAGICALLY HAVE A DIFFERENT LAYOUT THAN YOU EXPECT
[09:47] <pete-woods> tvoss: hi, do you have any time today to talk about the music hub / service? I've been asked to hook the sound indicator up to it
[09:47] <tvoss> pete-woods, sure, let me grab coffee real quick
[09:50] <pete-woods> cool
[10:00] <tvoss> pete-woods, can you open a hangout?
[10:02] <pete-woods> tvoss:sure
[10:02] <tvoss> pete-woods, thx
[10:03] <pete-woods> tvoss: https://plus.google.com/hangouts/_/453d38c0debd30d880901eef7114cd0241ef2f8e?authuser=1&hl=en
[10:14] <robert_ancell> RAOF, Will MM8 come in the next half hour or so?
[10:27] <robert_ancell> ok, my battery is telling me to call it a night. See you tomorrow
[10:28] <RAOF> robert_ancell: Should do.
[10:28] <RAOF> robert_ancell: 'gnight.
[10:40] <ricmm> alan_g: not sure what happened there, pushing fixed branch in a sec
[10:40] <ricmm> my bad
[10:42] <alan_g> ricmm: np
[10:47] <ricmm> alan_g: seems to be fine now
[10:47] <alan_g> ricmm: I will have another look...
[10:48] <ricmm> thanks
[12:05] <kgunn> RAOF hey...so will MM8 be worthy ? or is MM7 already worthy?
[12:07] <tvoss> kgunn, nope, better, but there is a stray Damage event killing us potentially
[12:08] <kgunn> updating now...i'm supposing we get punted to the greeter?
[12:09] <tvoss> kgunn, on monitor connect, yes
[12:24] <ricmm> alan_g|lunch: MR updated, last comment I dont think it warrants a change
[12:24] <ricmm> its just a trigger for the communication, which is what I'm testing
[12:24] <ricmm> and it guarantees arrival when expected if done that way
[12:27]  * ricmm coffee
[12:59] <ricmm> alan_g|lunch: went ahead and changed it too
[13:05] <alan_g> ricmm: ok
[13:39] <ricmm> alan_g: thanks for approving
[13:39] <ricmm> last jenkins just ran for the final rev
[13:39] <ricmm> if you want to top-approve at some point
[13:39]  * ricmm off to the doc
[13:39] <alan_g> ricmm: sure - but I like to give other team members a chance to review first
[14:58] <tvoss> racarr, you around?
[15:10] <tvoss> alan_g, I'm inclined to approve ricmm's mp
[15:11] <alan_g> tvoss: too late - I already did
[15:11] <tvoss> alan_g, ah :)
[15:19] <alan_g> ricmm: your MP failed to land - looks like a merge conflict
[15:22] <alan_g> tvoss: we were sabotaged by racarr and ricmm both adding an enum at the same place in the file
[15:22] <tvoss> alan_g, \o/
[15:26] <ricmm> sabotages
[15:26] <ricmm> :(
[15:29] <ricmm> alan_g: ok, conflict solved and pushed
[15:31] <alan_g> ricmm: top approved
[15:31] <ricmm> thanks
[15:32] <alan_g> yw
[16:38] <ricmm> alan_g: still around? same branch from robert added a test that was missing a method on my modified event sink
[16:38] <ricmm> so, need to top approve again :(
[16:38] <alan_g> ricmm: you've updated?
[16:39] <ricmm> yes
[16:39] <ricmm> test_surface.cpp builds fine now
[16:40] <alan_g> ricmm: top approved
[16:40] <ricmm> cheers
[16:52] <racarr> tvoss: Pong?
[17:54] <racarr> kgunn: So, DPMS coming back on still isn't cracking
[17:54] <racarr> talked about it with robert_ancell yesterday, and made the plan to land the API changes, etc
[17:55] <racarr> so we can update XMir
[17:55] <racarr> and finish the GBM impl as a bug
[17:55] <racarr> Make sense?
[18:18] <kgunn> racarr: so...does that mean android is happy? but gbm "no workie" ?
[18:18] <kgunn> racarr: if so, yes, plan makes sense
[18:19] <racarr> kgunn: No android isn't happy either
[18:19] <racarr> becuse android doesn't have display configuration yet
[18:19] <racarr> the deal is the clients can happily set DPMS but nothing happens yet :/
[18:19] <kgunn> racarr: ok...so this is simply about updating needed api's
[18:20] <racarr> yes
[18:20] <kgunn> racarr: makes sense....who will this break ? e.g. do we need to shout it out ?
[18:20] <racarr> Yeah mirclient API
[18:20] <racarr> I bumped ABI
[18:20] <racarr> :(
[18:21] <racarr> I wonder if its worth adding some padding to some of the structs at the same time
[18:21] <racarr> so i we need to change display configuration again can do it without breaking ABI
[19:09] <ricmm> https://launchpadlibrarian.net/148264842/buildlog_ubuntu-saucy-i386.mir_0.0.9%2B13.10.20130823.2-0ubuntu1_FAILEDTOBUILD.txt.gz
[19:09] <ricmm> :( ??
[19:42] <mlankhorst> racarr: .. or just a version in the struct :p
[19:44] <tvoss> ricmm, flaky, try again
[19:44] <ricmm> yea, already done
[19:47] <racarr> kgunn: Hey we got lucky for once!
[19:47] <racarr> I finally got to the stress test
[19:47] <racarr> so I decided to test if it still crashed in the same way
[19:47] <racarr> and just ran it for about 5 minutes while moving the mouse around and no crash
[19:47] <racarr> thomi: ^
[19:47] <racarr> When was the last time you tried XD
[19:49] <racarr> I think the create_surface_for changes may have made it so that the invalid surface exception you could get out of focus/input from the get_surface 'race'
[19:49] <racarr> is handled non fatally now
[19:49] <racarr> the only thing is its notabbly slower than it was when I had the test running a few weeks ago
[19:49] <racarr> i.e. I used to be able to run it and move the cursor with no noticeable lag
[19:49] <racarr> now there is definitely lag
[19:51] <racarr> seems too good to be true
[19:59] <tvoss> racarr, that there is a lag?
[20:00] <racarr> tvoss: No that the stress test fixed itself
[20:01] <racarr> and I don't have to
[20:01] <racarr> stress about it
[20:01] <tvoss> racarr, well, if there is a lag, we might want to investigate where :)
[20:02] <racarr> True
[20:02] <racarr> but its still nice to have part of it done
[20:04] <racarr> Going to let it run for the full 10 minutes no
[20:04] <tvoss> racarr, yeah, was just about to say that it's nice that it is working
[20:07] <racarr> tvoss: Except it was too good to be true
[20:07] <racarr> and almost immediately brought my hole system down this time
[20:07] <racarr> :p
[20:07] <racarr> back to the fun
[20:08] <tvoss> racarr, enjoy :)
[20:12] <racarr> tvoss: definitely :p
[20:18] <racarr> SessionMediator should only have a weak reference
[20:18] <racarr> to session
[20:18] <racarr> if its going to use
[20:18] <racarr> close/open session
[20:18] <racarr> and the session container is going to have ownership
[20:18] <racarr> can fix one of the races this way but I dont even know if this one is still exhibiting because I can't get backtraces or recover my system anymore
[20:21] <racarr> strange, that fixes the lag
[20:21] <racarr> maybe the lag was a bunch of handled exceptions
[20:21] <racarr> frontend handles some exceptions silently
[20:22] <racarr> Giving it a ten minute run again cross your fingers
[20:26] <kgunn> fingers crossed
[20:42] <racarr> Lag is intermittent
[20:42] <racarr> got two ten minute runs
[20:42] <racarr> with no crash though
[20:46] <racarr> ok another ten minute stress brb
[20:58] <racarr> :)
[21:07] <robert_ancell> RAOF, let me know when you're online
[21:16] <racarr> robert_ancell: So if the stress test is fixed (I think it is!) is there something I should be doing more important than trying to make DPMS impl ork?
[21:17] <robert_ancell> racarr, I think DPMS is a good goal
[21:18] <racarr> Ok ill work on it today, ill be around tomorrow too, and write up a hand over email/potentially finish it depending on how things go
[21:18] <racarr> sunday morning am gone though
[23:35] <RAOF> Alright. Where's that damageptr going wrong.
[23:35] <RAOF> robert_ancell: Good morning.
[23:36] <robert_ancell> RAOF, hi
[23:37] <RAOF> You were up early!
[23:38] <robert_ancell> normal time
[23:38] <RAOF> Or are you 2 hours ahead of me?
[23:38] <robert_ancell> yes
[23:39]  * RAOF always forgets that
[23:39] <robert_ancell> there's a merge conflict with  lp:~raof/mir/fix-multi-surface-buffer-tracking - I've fixed it in lp:~robert-ancell/mir/multi-monitor but you probably want to update your branch
[23:39] <RAOF> Urgh, ok.
[23:39] <robert_ancell> some whitespace changes around your change
[23:40] <RAOF> Will do while this server builds with -DDAMAGE_VALIDATE_ENABLE
[23:40] <robert_ancell> RAOF, also, I tried testing by running mir_demo_server then X -mir and I can reproduce the issues (flickering, X crash when plugging in monitor)
[23:41] <RAOF> There are two problems there; one mispassed pointer and then the stray damageptr
[23:41] <robert_ancell> RAOF, is there an easy way to build your branch locally so I can try it? Does it need all of debian/patches/*
[23:41] <robert_ancell> fixed in MM8?
[23:42] <RAOF> robert_ancell: I've pushed qa-testing-ppa to github.com/RAOF/xserver
[23:42] <robert_ancell> cool
[23:42] <robert_ancell> RAOF, also tvoss said he still had issues with MM8
[23:42] <RAOF> Yeah, the mispassed pointer should be fixed in MM8. The damage issue is still pending.
[23:48] <robert_ancell> X has a scary number of compile warnings
[23:50] <RAOF> It comes of being a codebase that still contains some honest-to-got K&R C
[23:58] <robert_ancell> RAOF, btw, did you find time to write that blog post?
[23:58] <RAOF> No
[23:58] <robert_ancell> k


[00:42] <breakpoint> hello
[00:43] <breakpoint> whats up
[12:26] <qswz> Can someone explain me how it's possible that debian lxqt is 2.2G https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/ while lubuntu lxqt is 1.6G http://cdimage.ubuntu.com/lubuntu/releases/focal/release/
 🤔
[18:54] <Kamilion> qswz: debian ISOs usually contain a lot more packages unrelated to the desktop environment choice.
[18:55] <Kamilion> Also, my ISO is only 1.3G after removing libreoffice.
[18:56] <Kamilion> if you're curious how it breaks down, look at the /pool/ folder on both isos. Lubuntu's will be almost empty, while debian's will be the bulk of the ISO contents.
[19:00] <qswz> Kamilion: ah thanks for the answer, ok
[19:00] <Kamilion> Sure.
[19:01] <Kamilion> it's more to do with how the casper live scripts work
[19:01] <Kamilion> we ship a rather large squashfs that we unpack over the installation root; and then do a little bit of package removal
[19:02] <Kamilion> while debianinstaller tends to prefer unpacking individual packages into an installation root.
[19:02] <qswz> ah so lubuntu iso is a biy compressed too
[19:02] <qswz> bit*
[19:02] <Kamilion> as a result, we don't keep a large package pool on the iso itself
[19:03] <Kamilion> only like ~40MBish right now, stuff like grub-efi and a couple others
[19:03] <qswz> I see ok
[19:03] <Kamilion> not just a bit compressed
[19:03] <Kamilion> a LOT compressed. ~4.8GB -> 1.5GB squashfs
[19:04] <qswz> debian iso is also compressed, but less efficiently if I understand you
[19:04] <Kamilion> different method
[19:04] <qswz> yea
[19:04] <Kamilion> they're mostly .xz compressed .deb files
[19:04] <Kamilion> squashfs can do 'deduplication' to some degree.
[19:05] <Kamilion> "hey, there's three copies of this file called initramfs; I'm just going to make them all point to the same clusters."
[19:06] <Kamilion> plus the patches to mkisofs that will do the same thing (link identical files to the same clusters_
[19:12] <qswz> yea, and thanks to all guys working on lxqt/lubuntu, great stuff
 @qswz [<qswz> yea, and thanks to all guys working on lxqt/lubuntu, great stuff], +1
[19:33] <hex_> Hello
[19:47] <qswz> yw :)
[20:18] <akem> I got the system frozen few times on my other machine, mouse frozen not responding, keyboard the same, what can i look for after reboot?
[20:19] <akem> I think this started after last update. :X
[22:31] <M--uismojvkinbis> Does tiling work in Lunbuntu? I never got it to work in 19.10 now on 20.04 and same
[22:31] <M--uismojvkinbis> Lubuntu*
[22:32] <wxl> use a tiling window manager and it works great
[23:07] <M--uismojvkinbis> I figure I could do that. Wasn't sure if it was implemented at all
[23:08] <M--uismojvkinbis> in the base image
[23:11] <wxl> nope
[23:11] <wxl> openbox is not a tiling window manager


[05:46] <Dmitrii-Sh> o/
[06:16] <jam> Dmitrii-Sh, morning. (I'm not really here, but there were comments left by someone on https://github.com/canonical/operator/pull/212)
[06:17] <Dmitrii-Sh> jam: thanks, just responded there
[06:18] <Dmitrii-Sh> I think extending add_relation by allowing it to accept initial data would be a good way to move some checks away from update_relation_data and make it less overloaded than it is right now
[06:19] <jam> Dmitrii-Sh, maybe we have both options written out and can compare the tests that result and what we feel is easier to understand
[06:20] <Dmitrii-Sh> jam: ok, I'll make a branch locally so that I have the current implementation preserved
[06:20] <Dmitrii-Sh> and see what I can come up with
[06:21] <jam> I had initially done the initial_app_data form, and then was trying to streamline and saw that you could use update for self. but I wasn't convinced which way would be better.
[06:24] <Dmitrii-Sh> jam: also, if I look at this signature `def add_relation(self, app, *, initial_unit_data=None, initial_app_data=None, remote_app_data=None):`, it gets confusing on which argument is for which purpose for peer relations
[06:24] <jam> app is redundant for peer but the rest isn't
[06:25] <jam> I would say for peers we just make one of them illegal to set
[06:26] <Dmitrii-Sh> hmm, there is a case where our unit comes app and there's already something in peer app relation data
[06:29] <Dmitrii-Sh> just thinking about a later addition of `relation-created` events - add_relation should trigger "relation-created" for our unit but during that there may already be some app relation data present for that relation-id and a "remote app" (which may be local on a peer rel)
[06:31] <Dmitrii-Sh> I think it should be illegal to use the `remote_app_data` argument for peer relations - I am going to raise an exception if that happens and see how it looks like
[06:39] <t0mb0> Hi I've been struggling with some issues with actions. It seems every time I tried to retrieve some data from StorageState with my action I keep getting the initial value of my variable, however this variable gets populated with some data as part of the configuration process and I can confirm the variable is set. It seems that when I call my action it is referencing a different state object?? https://pastebin.canonical.com/p/jWT6bDcRVR/
[06:39] <t0mb0> am I missing something ^^ or should I raise a bug
[06:39] <jam> t0mb0, can you link the code?
[06:40] <t0mb0> jam, https://pastebin.canonical.com/p/7BnhqRxDfG/
[06:41] <jam> t0mb0, so #1 i would suggest moving from an on_start setting all the attributes to a 'set_default()' call in __init__
[06:42] <jam> t0mb0, the on_start doing apt-get stuff is fine
[06:42] <t0mb0> jam, I had done a set_default for in __init__ for the data i'm trying to retrieve
[06:43] <jam> t0mb0, that isn't the code you linked
[06:43] <jam> hard to debug code that isn't what I'm looking at :)
[06:43] <t0mb0> jam, yeah I know, I'm just saying it's something I've already tested
[06:43] <t0mb0> I've been trying all number of things to try and isolate the issue :P
[06:43] <t0mb0> I'll move it back to __init__ though
[06:44] <jam> t0mb0, ah, you're on k8s, right? Charms fire hooks in the Operator pod, but fire actions in the Workload pod.
[06:44] <jam> (currently)
[06:44] <jam> I believe there is a flag
[06:44] <t0mb0> :O
[06:44] <t0mb0> I am in k8s yup
[06:47] <jam> t0mb0, sigh, the flag is only in dev mode. So if you set "export JUJU_DEV_FEATURE_FLAG=juju-v3" then "juju run-action" is renamed to "juju run" and has a "juju run --operator" to run the action in the operator pod.
[06:47] <jam> t0mb0, I'd bring that up in #juju about not being able to supply --operator to 'juju run-action'
[06:49] <t0mb0> jam, does this work with microk8s juju?
[06:49] <t0mb0> I don't seem to have that flag when I export the variable there
[06:49] <jam> t0mb0, it might be a 2.8 feature, not sure.
[06:50] <jam> t0mb0, with any k8s
[06:50] <t0mb0> hmm
[06:50] <jam> t0mb0, submitted https://bugs.launchpad.net/juju/+bug/1870487 for you.
[06:52] <t0mb0> thanks!
[06:52] <t0mb0> jam, I do have juju run --operator
[06:52] <t0mb0> but I'm not trying to run a shell cmd, I'm trying to run a charm action
[06:53] <t0mb0> ah - on another read of that bug report you're saying there is no reason not to also include --operator to "run-action"
[06:54] <jam> t0mb0, ah, it was juju run that grew --operator, not run-action
[06:55] <jam> t0mb0, bug update
[06:55] <jam> updated
[06:56] <t0mb0> jam, shouldn't state be the same whether it's running in the operator pod or on the workload?
[06:56] <jam> t0mb0, state is read from the local disk atm, no way to read it from the other pod
[06:57] <t0mb0> jam, so if the operator pod was to die then you'd lose that state?
[06:57] <jam> t0mb0, operator pods are currently stateful stets
[06:57] <jam> sets
[06:58] <jam> t0mb0, so they ask k8s for a disk mount that will float with a restart of the pod
[06:58] <jam> t0mb0, in 2.8 there are some hook tools that will let us save state back in the controller, and work that would allow operator pods to become stateless
[06:58] <jam> the operator framework doesn't support that yet. its on our 'todo next' list
[06:58] <t0mb0> jam, I also noticed that if I initialised admin_password in on_start, then my action was able to read it, it was just when that value was overwritten in the configure hook
[06:59] <jam> t0mb0, once you declare a pod spec, the Juju code copies the charm in an init container to the application pod
[06:59] <jam> t0mb0, currently the charm state is stored in the state dir, causing it to get copied
[06:59] <jam> but that is 'state as it exists at one point in time'
[07:00] <jam> which is naughty of how it is all done and definitely shouldn't be relied upon
[07:07] <Dmitrii-Sh> that also has an effect of not being able to update StoredState from actions such that regular hooks can see those updates
[07:08] <Dmitrii-Sh> as jam says, it should work when we have controller-side state storage used in the framework with juju 2.8
[08:14] <t0mb0> am I correct in understanding that by emitting an event like this https://github.com/dshcherb/cockroachdb-operator/blob/master/src/charm.py#L192 emit() will block or should it be asynchronous?
[08:16] <Chipaca> mo'in
[08:16] <niemeyer> t0mb0: That call dispatches the event to handlers
[08:16] <niemeyer> Morning
[08:18] <t0mb0> niemeyer, so if I was to do something like this https://pastebin.canonical.com/p/hpzGSrTSGh/ it shouldn't cause a stack overflow or hit maximum recursion limits?
[08:20] <niemeyer> If you emit an event inside the handler of that event, yes bad things can happen if that takes place forever
[08:21] <niemeyer> It's also not super nice to read and maintain despite anything else
[08:22] <niemeyer> It's awkward to say "Hey, it's now initialized!" inside the thing that handles "Oh, is it initialized? Cool, let me handle that.".. makes sense?
[08:22] <t0mb0> niemeyer, it shouldn't take place forever in that eventually the pod would have loaded (this is an interim solution until juju notifies us when the pod is alive).
[08:23] <niemeyer> It's better that it's known to be going away, but it doesn't make they nice.. I'd still look for a different solution
[08:24] <niemeyer> *that
[08:24] <niemeyer> t0mb0: You might just defer the event, for example
[08:25] <t0mb0> niemeyer, yeah that's my preferred solution atm however it's kind of annoying having to wait around for an update-status hook to fire for that event to be processed again
[08:27] <niemeyer> t0mb0: Okay, let me think about this and I will try to suggest something
[08:28] <t0mb0> niemeyer, it's not super critical, I think we're happy to just wait for an update-status for the time being until we have more k8s hooks to work off
[08:29] <t0mb0> I was just wondering if the emit() loop was viable
[08:45] <niemeyer> t0mb0: Viable it is.. it's just not a very nice way to organize things.. it's a very complex way to run an unbounded loop
[08:46] <Dmitrii-Sh> t0mb0: .emit() is not asynchronous but handling of that event may be deferred by whoever receives it
[08:48] <Dmitrii-Sh> t0mb0: from what I understand you would like to update the unit status based on whether a workload pod is actually ready or not
[08:50] <Dmitrii-Sh> this is a little odd to do from the operator pod because (in my view) its status is determined by whether it has enough data to produce a pod spec
[08:51] <Dmitrii-Sh> I can see the use case where you need to, for example, expose a service URL only when your services are actually up because otherwise a remote unit might fail trying to connect using that URL immediately after receiving it
[08:52] <Dmitrii-Sh> ideally a client would retry on connection failures because we cannot guarantee that a service is up and will stay up when we expose a URL over a relation
[08:53] <niemeyer> Dmitrii-Sh: That seems to be well understood. It's exactly the trying that is being discussed here.
[10:12] <Chipaca> how do we define when a charm is 'done'?
[10:13] <Chipaca> in my mind that's a case-by-case thing, with a process for ekeing out what done is for each charm
[10:13] <niemeyer> What would it mean for a charm to be done?
[10:15] <Chipaca> niemeyer: that the person assigned with doing it can tick it off a list :)
[10:16] <niemeyer> Chipaca: This is moving the question to what was the person aiming to do with that list..
[10:16] <Chipaca> we can't say "we need you to do this thing" without saying what that thing being "done" actually is
[10:16] <niemeyer> Chipaca: The charm manages the entire lifecycle.. it's never done
[10:16] <niemeyer> It's an event consumer.. it's always waiting for the next reason to do something
[10:17] <Chipaca> heh
[10:17] <niemeyer> Chipaca: Exactly.. and we can't say what "done" means without us knowing what "we need you to do this thing" means
[10:17] <niemeyer> Chipaca: The charm can be done handling a hook
[10:18] <niemeyer> Chipaca: "heh" is pretty much never the right answer, though
[10:18] <Chipaca> I thought you made a joke
[10:20] <Chipaca> niemeyer: we _have_ told people "we need you to do this charm". So I'm askig, how do they, and how do we, know when they're done?
[10:21] <niemeyer> Chipaca: So the actual question is "When are people done writing a charm?".. okay, that's something else altogether
[10:23] <niemeyer> Chipaca: The charm is supposed to manage the lifecycle of the applications involved. If we can start, stop, handle the applications relationships so it can actually work, communicate the necessary information for the underlying software to be useful.. it seems like we've got something tangible in hands
[10:58] <Chipaca> niemeyer: so questions of vert/horiz scalability, managing secrets, upgrades, metrics and logs, are all beyond the scope of a basic "charm is done"?
[10:59] <Dmitrii-Sh> jam: (for when you're around). Updated https://github.com/canonical/operator/pull/212 per our discussion and will have a look at debug-code.
[11:01] <niemeyer> Chipaca: I'm assuming you're talking specifically about the conversation we had yesterday, which was in the context of getting the Charmcraft developers to come up with working examples so that they can benefit from having actual experience on how to write a charm in the framework, and so that we can develop experience to help other people
[11:02] <Chipaca> niemeyer: yes but also for teams beyond just ours, that are also being tasked with charming things
[11:02] <niemeyer> Chipaca: If that's the case, then we don't need something fancy and comprehensive to start documenting these charms in our catalog of examples
[11:03] <niemeyer> Chipaca: If it's something else, then I cannot possibly answer that question without knowing what that something else is..
[11:03] <niemeyer> Chipaca: Yes, sometimes managing secrets, scalability, logs, metrics, are fundamental to consider basic work on a charm donw
[11:03] <niemeyer> *done
[11:04] <facubatista> Muy buenos días a todos!
[11:04] <Chipaca> facubatista: buen día!
[11:04] <Chipaca> facubatista: buen viernes, even :)
[11:04] <facubatista> hola Chipaca! :)
[11:09] <niemeyer> facubatista: Que tal?
[11:13] <facubatista> niemeyer, hola! all fine, I already did some gym, have my mate, sun enters through the window...
[11:13] <facubatista> you?
[11:13] <niemeyer> That sounds nice
[11:13] <niemeyer> I just finished my morning bottle of mate
[11:14] <facubatista> good
[11:23] <facubatista> niemeyer, Chipaca, in my mind, we should have a comprehensive set of charms that shows how to do each of those things (vert/horiz scalability, managing secrets, upgrades, metrics, logs, etc) but we should NOT do all those things on each example
[11:24] <facubatista> (of course, we need a couple of "big fully done" examples)
[11:25] <facubatista> but the small ones are very useful for other people writing charms... when a developer writing a charm says "I'm doing my charm, have much done, need to add 'secrets' here", we can point to docs, and an example where is easy to find *that*
[11:26] <facubatista> (note that even they should be very small and focused examples, they will be fully functional in the sense that can be deployed, we run functional tests on them, etc)
[11:33] <niemeyer> facubatista: The medium term task for the charmcraft team in that regard should be to identify what patterns need to be enabled.. it's not a goal to be maintaining comprehensive charm that can e.g. do everything one might possibly want to do in PostgresSQL in production
[11:34] <facubatista> yeap
[11:34] <niemeyer> facubatista: For this example, stub would be much better positioned to do that.. but what we must do is ensuring that he can indeed do that and isn't running short in support from the underlying framework
[11:35] <facubatista> perfect
[12:04] <Chipaca> facubatista: could you look at #196 again?
[12:05] <facubatista> Chipaca, yes, I'm on that right now
[12:05] <Chipaca> facubatista: 👍
[12:23] <Chipaca> I went to look at https://github.com/juju/juju/pull/11389 and at the bottom of all the discussion, it's merged :-D
[12:28] <facubatista> Chipaca, done with #196
[12:28] <facubatista> (not sure what you were expecting from that)
[12:29] <Chipaca> facubatista: what you've done seems fine
[12:30] <Chipaca> facubatista: i'm just allergic to "changes requested" and then nothing
[12:30] <facubatista> sure
[12:31] <facubatista> we probably need to interact more here, regarding PRs... like "answered your comments, pushed a commit, something still open to discussion"
[12:31] <facubatista> otherwise we (I) get to those changes after reading other 12496 issues
[12:40] <Dmitrii-Sh> relation-created in a to-be-published 2.8-beta1:
[12:40] <Dmitrii-Sh> juju show-status-log cockroachdb/0
[12:40] <Dmitrii-Sh> Time                        Type       Status       Message
[12:40] <Dmitrii-Sh> 03 Apr 2020 15:25:20+03:00  juju-unit  executing    running proxy-listen-tcp-relation-created hook
[12:40] <Dmitrii-Sh> 03 Apr 2020 15:25:21+03:00  juju-unit  executing    running cluster-relation-created hook
[12:40] <Dmitrii-Sh> 03 Apr 2020 15:25:22+03:00  juju-unit  executing    running leader-elected hook
[12:40] <Dmitrii-Sh> 03 Apr 2020 15:25:23+03:00  juju-unit  executing    running config-changed hook
[12:40] <Dmitrii-Sh> 03 Apr 2020 15:25:24+03:00  juju-unit  executing    running start hook
[12:49] <Chipaca> Dmitrii-Sh: nice
[12:51] <Chipaca> Dmitrii-Sh, niemeyer, did I understand right yesterday that juju changed the command we need to run to set a pod spec?
[12:53] <Dmitrii-Sh> Chipaca: https://github.com/juju/juju/pull/11323
[12:53] <Dmitrii-Sh> yes, that's correct
[12:54] <Chipaca> what does the deprecation look like? are we ok to carry on using the old one, or do we need to use jujuversion to run one or the other?
[13:08] <crodriguez> Good morning everyone! Just wanted to say thank you for yesterday, I was able to convert my pod_spec to v3 and incorporate the secret successfully :)
[13:09] <crodriguez> so is the whole charm-tech team EMEA?
[13:10] <facubatista> good morning crodriguez!
[13:10] <crodriguez> happy friday too !
[13:14] <Chipaca> crodriguez: part EMEA, part americas
[14:14] <Dmitrii-Sh> crodriguez: glad to hear it!
[14:40] <Dmitrii-Sh> facubatista: https://paste.ubuntu.com/p/kvNvF45Jm4/ - seems to work fine
[14:40] <Dmitrii-Sh> (first impression)
[14:47] <facubatista> Dmitrii-Sh, great!
[14:47] <facubatista> Dmitrii-Sh, just checking the value of the envvar is enough, for the different cases
[14:49] <facubatista> (I'm actually writing the Python code to react on that)
[14:54] <Dmitrii-Sh> facubatista: need to split the string if multiple breakpoints are specified https://paste.ubuntu.com/p/QfTSwnnjXg/
[14:54] <facubatista> Dmitrii-Sh, yeap
[15:05] <crodriguez> design question: My charm deploys a mssql container and its operator container. If I want to deploy (optionally) another container that contains tools to interact with the main container, should I create a new class for it? I see that if I simply add the container info in the same pod_spec, it includes it in the main mssql pod, which is not what I want, I would like a separate mssql-tools pod
[15:09] <crodriguez> or should it be a separate charm altogether and relate them in a bundle? (I hope not)
[15:12] <niemeyer> crodriguez: It's a pretty good question.. I don't have a good answer myself because I don't yet understand the design of the k8s integration as well as I want to
[15:12] <niemeyer> crodriguez: What I'd like to enable is a situation where the main charm container lives right next to the managed container, and you might have any number of workload containers next to it, but that's not there yet
[15:13] <niemeyer> crodriguez: Would be nice to have the view of someone that is comfortable with the ways currently work and might provide some advice on that
[15:13] <niemeyer> crodriguez: From the charm team, the best person would be jam.. tvansteenburgh might also have a good view on this from the k8s perspective
[15:14] <niemeyer> crodriguez: jam is off today
[15:15] <crodriguez> niemeyer: yes, maybe they could help. This is my first k8s charm so I'm not always sure of best practices . I was thinking that I'd try to create a 2nd charm class that is triggered optionally, and see how that does
[15:16] <Dmitrii-Sh> crodriguez: just trying to understand the use-case a little bit more: is there anything specific that you would like to do from a separate pod with mssql-tools?
[15:18] <crodriguez> Dmitrii-Sh: mostly just make it visible. Otherwise it's hidden, the pod/mssql-0 gets 2 containers instead of 1, like this (ignore the crashloopbackoff lol) https://usercontent.irccloud-cdn.com/file/be7sDsYu/image.png
[15:20] <crodriguez> for the use case, I am also going to add other sql components in this charm, such as a Machine Learning component, and I will have to decide if I want to extend the base mssql container or if I would prefer to deploy these components in separate containers
[15:21] <Dmitrii-Sh> crodriguez: hmm, the first impression is that a machine component would be a separate application
[15:22] <Dmitrii-Sh> and tools to access mysql would be, for example, a part of its container image
[15:23] <Dmitrii-Sh> when Juju deploys an application to k8s it creates a Deployment in k8s with a pod template specified
[15:24] <Dmitrii-Sh> that pod template may have multiple containers
[15:24] <Dmitrii-Sh> but, as far as Juju is concerned, a combination of a workload pod and an operator pod is considered to be a unit
[15:24] <Dmitrii-Sh> so individual containers in that unit are not visible
[15:26] <crodriguez> Okay, so there is not really a way to display more than one pod with one k8s charm right now, is that correct?
[15:29] <Dmitrii-Sh> crodriguez:  1 app can have multiple units which would correspond to multiple pods
[15:29] <Dmitrii-Sh> each pod can have multiple containers - that part is within the scope of 1 unit
[15:29] <Dmitrii-Sh> so, yes, that's correct
[15:30] <Dmitrii-Sh> crodriguez: containers within a pod share networking and storage, for example
[15:30] <crodriguez> Dmitrii-Sh: ok! so to make multiple units in this framework, would it be to create multiple charm classes in charm.py ?
[15:32] <Dmitrii-Sh> Similar to non-k8s charms, all units share the same code and have one Charm class. Except for actions, that code gets executed in operator pods, not workload pods (where multiple containers would be)
[15:32] <Dmitrii-Sh> so you'd still have one class providing the same code to run multiple units
[15:34] <Dmitrii-Sh> a leader unit would be able to use pod-spec-set, other units would mostly react to lifecycle events and, if a leader is gone, one of the units would take leadership over and be able to use pod-spec-set
[15:35] <Dmitrii-Sh> crodriguez: what are the component-specific things that you need to do in the charm code?
[15:35] <Dmitrii-Sh> is it about feeding some parameters to the container spec?
[15:36] <Dmitrii-Sh> crodriguez: if so, I think you could have multiple classes responsible for different parts of the final podspec
[15:44] <crodriguez> Dmitrii-Sh:  I'm not sure yet. I was working with mssql-tools image first as it helps me see how the charm structure works with different containers in one charm
[15:46] <crodriguez> you said one app can have multiple units, which would correspond to multiple pods, and that this would be only one class in the code. I do not see that. With using the same class (so the same pod spec), it deploys only one pod.
[15:52] <Dmitrii-Sh> crodriguez: just to demonstrate what I mean https://paste.ubuntu.com/p/rgFzBtpSWC/
[15:53] <Dmitrii-Sh> let me get some sample output from k8s as well to demonstrate multiple units
[15:57] <crodriguez> ok thanks Dmitrii-Sh
[16:13] <Dmitrii-Sh> crodriguez: https://paste.ubuntu.com/p/2P93kyFxd9/
[16:14] <Dmitrii-Sh> so in this example there is one charm that gets deployed, the app is called "wp" with 2 units. As a result you get 1 operator pod and 2 workload pods
[16:17] <Dmitrii-Sh> crodriguez: if you exec into the operator pod, you will see that there are multiple directories under /var/lib/juju
[16:17] <Dmitrii-Sh> microk8s.kubectl exec -n controller-microk8s-localhost wp-operator-0 -it -- bash
[16:17] <Dmitrii-Sh> root@wp-operator-0:/var/lib/juju# ls /var/lib/juju/agents/
[16:17] <Dmitrii-Sh> application-wp  unit-wp-0  unit-wp-1
[16:18] <Dmitrii-Sh> so the charm code for different units gets executed in the same operator pod, however, it runs with a different context and in different charm directories
[16:18] <Dmitrii-Sh> the operator pod is the same, the code is the same, the stored state is different, leadership status is different
[17:13] <facubatista> I need help for a error message
[17:13] <facubatista> this looks too long: "breakpoint names must start and end with lowercase alphanumeric characters, and only contain lowercase alphanumeric characters, the hyphen '-' or full stop '.'"
[17:14] <niemeyer> facubatista: 'breakpoint names must look like "foo" or "foo-bar"'
[17:14] <niemeyer> facubatista: I'd drop the dot..
[17:14] <niemeyer> facubatista: Reserve that for namespacing if we have to
[17:14] <facubatista> niemeyer, I just used the same rule than for actions
[17:14] <facubatista> but totally agree
[17:14]  * facubatista fixes the spec
[17:15] <niemeyer> facubatista: These are not actions.. if we have to add namespacing, we should have a good plan in mind
[17:16] <facubatista> niemeyer, and I like the error with the examples; developer can go for documentation if we want the "full rules" anyway
[17:16] <niemeyer> facubatista: Agreed
[19:09] <crodriguez> Dmitrii-Sh: Sorry if it's late for you, we can continue this conversation Monday morning. So I think we misunderstand each other, maybe it's because we do not reference the same thing when we say "unit". The example with wp still shows the same wordpress pod deployed multiple times. It's the same container image, etc. What I am trying to achieve is to have something like:
[19:09] <crodriguez> - 1x mssql-server pod
[19:09] <crodriguez> - 1x mssql-tools container (which depends on a different image that mssql-server)
[19:09] <crodriguez> - 1x mssql-machine-learning-components
[19:09] <crodriguez> - 1 operator pod
[19:09] <crodriguez> Since they are dependant on a different image, it's a different unit to deploy. I'm not looking to just scale my mssql-server to 2 containers.
[19:09] <crodriguez> But then, maybe my approach is wrong, and that I should combine all these components in a unique container image.
[19:20] <Dmitrii-Sh> crodriguez: hmm, I think I need to read on https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup-machine-learning-docker?toc=%2Fsql%2Fadvanced-analytics%2Ftoc.json&view=sql-server-ver15
[19:20] <Dmitrii-Sh> skimming through it I think I understand it better. mssql-machine-learning-components is just an add-on service to MSSQL to be able to execute python and R scripts in the DB itself.
[19:21] <Dmitrii-Sh> it feels like ML services should be a separate container in the mssql-server pod
[19:21]  * facubatista loves `watch -n 5 -d juju status`
[19:21] <Dmitrii-Sh> mssql-tools could be as well just for the case where you want to exec into a container and access it through the CLI client
[19:22] <crodriguez> yeah I'm reading more about it and it might actually be a bigger image that includes mssql-server itself. From https://github.com/Microsoft/mssql-docker/tree/master/linux/preview/examples/mssql-mlservices
[19:23] <crodriguez> My point remains that if I wanted to deploy separate pods from one charm, there's no clear answer on how to do that
[19:24] <crodriguez> and mssql-tools was just a practice to figure out how to do this. because it's actually included by default in the mssql-server, I do not need to deploy it separately. But I would like to understand how to do it if I wanted to go that route, you know?
[19:29] <Dmitrii-Sh> crodriguez: multiple pods, each with different sets of container specs in one charm - no. It's not possible to do that with deployment objects in k8s IIRC (https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) and Juju apps result in deployment objects being created
[19:30] <Dmitrii-Sh> I think we need to work out the target yaml for K8s that we would like to see
[19:30] <Dmitrii-Sh> and then map it to a podspec
[19:31] <Dmitrii-Sh> crodriguez: "would like to understand how to do it if I wanted to go that route", - understood, I sent out an invite for Monday to go over this
[19:31] <Dmitrii-Sh> let me know if the time is OK for you
[19:33] <crodriguez> ok thank you! yes that time works. Thanks for the additional info
[19:35] <Dmitrii-Sh> great, np
[19:36] <Dmitrii-Sh> Have a good weekend!
[19:38] <crodriguez> you too Dmitrii-Sh !
[20:29] <facubatista> reviews appreciated! Added breakpoint manual call to the framework - https://github.com/canonical/operator/pull/213
[20:30] <niemeyer> Thanks, will look on Monday
[20:30] <niemeyer> For now, have a great weekend
[20:53]  * facubatista eods
[20:53] <facubatista> Bye all! have a nice weekend
[20:56] <Chipaca> have a good weekend, all