[06:39] <pitti> Good morning
[08:29] <mlankhorst> Hello, world!\n
[09:03] <Laney> morning
[09:04] <seb128> good morning desktopers
[09:04] <seb128> Laney, hey, how are you on this sunny thursday?
[09:05] <Laney> the inverse weather theory holds true
[09:05] <Laney> it is super grey here
[09:05] <seb128> sorry for you
[09:05] <Laney> oh well
[09:06] <Laney> they set a new series of climbs at my grade at the centre yesterday so I had a great session
[09:06] <Laney> so I'm excellent thanks!
[09:06] <Laney> how are you?
[09:06] <seb128> nice!
[09:06]  * larsu waves to Laney
[09:07] <seb128> I'm good, had a good night of sleep and nice to have sun out there today
[09:12] <MacSlow> seb128, will you be able to beat 18 °C this weekend? :)
[09:13] <seb128> MacSlow, they forecast 16°C I think ;-)
[09:13] <MacSlow> seb128, we're promised 18 °C here on Sunday ... I can hear my bike screaming already ;)
[09:20] <Laney> hm, I have a "Calendar authentication request" on l ogin
[09:20] <Laney> for my canonical gapps account
[09:20] <seb128> weird
[09:24] <mlankhorst> it was freezing tonight :(
[09:28] <Laney> ah, u-s-s and telephony got released
[09:28] <Laney> all your calls are broken by me
[09:29] <seb128> lol
[09:29] <seb128> who pressed the button?
[09:30] <Laney> looks like robru
[09:30] <seb128> good
[09:30] <seb128> so you can blame him if it turns out to be buggy :p
[09:30] <Laney> bfiller tested it and said it worked
[09:30] <seb128> good
[09:30]  * Laney is fully covered ;-)
[09:31] <Laney> alright, let's look at this package from gunnar
[09:59] <larsu> is bash completion broken for anyone else?
[10:02] <seb128> larsu, somebody mentioned ~/ resolution being buggy yesterday I think
[10:02] <ochosi> hey everyone
[10:02] <seb128> wfm
[10:02] <seb128> well,  on local path, didn't try with ~/
[10:03] <seb128> larsu, https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1288031
[10:03] <ubot2`> Launchpad bug 1288031 in bash-completion (Ubuntu) "Tab expansion only auto-completes directory names" [Undecided,Confirmed]
[10:03] <larsu> seb128: same for me
[10:04] <larsu> also, when I <tab> on an empty prompt, I get "bash: words: bad array subscript"
[10:04] <larsu> thanks for pointing me to the bug
[10:04] <seb128> yw
[10:04] <ochosi> if any of you indicator-devs get a chance to merge this (https://code.launchpad.net/~ochosi/indicator-power/recommend-xfce4-powermanager/+merge/207018) that'd be great! (currently it pulls in a lot of recommends in in xubuntu :))
[10:05] <seb128> ochosi, I can do a landing with that
[10:05] <seb128> let me check if we have other indicator-power work queued
[10:06] <ochosi> yeah, there's one more accepted MR
[10:06] <ochosi> thanks a bunch seb128 !
[10:06] <seb128> yw!
[10:06] <seb128> the "startup-cleanup" branches are stacked in a landing ask including all the indicators
[10:06] <ochosi> ah yeah
[10:06] <seb128> larsu, do you want to review https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1288031?
[10:06] <ubot2`> Launchpad bug 1288031 in bash-completion (Ubuntu) "Tab expansion only auto-completes directory names" [Undecided,Confirmed]
[10:06] <seb128> shrug
[10:06] <ochosi> upstart for all indicators
[10:07] <seb128> yeah
[10:07] <seb128> larsu, https://code.launchpad.net/~charlesk/indicator-power/lp-1234458/+merge/209371 I meant
[10:07] <seb128> larsu, I'm going to do an indicator-power landing for the xubuntu recommends thing, if that one is good I can include it as well
[10:07] <seb128> larsu, shrug, that's a bigger diff that I though, let's keep that for next round
[10:08] <ochosi> fwiw, i wonder whether you're seeing this too in unity with Trevinho's latest change to libindicator (use GIcon and icon-name over pixbuf hardcoded to 22px): http://www.zimagez.com/zimage/screenshot-2014-03-06-110807.php
[10:08] <seb128> ochosi, "this"?
[10:08] <ochosi> could be that it's just our plugin not handling icon-sizes correctly or a problem in indicator-application
[10:09] <ochosi> well, cut off icons, because they're provided in a too-large-size
[10:09] <seb128> I don't know how it looked like before for you
[10:09] <ochosi> the icons for skype and spotify were scaled down to be the same as the others (power, message and sound)
[10:09] <seb128> ochosi, http://people.canonical.com/~seb128/indicator/newunity.png
[10:09] <seb128> that's how it looks like here (that one is scaled up)
[10:10] <seb128> ochosi, http://people.canonical.com/~seb128/indicator/new.png
[10:10] <seb128> is scaling=1
[10:10] <ochosi> right, but those aren't fugly proprietary apps like skype or spotify over which we have no control :)
[10:10] <ochosi> the unity indicators still work fine
[10:10] <seb128> did you try those apps in unity?
[10:11] <ochosi> not yet, but i guess i'm going to do that very soon
[10:11] <ochosi> unless someone here uses any of them
[10:11] <ochosi> (my suspicion is that this only affects xubuntu anyhow)
[10:12] <seb128> ochosi, http://people.canonical.com/~seb128/unityicons.png
[10:12] <seb128> skype included
[10:12] <ochosi> hmm, looks nice :)
[10:12] <ochosi> ok, thanks!
[10:12] <seb128> yw!
[10:13] <ochosi> so i'll have to sort it out in xfce4-indicator-plugin then :)
[10:13] <larsu> seb128: what's that esoteric "Fr" language that you're using?
[10:13] <ochosi> huhu
[10:13] <seb128> larsu, I can teach you if you want!
[10:13] <larsu> ochosi: Trevinho might be able to help you out with the specifics of the changes
[10:13] <larsu> but I think his patch shouldn't affect the appindicator icons at all...
[10:13] <larsu> seb128: je n'est sais pas
[10:14] <ochosi> yeah, i thought so too
[10:14] <ochosi> je ne sais plus rien
[10:14] <seb128> ochosi, larsu: he did http://bazaar.launchpad.net/~3v1n0/unity/hidpi-better-scaling/revision/3784 ... not sure if that would help there?
[10:15] <ochosi> ah yeah, thanks
[10:15] <seb128> I think we had blurry icons for e.g indicator-power before that commit
[10:15] <mlankhorst> yay ppc64el porter :D
[10:15] <ochosi> that looks like it's it, but i presumed that stuff like skype would use the pixbuf fallback anyway
[10:15] <ochosi> but maybe i was wrong about that
[10:16] <ochosi> larsu: i guess you don't have time for some last-minute fun with me, adding support for symbolic icons to all indicators? :)
[10:16] <larsu> why is he reading the file name in the pixbuf case?!
[10:16]  * Laney ports mlankhorst to powerpcspe
[10:16] <larsu> ochosi: oh well, please talk to him about it
[10:16] <larsu> ochosi: you mean as opposed to -panel?
[10:16] <ochosi> yup
[10:16] <ochosi> well, first try -symbolic, then -panel, then...
[10:17] <ochosi> then you could get rid of ubuntu-mono-dark
[10:17] <larsu> I'll accept patches if they also fix the icon theme
[10:17] <larsu> no...
[10:17] <larsu> there are some icons with color in there
[10:17] <ochosi> oh
[10:17] <larsu> (or at least there used to be)
[10:17]  * ochosi goes to look
[10:17] <larsu> power I think?
[10:18] <larsu> which is certainly not monochrome
[10:18] <ochosi> yeah, but those are the same color in -dark and light
[10:18] <ochosi> same with audio-volume-muted-blocking-panel
[10:19] <ochosi> only three colors there, and symbolic icons even support those variants afaik (errors or warnings can be colored by the theme)
[10:20] <ochosi> anyway, i understand that this isn't your top priority
[10:20] <ochosi> but if you need help on the icon side, i can help with that
[10:20] <larsu> right
[10:20] <larsu> I'd love to see that done (or do it myself)
[10:20] <larsu> let's see if I can find some time
[10:21] <ochosi> feel free to ping me about it if you do
[10:21] <larsu> you can bet I will ;)
[10:21] <larsu> thanks!
[10:21] <ochosi> hehe, no problem
[10:22] <ochosi> or is tiheum already working on symbolic icons for the panel?
[10:22] <seb128> not that I know
[10:22] <larsu> I don't know either
[10:23]  * mlankhorst ports Laney to bigendian
[10:23] <mlankhorst> enaL\0\0\0y
[10:24] <larsu> lol
[10:26] <seb128> larsu, let me know when you have a theme patch for the menu, I've the new GTK built and it creates no issue that I can see, now I want to test with the theme to confirm it fixes the issue before uploading
[10:26] <larsu> seb128: people keep pinging me!
[10:26] <larsu> seb128: I have it in *some* terminal in the background
[10:27] <seb128> larsu, how dare they?!
[10:27]  * larsu alt-tabs
[10:27] <larsu> :)
[10:27] <seb128> larsu, ping
[10:27] <seb128> :p
[10:27] <larsu> ARGH
[10:30] <tiheum> ochosi: seb128: Hi, we don't have symbolic icons for the desktop panel atm. Suru indicator icons for the mobile are quite similar to symbolic icons (SVG, monochromatic, can be colorized) but the size is not the same so they will look blurry on the desktop. And names differ as well. What do you want to do exactly?
[10:31] <larsu> seb128: https://code.launchpad.net/~larsu/ubuntu-themes/add-menu-margin/+merge/209632
[10:32] <ochosi> tiheum: well to be concrete, the indicators in the desktop could support symbolic icons, so there'd not be a need anymore to have a ubuntu-mono-dark and -light icon theme
[10:32] <ochosi> tiheum: that would also be more convenient for users when switching themes i guess...
[10:33] <ochosi> tiheum: no idea what design plans you have for the desktop, but in case you want the status icons to be the same in style, it would be good to know that before starting to port those >800 icons to symbolic ones :)
[10:34] <tiheum> ochosi: >800?
[10:34] <ochosi> tiheum: the implementation of indicator-keyboard accounts for >500 icons... (one for each layout variant)
[10:36] <tiheum> ochosi: system indicators (wifi, battery, keyboard, etc) can support symbolic icons, but what about app indicators (like weather)?
[10:36] <larsu> indicator-keyboard creating that many icons is crazy
[10:36] <larsu> why did we do this again?
[10:37] <ochosi> tiheum: why could those not be patched?
[10:38] <ochosi> at least those that are part of ubuntu by default or that are installable could be patched imo
[10:38] <seb128> larsu, you would generate the pixmaps are runtime at every login instead?
[10:38] <seb128> larsu, I'm not even sure how we can generate those pixmaps
[10:38] <ochosi> why does it have to be pixmaps?
[10:38] <ochosi> i mean this could *easily* be drawn with cairo in the indicator
[10:39] <ochosi> it's such a simplistic shape, with just a little bit of font on it
[10:39] <seb128> how do you know what to draw?
[10:39] <tiheum> I am agree: so many icons make a transition to a newer theme very difficult
[10:39] <seb128> ochosi, larsu, tiheum: http://iloveubuntu.net/pictures_me/indicator%20keyboard%20new%20mouse%20wheel%20ubuntu%2014.04.png
[10:39] <larsu> seb128: I hope attente didn't sit down and draw all of these icons ...
[10:39] <ochosi> yeah, or at least very annoying :)
[10:39] <larsu> so there has to be a way of generating them
[10:39] <seb128> right
[10:39] <seb128> it doesn't mean it's practical to do it at runtime
[10:40] <larsu> and we can just do that at runtime, nobody has all layouts
[10:40] <seb128> I think he generated them from ibus or something
[10:40] <larsu> so in practice, we only need to do a handful of them
[10:40] <seb128> well, if you have the material to generate them
[10:40] <larsu> oh we don't have that?
[10:40] <seb128> not sure it's installed
[10:40]  * larsu remembers talking to attente about this before, but forgot his conclusion
[10:40] <larsu> I'm sure he has a good reason for it
[10:41] <seb128> but they are not all squares with text in it
[10:41] <ochosi> seb128: frankly that icon isn't even in ubuntu-mono-dark, so no idea where it comes from...
[10:41] <seb128> e.g that screenshot the pinyin one
[10:41] <larsu> that icon is very blue
[10:41] <seb128> ochosi, yeah, me neither
[10:41] <seb128> but it's not that simple
[10:41] <ochosi> yeah, but how many of those are there?
[10:41] <seb128> we should stop speculating and talk to attente when he's up
[10:41] <ochosi> agreed :)
[10:43] <ochosi> ok, so ignoring those kb-icons (they could be scripted to become symbolic i guess, with inkscape), where does that leave us at the symbolic-icons discussion
[10:44] <ochosi> (btw it's possible that he drew the icons exactly because you have two different icon themes and the plugin wouldn't know which color to supply)
[10:45] <ochosi> (a problem that'd be solved with symbolic icons)
[10:49] <ochosi> tiheum: so you're not planning to change the style of the panel icons on desktop to match those of phone?
[10:57] <tiheum> ochosi: I don't think so. The new desktop icon theme is planned for 14.10 and we don't have much time to design all the symbolic indicators before the UI freeze.
[11:00] <tiheum> ochosi: however, I'll talk with my manager about that to take a decision.
[11:00] <ochosi> tiheum: ok, great! let me know how it goes
[11:00] <tiheum> ochosi: sure
[11:00] <ochosi> ty
[11:23] <seb128> didrocks, is your release magic taking bug numbers for launchpad mps or from commits (--fixes lp:...) or from both?
[11:23] <seb128> Laney, ^
[11:23] <seb128> from launchpad*
[11:25] <Laney> I'm quite sure it looks at the related bugs on the MP
[11:25] <Laney> have done that before
[11:26] <seb128> cool, I didn't know
[11:26] <didrocks> seb128: both
[11:26] <seb128> I usually uncommit/commit with --fixes and push over
[11:26] <seb128> didrocks, great, thanks ;-)
[11:26] <seb128> Laney, approved
[11:27] <didrocks> normally, can have a bug :p
[11:27] <seb128> let's see how it works
[11:27] <seb128> if it doesn't work Laney gets to close the bug by hand :p
[11:27] <Laney> heh
[11:28] <Laney> branch_merge_proposal.getRelatedBugTasks()
[11:29] <didrocks>             for bug in mp.getRelatedBugTasks():
[11:29] <didrocks> so from Mp, it's sure
[11:29] <didrocks> and normally, I scan the commit message for any "bug blablabla" message
[12:30] <seb128> happyaron, are you around this week?
[12:32] <seb128> ochosi, https://launchpad.net/ubuntu/trusty/+source/indicator-power/12.10.6+14.04.20140306-0ubuntu1
[12:56] <ochosi> thanks a bunch, seb128 !
[12:56] <seb128> yw!
[13:00] <happyaron> seb128: I'm spending most of my time with NUDT and Sogou, :)
[13:01] <seb128> happyaron, hey
[13:02] <seb128> happyaron, could you have a look to https://bugs.launchpad.net/ubuntu/+source/ibus-anthy/+bug/1279845 anyway? it shouldn't be too much work to review, it has been waiting in the sponsoring queue for a while
[13:02] <ubot2`> Launchpad bug 1279845 in ibus-anthy (Ubuntu) "ibus-anthy sets to jp keyboard layout forcibly." [Undecided,New]
[13:02] <happyaron> seb128: sure
[13:02] <seb128> thanks
[14:25] <seb128> mterry, hey
[14:26] <mterry> seb128, hello!
[14:26] <seb128> mterry, we have our weekly settings/indicator hangout meeting in 35 min, want to join?
[14:27] <seb128> mterry, ted, larsu, Laney are going to be there, we though it would be nice to have a discussion about a-s/lock screen settings sharing
[14:27] <seb128> we can do it another time/after the meeting as well
[14:27] <seb128> but that should be more effective that have several discussions over bugs and merge requests for those changes
[14:27] <seb128> tedg, ^ btw
[14:27] <tedg> Sounds good
[14:29] <seb128> mterry, tedg: do you guys have some notes/document discussing why we ended up opting by doing locking using the greeter rather than doing it in session?
[14:38] <seb128> mterry, stop timeouting!
[14:39] <seb128> mterry, did you get what I was saying before?
[14:39] <mterry> seb128, I said "sure" last I saw
[14:39] <seb128> mterry, I didn't receive that, what did you get on your side before writing that?
[14:40] <seb128> mterry, copied in query what I was writing, in case you missed a bit
[14:40] <seb128> mterry, oh, also
[14:40] <seb128> mterry, tedg: do you guys have some notes/document discussing why we ended up opting by doing locking using the greeter rather than doing it in session?
[14:42] <mterry> seb128, ?  I thought using the greeter was a long standing desire even on desktop for locking
[14:45] <xnox> yes!
[14:45] <seb128> mterry, yeah, the idea sounds appealing in principle, but in practice we hit all those issues, which is why it never happened, which makes us wonder if that's the right call
[14:45] <xnox> we had it at one point, and it was reverted =/
[14:45] <seb128> like having access to the user session status/services (music playing, play/pause)
[14:49] <mterry> seb128, yeah.  We're close to solving these issues though
[14:49] <seb128> by piling up hacks :p
[14:49] <seb128> "hacks"
[14:55] <mterry> seb128, yes and no.  Only half-hacks.  But it is nice to be able to use same code/experience for greeter and lock
[14:56] <seb128> right, both approach have pros and cons
[14:57] <seb128> Laney, tedg, larsu, charles, mpt, attente: settings-indicator meeting in a few minutes, get ready. We also want to discuss the sharing in settings between session and greeter during the meeting, maybe after the roundtable/other topics (so we don't need to keep those who don't want to stay for that discussion)
[14:57] <seb128> mterry, feel free to join from the start or I can ping you when we are done with the first part of the meeting
[14:57] <Laney> whip cracking
[14:57]  * seb128 gets something to drink and comes back for the meeting
[14:59] <tedg> seb128, Might be a couple seconds late, finishing up another meeting.
[15:01] <mterry> seb128, I'm fine with being there from start.   Is this IRC or hangout?
[15:01] <seb128> mterry, hangout, queried you the url
[15:16] <slowcon> hey guys
[15:16] <slowcon> i just got an ubuntu server and installed ubuntu desktop on it. im trying to setup remote connections to the server from MAC and WINDOWS. currently trying to setup the windows connection. I set Remote Desktop in Ubuntu to active.
[15:16] <slowcon> when i go to Network > Connection Info, I get an error of "No valid active connections found"
[15:17] <slowcon> here is what the desktop looks like http://snag.gy/EMLyh.jpg
[15:18] <slowcon> you can see there are two wired connections, but they are not listed under Wired in the Network Connections dialog box
[15:20] <ali1234> "device not managed" is your clue
[15:21] <ali1234> that means network manager is ignoring it
[15:21] <slowcon> ahhhh
[15:23] <slowcon> going to try this now ali1234
[15:23] <slowcon> http://askubuntu.com/questions/71159/network-manager-says-device-not-managed
[15:23] <ali1234> i suspect this might be a customization done by your server provider
[15:24] <ali1234> in any case there is probably a reason for it
[15:24] <slowcon> ali1234: i think so also. i went to the NetworkManager.conf
[15:24] <slowcon> and there are no lines to edit
[15:33] <dobey> Trevinho: PLEASE fix this compiz resizing bug. i'll bribe you with rum, even. :)
[15:47] <seb128> dobey, if you bribe with rum maybe you can get kenvandine to fix it :p
[15:47]  * kenvandine hides
[15:47] <dobey> heh
[15:47] <kenvandine> rum isn't enough to touch compiz
[15:47] <dobey> kenvandine: you just have to drink the rum first
[15:48] <kenvandine> it would have to be quite a bit... last time i patched compiz i had fixes for weeks after
[15:49] <desrt> so at the very least, i would expect that we can share non-persistent information between the login screen and the user's session via putting files in XDG_RUNTIME_DIR
[15:49] <desrt> this is already better than using accountsservice for volatile information
[15:49] <desrt> we could also put a socket here for communication
[15:49] <desrt> possibly via dbus or another protocol
[15:50] <desrt> (via a small process in the user's session or unity-settings-daemon plugin)
[15:50] <seb128> ted, mterry, ^ thoughs on that?
[15:50] <desrt> we could also get core lightdm onto the user's session bus to relay the information
[15:50] <desrt> that way if someone attacks the greeter session, they still don't have access to the user's bus
[15:50] <desrt> (and neatly sidesteps the question of how to get a non-privileged process into someone else's session)
[15:51] <desrt> but really, above all else: please anything but accountsservice
[15:51] <desrt> this is for storing information when the user is not logged in because their homedir is inaccessible to us
[15:51] <desrt> that's it
[15:52] <slowcon> ali1234 - ok i got the network to be available on desktop
[15:52] <desrt> honestly, the idea of lightdm getting on the user's session bus while it is pulling up the session is somewhat attractive anyway
[15:52] <seb128> I sort of like that as well
[15:52] <desrt> might want to be there for reasons like inhibit lockscreen, etc.
[15:53] <seb128> mterry, what do you think about that?
[15:55] <cyphermox> ali1234: slowcon: remove the entries from /etc/network/interfaces, if eth0 is set there.
[15:55] <cyphermox> managed=true might work but it's not supported.
[15:55] <desrt> could also do a hybrid approach where lightdm monitors a subdirectory in XDG_RUNTIME_DIR for changes and tells the greeter about it (so the greeter doesn't have direct access to the user's xdg dir)
[15:55] <desrt> and then the session needs only to touch files here (which is tmpfs, so extremely cheap)
[15:56] <desrt> this is vaguely how logind already works...
[15:56] <seb128> seems reasonable as well
[15:56] <desrt> this keeps the amount of code running in privileged context (lightdm core) extremely small
[15:56]  * seb128 wonders if we should put a blueprint for that and having a vUDS discussion ;-)
[15:56] <desrt> and it gives it almost a non-existent attack surface from the user session (and very small from the greeter, even)
[15:57] <seb128> desrt, shame you were not able to join that hangout we just had :/
[15:57] <kenvandine> seb128, lets discuss default media player again
[15:57]  * kenvandine ducks
[15:57] <Laney> srsly
[15:57] <Laney> what is there to discuss
[15:57] <mterry> seb128, sorry, was in showre
[15:57] <seb128> kenvandine, no rum for you!
[15:57] <Laney> everyone knows banshee is the obvious choice, it'd just be too embarrassing to go back again
[15:57] <kenvandine> i want banshee!
[15:57] <desrt> i'd consider either of these approches to be nice
[15:57] <Laney> :-)
[15:58] <kenvandine> :-D
[15:58] <desrt> i prefer the lightdm-on-user's-bus approach, but i don't like the idea of such a large chunk of privilged code having such exposure to the user's session
[15:58] <kenvandine> UDS isn't the same with the banshee and chromium discussions
[15:58] <Laney> I like an approach that means you don't have to modify too much software to spit out its settings in some other place
[15:59] <mterry> seb128, desrt: we just added a very convenient support for shared user-data dirs between greeter / users
[15:59] <seb128> desrt, I like both (lightm talking to the user bus, and the xdg_runtime_dir one), first seems more powerful with the  security downside that go with it, the second one seems safe and enough
[15:59] <desrt> mterry: on tmpfs, per chance?
[16:00] <desrt> seb128: exactly my thoughts.
[16:00] <slowcon> hey guys, im trying to find a way to be able to access my ubuntu server from a windows and mac enviornment. would it be easier to setup something where ubuntu desktop can be accessed from a webdomain?
[16:00] <mterry> seb128, desrt: no, not on tmpfs because it was created explicitly to support persistent files.  /var/lib/lightdm-data/$USER
[16:00] <desrt> mterry: sounds like a bit of an overlap with accountsservice
[16:00] <mterry> seb128, desrt: but the directories are owned by whichever user is configured as the greeter user and the individual user, 0770
[16:00] <mterry> desrt, this was designed for large files (like camera photos, etc)
[16:00] <desrt> right
[16:00] <desrt> mterry: but i'm suggesting that maybe we could stop using the accountsservice stuff entirely if this covers the same usecase
[16:01] <mterry> seb128, desrt: anyway, you were talking about needing a writable directory shared between greeter and user.  We have one
[16:01] <desrt> mterry: this is going to be frequently-trashed, though
[16:01] <desrt> *thrashed
[16:01] <desrt> like... IPC style... probably want a tmpfs
[16:01] <mterry> desrt, eh, AS is fine for what it does (small pieces of data)
[16:01] <desrt> maybe /var/run/lightdm-data/$USER :)
[16:02] <mterry> :)
[16:02] <slowcon> anyone ever use Guacamole?
[16:03] <desrt> mterry: i guess the greeter has some special interaction with lightdm core...
[16:03] <desrt> presumably enforced by dbus security mechanisms
[16:03] <desrt> via the system bus
[16:03] <desrt> or does it have a p2p connection or something?
[16:03] <mterry> desrt, socket
[16:03] <mterry> with custom protocol
[16:04] <desrt> so we could add support to this protocol for
[16:04] <desrt>  a) read me a file out of user's xdg dir, limited to a specific subdir
[16:04] <desrt>  b) notify me of any changes there
[16:05] <mterry> desrt, couldn't the user session just throw data into lightdm-data/$USER for that?
[16:05] <desrt> if you want to get real fancy you could just ask lightdm to pass an fd to the directory itself into the greeter... and it could inotify it for itself and use openat() to read the file contents
[16:05] <desrt> mterry: we're talking about things like current song playing updated via mpris.. including seconds
[16:06] <desrt> you don't want to write and fsync a file to persistent storage once per second
[16:06] <mterry> desrt, well you said "read me a file out of user's xdg dir"
[16:06] <desrt> whereas with tmpfs it's basically just a low-tech kernel-backed IPC mechanism
[16:06] <mterry> desrt, you could put a socket in lightdm-data/$USER
[16:06] <desrt> mterry: yes... but this is gross.
[16:06] <mterry> it is...?
[16:06] <desrt> mterry: precisely because this directory persists
[16:07] <desrt> so you'll have stale sockets littered about
[16:07] <mterry> not littered about.  at most.. one per user?
[16:07] <desrt> yes
[16:07] <mterry> who does that hurt?  :)
[16:07] <desrt> this is precisely the reason we try to move all sockets into the runtime dir and the same reason that sockets for system services are in /run and not /var/lib
[16:07] <desrt> ditto pid files
[16:08] <mhall119> jasoncwarner: seb128: sil2100: didrocks: there are several client track sessions created for UDS but they aren't scheduled yet, are you guys coordinating who'd going to do that?
[16:08] <seb128> mhall119, not that I know
[16:08] <mterry> desrt, I'm just leery of all the seemingly special-purpose protocol required in lightdm for this feature
[16:08] <desrt> mterry: don't blame you
[16:09] <mterry> desrt, can the user mount a tmpfs in lightdm-data?  :)  probably not
[16:09] <mhall119> jasoncwarner: seb128: sil2100: didrocks: can one of you manage your schedule?  Otherwise I can just place them myself, but I don't know your scheduling needs
[16:10] <seb128> mhall119, I can try having a look, things are quite busy though, LTS coming soon, lot of work, etc
[16:10] <desrt> mterry: i think either way we will want some support in lightdm for what we are trying to do... and i don't think the shared directory is the right thing to use here
[16:10] <mhall119> seb128: I understand, just trying to get this done as soon as possible, since it starts next week
[16:11] <desrt> the support could be very very small -- as much as an API that sends the fd of the shared directory via unix socket to the greeter
[16:11] <seb128> mhall119, yeah, I understand, I'm going to try to have a look, timing is just not great
[16:11] <mhall119> thanks seb128
[16:11] <desrt> (although this would prevent use of sockets, since afaik there is no connectat() equivalent)
[16:12] <mterry> desrt, I don't get why tmpfs is so much better.  It's not reboots that cause stale sockets.  We'd have that problem between user session instances (log out, log in later) just the same.  The socket just needs cleaning on shutdown or something
[16:12] <desrt> mterry: the xdg runtime dir is cleaned between sessions
[16:12] <mterry> desrt, really?  interesting.  logind does that?
[16:12] <desrt> that's the point -- its lifespan is limited to the user being logged in and it is guaranteed to be wiped between
[16:12] <desrt> yes
[16:13] <mterry> cute
[16:13] <desrt> we created this exactly because of these problems
[16:13] <seb128> desrt, what if you are logged in from a ssh and log out/in from the graphic session?
[16:13] <Trevinho> dobey: ahah, yeah, I know... I've still some higher prios now unfortunately, but it's quite on the top of my list :)
[16:13] <desrt> seb128: it persists as long as the user is logged in from anywhere
[16:13] <mterry> well, someone chmod those directories to 711 so that other processes can be passed paths into it
[16:13] <desrt> seb128: this is also why we want to move toward viewing the session bus as a user bus, rather
[16:14] <desrt> seb128: ie: this will finally solve the problem of someone doing ssh or console logging and typing 'gsettings set...'
[16:14] <desrt> it will find dbus via the socket in the user's xdg runtime dir and will talk to the dconf-service already in the user's session
[16:14] <larsu> biggest problem ever
[16:15] <seb128> larsu, heh, I get annoyed by it every now and then! ;-)
[16:15] <desrt> (or socket-based activate dbus and then dbus-activate dconf-service, if just logging in from console only)
[16:16] <desrt> larsu: can't tell if you're being sarcastic :)
[16:16] <Laney> I can :P
[16:16] <desrt> because really, i do consider this to be a very annoying problem
[16:16] <desrt> it means that people can't do a lot of things from cron jobs either, for example
[16:16] <dobey> Trevinho: ok. it's starting to drive me crazy
[16:17] <larsu> desrt: I was being sarcastic, but only because of your choice of example
[16:17] <larsu> clearly having such a bus is awesome
[16:17] <seb128> dobey, I guess you can downgrade unity as a workaround...
[16:17] <larsu> but not to ssh into my desktop machine and type gsettings set
[16:17] <desrt> larsu: meh... lots of advice on stackoverflow about "i hosed my session and i can't login...." "oh.. just do this gsettings reset command..." "uh... i can't do that outside of my session..."
[16:18] <larsu> really?
[16:18] <desrt> ya
[16:18] <larsu> if changing some gsettings keys hoses your session we're doing something wrong
[16:18] <desrt> i've particularly seen a lot of advice about certain non-viable compiz configs
[16:18] <larsu> ah. yeah. compiz. I understand.
[16:19] <desrt> seems like it's pretty easy to mess up badly with ccsm
[16:19] <mterry> seb128, desrt: well, I'm not opposed to some extra protocol for lightdm, but robert_ancell is the real owner there
[16:20] <seb128> mterry, desrt: I'm happy to start an email discussion about that, though I lost track of what desrt is suggesting, we went through a bunch of options/iterations in possible solutions
[16:20] <desrt> seb128: still two main suggestions... with the devil in the details, as always :)
[16:21] <seb128> desrt, still "get lightdm on the user bus" and "have a shared dir used for communication" (where the details being on what sort of ipc in the shared dir)?
[16:21] <seb128> where->with
[16:22] <desrt> seb128: specifically "have a subdirectory of xdg runtime dir visible to the greeter via a privileged protocol in lightdm"
[16:22] <seb128> let me write an email, you can reply with more details, then we can wait on robert_ancell to comment during his day
[16:22] <desrt> either via lightdm opening the files and sending the contents (and being responsible for change notification) or through some fd-passing scheme
[16:23] <Laney> I guess we still end up with a lot of stuff being stored in AS for the not-logged-in case
[16:24] <seb128> that's fine
[16:24] <desrt> ya... that's totally reasonable... it needs to be somewhere.
[16:24] <Laney> it's acceptable
[16:24] <desrt> kinda sucks that the API doesn't have all of the features that we got used to with gsettings
[16:24] <Laney> but it's not
[16:25] <Laney> yeah that
[16:25] <desrt> fwiw, it would be possible to wrap gsettings schemas around this API if we wanted
[16:26] <desrt> all you need to do is leave the default value out of the xml file that you install
[16:26] <desrt> accountsservice will throw an exception
[16:26] <desrt> and you can query the default value out of the schema (with overrides supported)
[16:26] <desrt> would be an interesting but fairly trivial exercise to write a gsettingsbackend for this
[16:26] <desrt> then you could just do g_settings_new_with_backend()
[16:27] <Laney> why do you need the exception thing?
[16:27] <desrt> this API can work in two ways
[16:27] <desrt> the first way is that you put a default value in the interface xml file you install
[16:27] <desrt> in which case Get is always successful -- and returns the default value, if none is set
[16:28] <desrt> the other way is that you put no default value
[16:28] <desrt> and then Get is only successful in the case that someone did a Set before.  if there is no value to return then you get an exception instead
[16:28] <desrt> this is useful because it lets you detect the "there is nothing set" case and handle the process of determining the default value manually
[16:28] <desrt> eg: via gsettings schema rules
[16:31] <Laney> doesn't seem like it would play so well with non-gsettings uses of the data
[16:32] <desrt> not unless they have some other way to figure out the default value for themselves
[16:32] <Laney> ya
[16:32] <desrt> but that's sort of the point, right?
[16:32] <desrt> if you want more control then you get more control...
[16:32] <desrt> we certainly don't want to get into a place where we're returning a default value and it's the wrong one
[16:33] <didrocks> mhall119: already we'll try, but as seb128 told, we are already maxing out and the timing doesn't help
[16:37] <Laney> 'you only get the right default if you use this interface via gsettings' seems weird
[16:37] <Laney> it's not that you don't know it, it's just stored in some place that AS can't access
[16:38] <Laney> seb128: will you put this thread on some ML?
[16:38] <desrt> Laney: this is pretty much dconf
[16:38] <desrt> literally: 'you only get the right default if you use this interface via gsettings'
[16:39] <desrt> in dconf's case you get NULL.  in AS's case you get a dbus error.
[16:39] <desrt> semantically exactly equivalent
[16:39] <seb128> Laney, do you feel like ubuntu-devel@ is appropriate?
[16:39] <desrt> "no value was set"
[16:42] <Laney> AS is an interface in its own right in a way that dconf isn't really
[16:42] <Laney> i dunno, maybe it's not that bad
[16:42] <Laney> it would be a nicer api
[16:43] <desrt> Laney: there is definitely more confusion here, i agree
[16:43] <desrt> since we have been telling people "call AS to get this value"
[16:43] <desrt> whereas with dconf we always told from the start "don't use dconf directly"
[16:45] <desrt> funny story about that, of course... dconf-editor was using dconf directly and in cases of overrides had the incorrect default value shown because of it...
[16:45] <desrt> so ya... bugs happen
[16:45] <kenvandine> those virtual armhf builders are a real pain... now the ubuntu-system-settings build keeps hanging
[16:45] <kenvandine> just stops logging anything... for hours
[16:45] <kenvandine> sigh...
[16:46] <seb128> :-(
[16:46] <seb128> Laney, you would prefer to have the discussion on ubuntu-devel@?
[16:46] <kenvandine> not sure if this is better than qemu crashes :)
[16:46] <Laney> seb128: sorry, forgot to reply
[16:46] <Laney> I don't mind, I was thinking phone but that might be ok
[16:47] <seb128> well, phone works but I'm unsure e.g desrt and robert_ancell are on it
[16:47] <seb128> I guess I can Cc them
[16:47] <Laney> yup
[16:47] <seb128> let's do that
[16:47] <seb128> thanks
[16:56] <Laney> Is there a LIM bug filed for the issue where they're always in the top panel at start? i.e. if you launch a non-maximised application
[16:59] <seb128> Laney, not that I know, but I don't follow all compiz bugs
[17:00] <Laney> will file
[17:00] <Laney> I have an update though, so better check that
[17:13] <Laney> args
[17:14] <Laney> what's happened? I can't focus windows
[17:16] <Trevinho> seb128: I should probably do it, but I'm quite busy... Can we have a mark on the scale of ucc for the monitor scaling factor?
[17:16] <seb128> Trevinho, we already have one?
[17:17]  * Trevinho is not that updated
[17:17] <Laney> I can click buttons and decorations but not focus anything
[17:17] <Trevinho> seb128: mh, no I don't see it at 1.0
[17:20] <seb128> Laney, sounds like you have a win taking focus somewhere
[17:20] <Trevinho> seb128: oh, I'm blind, it was there :D
[17:20] <seb128> Laney, like gome-keyring prompt
[17:20] <seb128> Trevinho, ;-)
[17:20] <Laney> probably, it could be off screen
[17:20] <Trevinho> but it's a recent change, right?
[17:20] <seb128> Laney, is it in the launcher?
[17:20] <Laney> I restarted the session now
[17:20] <seb128> Trevinho, https://launchpad.net/ubuntu/+source/unity-control-center/14.04.3+14.04.20140225-0ubuntu1
[17:21] <seb128> Trevinho, 10 days
[17:21] <seb128> or 9 rather
[17:21] <seb128> Trevinho, which is almost as recent as the feature :p
[17:22] <Trevinho> seb128: ok, my fault to keep my machine not that updated :)
[17:22] <Laney> ah, this time I do have a window
[17:23] <Laney> I guess this comes from eds
[17:23] <Laney> not sure why it's not using uoa
[17:24] <renato_> Laney, ping
[17:24] <Laney> hi
[17:25] <renato_> Laney, I tested your syncevolution package and it did not work with ubuntu online accounts
[17:25] <Laney> erm
[17:25] <seb128> Laney, syncevolution?
[17:25] <Laney> why did mardy tell me it worked?
[17:25] <Laney> why did mardy tell me that you told him it worked?
[17:25] <seb128> Laney, did you install that thing? maybe it's it prompting you :p
[17:25] <Laney> maybe
[17:25] <Laney> HAHA
[17:26] <Laney> I just got a shrinking terminator window
[17:26] <Laney> that was amazing
[17:26] <renato_> Laney, did you build that with "--enable-uoa" ?
[17:26] <Laney> yes
[17:26] <Laney> He told me that you tested the package and it worked
[17:26] <Laney> was that untrue?
[17:27] <Laney> Did you install syncevolution-provider-uoa?
[17:27] <renato_> no
[17:27] <renato_> let me check that
[17:30] <Laney> Actually I can't find where he told me that
[17:30] <Laney> did I make it up?
[17:30] <renato_> no I told him that works
[17:30] <renato_> now I found the problem
[17:31] <seb128> Laney, tedg, desrt, mterry, larsu: https://lists.launchpad.net/ubuntu-phone/msg06773.html
[17:31] <renato_> I had the file that this package " syncevolution-provider-uoa"  installed on my device from my build
[17:32] <tedg> seb128, Okay, I need to run now, but I'll reply after.
[17:32] <renato_> stop to work after I flash my device
[17:32] <Laney> renato_: so it's okay with that?
[17:32] <Laney> You can add a Depends for it or we can put it in the seed
[17:32] <seb128> tedg, thanks
[17:32] <renato_> Laney, when the package will land?
[17:32] <Laney> I already uploaded it
[17:33] <renato_> great
[17:33] <seb128> renato_, it's building, I'm going to binNEW the binaries once ppc/armhf are done
[17:33] <Laney> It'll wait in the queue for an ar
[17:33] <Laney> seb128 is a great guy!
[17:33] <seb128> ;-)
[17:33] <renato_> I will add "syncevolution-provider-uoa" as dependency into my project
[17:34] <Laney> okey dokey
[17:34] <renato_> thanks, and sorry for the confusion
[17:34] <Laney> no worries
[17:34] <Laney> I dunno why I can't find the message where he told me it was ok
[17:34] <Laney> scary
[17:34]  * Laney goes to test webkit
[17:35] <Laney> brave is not test building on arm64 first
[17:43] <kenvandine> seb128, i think the uss build hangs in the same place everytime, have you seen that before?
[17:43] <kenvandine> 2/4 Test #2: tst-arguments .................... Passed 0.07 sec
[17:43] <kenvandine>     Start 3: tst-update-manager
[17:43] <kenvandine> seems to be that one test hanging...
[17:43] <kenvandine> last time i let it run for 2 hours
[17:43] <seb128> kenvandine, no, never
[17:44] <seb128> works fine in CI, jenkins, local...
[17:44] <kenvandine> just in qemu of course... so much fun
[17:44]  * kenvandine might just disable the tests for the preview ppa... hate doing that
[17:44] <kenvandine> i know tests pass :)
[17:49] <seb128> kenvandine, turn off arm in the ppa ;-)
[17:49] <kenvandine> it's the most important arch for this preview!
[17:49] <Laney> do it in canonical-arm-dev and copy it over
[17:50]  * kenvandine didn't know about this ppa...
[17:50] <kenvandine> good idea
[17:50] <Laney> you need access, ogra can sort that out
[17:51] <kenvandine> or i can just disable tests in this PPA for now... we know CI tests pass
[17:52] <kenvandine> and hopefully it'll only be for a week or so
[17:53] <Laney> maybe you broke the tests :-)
[18:01] <Laney> webkit'd
[18:01] <Laney> if it works on the arches I didn't test build for (arm64, powerpc) then I'll owe the gods one beer
[18:01] <Laney> & ppc64el
[18:01] <seb128> hehe
[18:02] <xnox> Laney: canonical-arm-dev, what does that do? looks like red-carpet of A-list developers
[18:02] <Laney> it's a devirt ppa
[18:02] <Laney> I use it for test building hardcore stuff like webkit
[18:03] <rsalveti> you could also use silos if you want for that
[18:03] <rsalveti> if you're trying to land something
[18:03] <kenvandine> rsalveti, not yet, next week
[18:03] <Laney> yeah as a fancy way to get a devirt ppa
[18:03] <Laney> but you have to use the archive versions there
[18:03] <kenvandine> rsalveti, and  we want to get the gallery as click landed first
[18:03] <Laney> it's easier for me to go for manual uploads
[18:04]  * Laney needs to go give blood now, ttyl
[18:04] <rsalveti> right
[18:10] <seb128> Laney, good luck
[18:18] <didrocks> in the evening?
[18:18] <didrocks> that country really does everything on the wrong side :)
[18:34] <desrt> tkamppeter: hey... do you have some examples of complex pdf files around?  ones with lots of complicated vectors graphics with lots of curves, etc?
[18:37] <tkamppeter> desrt, I will look, for what do you need them?
[18:37] <desrt> tkamppeter: performance testing...
[18:38] <desrt> actually.. it just occured to me that cairo may have some test data
[18:38] <seb128> desrt, http://www.nist.gov/el/nzertf/upload/NZERTF-Architectural-Plans1-June2011.pdf ?
[18:38] <desrt> seb128: too simple :p
[18:39] <seb128> bah :p
[18:39] <desrt> cairo does indeed have some built-in performance tests
[18:42] <tkamppeter> desrt, you should have a nice PDF showing the parking zones in Berlin now, nice to watch (but it is not a video) ...
[18:47] <tkamppeter> desrt, did you get my mail?
[18:48] <desrt> yes.  thank you.
[18:49] <desrt> still waiting for evince to finish opening it :)
[18:50] <tkamppeter> desrt, you will see on the screen how Berlin's streets get built, should be faster than the building of the real streets ...
[18:51] <desrt> tkamppeter: thanks for not sending me a map of the new airport...
[18:52] <tkamppeter> desrt, this will take decades even on Sweetshark's 42-core machine ...
[18:52] <tkamppeter> s/42/32/
[19:01] <dobey> hmm. do-release-upgrade is not a very good judge of connection speed i guess (though i'm glad it was wrong)
[19:03] <mhall119> seb128: is there a script or instructions I could use to create my own bootable/live Ubuntu ISO?
[19:03] <mhall119> I know it's something with debootstrap and seed files, but I don't know how it all goes together to make an image
[19:03] <mhall119> this is for desktop, btw
[19:05] <dobey> mhall119: i know there are a *lot* of questions about that exact process, on askubuntu. so i'm sure more than one of them points at the appropriate wiki page (though i don't know what that page is) :)
[19:06] <seb128> mhall119, I don't know
[19:06] <seb128> mhall119, google points to https://help.ubuntu.com/community/LiveCDCustomization
[19:07] <seb128> mhall119, but I don't know how outdated that is
[19:07] <seb128> you better ask on #ubuntu-devel
[19:08] <mhall119> ok, thanks seb128
[20:00] <ochosi> hey robert_ancell
[20:00] <robert_ancell> ochosi, hello
[20:01] <ochosi> i'm involved with light-locker a bit, so i quickly wanted to ask you something as we were planning a new lightdm based feature
[20:01] <ochosi> the VT-switching is a bit annoying when locking the screen and there are still many desktops that will take a while until they'll have a lockscreen in the compositor
[20:02] <ochosi> so i was wondering whether we couldn't just start a greeter in the currently running VT as toplevel window
[20:02] <thumper> Trevinho: ping
[20:02] <ochosi> basically "emulate" lightdm and add some PAM magic
[20:02] <ochosi> robert_ancell: or would you say that's a really terrible idea? ^
[20:03] <thumper> Trevinho: just wondering if it is possible to have some loopback devices not show in the unity launcher
[20:03] <robert_ancell> ochosi, there's too many security issues in doing that unfortunately. We did look at that at one point
[20:04] <robert_ancell> ochosi, if you were to go that method it's better for the shell to launch a lock screen
[20:04] <thumper> Trevinho: I'm making two or three loopback files and then making btrfs with them, and mounting elsewhere
[20:04] <thumper> however some show in the launcher, and I don't want them there
[20:04]  * thumper afk for a bit but back later
[20:04] <Trevinho> thumper: hi!! isn't the quicklist item to hide from launcher working for you
[20:07] <ochosi> robert_ancell: what kind of security issues did you encounter on that route? (we'd launch it from light-locker directly, so basically standing on gnome-screensaver's security shoulders)
[20:09] <robert_ancell> ochosi, I was thinking the other direction (launched by the daemon)
[20:10] <ochosi> robert_ancell: what daemon? you mean light-locker's daemon? or lightdm?
[20:10] <robert_ancell> ochosi, the lightdm daemon
[20:10] <robert_ancell> ochosi, in that case, you need a method to access the authentication routines from the daemon, but since the daemon didn't launch you it's hard to ensure that light-locker is a valid client
[20:11] <robert_ancell> ochosi, you could go the gdm route and provide these interfaces to the session and they are claimed by the first thing to request them (designed to be the shell)
[20:11] <robert_ancell> in this case you couldn't wait until light-locker started because another app could claim them before that
[20:12] <ochosi> or just make the locker call the greeter and make it act as if it were lightdm?
[20:13] <ochosi> (since light-locker is designed to be DE independent, we can't really go the session/shell way)
[20:16] <ochosi> robert_ancell: ^
[20:17] <robert_ancell> ochosi, right, but you can't do all the things a full greeter wants to do, e.g. authenticate as other users
[20:17] <ochosi> robert_ancell: yeah, that's a small problem, there'd have to be a "switch-user" button
[20:17] <robert_ancell> ochosi, for Unity 7 we modified g-s to be more like unity greeter. But it can't do all the features
[20:18] <ochosi> robert_ancell: but i'd implement that in lightdm-gtk-greeter
[20:18] <robert_ancell> ochosi, but yes, we looked at making g-s launch u-g in a "user mode"
[20:18] <ochosi> robert_ancell: woot? someone in this channel told me it was written from scratch :p
[20:19] <robert_ancell> ochosi, no, it was a big hack. We've scrapped that and there is a for-scratch implementation for Unity shell instead
[20:19] <robert_ancell> ochosi, completely doable as long as you make your greeter able to handle both in session and standalone
[20:19] <robert_ancell> ochosi, you have to potentially watch out for things like the session setting a different theme
[20:20] <ochosi> robert_ancell: well the theme is set in the greeter's config, so it's not getting "picked up" by the greeter anyway
[20:20] <ochosi> robert_ancell: but yeah, good to hear it's doable
[20:20] <robert_ancell> ochosi, then you have to make sure it doesn't set the session theme :)
[20:20] <ochosi> robert_ancell: hehe, yeah :) well i've done some of this already, e.g. setting special blank times only for the greeter (and reverting them when exiting)
[20:21] <ochosi> robert_ancell: basically the idea is to mold lightdm-gtk-greeter and light-locker into a lightdm locking/user-switching team
[20:21] <robert_ancell> ochosi, so the conclusion from our side was, the most reliable experience using VTs is to make an in-session lock screen that looks like a greeter (though the design people wince that being almost the same can be a worse user experience than being different)
[20:22] <robert_ancell> ochosi, and when we can do proper multi-session without VTs then we get the full experience
[20:22] <ochosi> robert_ancell: yeah, ofc it would be easy to fork g-s and just make it look like the greeter, but then again that isn't very flexible...
[20:22] <ochosi> robert_ancell: understandable, i don't see that perspective for e.g. xubuntu in the near future though (xfce is still gtk2)
[20:23] <robert_ancell> ochosi, I'm open to the idea of having a special interface to the session to allow in session greeters more power (like GDM). But wary about the security considerations / complexity so not pushing it myself
[20:24] <robert_ancell> ochosi, I hope once the post X stack dust settles it will be clearer if we can just use LightDM as is using reliable session switching
[20:25] <ochosi> robert_ancell: ok, great! if you don't mind i might ping you about this again once we've gotten a bit further with light-locker on that front
[20:25] <robert_ancell> sure, please do
[20:25] <ochosi> robert_ancell: i presume the results of your experiments with g-s arent publicly available (or available at all)?
[20:25] <robert_ancell> ochosi, I'll find the branch
[20:25] <ochosi> thanks!
[20:26] <robert_ancell> ochosi, lp:~robert-ancell/gnome-screensaver/unity
[20:27] <robert_ancell> it's one big patch from a git branch I never pushed anywhere (cause I've never learned/liked enough github to push it)
[20:27] <ali1234> it would be trivial to make xfwm compositor handle the lock screen
[20:27] <ali1234> the problem is not everyone has the compositor enabled
[20:27] <robert_ancell> I've been running it for months now. The experience is a lot better than the old gnome-screensaver
[20:30] <ali1234> does mir support libwnck?
[20:30] <ochosi> robert_ancell: ok, great, will take a look at this
[20:31] <robert_ancell> ali1234, I don't think so. The current work is for the phone which doesn't need that. They're working on window management (i.e. desktop) functionality now
[20:31] <robert_ancell> ali1234, you can ask in #ubuntu-mir if you need more info
[20:32] <ali1234> well, ideally i need to know if it's part of mir, or something baken into unity8 shell
[20:32] <ali1234> it's not part of wayland by design, every compositor has to implement it - and currently none do
[20:34] <ali1234> as i understand it, KDE's wayland session doesn't support native clients for this reason
[20:35] <ali1234> it's rather difficult to get any information on this because of bunker mentality from all sides
[20:40] <robert_ancell> ali1234, are you asking if the functionality of libwnck is baked into Mir?
[20:40] <robert_ancell> which functionality exactly/
[20:40] <ali1234> no, i'm asking if mir defines the protocol required for libwnck to work at all
[20:40] <robert_ancell> ?
[20:40] <ali1234> functionality such as the ability for a client to get a list of other client's windows
[20:40] <robert_ancell> ali1234, ok, I know this one
[20:41] <ali1234> all the stuff you need to build a panel that is a separate process to the shell/compositor
[20:41] <robert_ancell> ali1234, so that information is not currently exposed in the Mir protocol by design because that leaks information between processes. It is exposed in the library interface between the shell (i.e. Unity 8) and libmirserver
[20:42] <robert_ancell> ali1234, last I heard it was the responsibility of the shell to provide a (secure) interface to that privileged information to other processes that might need it (e.g. a panel)
[20:42] <ali1234> so identical to wayland
[20:42] <robert_ancell> ali1234, yes
[20:43] <robert_ancell> ali1234, do you want the information for a third party panel?
[20:44] <ali1234> yes
[20:44] <ali1234> basically, i want libwnck to work
[20:44] <ali1234> because that is what all panels use
[20:44] <ali1234> (except unity and gnome shell of course)
[20:45] <robert_ancell> ali1234, yeah, that's the old X world. I think the post X world is going to be more like
[20:45] <robert_ancell> 1. Some shells will just not allow that
[20:45] <ali1234> (when you run them on mir/wayland respectively)
[20:45] <robert_ancell> 2. Some shells will allow that through plugins (e.g. GNOME)
[20:46] <robert_ancell> 3. Some (probably not mainstream) shells will allow all sorts of extensibility by providing interfaces and trading security for flexibility
[20:46] <mhall119> seb128: do you mind if I move the one client meeting I created (API website for Unity docs)?
[20:46] <ali1234> yes, basically every shell will define an incompatible protocol for this
[20:46] <mhall119> from Tuesday to Wednesday
[20:46] <robert_ancell> ali1234, hopefully someone will make a standard, but you're probably right
[20:46] <seb128> mhall119, that's ok, thanks for checking
[20:47] <seb128> mhall119, the schedule is quite empty anyway, so it's not going to create lot of issues
[20:47] <robert_ancell> seb128, can you reliably reproduce that switching bug? I think I understand it and have a fix
[20:47] <ali1234> this will pretty much prevent anyone from using wayland except as a backend renderer for X
[20:47] <mhall119> well I couldn't very well bug you about scheduling them and then go changing it without asking now can I :)
[20:47] <ali1234> unless they're just using a phone or a tablet or something
[20:47] <robert_ancell> ali1234, or GNOME or KDE or Unity...
[20:47] <robert_ancell> ali1234, the mainstream shells want this. It makes things more secure and reliable
[20:47] <ali1234> as I said, KDE can't handle native wayland clients for this reason
[20:47] <seb128> robert_ancell, not sure, I stopped switching users because of it, but I was hitting hit every few switches before, so if that didn't change, "yet"
[20:47] <seb128> "yes"
[20:48] <robert_ancell> seb128, ok, I'll flick you a branch later and see if it helps
[20:49] <seb128> robert_ancell, ok, drop me an email, I'm not likely to try a fix today, but tomorrow is fine ... what's the issue (I'm curious)
[20:50] <robert_ancell> seb128, I think it's because lightdm kills the child sessions before they exec(), and this means that the SIGTERM is sent back to the daemon and interpreted as coming from itself. The reason we're seeing this is unity-greeter seems to do two authentications in quick succession (which is allowed but shouldn't)
[20:50] <robert_ancell> it's fun with racing with signals and forks
[20:50] <seb128> is that something new?
[20:51] <seb128> because it was not happening at all early in the cycle
[20:51] <robert_ancell> seb128, I think the u-g bug must be new which is triggering it
[20:51] <seb128> k
[20:51] <robert_ancell> but it would have existed
[20:52] <seb128> let me check how easily I can trigger, or not trigger, the issue
[20:56] <seb128> robert_ancell, didn't happen with a few switches, but let's see over a few days with your changes, I usually have it at least once a day
[20:57] <robert_ancell> seb128, k
[21:01] <ali1234> robert_ancell: btw, "Some shells will allow that through plugins (e.g. GNOME)" sounds a lot like X extensions to me :P
[21:01] <robert_ancell> ali1234, yep
[21:04] <thumper> Trevinho: it says "unlock from launcher", not entirely obvious
[21:04] <thumper> clicking on one removed both
[21:04] <Trevinho> thumper: mh I agree...
[21:04] <Trevinho> but that's what has been designed :)
[21:04] <Trevinho> thumper: mh, weird, iirc it dpeends on the disk label
[21:04] <thumper> hmm... I didn't know it was "locked"
[21:04] <Trevinho> thumper: or uuid...
[21:05] <Trevinho> probably it should mention "icon"...
[21:05] <thumper> I'm making multiple loopback devices, using "losetup"
[21:07] <desrt> xnox: *fight*
[21:47] <mhall119> seb128: I used a client room for some appdev track session that really are more client/phonedations oriented than app developer oriented
[21:48] <mhall119> since you weren't using those slots anyway, I'm assuming you wouldn't mind :)
[21:48] <seb128> mhall119, well, you still have slots on your track...
[21:49] <ochosi> robert_ancell: just saw that the branch you pointed me to is one where gnome-screensaver looks like unity-greeter, i was wondering whether there was anything left from your experiments with calling unity-greeter in the same VT instead
[21:50] <seb128> mhall119, if the schedule doesn't get more packed I guess it's ok to host a few sessions for you guys, but it doesn't seem to be topic we especially know about or own
[21:52] <robert_ancell> ochosi, no, didn't go very far with those
[21:53] <mhall119> seb128: it looks to be mostly sessions for bill
[21:54] <ochosi> robert_ancell: ah ok, well good to know that we won't be duplicating code though :)
[21:54] <seb128> mhall119, right, who has nothing to do with "client" afaik ;-)
[21:54] <seb128> mhall119, we should maybe get bill to host a track if he has enough sessions for that...
[21:54] <mhall119> well they're not sessions for app developers either...
[21:54] <mhall119> how is it not client though?
[21:56] <mhall119> I can always make bill a track lead on client :)
[21:56] <seb128> mhall119, that would be nice
[21:56] <seb128> my main issue is that we "lock" people to host tracks who have nothing to do the topics hosted
[21:57] <seb128> like client hosts are going to be me and didrocks
[21:57] <mhall119> right, same with app dev track typically
[21:57] <seb128> but nobody in desktop works on any of the sessions you move to our track
[23:31] <xnox> desrt: =))))) our default compiler targets c89 ;-) and even with using -std=c99 or /usr/bin/c99 you'd get by default all of these bugs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16989
[23:31] <ubot2`> gcc.gnu.org bug 16989 in c "[meta-bug] C99 conformance bugs" [Normal,New]
[23:31] <xnox> desrt: (that meta-blocking bug is also the reason why gcc is still stuck on c89/gnu89 as the default)
[23:32] <xnox> desrt: i'm sorry about sad time you had with glib =( but you get to bash everyone about AC_PROG_CC_C99 =))))
[23:32] <xnox> from now on.
[23:40] <desrt> xnox: fwiw, i'd say c89 is actually stricter than c99
[23:40] <desrt> since there is no mention of excess precision there
[23:42] <desrt> (and for lack of a mention, one can only follow the ieee spec)
[23:43] <xnox> desrt: =))) i've fetched up c89 copy and i didn't quite manage to gather if the reproducibility is explicit or not. I thought c89 doesn't refer to the ieee spec (as in it's not required to implement the ieee for a c89 compliant compiler)
[23:43] <desrt> oh... so you can do anything at all for c89?
[23:43] <desrt> 1 * 1 = 42
[23:44] <xnox> yeap.
[23:44] <desrt> handy.
[23:44] <desrt> looks like you win this round >:|
[23:44] <xnox> desrt: well, you are multiplying ints, thus it would be 1. But 1.0 * 1.0 can give you 1.00000132
[23:44] <desrt> but seriously... assert(func(a) == func(a)) should not fail :p
[23:45] <xnox> desrt: that's why libnih and upstart use AC_PROG_CC_C99 =)))) otherwise it would assert and fail _a lot_ of things.
[23:46] <desrt> i wonder how much would break if i tried to use this with glib...
[23:46] <desrt> we use a lot of gnu features
[23:46] <desrt> but they're mostly still accessible if you add some extra underscores or something
[23:47] <desrt> xnox: AC_PROG_CC_C99 is a useful hint though... thanks for that
[23:47] <desrt> xnox: do you know what happens if it fails to find a strictly c99 compiler?
[23:47] <desrt> will it settle for a normal cc?
[23:48] <desrt> we don't strictly depend on c99 for a lot of reasons (*cough* windows), and i don't want to break existing systems
[23:49] <xnox> desrt: read the docs, that pragma enables c99 mode, if the compiler by default is not using it. Thus i believe for gcc it actually pushes it from -std=gnu89 to -std=gnu99. But let me check here.
[23:50] <xnox> desrt: yeap -> checking for gcc option to accept ISO C99... -std=gnu99
[23:50] <desrt> cute.
[23:50] <desrt> i wonder if that is enough to get the strict FP behaviour though
[23:50] <desrt> manpage only says it gets enabled with -std=c99
[23:50] <desrt> gnu99 might be exempt still
[23:50]  * desrt checks
[23:51] <desrt> ya... still crashes with gnu99
[23:51] <desrt> yay for "extensions"
[23:54] <xnox> desrt: lolz. surely there is an autoconf macro to do what you want.
[23:54] <desrt> ya... one that builds a test program and runs it and aborts ./configure if it fails, with a message for the user to check their CFLAGS :)
[23:55] <desrt> xnox: i'll look into this later.  dinner for now
[23:55] <desrt> i do think we should reevaluate for next cycle, in any case....
[23:55] <desrt> thanks for the input
[23:58] <xnox> desrt: the standard reply would be to rebuild the archive with gnu99 and/or c99 and see what breaks. The fact that clang implements gnu extensions and adds its own does not help the cause to switch to c99 =/


[10:40] <binBASH> Hi all could anyone look into https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1318551 please? There seems to be an issue with CONFIG_SCHED_AUTOGROUP causing system bootup to fail mostly with kernel panic
[10:40] <ubot2`> Ubuntu bug 1318551 in linux "Kernel Panic - not syncing: An NMI occurred, please see the Integrated Management Log for details." [High,Confirmed]
[10:49] <mnencia> binBASH: sometime with kernel panic, sometime not, but the system become so slow that it cannot even spawn a process
[10:49] <binBASH> mnencia: yup
[11:26] <apw> binBASH, this seems to be the -release pocket kerenl, ie not upgraded ?
[11:26] <apw>  [203930.174171] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0-24-generic #46-Ubuntu
[11:27] <apw> does this occur with the latest kernel in -updates ?
[11:44] <binBASH> apw: tested it also with some of the nightly kernel builds from 3.15.x series, happens there also
[11:44] <apw> binBASH, is there an older kernle which did not show this issue?
[11:45] <apw> binBASH, did we try the latest 3.13 though?  that has a heap of stable updates on it
[11:46] <apw> from anywhere up to 3.17
[11:51] <binBASH> apw: The only thing I got currently to answer this is kernel installation history => http://pastebin.com/raw.php?i=bxqAtDaN and yes I think it didn't appear on 3.11
[11:54] <apw> binBASH, ok add that info to the bug, as it was introduced quite recent, a gross bisect would be the first step, to test with the mainline kernels between 3.11 and 3.13
[11:54] <apw> ie confirm it as in v3.13 and not in v3.11.<latest>
[11:54] <apw> and then test v3.12.<latest>
[11:59] <apw> get what you can test into the bug, and we can drive it from there
[14:05] <kirkland> hey team -- I'm having a bunch of problems with USB on an Intel NUC where I just installed Utopic
[14:05] <kirkland> actually, I've been working with jsalisbury on some regressions on the Trusty updates kernel, which seems to be going in the wrong direction, on the same hardware, with respect to USB
[14:58] <apw> kirkland, bug #?
[14:59] <kirkland> apw: I suspect it's part of or related to Bug #1350480
[14:59] <ubot2`> Launchpad bug 1350480 in linux "[REGRESSION] Kernel update renders Intel NUC (i5-3427) unbootable with USB devices plugged in" [High,In progress] https://launchpad.net/bugs/1350480
[15:01] <apw> kirkland, ok, the last thing in there was a test kernel with a proposed upstream fix applied, did that work ?
[16:51] <smoser> rtg, did i give information needed at https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1355196
[16:51] <ubot2`> Ubuntu bug 1355196 in linux "compiz fails with intel_do_flush_locked failed: Invalid argument" [High,Confirmed]
[17:30] <rtg> smoser, I've had some upgrade issues on a couple of laptops and found that a re-install worked just fine. how about booting a Live USB to see if that is your case ?
[17:30] <rtg> I had the same symptoms, e.g., blanks screen after lightdm login
[17:30] <smoser> that doesnt seem likely. i reprodue with the 'guest' user.
[17:30] <smoser> possibly it could be config in /etc/ somewhere i guess.
[17:32] <Sarvatt> i just updated the bug, seems like a problem on that whole generation of gpus on 3.16..
[17:32] <rtg> Sarvatt, is it a GM45 ?
[17:32] <Sarvatt> yup
[17:32] <rtg> ah, one of the old ones
[17:32] <Sarvatt> theres a fix in 3.17 thats cc:stable but its not in the queue yet
[17:33] <rtg> Sarvatt, I was googling this bug earlier today (got distracted), but noticed that patch.
[17:34] <rtg> Sarvatt, I think I saw it in the 3.16.x review pile, so it'll appear by about tomorrow in stable
[17:35] <Sarvatt> figured it woulda been in https://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/tree/queue-3.16
[17:36] <Sarvatt> yeah i dont see it in https://lkml.org/lkml/2014/9/3/918
[17:37] <Sarvatt> may want to manually pick it up, thats a pretty darn nasty bug
[17:37] <rtg> Sarvatt, already done
[17:40] <rtg> smoser, I'm gonna upload today, so give 3.16.0-13.19 a try when it becomes available tomorrow.
[17:41] <Sarvatt> found a few dupes, its been busted since july, eww
[17:41] <rtg> Sarvatt, did you mark 'em as dupes against 1355196 ?
[17:42] <Sarvatt> yeah, figured you used that buglink
[17:42] <rtg> yup
[20:10] <BjoernC> ^^


[19:23] <ibeardslee> morning
[19:25] <Atamira> morning
[20:17] <olly> morning
[20:25] <snail> morning
[20:39] <mwhudson> morning
[20:54] <hads> morning
[20:59] <snail> I'm so tempted to write a script to use https://fyi.org.nz/ to log a request with every government department saying "The NSA has been revealed to be corrupting security standards (link, link link). Does the department rely on NSA influenced standards for protecting the personal information of New Zealanders? Is the department taking any steps to wean itself off the known-corrupt influences?"
[21:00] <snail> starting with the ACC and DIA
[21:01] <ajmitch> you're assuming that they protect the information & don't just lieave it sitting on a public network share
[21:01] <mwhudson> when the departments in question are sharing information by emailing excel spreadsheets around, there are bigger problems i think
[21:16] <thumper> morning
[21:34] <chilts> morning


[13:21] <wonko> Is there a way to send a dbus message that'll trigger msg_cb_new? There appears to be a bug in it, but it's hard to check because I need to wait for it to happen
[13:37] <wonko> Oh, I think I got it
[13:37] <wonko> JACK was getting set to False and not starting
[13:38] <wonko> so tweaked that and now it's good
[13:38] <wonko> It's all pushed up
[13:38] <wonko> and as far as I can currently tell (unless an error pops up while it's running) it should be good to go.
[13:40] <wonko> https://code.launchpad.net/~ubuntustudio-dev/ubuntustudio-controls/+git/ubuntustudio-controls/+merge/374143
[13:41] <wonko> We can start tracking stuff here
[15:12] <OvenWerks> wonko: I didn't get a chance to pull it yesterday, will do so now.
[15:27] <wonko> No worries
[15:27] <wonko> Merge request in
[15:27] <wonko> Think I got everything sorted
[15:29] <OvenWerks> autojack line 304 looks wrong.
[15:32] <wonko> Ok, I'll take a look when I get home in a few
[15:32] <OvenWerks> I will look further too.
[15:32] <OvenWerks> I am not sure if it is a mistake from before.
[15:42] <OvenWerks> Ok I know what and why that line does what it does...
[15:43] <OvenWerks> It compares the PID using the capture device to the PID using playback device and if they are the same... then jack owns it.
[15:45] <OvenWerks> This may not be strictly true and it may be better in the long run to actually check if that PID belongs to jackdbus.
[15:48] <OvenWerks> In this context it probably doesn't matter or is a good test anyway. If some other program is using it other than jack... we should probably leave it alone rather than killing the pid (someone's project?) and starting zita-ajbridge :)
[16:14] <wonko> Yeah, that's not a line I touched so I'm claiming not my problem> :)
[16:30] <OvenWerks> I have found some other things... likely my own logic and have made some changes. I am now looking through connect_pa and wondering where my head was that day...
[16:32] <OvenWerks> but there were some places where we were not replacing the old config with the new soon enough :P so I have fixed that.
[16:34] <OvenWerks> The layout of device is in notes.txt in the main directory, but is not clear enough for someone else to understand well and I am thinking it should be right in the autojack file.
[16:58] <wonko> Let's not get too ahead of ourselves
[16:59] <wonko> is a re-write something to be seriously considered?
[16:59] <wonko> if so we should definitely plan that out
[17:11] <OvenWerks> I would like a c++ like struct for each device so I could do device.name device.is_usb device.sub_no device.sub(1).name device.sub(1).has_play etc.
[17:11] <OvenWerks> I supose I could have global name = 0 global is_usb =1 etc :P
[17:12] <OvenWerks> but an object would be much nicer and much more readable.
[17:13] <OvenWerks> even enums would be better... lets rewrite in c++ :)
[17:13] <OvenWerks> we could use waf to build it... Eickmeyer would like that :)
[17:19] <wonko> I'm down for C++ or Go or whatever. I really dislike Python. :)
[17:21] <OvenWerks> packaging anything that needs compiling is at a whole other level. it means learning autobuild or something so it can be multi arch.
[17:22] <OvenWerks> It would mean we can use fltk instead of gtk.... which does mean not having to worry about gtk 4 when it shows up.
[17:22] <OvenWerks> That is how we lost GCDMaster.
[17:22] <wonko> I do DevOps for a living. autobuild is my thing. :)
[17:23] <wonko> Of course I'd have to learn whatever janky shit Launchpad uses, but that shouldn't be so bad.
[17:24] <OvenWerks> The other part of c++ vs python is that are likely to be people around who can maintain python in the Studio dev group, c++ is less certain
[17:25] <wonko> I do totally get that point. I just don't like it. It seems like an artifical limitation
[17:25] <wonko> "Write it in whatever language you like, as long as it's Python"
[17:25] <wonko> sounds Ford-ish. :)
[17:26] <OvenWerks> wonko: in some ways I would like to make controls more generic to work outside of ubuntu as well, but I have looked at what Cadence had to do to make it generic... more if statements than I want to think about.
[17:27] <wonko> The joys of cross-distro
[17:27] <OvenWerks> wonko: any time one deals with system stuff it gets that way.
[17:28] <wonko> Yeah, but it's worse in the Linux world than anywhere else.
[17:28] <OvenWerks> is there anything else?
[17:28] <wonko> That people use on their desktops other than Windows, OSX or Linux? Yes.
[17:28] <wonko> Large market share? Nope.
[17:29] <OvenWerks> windows is just that example you get with the computer so it looks like it works, its meant to be removed before the computer is actually used.
[17:30] <wonko> hahahahahaha. That++
[17:31] <OvenWerks> OSX? out of my price range, maybe corperations can afford that stuff, not me.
[17:31] <wonko> But the point I was making is, to be truly cross-compatible (ignoring windows for the time being) you have to port to 3 or 4 versions of unix and like 47 versions of linux.
[17:32] <OvenWerks> yup.
[17:33] <wonko> It's frustrating to me because what is the point? Why muddy the waters just because you think things belong somewhere else?
[17:33] <wonko> Anyway, enough of that. :)
[17:34] <OvenWerks> well there is systemd and initv, upstart has gone.
[17:34] <wonko> Which is unfortunate
[17:34] <wonko> I liked it a lot better than systemd
[17:34] <OvenWerks> systemd is pretty standard these days
[17:34] <wonko> that doesn't make it not horrible
[17:35] <OvenWerks> anyone who uses an init v system is not going to use controls anyway, cause they have their own script in sh (not bash)
[17:35] <wonko> heh
[17:35] <OvenWerks> (its called slackware)
[17:38] <OvenWerks> Anyway, for now I am going to make things work. connect_pa() looks wrong to me. I think it has been working because my system is sane with my thinking.
[17:40] <wonko> co-worker tried to get me to run slackware a couple years ago. Two days of that was enough for me.
[17:40] <OvenWerks> The configparser branch is a mess... I may compress it.
[17:40] <OvenWerks> (once it is working)
[17:41]  * OvenWerks ran slackware for over 10 years from 1995 till mid 2000s
[17:44] <wonko> yeah, I recommend rebasing it down to a single commit
[17:45] <wonko> Old me would have loved slackware. New me has better things to do with his time.
[17:45] <wonko> I was on Solaris back then. :)
[17:45] <OvenWerks> I still like a lot about fvwm
[17:46] <wonko> I'm an OpenLook kinda guy
[17:47] <wonko> Although I did use fvwm for a long while after switching away from Solaris
[17:48] <wonko> Anyway, no more talking until you've reviewed and approved the merge request. :)
[17:48] <OvenWerks> My main thing is A) the window with focus should be obvious... like a whole different contrasting colour. B) the window handles should be easy to find and grab
[17:49] <wonko> I'm all for A. I never know which window is active in xfce. :)
[17:49] <OvenWerks> That is the first thing I change.
[17:50] <OvenWerks> gnome is worse... they take away the title bar.
[17:50] <wonko> I stuck with gnome for a while when installing 18.04
[17:50] <wonko> but then I remembered xfce was better. :)
[17:51] <wonko> While you do that I'm going to beat my face into kubernetes
[18:26] <OvenWerks> wonko, Eickmeyer: with regard to policy for controls, right now whichever device the user chooses for pulse to connect it's outputs to is used as the input to connect to pulse as well. I am thinking that probably this shouold not be true.
[18:27] <Eickmeyer> OvenWerks: Agreed. It's an OK default, but to have an option to connect the outputs to a different device as inputs isn't a bad idea.
[18:28] <OvenWerks> The gui lists it as output device so the user would not expect inputs to follow.
[18:28] <OvenWerks> I thnk for now I will set input to system capture
[18:29] <OvenWerks> Eickmeyer: but yes in future they will be totally separate... I can't change that now though because the config option is not there yet :)
[18:31] <OvenWerks> The main reason for letting the outputs be settable is that the user probably has only one set of physical outputs connected to amp and speakers. So the sound shouold always go there from pulse regardless of what else is set up
[18:32] <OvenWerks> So if the user selects their usb mic as system, the output can remain through internal speakers/phones
[18:49] <OvenWerks> wonko: I have looked through the code and made some changes (mostly to my own code) but I can't test it just now as I am not at the right computer.
[18:50] <Eickmeyer> OvenWerks: Understood.
[18:50] <OvenWerks> It will be probably another 3 hours before I can do that after the Yf leaves for work.
[19:37] <wonko> Yf?
[19:38] <wonko> No worries, I've got things to do. Like my job and stuff. 🤣
[22:06] <OvenWerks> something with xdev is not working
[22:08] <OvenWerks> changing other internal devices and hitting apply (reconfig) does not change that. But if I then change the usb bridge setting and reconfig, then the xdev setting is picked up and of course restart jack works too.
[22:13] <OvenWerks> Hmm line 312 in autojack
[22:18] <OvenWerks> Fixed.
[22:42] <OvenWerks> ewyuck...
[22:43] <OvenWerks> my logic is weird
[22:43] <wonko> Yes
[22:43] <wonko> :-P
[22:44] <OvenWerks> wonko: in config chnage we really should be doing oldconfig as a save of the old and writing the new config to config.
[22:45] <OvenWerks> in reconfig
[22:45] <OvenWerks> that is
[22:45] <wonko> Yeah, I wanted to do that but I felt it better to leave it alone for now
[22:46] <wonko> You should be able to do oldconfig = config and then instantiate a new config.
[22:46] <OvenWerks> can we do a oldconfig = config, get config?
[22:46] <OvenWerks> How hard is it to copy the whole config?
[22:47] <OvenWerks> wonko: either i need to change it now or I have to make a bunch of old_param things to make it work.
[22:48] <OvenWerks> if I add the first internal audio device as an XDEV it works, but if I add any other it doesn't
[22:49] <wonko> We should be able to but I'll need to look at the code.
[22:49] <wonko> Xdev is probably wonky as hell if I'm guessing right
[22:50] <wonko> This is where it would be nice if the config file supported complex data so we could just store a list instead of this back and forth to a string nonsense
[22:51] <OvenWerks> Actually it is the pulse_in/out as well
[22:51] <OvenWerks> or it will be.
[22:52] <OvenWerks> The problem is that I have to have both the old and new, but at the same time have set the main to the new.
[22:52] <OvenWerks> because we call other bits that read config.
[22:54] <OvenWerks> wonko: does the config handle more than one line with the same name? like:
[22:54] <OvenWerks> xdev=0,0,0
[22:54] <OvenWerks> xdev=2,1,0
[22:55] <OvenWerks> or will it just save the last one?
[22:55] <wonko> I don't believe it does that nicely
[22:55] <wonko> Never tried. :-)
[22:55] <OvenWerks> probably just save the last one.
[22:55] <OvenWerks> I figured it out
[22:56] <wonko> I know you hate the idea but what about json or yaml for the config file? Would make us spend less time chasing our tails.
[22:56] <OvenWerks> we could split it each time...
[22:56] <OvenWerks> or not use the config parser...
[22:57] <OvenWerks> The proper way is probably to split it each time we use it.
[23:00] <wonko> I had considered switch to that
[23:00] <wonko> All let's do it
[23:00] <wonko> So*
[23:00] <OvenWerks> I really have too much time helping people fix tings already without have them send me a config file in paste that is a pain to read.
[23:02] <OvenWerks> but if I can old_dev_config = dev_config and still read all the params that would work fine.
[23:03] <OvenWerks> That would get rid of all the param=newparam as well
[23:11] <OvenWerks> oldconfig = config doesn't seem to work
[23:13] <wonko> This is where python gets weird for me
[23:14] <wonko> That's an object so is that a pointer or a copy?
[23:14] <OvenWerks> it probably needs to be a copy
[23:16] <wonko> https://docs.python.org/3/library/copy.html
[23:16] <wonko> You'll be wanting that then
[23:17] <wonko> Or a real language. Your choice. :-P
[23:18] <OvenWerks> I hate python docs.. allmost every one of them does not have just a few examples of anything.
[23:19] <wonko> Or they have examples that make no sense
[23:19] <wonko> And no explanation as to what is going on
[23:23] <OvenWerks> nope, those don't work either (copy deepcopy)
[23:24] <OvenWerks> those work for lists, not objects
[23:26] <OvenWerks> wonko: https://stackoverflow.com/questions/23416370/manually-building-a-deep-copy-of-a-configparser-in-python-2-7
[23:27] <OvenWerks> all the answers say the same thing, save the original config as a string then read that string in as if it was a file to the copy...
[23:29] <wonko> Oh FFS
[23:32] <OvenWerks> And... they are python2 so look up what I do to do the same in 3