[01:14] <sethj> andyrock, I was able to reproduce the lock screen/keyboard layout bug. It's not 100% consistent, but I did get it to trigger two of out 5 times.
[01:33] <sethj> I take it the EOL scripts haven't been run as I'm finding a lot of really old bugs..
[05:14] <hikiko> hello
[05:30] <pitti> Good morning
[06:14] <didrocks> hello!
[06:23] <pitti> bonjour didrocks !
[06:23] <didrocks> ça va pitti ?
[06:24] <pitti> didrocks: ça va bien, et toi ? Dieu merci c'est vendredi :-)
[06:24] <didrocks> pitti: en effet, c'est vendredi !  :) Heading off for the weekend, and indeed for a week off. You see you folks in a week or so. :)
[06:33]  * TheMuso -> EOD
[06:33] <seb128> hey TheMuso, enjoy your w.e!
[06:34] <didrocks> enjoy your week off TheMuso!
[06:34] <seb128> and your holidays as well
[06:34] <larsu> good morning!
[06:34] <larsu> bye TheMuso :)
[06:35] <didrocks> great morning larsu
[06:36] <larsu> salut didrocks
[06:36] <larsu> ça va?
[06:36] <seb128> hey larsu
[06:36] <didrocks> larsu: bof, toujours malade…
[06:36] <larsu> didrocks: ugh, sorry to hear :/
[06:37] <larsu> seb128: hola! que tal?
[06:37] <seb128> larsu, prima, danke!
[06:38] <FJKong> good afternoon
[06:40] <seb128> hey FJKong
[06:40] <larsu> hi FJKong
[06:40] <seb128> just as a note, I'm going to be offline in the afternoon
[06:40] <larsu> Friday \o/
[06:40] <seb128> travelling, so working a bit offline and going to catch up a bit after arriving
[06:40] <FJKong> seb128: larsu hey~
[06:41] <didrocks> afternoon FJKong
[06:41] <didrocks> seb128: safe driving!
[06:41] <seb128> didrocks, thanks :-)
[06:41] <FJKong> it seems that I need to learn more about golang if we work on snappy.
[06:41] <FJKong> right/
[06:42] <FJKong> s/\/?
[06:44] <seb128> FJKong, not everybody is going to work on snappy
[06:44] <seb128> but you can have a look to go if you want, doesn't hurt
[06:45] <FJKong> just look at some demo apps, I find most of them are written with golang
[07:52] <willcooke> good morning you fine fellows
[07:53] <hikiko> hello willcooke
[07:53] <willcooke> morning hikiko.  That bug from yesterday, I can't reproduce it, so I dont know why I marked it as rls-w-incoming
[07:53] <willcooke> you can close if you want
[07:54] <hikiko> thanks willcooke :)
[07:54] <seb128> hey willcooke hikiko
[07:55] <willcooke> morning seb128
[07:55] <larsu> morning all
[07:55] <willcooke> g'day larsu
[07:56] <larsu> this is n²...
[07:56] <larsu> at least it comes in waves :)
[07:58] <willcooke> I prefer to think of it as The Waltons effect
[07:58] <larsu> heh
[08:00] <willcooke> http://www.ubuntu.com/usn/usn-2743-3/
[08:00] <willcooke> seb128, did you see that ^^ ?
[08:01] <hikiko> hi seb128 larsu et al
[08:01] <seb128> willcooke, saw now, "fun"
[08:03] <Laney> yo
[08:03] <seb128> hey Laney
[08:04] <didrocks> good morning willcooke, hikiko, Laney!
[08:05] <didrocks> 3 in a row \o/
[08:05] <hikiko> hi didrocks :)
[08:07] <seb128> Laney, seems like we got adwaita-icon-theme-full on the iso, unsure if that's wanted?
[08:07] <seb128> (I guess not, otherwise the split becomes useless?)
[08:07] <Laney> yes
[08:08] <Laney> you looking at it?
[08:11] <seb128> not yeah, I don't have it installed on my desktop, so probably a recommends somewhere
[08:11] <seb128> need to download a daily iso I guess ;-)
[08:11] <larsu> hi Laney :)
[08:11] <larsu> pesky recommend!
[08:12] <larsu> *recommends
[08:12] <Laney> hey larsu and didrocks and seb128 btw :)
[08:12] <Laney> seb128: I would usually check http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.wily/all first
[08:12] <Laney> (probably don't open that in your browser)
[08:12] <Laney> (firefox...)
[08:13] <didrocks> btw, if anyone wants to debug the media keys not working, I'm again in a session with that state
[08:13] <didrocks> as yesterday
[08:13] <didrocks> as the day before…
[08:13] <didrocks> and such :p
[08:13] <willcooke> hey didrocks, how are you feeling today?
[08:13] <didrocks> Trevinho: once you are here, I thought you were looking into this race? ^
[08:14] <didrocks> willcooke: worse than yesterday, speaking heavily from the nose…
[08:14] <willcooke> :(
[08:14] <didrocks> (add that to a French accent :p)
[08:14] <willcooke> ;)
[08:14] <larsu> lol
[08:14]  * larsu hugs didrocks
[08:14]  * didrocks hugs larsu back (IRC germ firewall FTW \o/)
[08:16] <seb128> larsu, Laney, do we want gnome-themes-standard on the iso?
[08:16] <seb128> it's what pulls in adwaita-icon-theme-full
[08:17] <Laney> why is that there?
[08:17] <larsu> seb128: I thought this was not needed anymore?!
[08:18] <larsu> maybe it has the gtk2 theme?
[08:18] <Laney> calm
[08:47] <Trevinho> hi
[08:47] <Trevinho> didrocks: media keys...
[08:47] <Trevinho> mh
[08:48] <didrocks> Trevinho: media and shorcuts
[08:48] <didrocks> like ctrl+alt+t, and such
[08:48] <Trevinho> yeah, the code is the same
[08:48] <didrocks> remember, we talked about a race that started to happen last cycle if I'm right?
[08:48] <didrocks> yeah
[08:48] <Trevinho> I don't remember we did... But might be :)
[08:48] <didrocks> so, I'm in that state currently (happened quite more recently than before)
[08:49] <Trevinho> last cycle the API changed, but I never got issues because of tat
[08:49] <Trevinho> that*
[08:49] <didrocks> like once every 4 login
[08:49] <didrocks> willcooke experienced it for sure
[08:49]  * willcooke me toos
[08:49] <Trevinho> didrocks: when it happens have you tried to give dbus-monitor a check?
[08:49] <didrocks> Trevinho: what do you want me to monitor in particular?
[08:49] <willcooke> heh, dbus monitor is broken, right larsu :)
[08:50] <Trevinho> well, see what's dispatched and how
[08:50] <Trevinho> well, mh it's on interface org.gnome.Shell
[08:51] <Trevinho> signal AcceleratorActivated
[08:51]  * didrocks stops the workrave
[08:51] <didrocks> ok, let's see
[08:51] <didrocks> because workrave is spamming dbus
[08:51] <Trevinho> but... well, that might not work if it has not been registered
[08:51] <didrocks> Trevinho: ok, signal is sent
[08:51] <Trevinho> didrocks: ahhh... actually better, maybe trying to initctl restart unity-settings-daemon?
[08:51] <didrocks> http://paste.ubuntu.com/12552555/
[08:51] <didrocks> for instance
[08:51] <Trevinho> no, dono't do that then
[08:52] <didrocks> Trevinho: killing unity-settings-daemon doesn't work normally
[08:52] <Trevinho> So.... registration of keybindings on startup is done, so unity is aware and it does the right thing...
[08:52] <Trevinho> now, I guess it's still u-s-s that should receive the AcceleratorActivated signal and do what expected
[08:52] <Trevinho> attente: is this right, correct?
[08:53] <seb128> he's probably sleeping
[08:53] <didrocks> I don't remember what it spawing those, I think you are right, it's u-s-s
[08:53] <didrocks> u-s-d*
[08:54] <Trevinho> yaeah, ...-d :P
[08:55] <didrocks> I can see the MediaKeys interface on the bus
[08:55] <didrocks> org.gnome.SettingsDaemon.Keyboard
[08:55] <larsu> yeah people, don't use dbus-monitor with a destination match
[08:55] <larsu> it's broken
[08:56] <larsu> `busctl --match destination=...` works
[08:56] <larsu> or dbus-monitor and ... err .... grep
[08:56] <larsu> (bug is filed)
[08:56] <didrocks> destination=(null destination)
[08:56] <didrocks> is that supposed to be the case?
[08:56] <didrocks> (it's what we have for a broadcast, I guess?)
[08:58] <larsu> didrocks: sorry, I meant when you give a specific destination
[08:58] <larsu> like, dbus-monitor destination=org.freedesktop.Notifications
[08:58] <larsu> you will *not* see bus traffic to notification daemon
[08:58] <didrocks> larsu: but those media keys don't have any destination in the normal case, right (do you mind checking by giving it a try?)
[08:58] <larsu> it works if you leave off the destination match, or use busctl
[08:59] <larsu> didrocks: in a 1:1 right now. Is there a bug I can get the summary from?
[08:59] <didrocks> as you are in a working state, and I hope to keep my broken state to debug it
[08:59] <didrocks> willcooke opened one, let me check if I can find it
[09:01] <didrocks> bug #1482181
[09:01] <larsu> ah *this* problem
[09:01] <larsu> I've had this
[09:01] <larsu> didrocks: please STAY in the broken state. I'll be with you in a few minutes
[09:02] <didrocks> thx!
[09:02]  * didrocks commented
[09:02] <didrocks> and stay broken
[09:02] <didrocks> (broken and sick, nice Friday! :p)
[09:04] <larsu> didrocks: :1.28 is u-s-d? (busctl status --user :1.28)
[09:05] <didrocks> larsu: no, it's compiz
[09:06] <didrocks> it's the compiz gnome plugin IIRC which handles the keys
[09:06] <didrocks> (as we have some special build process for that)
[09:06] <didrocks> so compiz gets the press event, and broadcast it correctly
[09:07] <didrocks> then, the other side (which should listen on that iface and launch the corresponding app) doesn't work
[09:07] <didrocks> I wonder if that couldn't be a side effect of the "listen to a signal, and then read the key"
[09:07] <didrocks> (in gsettings)
[09:07] <didrocks> on the receiver side
[09:08] <larsu> gsettings shouldn't be involved here
[09:08] <didrocks> sorry, I meant the glib signal change
[09:09] <didrocks> but yeah
[09:09] <didrocks> sorry ECONFUSED ;)
[09:09] <larsu> so we don't use u-s-d media keys plugin?
[09:10] <didrocks> not for listening in the unity settings, no
[09:10] <didrocks> (we never had since unity)
[09:10] <didrocks> it's the compiz-gnome plugin
[09:11] <larsu> media keys plugin is active though..
[09:11] <didrocks> yeah, unsure why…
[09:12] <larsu> maybe these two step on each other's feet?
[09:12]  * willcooke fires up his test laptop
[09:12] <larsu> let me check the bus traffic
[09:12] <larsu> (working for me right now
[09:12] <larsu> )
[09:12] <didrocks> yeah
[09:13] <didrocks> so, what is the listening interface on the other side to receive the signal and spawn a process?
[09:13] <didrocks> sounds like compiz, not that the interface is GnomeShell?
[09:13] <larsu> wow, 10 messages for one key
[09:13] <larsu> oh, with returns
[09:13] <didrocks> I only have one?
[09:14] <didrocks> yeah, just one here
[09:14] <didrocks> and no returns :p
[09:14] <larsu> didrocks: the gnome shell interface is exposed by unity
[09:14] <didrocks> so it's back on Trevinho's plate? :)
[09:14] <didrocks> larsu: yeah, that's what I'm seeing from the .service file
[09:14] <larsu> didrocks: you should at least also get messages to notify-osd and "backlight-changed" or similar
[09:15] <didrocks> larsu: no, nothing, (and of course, no notify-osd)
[09:15] <larsu> this is because it's broken, right?
[09:15] <didrocks> yep
[09:16] <larsu> holy shit whatever is sending the notify thing is asking the daemon about it's capabilities all the time
[09:17] <larsu> *sigh*
[09:17] <didrocks> larsu: just in case, "did you change yet?" :p
[09:17] <larsu> haha
[09:18] <willcooke> Laney, wallpaper judging has begun....
[09:18] <didrocks> so, if I use a Method like UngrabAccelerator(0), I get a return value
[09:18] <Laney> good!
[09:18] <didrocks> there is clearly something listening on the other side
[09:18] <didrocks> but not at signals on that iface?
[09:18] <willcooke> desktoppers:  Take a look at the wallpaper entries... https://www.flickr.com/groups/ubuntu-fcs-1510/pool/
[09:19] <didrocks> larsu: so, seems like to be in Unity code?
[09:19] <larsu> didrocks: you see the signal though, right?
[09:19] <larsu> just not the "result"
[09:19] <larsu> why would unity send itself a signal via dbus, I wonder
[09:19] <didrocks> larsu: yeah, I have the signal, but no response
[09:20] <didrocks> larsu: because it's 2 different plugins handling it? :p
[09:20] <larsu> hah
[09:21] <larsu> hm, unity-settings-daemon is talking to itself
[09:21] <Laney> seb128: did you look at it or should I?
[09:22] <didrocks> it seems that GnomeGrabber::Impl::activateAction isn't called for whatever reason
[09:22] <Laney> seb128: seems either metacity or gnome-themes-standard or both could fix this
[09:22] <didrocks> larsu: I guess it's where we are blocking on Trevinho to have a look now
[09:24] <larsu> sorry, brb
[09:26] <seb128> Laney, I didn't, sorry, busy with something else and travelling this afternoon, feel free if you want
[09:26] <Laney> thx
[09:26] <seb128> otherwise it's likely going to be on monday for me
[09:26] <Laney> np
[09:27] <seb128> thanks
[09:29] <seb128> larsu, didrocks, just for info https://code.launchpad.net/~attente/unity/gnome-key-grabber was the changeset to use those interfaces
[09:29] <seb128> it might make easier to see the code impacted from the diff of the feature landing
[09:30] <seb128> but basically unity should do the grabbing and dbus message u-s-d which does the actions
[09:36] <hikiko> https://code.launchpad.net/~hikiko/compiz/compiz.fix-811591/+merge/272359 Trevinho could you approve this? (it's a bug from ages sam proposed that solution that works for me but it was never added to ubuntu)
[09:36] <hikiko> or andyrock ^
[09:36]  * hikiko gets rid of bugs :p
[09:37]  * Trevinho on it
[09:38] <Trevinho> mh hikiko don't comment code, or if you do add some explaination please. However, I'd just go by dropping those lines. In case bzr annotate or log will help to understand what changed
[09:38] <hikiko> ok :)
[09:39] <hikiko> sec
[09:39] <larsu> seb128: thanks!
[09:40] <larsu> didrocks: you're getting the signal, so I'm guessing the problem is in settings-daemon
[09:40] <larsu> which actually has two plugins talking to themselves on the bus :/
[09:41] <hikiko> Trevinho, fixed
[09:41] <Laney> hi u-s-d, how are you?
[09:42] <Laney> find u-s-d, and you?
[09:42] <Laney> fine*
[09:42] <Laney> great thanks u-s-d!
[09:42] <seb128> didrocks, larsu, isn't media-key what has the handlers for those dbus calls?
[09:42] <seb128> what is the second plugin?
[09:43] <larsu> seb128: the media key plugin calls the org.gnome.SettingsDaemon.Power.Screen.GetPercentage
[09:43] <larsu> and then .StepUp
[09:43] <larsu> but all of this doesn't seem to be happening for didrocks
[09:44] <seb128> why does it call that?
[09:44] <larsu> to chnage brightness (the media key I pressed)
[09:44] <larsu> for volume, I guess it calls pulse directly?
[09:45] <seb128> oh, I see
[09:46] <seb128> ok, good desktop people I need to drop offline, going for lunch and then travelling
[09:46] <seb128> I'm going to work a bit offline and should be back betwee 17-18
[09:46] <larsu> hehe enjoy!
[09:46] <seb128> see you later or have a good w.e for those who call it a day by then
[09:47] <seb128> thanks!
[09:47] <larsu> you too!
[09:47] <willcooke> cya seb128
[09:47] <larsu> didrocks: can you paste the output of `busctl --user call org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.Debug.Stats GetAllMatchRules` please
[09:53] <didrocks> larsu: sorry, in a HO
[09:53] <didrocks> just read last line but: http://paste.ubuntu.com/12552889/
[09:56] <larsu> didrocks: no worries, that was the only interesting one
[10:05] <didrocks> larsu: ok, can focus more on this, and opened to any experience that doesn't include physical danger :p
[10:09] <larsu> didrocks: ha ok
[10:09] <larsu> so, you have the match rule
[10:10] <larsu> currently going through u-s-d code to see what could go wrong
[10:10] <didrocks> larsu: but it's not u-s-d which spawn the process, it's only handling the notification communication?
[10:10] <didrocks> meaning, we would have:
[10:10] <didrocks> compiz-gnome -> send signal
[10:10] <didrocks> 1. u-s-d grab it and send notification
[10:11] <didrocks> 2. unity grabs it and launch the corresponding action/process
[10:11] <didrocks> ?
[10:11] <didrocks> (like for ctrl+alt+t, launch the terminal)
[10:11] <larsu> right, unity grabs some keys
[10:11] <larsu> but volume and brightness are handled directly
[10:11] <larsu> they all don't work for you, right?
[10:11] <didrocks> yeah, all
[10:12] <didrocks> so media keys are per see, and other command shorcuts
[10:12] <didrocks> let me try to see if I see different traffic for ctrl+alt+t
[10:12] <didrocks> argh,and of course, I tried ctrl+alt+t to have a terminal to monitor the traffic…
[10:13] <larsu> try volume
[10:13] <didrocks> ok, same with ctrl+alt+t, just getting the broadcast signal
[10:13] <larsu> or brightness
[10:13] <didrocks> volume is what I tried in my previous paste
[10:13] <larsu> ok, then unity is not involved at all
[10:13] <didrocks> so, same, just getting broadcast signal in both case
[10:13] <didrocks> yeah, can be dbus not delivering to any of them?
[10:14] <larsu> hm?
[10:14] <larsu> someone has the match rule, so it should arrive
[10:14] <larsu> and that someone is most likely u-s-d
[10:14] <didrocks> shouldn't we have 2 then?
[10:14] <didrocks> (matching)
[10:14] <didrocks> u-s-d for media keys
[10:14] <didrocks> unity for shorcuts
[10:15] <larsu> does unity also listen on the gnome shell interface?
[10:15] <didrocks> and then, they filter and only care about some part of the answer
[10:15] <larsu> unity *is* the gnome shell interface
[10:15] <larsu> I hope they simply handle Ctrl+Alt+T internally?!
[10:15] <didrocks> well, if this was internally handled, it would work, right?
[10:15] <didrocks> seems like it's using the exact same pipe
[10:15] <larsu> indeed
[10:17] <larsu> maybe u-s-d handles all of those?
[10:18] <didrocks> larsu: maybe (as it's working for you), set some new env variable to u-s-d
[10:18] <didrocks> then ctrl+alt+t
[10:18] <didrocks> and see if the terminal gets them?
[10:18] <didrocks> that would tell us if it's unity or u-s-d spawning the app?
[10:20] <didrocks> Trevinho: maybe you know this workflow, what is supposed to launch a terminal for instance on ctrl+alt+t, is it unity?
[10:21] <didrocks> or does compiz-gnome just grab the keys, and forward them to the gnomeshell iface?
[10:21] <Trevinho> didrocks: unity only grabs the keys, the it's up to u-s-d to launch
[10:21] <larsu> right
[10:21] <didrocks> ok, so at least, none of them working makes sense
[10:22] <didrocks> so, the issue is in u-s-d
[10:22] <didrocks> thanks Trevinho
[10:23] <larsu> didrocks: gsettings reset org.gnome.settings-daemon.plugins.media-keys terminal
[10:23] <larsu> does this make the terminal key work?
[10:24]  * didrocks tries
[10:24] <didrocks> larsu: nope
[10:25] <didrocks> the value didn't change (I did a get before), and still the default: '<Primary><Alt>t'
[10:25] <larsu> ah
[10:25] <larsu> try changing it to something
[10:25] <didrocks> ok
[10:25] <didrocks> larsu: yeah, after changing, it works
[10:25] <didrocks> resetting though, doesn't
[10:26] <larsu> FUCK
[10:26] <larsu> ok
[10:26] <larsu> but resetting after changing keeps it working, right?
[10:26] <didrocks> nope
[10:26] <larsu> oh?
[10:26] <didrocks> I resetted it (and so '<Primary><Alt>t' again)
[10:26] <didrocks> and it doesn't work
[10:26] <larsu> but if yo set it to something else it does?
[10:27] <Trevinho> Weird
[10:27] <didrocks> yep, I tried Alt + t
[10:27] <didrocks> want me to try with the volume keys?
[10:27] <didrocks> to confirm this
[10:28] <larsu> yes please
[10:28] <didrocks> same
[10:28] <didrocks> so setting it to Alt +t, I can increase the volume
[10:28] <didrocks> gsettings reset it
[10:28] <larsu> should be the same changed signal
[10:28] <didrocks> and then, the media key doesn't work
[10:28] <larsu> this is awesome :)
[10:28] <didrocks> isn't it? :p
[10:28] <Trevinho> lovely
[10:28] <didrocks> let me dbus-monitor this
[10:29] <didrocks> to ensure that it's still unity grabbing the key in the second case
[10:29] <didrocks> (when setting it to something else)
[10:31] <didrocks> so: http://paste.ubuntu.com/12553084/
[10:31] <didrocks> and then, getting all the dbus spam with notification, panel service…
[10:31]  * didrocks looks for the send id
[10:32] <didrocks> interesting btw
[10:32] <didrocks> the old key still send a signal
[10:32] <Trevinho> using dbus-monitor --session "interface='org.gnome.Shell'"  does help in filtering?
[10:33] <didrocks> can be, but I see enough here
[10:33] <didrocks> sender=:1.28 in both case
[10:33] <didrocks> still weird that the previous old volume up key send the signal
[10:33] <didrocks> so something is wrong unity-side for sure already
[10:33] <didrocks> oh
[10:33] <didrocks> the first arg has different values
[10:34] <larsu> are you sure? You always get ths signal, regardless of whether the key works, right?
[10:34] <didrocks> yeah
[10:34] <Trevinho> action id maybe is not well defined
[10:34] <didrocks> so, I changed to Alt+t, right?
[10:34] <didrocks> for volume up
[10:34] <didrocks> and then:
[10:35] <didrocks> http://paste.ubuntu.com/12553099/
[10:35] <didrocks> the first value of that signal is the keycode pressed (the values are different) right? it's not a "capability index" like volume up or such?
[10:35] <larsu> no, it's the accel id
[10:36] <didrocks> so, it should be the same between the 2 calls?
[10:36] <didrocks> or at least, it's unique for "volume up"?
[10:36] <larsu> no, u-s-d gets a new one from GrabAccelerator() every time it does a grab
[10:36] <didrocks> ok
[10:36] <larsu> if I understand this correctly
[10:37] <larsu> basically it works like this: u-s-d asks unity to grab "Alt+T" and gets an id
[10:37] <larsu> and the unity sends signals with that id - so that u-s-d knows which accel was hit
[10:37] <didrocks> that's why you thought reset would work, right? like reasking to regrab "volume up"
[10:37] <larsu> yes
[10:37] <didrocks> and the bug would have been u-s-d starting before unity
[10:37] <larsu> indeed
[10:38] <larsu> but since it stops working again when you regrab the old key, this doesn't seem to be the case
[10:38] <didrocks> yeah…
[10:38] <larsu> but we're onto something
[10:38] <larsu> try this:
[10:38] <larsu> dbus-monitor interface=org.gnome.Shell
[10:39] <larsu> gsettings set org.gnome.settings-daemon.plugins.media-keys terminal "<Alt>t"
[10:39] <larsu> gsettings reset org.gnome.settings-daemon.plugins.media-keys terminal
[10:39] <larsu> gsettings set org.gnome.settings-daemon.plugins.media-keys terminal "<Alt>t"
[10:39] <larsu> in between, hit Alt+T and Ctrl+Alt+T
[10:39] <larsu> and send the log of the monitor
[10:39] <didrocks> k
[10:39] <larsu> thanks for being so patient!
[10:40] <didrocks> no worry, I'm eager to see it fixed, this waited for too long :)
[10:43] <didrocks> larsu: here we go, with annotation: http://paste.ubuntu.com/12553139/
[10:43] <larsu> you're the best!
[10:43]  * didrocks hugs larsu
[10:43] <didrocks> so, the weird thing
[10:44] <didrocks> UngrabAccelerator
[10:44] <didrocks> the id isn't the one for Primary alt T
[10:44] <larsu> yeah
[10:44] <larsu> looks like it's getting confused?!
[10:44] <didrocks> yeah
[10:44] <didrocks> if I keep pressing it
[10:45] <didrocks> resetting*
[10:45] <didrocks> I always have a GrabAccelerator -> id 3
[10:45] <didrocks> but an ungrab id incrementing
[10:45] <didrocks>    uint32 736
[10:45] <didrocks>    uint32 737
[10:45] <didrocks> …
[10:45] <didrocks> (and I just gsettings reset in loop, didn't set it anything else in between)
[10:46] <larsu> but also Activated() doesn't send the right accel id
[10:46] <didrocks> yep
[10:46] <larsu> so that's *clearly* wrong
[10:47] <didrocks> indeed
[10:47] <didrocks> and that explains why unity doesn't ungrab
[10:47] <larsu> unless...... there's an old grab that u-s-d forgot to ungrab
[10:47] <larsu> and unity only sends signals for one grab
[10:47] <larsu> this interface is the biggest shit I've ever seen
[10:47] <larsu> so many problems
[10:47] <didrocks> larsu: I'm sure you can always find worse! :)
[10:47] <larsu> lol
[10:48] <larsu> it should work like this: hey unity, I'm interested in these 10 keys!
[10:48] <didrocks> ah, remapping rather than incremental?
[10:48] <larsu> ok :1.xyz, I'll send signals for these keys until you die
[10:48] <larsu> or tell me a new set of keys
[10:48] <didrocks> yeah
[10:49] <larsu> it needs to check lifetime anyway, in case it crashes
[10:49] <larsu> so ungrab() is completely useless
[10:49] <didrocks> indeed
[10:49] <larsu> and apparently causing the problems here
[10:49] <didrocks> I don't have any crash of u-s-d, in case this would have been the issue…
[10:50] <didrocks> like asked for grabbing, crashing and using weird id
[10:50] <didrocks> that's… weird
[10:50] <didrocks> so: here is another try:
[10:51] <larsu> no I think it doesn't crash but gets the ungrabbing wrong
[10:51] <didrocks> http://paste.ubuntu.com/12553213/
[10:52] <didrocks> so, the id for alt + T which is grabbed when pressed is different from the one set? (always 3)
[10:52] <larsu> oh wait, 3 is input, not return
[10:53] <didrocks> ah yeah, it's a flag
[10:54] <larsu> didrocks: sorry I have a lunch date with systemd hackers now. I think I have enough information to figure this out now
[10:54] <larsu> didrocks: thanks a lot again. I might have more questions in an hour or two
[10:55] <didrocks> larsu: no worry, keeping it broken for the day. Thanks for looking at it!
[10:55] <didrocks> enjoy your lunch :)
[10:56] <larsu> man, this totally works for me thougj
[10:56] <larsu> I bet it gets confused at startup for you
[10:56] <larsu> and then stays in some weird state
[10:56] <larsu> didrocks: thanks! Eating bulgarian
[10:56] <didrocks> sounds nice! :)
[10:56] <didrocks> larsu: yeah, I think there is something at startup and that's why it's lost then *forever*
[10:57] <larsu> indeed
[11:15] <willcooke> desktoppers:  https://goo.gl/jqRgRC
[11:16] <didrocks> cute!
[11:16] <Trevinho> nice
[11:17] <Trevinho> Dual landing, then! :(
[11:17] <Trevinho> :) ^
[11:17] <didrocks> ahah
[11:21] <willcooke> :D
[11:28] <attente> good morning
[11:28] <didrocks> hey attente!
[11:29] <attente> hi didrocks!
[11:34] <willcooke> o/ attente
[11:35] <attente> o/
[11:48] <andyrock> good morning!
[11:51] <willcooke> hey andyrock
[12:58] <Trevinho> didrocks: so, I was looking further... And I noticed that the gnomecompat plugin in compiz is still enabled (actually we should remove it from our list nowadays), and that it tries to grab Ctrl+Alt+t... So maybe disabling that plugin (or keybinding) should explain why the activated signal is emitted anyway when chaning setting
[13:00] <didrocks> Trevinho: can be, yeah
[13:00] <Trevinho> Oh, well no... Actually it shouldn't be there /usr/share/session-migration/scripts/00_remove_gnomecompat_in_unity_session.py
[13:00] <Trevinho> (as per this, but maybe it doesn't work?)
[13:00]  * Trevinho tries a clean session
[13:00] <didrocks> it's not enable here
[13:00] <didrocks> enabled*
[13:00] <Trevinho> ah, ok fine
[13:01] <Trevinho> so no troubles from that... It's all in unity
[13:01] <Trevinho> but I don't see unity behave badly... I mean, it should do what expected.
[13:01] <didrocks> yeah, it seems to be more on the u-s-d side maybe
[13:01] <didrocks> or unity doesn't ungrab the first key
[13:03] <Trevinho> didrocks: if you've installed libxpathselect, you might be able to try to run these AP test autopilot/unity/tests/test_gnome_key_grabber.py
[13:03] <Trevinho> they play with the interface...
[13:04] <Trevinho> So you might check if ungrabbing happens also
[13:05] <andyrock> willcooke: congrats!! :D
[13:05] <willcooke> thanks andyrock :)
[13:22] <kgunn> tjaalton: ping
[13:22] <Trevinho> didrocks: oh... Actually I was looking at the ungrab code... And well it's probably not working well
[13:23] <Trevinho> didrocks: did you try to manually call the UngrabAccelerator command with a valid id and see what's returning?
[13:23] <Trevinho> if it's false, as I believe it might do, then... we're into problems
[13:28] <qengho> good morning
[13:29] <willcooke> hey qengho
[13:35] <larsu> Trevinho: well, unity does some things wrong
[13:36] <larsu> for example, it sends the AccelaratorActivated signal to everyone
[13:36] <larsu> even though only one process can know about the id
[13:36]  * larsu wonders if gnome shell gets this right
[13:38] <larsu> ah, seems to
[13:38] <Trevinho> larsu: well, that's right... But since the ID is generated with methods, others shouldn't listen that
[13:38] <Trevinho> however, i was mostly concerned by this didn't work, but it actualyl does http://pastebin.ubuntu.com/12554355/
[13:39] <larsu> well, others get woken up
[13:39] <larsu> and then ignore the message because it doesn't have an id they know about
[13:40] <larsu> could set up a match rule with arg0 set to the id
[13:40] <larsu> ... for every key
[13:40] <larsu> man this interface is dumb
[13:41] <Trevinho> we should emit the id to the register only, true... To do that we should change our glib::DBusObject too, but feasible
[13:54] <didrocks> sorry guys, still on a HO
[14:01] <didrocks> larsu: Trevinho: do you want still me to try to manually call the ungrabAccel (I'm unsure about the first key id which was set though)
[14:04] <Trevinho> didrocks: well, in theory it's the same id you get when you use the key and unity emits the signal
[14:04] <didrocks> Trevinho: oh sure, let me try
[14:05] <didrocks> ok, called ungrabbed
[14:05] <didrocks> returned true
[14:05] <didrocks> pressing and working now
[14:05] <didrocks> with another id
[14:05] <didrocks> so, yeah, the key is registered twice
[14:05] <didrocks> and unity only send the first one
[14:06] <didrocks> so, this starts to make sense
[14:06] <didrocks> larsu: Trevinho ^
[14:06] <didrocks> to sum up:
[14:06] <didrocks> -> key id was 33
[14:06] <didrocks> I ungrabbed(33)
[14:06] <didrocks> press again
[14:06] <didrocks> and now, it's 720
[14:06] <didrocks> and the notification popups and such
[14:06] <Trevinho> Ok, makes sense... So we need to ensure that an action is just registered once
[14:06] <didrocks> yep
[14:07] <didrocks> as it will stop at the first match I guess
[14:07] <Trevinho> and no register again if someone tries to do that
[14:07] <didrocks> but then, it means there is one case where it registers twice
[14:07] <didrocks> without ungrabbing?
[14:07] <Trevinho> unless there's an ungrab (best if from the same who asked to grab, but I wouldn't do that for avoiding trobules :P)
[14:07] <didrocks> (for all keys, with some racy start condition?)
[14:07] <didrocks> yeah
[14:07] <didrocks> ungrab is always called before grabbin?
[14:08] <didrocks> grabbing*
[14:08]  * didrocks looks
[14:08] <didrocks> at least, seems so from the logs
[14:08] <didrocks> so it's supposed to work
[14:08] <Trevinho> larsu: do you want me also to emit the signal only to the one who registered the grab? Although, if u-s-s crashes, we need to re-register every keybinding... it seems too much noise, considering that security isn't there ayway
[14:08] <didrocks> (your strategy to not reregister)
[14:09] <didrocks> good call on the crash case, you will need to track and reregister
[14:09] <didrocks> where broadcast only enable you to "not care"
[14:10]  * Trevinho takes the occasion to semplify this stuff
[14:11] <didrocks> Trevinho: ok, confirmed with another key where I didn't do any reset/set
[14:11] <didrocks> and of course, the id is way smaller (89)
[14:11] <didrocks> doesn't fix the real bug where is this something registering twice at startup though
[14:12] <didrocks> but weird, especially with no u-s-d crash
[14:13] <willcooke> didrocks, so we have got to the bottom of the issue then?
[14:15] <didrocks> willcooke: well, we know how it happens, Trevinho is working on a fix (I guess?), we don't know exactly why it goes to that state sometimes though
[14:16] <willcooke> oki, progress though, thanks all
[14:16] <didrocks> yeah, at least, this should be fixed from an user perspective :)
[14:16] <Trevinho> yeah, working on that
[14:16] <larsu> Trevinho: hm? You need to watch the service anyway to unregister the ids (in case it crashes)
[14:17] <didrocks> would be good to understand exactly why this happens, as this kinds of things are always stricking back in a worse case
[14:18] <Trevinho> larsu: yes, that's true... But I don't think it's something done right now... I was doing that, anyways...
[14:18] <Trevinho> larsu: i guess that's the reason why we didn't replace actions before
[14:20] <larsu> actions?
[14:21] <Trevinho> I mean keybindings... The problem was that we were just adding new keys ignoring the old ones
[14:21] <larsu> right, that's the problem didrocks is seeing?
[14:21] <Trevinho> so, when restarting usd, we were just adding the same keybindings twice
[14:22] <Trevinho> yeah... To reproduce just do something like
[14:22] <Trevinho> gdbus call --session --dest org.gnome.Shell --object-path /org/gnome/Shell --method org.gnome.Shell.GrabAccelerator "<Shift><Control>x" 0
[14:22] <Trevinho> twice or more...
[14:22] <Trevinho> We don't return false
[14:22] <larsu> indeed
[14:23] <larsu> so this is the issue?
[14:23] <larsu> didrocks' u-s-d crashes
[14:23] <larsu> once on startup?
[14:23]  * larsu checks
[14:23] <Trevinho> no, it adds twice the same shortcuts..
[14:23] <larsu> well, it adds them again when restarting
[14:24] <Trevinho> so only the first id is used by ucc, but unity sends the last registered one
[14:24] <larsu> and unity doesn't delete the old ones
[14:24] <larsu> oh
[14:24] <Trevinho> Well, that wouldn't be an issue, as restarting adds new ones...
[14:24] <larsu> it only registers them once for me
[14:24] <larsu> Trevinho: except for the obvious memory leak ;)
[14:25] <Trevinho> here's what I get http://pastebin.ubuntu.com/12554875/
[14:25] <didrocks> larsu: I don't have anything in /var/crash
[14:25] <didrocks> as told
[14:25] <Trevinho> yeah, I just think that for some reason you get the method called twice
[14:25] <didrocks> yep
[14:25] <didrocks> and without ungrab in the middle
[14:26] <larsu> Trevinho: I don't see it twice in didrocks' logs
[14:26] <Trevinho> didrocks: for double checking, you might set UNITY_TEST_LOG_SEVERITY="<root>error;unity.key.gnome.grabber=debug" for your session and see if you get anything relevant
[14:26] <Trevinho> larsu: I guess it happens on startup..
[14:26] <Trevinho> err, sorry wrong env name
[14:27] <didrocks> Trevinho: well, it's not a one 100% startup case, but yeah, I can do that for future logins
[14:27] <Trevinho> didrocks: it's UNITY_LOG_SEVERITY="<root>error;unity.key.gnome.grabber=debug" for your session and see if you get anything relevant
[14:27] <Trevinho> didrocks: yeah, I know, but you might try to relogin tons of times :)
[14:28] <didrocks> Trevinho: unsure about now, I have quite some stuff opened and working on, but yeah, adding for later :)
[14:28] <Trevinho> didrocks: sure, no worries
[14:28]  * Trevinho has an uptime of weeks generally, so... I also never leave my session :)
[14:30] <didrocks> larsu: so, let's say I press volume down, I see the "32" key id being fired
[14:30] <didrocks> larsu: then, I ungrab(32)
[14:30] <didrocks> larsu: I press again, and I get another event with key id 89, everything now works
[14:30] <didrocks> larsu: so, there are been at some point, 2 grab() calls without ungrab
[14:31] <didrocks> and unity only send the first match
[14:31] <didrocks> where u-s-d expects the second
[14:31] <larsu> ya
[14:31] <didrocks> (which is, I guess for it, the only valid one)
[14:31] <larsu> crashing u-s-d is enough to trigger this for me
[14:31] <larsu> I guess for the same reason
[14:31] <didrocks> the weird part is u-s-d didn't crash for me
[14:31] <larsu> Trevinho: you need to watch the name and remove all grabs when it disappears
[14:32] <larsu> s/you/unity :P
[14:32] <larsu> didrocks: thank!
[14:32] <didrocks> so, there is a case where 2 grabs are called, without ungrab in between
[14:32] <didrocks> yw!
[14:32] <larsu> right
[14:32] <larsu> which is the case when it crashes
[14:32] <didrocks> larsu: I do expect Trevinho to look at every laptop and watch for the grabs :)
[14:32] <didrocks> yep
[14:32] <larsu> haha
[14:33] <larsu> Trevinho: do you want to fix it or should we make a better API?
[14:33]  * larsu wonders what else is using this
[14:35] <Trevinho> larsu: well, as you prefer... I was about to use this API as it was the same gnome uses, but we can also make a new one
[14:35] <Trevinho> larsu: what would you prefer? I'd say the new one, right?
[14:35] <larsu> Trevinho: do you know if anyone else is using this interface?
[14:36] <Trevinho> larsu: I was about asking you the same :)
[14:36] <larsu> because if you need to implement it anyways, we might as well keep it
[14:36] <Trevinho> larsu: well... let me see... We use it for menus I believe, but not sure if it's unity module or we do in unity (/me checks)
[14:36] <didrocks> well… we need something for wily though
[14:37] <didrocks> and I don't think you want to introduce the new API now :p
[14:37] <willcooke> yes!
[14:37] <Trevinho> no, we do that internally for menus, so I don't think anyone would use
[14:37] <Trevinho> well... private stuff... :P
[14:37] <willcooke> didrocks, yes, as in, no - no you dont
[14:37] <Trevinho> Ok, I'm reusing the old one....
[14:37] <larsu> good point
[14:38] <didrocks> still, behavior change and such, you can still do a bandaid for now
[14:38] <didrocks> and nothing prevents to work on the new API now :)
[14:38] <didrocks> but first bandaid I would say ;)
[14:39]  * Trevinho hates bandaids...
[14:39] <Trevinho> but yeah...
[14:39] <didrocks> well, as everything, it's a risk/benefit assement :)
[14:40] <Trevinho> larsu: let's decide it now though... as actually I'd avoid to do things twice and probably it's not the best thing to rewrite this in u-s-d and unity. Considering we can rewrite just one side
[14:40] <larsu> ya
[14:40] <Trevinho> (keeping u-s-d even closer to upstream)
[14:43] <larsu> ok, so nothing needed from me?
[14:44] <didrocks> larsu: don't you think we should investigate why the grab can happen twice at some startup?
[14:44] <didrocks> (and without an ungrab in between)
[14:44] <larsu> ah right you said it's not because it crashed
[14:44] <didrocks> yeah…
[14:44] <didrocks> that worries me
[14:44] <didrocks> maybe we just get lucky most of the time and the last grab is what unity sees
[14:44] <didrocks> but maybe sometimes…
[14:45] <didrocks> and so, we would double grab for everyone at every login?
[14:46] <larsu> sigh
[14:47] <didrocks> larsu: so, I just looks at /proc/pid/maps
[14:47] <didrocks> larsu: it doesn't load (phew) the g-s-d media keys plugin
[14:47] <didrocks> I wonder though why I have every plugin listed 4 times?
[14:47] <larsu> haha good idea
[14:47] <larsu> hm? in maps?
[14:48] <didrocks> yep
[14:48] <didrocks> even libwacom and such
[14:48] <didrocks> that might be "normal", I would have expected to see it only once though
[14:48] <larsu> that's all libs though, not only the plugins
[14:48] <larsu> at least for me
[14:48] <didrocks> yeah
[14:48] <didrocks> sale
[14:49] <didrocks> same*
[14:49] <didrocks> ok, so "normal"
[14:49] <didrocks> I guess it spawns multiple memory chunks
[14:49] <didrocks> so, it's not the g-s-d plugin interfering, so, in the code itself…
[14:49] <tjaalton> kgunn: pong, EOW already, but if you have a bug just assign it to me :)
[14:50] <kgunn> tjaalton: no worries, i'll just email you...oh, i'm assuming you're the person to talk to about mesa uploads ?
[14:51] <tjaalton> kgunn: yes, did 11.0.0 break something?
[14:52] <kgunn> tjaalton: yep :) so just wanted to establish some kinda of communication/agreement between us
[14:52] <tjaalton> first point release will arrive today, i'll push it next week
[14:52] <tjaalton> ah
[14:52] <kgunn> busted our mir ci jobs for wily
[14:53] <tjaalton> well the FFE was filed a month ago and raof tested it iirc
[14:53] <tjaalton> but i hear you
[16:02] <didrocks> have a good week-end guys!
[17:11] <Laney> bye!
[17:12] <willcooke> gnight Laney
[17:12] <willcooke> gnight all
[18:11] <Trevinho> Good weekend folks!
[21:49] <attente> bye!


[04:25] <magnon> w3
[04:25] <magnon> nvm :P
[08:07] <jsgotangco> hey all
[12:33] <ogra> gah !
[12:33] <ogra> the doc team broke the CD builds
[12:33] <magnon> :(
[12:34] <ogra> the one of yesterday is quite good already, you only have to run sudo ltsp-build-client manually in the end....
[12:35] <ogra> should have been solved on todays... but now the docs are totally broken, so you cant even install anything after the first reboot :(
[12:36] <ogra> that was the last i'd have expected :(
[12:36] <magnon> hm
[12:36] <magnon> sucks
[12:36] <ogra> yu
[12:36] <ogra> p
[12:36] <ogra> they changed the binary names of the doc packages....
[12:36] <magnon> I'd like to test it in a pristine state... at least as pristine as it gets atm
[12:36] <magnon> doh
[12:37] <ogra> i'll rip out the docs, so tomorrows should be fine.... the odd thing is, that i cant test the ltsp-build-client fix now
[12:38] <magnon> the doc team fawked breezy as well, then?
[12:38] <ogra> i'm not sure if it was the docteam or jbailey (the packager)
[12:39] <magnon> I hope it's not Jeff, I've been bugging him a lot lately ;D
[12:41] <ogra> i dont know who decided to change the package ... so i'm carfull with blyming anybody


[02:23] <mup> PR snapd#11206 opened: mkversion.sh: do full opts parsing, add --ignore-debian-rules-changes  <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/11206>
[02:28] <mup> PR snapd#11207 opened: gadget: allow gadget struct with unspecified filesystem to match part with fs <Needs Samuele review> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/11207>
[08:04] <mup> PR snapd#11208 opened: interfaces: allow access to new at-spi socket location in desktop-legacy <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/11208>
[08:52] <mup> PR core20#125 opened: static: disable systemd ctrl-alt-del burst action <Created by flotter> <https://github.com/snapcore/core20/pull/125>
[08:59] <mup> PR snapd#11209 opened: github: test for "dirty" in usr/lib/snapd/info <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/11209>
[11:59] <mup> PR core18#184 opened: static: disable systemd ctrl-alt-del burst action <Created by flotter> <https://github.com/snapcore/core18/pull/184>
[12:13]  * ogra glares at the forum ...
[12:13] <ogra> kernel 2.6.32-042stab145.3
[12:13] <ogra> ooof ...
[13:05] <mup> PR snapd#11210 opened: .github/workflows/test.yaml: also check internal snapd version for cleanliness <Precious Logs> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/11210>
[14:26] <mup> PR snapd#11210 closed: .github/workflows/test.yaml: also check internal snapd version for cleanliness <Precious Logs> <Skip spread> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/11210>
[15:31] <mup> PR snapd#11211 opened: packaging, bloader, github: restore cleanliness of snapd info file; check in GA workflow <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/11211>
[15:36] <mup> PR snapd#11209 closed: github: test for "dirty" in usr/lib/snapd/info <Skip spread> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/11209>
[16:56] <mup> PR snapd#11203 closed: tests/nested/manual/core20-to-core22: wait for device to be initialized before starting a remodel <Simple 😃> <Test Robustness> <Run nested> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11203>
[17:01] <mup> PR snapd#11212 opened: tests: fix testing in trusty qemu <Created by mvo5> <https://github.com/snapcore/snapd/pull/11212>
[18:17] <mup> PR snapd#11204 closed: tests/lib/tools/tests.invariant: simplify check <Simple 😃> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/11204>
[18:27] <mup> PR snapd#11213 opened: tests: do not test microk8s-smoke on arm <Created by mvo5> <https://github.com/snapcore/snapd/pull/11213>
[18:32] <mup> PR snapd#11214 opened: tests: exclude interfaces-kernel-module load on arm <Flaky Test> <Created by mvo5> <https://github.com/snapcore/snapd/pull/11214>
[18:42] <mup> PR snapd#11206 closed: mkversion.sh: do full opts parsing, add --ignore-debian-rules-changes  <⚠ Critical> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/11206>
[19:02] <mup> PR snapd#11215 opened: tests: ensure that test-snapd-kernel-module-load is removed <Simple 😃> <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/11215>
[19:27] <mup> PR snapd#11211 closed: packaging, bloader, github: restore cleanliness of snapd info file; check in GA workflow <⚠ Critical> <Simple 😃> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/11211>
[20:22] <mup> PR snapd#11213 closed: tests: do not test microk8s-smoke on arm <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11213>
[20:54] <mup> PR snapcraft#3609 opened: [DRAFT] tests: move legacy snapcraft tests (CRAFT-728) <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/3609>
[21:17] <mup> PR snapd#11214 closed: tests: exclude interfaces-kernel-module load on arm <Flaky Test> <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/11214>
[21:17] <mup> PR snapd#11215 closed: tests: ensure that test-snapd-kernel-module-load is removed <Simple 😃> <Test Robustness> <cherry-picked> <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/11215>
[21:32] <mup> PR snapd#11216 opened: release: 2.54.2 <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/11216>
[22:19] <mup> PR snapcraft#3610 opened: lifecycle: do not stage deps for pull on core20 (CRAFT-725) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3610>
[23:30] <hardwire> Hola.  Anybody working with core22 on arm64 raspi systems?
[23:31] <hardwire> I'm hoping to bring in something later than linux 5.4 and wasn't sure on any gotchas.
[23:43] <mup> PR snapd#11216 closed: release: 2.54.2 <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/11216>


[07:55] <studio-user998> Is there an EFI versin of the ubuntu studios live-image? I am trying to install it but my laptop can not find a bootable media at boot after I dd'ed the iso to the stick.
[08:30] <studio-user998> I get isolinux.bin missing or corrupt
 If I run Ubuntu Studio Live, can I access my internal drives?
[12:49] <Limuxic> yes, you can
 Thanks!
[16:17] <OvenWerk1> Duke: Please note you can use them but you have to mount them first. You can do this by opening them with the file manager which auto mounts them, or you can mount them manually. In either case, you may wish to create a symbolic link to someplace somewhat more handy than /media/user/very_long_number/ ...
[16:18] <OvenWerk1> Duke this is the same for running linux off a disk when you want to look at a partition from another os.
[16:19] <OvenWerk1> Duke: mind you, when running from a disk, it is possible to have a second disk mounted at boot time to a convenient place on the file tree.
[17:09] <eeight> Hey all, long time user of ubuntu studio, thanks for creating this distribution!
[17:09] <eeight> I was wondering if I need to use rtirq script, my setup is using an usb soundcard.
[17:09] <OvenWerk1> eeight: yes.
[17:09] <OvenWerk1> it will help
[17:10]  * eeight installing
[17:11] <OvenWerk1> eeight: however I would modify the /etc/defualt/rtirq file. in particular the RTIRQ_NAME_LIST line
[17:13] <OvenWerk1> eeight: I have fouhnd that most systems use only two USB ports and have internal hubs to give more. check your own.
[17:14] <OvenWerk1> I look for a USB port that is not physically connected to A) irq16 and B) a hub that I use other plugs for things like kb, mouse, external drive.
[17:16] <eeight> is rtirq already installed on ubuntu studio or I have to use https://github.com/rncbc/rtirq?
[17:17] <OvenWerk1> So if I find that internally only usb2 and usb3 are used, and usb2 uses irq16. Then I plug a hub into a plug that goes to usb2 and use that for mouse and kb (and whatever) and then plug thge usb audio device in the plug that goes to usb3. then I set the RTIRQ_NAME_LIST line to usb3 snd usb
[17:17] <OvenWerk1> the one that comes with Studio is fine.
[17:20] <eeight> I read that you can remove snd if you don't use the internal soundcard of the motherboard?
[17:20] <OvenWerk1> The computer keyboard is generally not too bad, but a mouse generates a lot of events and if it is on the same usb port or worse the port it is on ends up with higher prioity than the audio... that is trouble
[17:20] <OvenWerk1> yes you can remove snd if you don't use internal stuff
[17:21] <eeight> looks like grub didn't use rtirq: grep threadirqs /proc/cmdline = null
[17:22] <OvenWerk1> eeight: rtirq is not loaded till the system is almost all the way up
[17:22] <eeight> do i need to add something in grub (threadirqs)
[17:22] <OvenWerk1> rtirq should not be run until the system already has the usb drivers up and running
[17:23] <OvenWerk1> threadirq I don't know. I think pinning the right irq to one core might be better because audio is sequencial.
[17:25] <OvenWerk1> but I don't know that would be better for sure. In general, when recording that is the only thing going on in the system (we hope)
[17:33] <eeight> I am trying to reduce the latency of my Surface Pro 3 to use a VST (via linvst - wine). Any advice is more than welcome!
[18:54] <s1200> s98d8u8cs8d8sdcu8s8cu89u8uu8u9c8cucuc8889su8uc8888989898u7yycccccccccccc7877e8e787878cuccur8u8u8eee8iiwwiouoioiueuoiyo
[18:54] <s1200> ioirt o9iov6iovu iri
[18:54] <s1200> uiujuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu
[18:55] <OvenWerk1> Kitty cat?
[19:09] <Eickmeyer> One can only hope that was a cat.
[19:31] <studio-user913> hello
[20:00] <eeight> update-rc.d: error: unable to read /etc/init.d/ubuntustudio when trying to turn off intel boost
[20:01] <Eickmeyer> eeight: Were you doing that using Ubuntu Studio Controls?
[20:01] <eeight> yes
[20:01] <Eickmeyer> OvenWerk1: We have a bug.
[20:01] <Eickmeyer> I can't replicate, I have an AMD system.
[20:02] <Eickmeyer> eeight: Hopefully OvenWerk1 Can fill us in.
[20:02] <eeight> :+1
[20:03] <Eickmeyer> That's something that, since I have an AMD system, may have slipped through the cracks.
[20:04] <Eickmeyer> eeight: We might have you do some testing soon, if you don't mind.
[20:06] <eeight> no problem, will stick around
[20:07] <Eickmeyer> eeight: 18.10 or 18.04?
[20:09] <Eickmeyer> As I look at the code, it shouldn't even be calling anything from /etc/init.d. That's left over from before systemd.
[20:14] <eeight> Eickmeyer: 18.10
[20:15] <Eickmeyer> Are you using our backports PPA by any chance?
[20:15] <eeight> No, stock
[20:16] <eeight> Looks like it's working (cat /sys/devices/system/cpu/intel_pstate/no_turbo = 0 or 1 depending on my selection). But the question is 1: what is the good value, 2: will it survice a reboot
[20:17] <Eickmeyer> Well, if it's working than we're good. I highly recommend adding the backports PPA (ppa:ubuntustudio-ppa/backports) since it contains quite a few fixes for Controls, including a fix to reboot persistence.
[20:19] <Eickmeyer> The backports PPA is still work-in-progress, but we don't update it nearly as often as the Autobuilds PPA, which is what we use for development.
[20:23] <Eickmeyer> eeight: As for what a good value is, 1 is best for lowlatency audio work since that disables the turbo.
[20:39] <OvenWerk1> Eickmeyer, eeight: what version of -controls?
[20:40] <Eickmeyer> OvenWerk1: He said stock 18.10, so my guess is 17.
[20:41] <Eickmeyer> Rather, 1.7.
[20:41] <Eickmeyer> I'm sorry, 1.6.
[20:50] <OvenWerk1> Eickmeyer: it is not worth chasing anything not in the latest version.
[20:56] <Eickmeyer> OvenWerk1: I agree, that's why I suggested using the backports PPA.
 OvernWerk: thanks. I tested two different versions of Ubuntu Studio (18.04 and 18.10) on a machine with Ardour crashes.  I did access the disks with sessions that are particularly troublesome.  FYI, the sessions caused problems with both distros. IMO, it seems to be a Mac problem. I'm running Ubuntu Studio on a 2010 MacPro desktop, and U
[23:23] <studiobot> buntu on a 2011 iMac (both have Ardour installed). Ardour crashes on both machines.
[23:24] <studio-user228> CONFIG
 @Duke [OvernWerk: thanks. I tested two different versions of Ubuntu Studio (18.04 and 1 …], Is calf-ladspa uninstalled on both?
 Yes. Actually I renamed them ladspa_old.  The problem is that I have to close Ardour after working in any session; if I close the session and try to open another one, I get an error. I was working with the Ardour team. Apparently there is something weird going on. Once I get ssh set up, I'm going to let them see if they can figure it out
[23:51] <studiobot> . However, my computers are old. I'm planning to buy a new one, later this year or early next year.


[10:25] <brendand> i have a system that can't resolve domain names unless i remove bind9, is this a known issue?
[18:03] <RedSingularity> Anyone know when the daily spins will be done?
[18:04] <hggdh> we hope soon now, the last pieces are being built
[18:04] <RedSingularity> hggdh: sounds good ;)
[18:04] <bkerensa> :D
[19:25] <Laibsch> Is it just me or is a http://www.streetauthority.com/energy-commodities/forget-oil-could-be-biggest-story-energy-458736 creating 100% CPU both in FF and Chrome?
[19:27] <RedSingularity> Laibsch: no problems here.
[19:28] <Laibsch> RedSingularity: thank you for testing.  I wonder what's causing it here, then.  I'm running lucid, but I believe these days we still get the latest browsers.
[19:28] <Laibsch> I'll treat it as a singularity then and ignore it ;-)
[19:28] <RedSingularity> Laibsch: lol!
[19:29] <greg-g> Laibsch: I'm getting a slow script warning from Fx
[19:29] <greg-g> http://paste.mitechie.com/show/585/
[19:29] <greg-g> (the space in the url is because I had to trick the paste service I didn't have a link)
[19:29] <Laibsch> RedSingularity: are you blocking scripts, flash or anything like that?
[19:29]  * greg-g isn't blocking anything, and has flash nonfree install
[19:30] <greg-g> ed
[19:30] <RedSingularity> Laibsch: nope.  Running lucid as well.
[19:30]  * greg-g is on Oneiric
[19:30] <RedSingularity> Laibsch: what version ff you have?
[19:30] <Laibsch> RedSingularity: javascript enabled?
[19:30] <RedSingularity> Laibsch: yep
[19:30] <Laibsch> OK
[19:30] <Laibsch> I have 11.0
[19:30] <Laibsch> updated yesterday, I think
[19:30] <RedSingularity> Laibsch: version:  10.0.2+build1-0ubuntu<IP_ADDRESS>
[19:31] <RedSingularity> on mine
[19:31] <Laibsch> I see
[19:31] <Laibsch> maybe a regression, then
[19:31] <Laibsch> try to update FF, please
[19:31] <RedSingularity> Laibsch: alright standby
[19:32] <RedSingularity> there was an update.  installing now.
[19:32] <RedSingularity> New version: 11.0+build1-0ubuntu<IP_ADDRESS>
[19:33] <RedSingularity> Laibsch: still no problems here
[19:33] <Laibsch> just to be sure, you restarted FF?
[19:34] <RedSingularity> yep, killall firefox-bin
[19:34] <Laibsch> OK
[19:34] <Laibsch> singularity it is, then ;-)
[19:34] <Laibsch> thanks, guys
[19:34] <RedSingularity> no prob ;)
[19:37] <RedSingularity> daily iso's are still not done :(
[22:08] <notgary> Hi there. Could I ask someone with the correct permissions to close this bug please? https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/144797 It's four and a half years old, was closed upstream last year, the steps provided are not sufficient to reproduce, and the stacktrace is too outdated to use. The Rhythmbox code has changed so much that it has probably been designed out.
[22:08] <ubot2> Launchpad bug 144797 in rhythmbox "rhythmbox crashed with SIGSEGV in rhythmdb_entry_get_playback_uri()" [Medium,Triaged]
[22:11] <notgary> Ah, sorry, I didn't realise I could close it myself :P


[02:45] <lotuspsychje> good morning
[11:22] <EriC^^> good morning all
[12:19] <TJ-> tomreyn: careful with Kolusion; australian person, /very/ nasty and abusive to several people trying to help him in #networking the last week. He in there again now, getting help, claiming info is missing from man iptables when we're quoting it and linking to the debian HTML man-page of it
[12:24] <tomreyn> thanks TJ-
[12:24] <tomreyn> and good morning, EriC^^
[13:06] <TJ-> Kolusion got shutdown in #networking a few minutes ago for being abusive (again!); now cross-posting the same questions again in #linux and #ubuntu. Take care if you interact with them
[13:33] <TJ-> cbreak: hehehe like it
[13:36] <cbreak> I'm not sure my answer was appreciated. :/ ah well.
[13:37] <TJ-> it was, by me :)
[13:39] <TJ-> cbreak: don't engage with them; that's what they want
[13:40] <cbreak> yeah. But... playing with little things is fun :(
[13:40] <TJ-> but not in the support channels; because if even a few do that it quickly gets out of hand, and sets a bad example.
[13:45] <EriC^^> tomreyn: :)
[16:50] <lotuspsychje> you around ogra ?
[16:51] <ogra> semi (on the way out to do weekend groceries)
[16:52] <lotuspsychje> ogra: whats the alternate way to list all installed snaps, now its vanished from df -h ?
[16:52] <ogra> snap list
[16:52] <TJ-> "snap list"?
[16:52] <ogra> 😉
[16:52] <TJ-> I guessed correct :P
[16:52]  * daftykins chuckles
[16:52] <daftykins> damn lotus i knew that and i won't touch the stuff :P
[16:52] <lotuspsychje> tnx
[16:53] <TJ-> well,, to be fair, if it had been invented by Redhat devs, it'd be called listcracklexml
[16:53] <TJ-> (homage to the stupid naming in libvirt/virsh!)
[16:53] <lotuspsychje> https://dpaste.org/98Ff
[16:53] <lotuspsychje> there we go
[16:53]  * ogra grins
[16:54] <ogra> wow,, how did you get "bare" installed ?
[16:54] <lotuspsychje> ogra: im on 22.04 devel :p
[16:55] <lotuspsychje> bad news?
[16:55] <ogra> nah, just useless
[16:56] <ogra> bare is an empty execution env ... i.e. if you have a fully static snap you could use bare as its runtime (other runtimes are core/core20)
[16:59] <lotuspsychje> ok, ill leave it to defaults here, see what happens in the future
[17:00] <ogra> yeah, it wont do any harm ... just waszes 4kb on disk
[17:00] <ogra> *wastes
[17:00] <TJ-> how dare it!
[17:02] <lotuspsychje> lol
[17:03] <TJ-> I recently invented an infinity drive; I installed it on all your systems. You'll find it mounted at /dev/null
[17:05] <lotuspsychje> https://imgur.com/a/ftJstqC
[17:13] <daftykins> TJ-: ooh that's where #ubuntu chat logs go!
[17:13] <daftykins> 8D
[17:13] <TJ-> daftykins: :)
[17:30] <lotuspsychje> https://imgur.com/a/VQrgg6y
[17:30] <lotuspsychje> desktop icons seems to be an extension now
[17:44] <Fatal_Sushi> lotuspsychje: has been for the past few releases
[17:45] <Ronalds_Mazitis_> hey
[17:45] <lotuspsychje> Fatal_Sushi: i didnt see that on fossa
[17:45] <Ronalds_Mazitis_> which video editor would You use with nvidia gpu
[17:45] <Ronalds_Mazitis_> on ubuntu?
[17:45] <Ronalds_Mazitis_> 21.04
[17:46] <Fatal_Sushi> lotuspsychje: has been since 20.10
[17:46] <lotuspsychje> Fatal_Sushi: i only test lts :p
[17:47] <lotuspsychje> Ronalds_Mazitis_: video editors will use the graphics card thats in your machine?
[17:47] <Ronalds_Mazitis_> yeah
[17:47] <Ronalds_Mazitis_> there is vaapi hardware acceleration and nvenc
[17:47] <Ronalds_Mazitis_> shotcut had this feature
[17:47] <Ronalds_Mazitis_> on windows and linux
[17:47] <Ronalds_Mazitis_> but it stopped worked
[17:48] <Ronalds_Mazitis_> I already explained on #ubuntu
[17:48] <Ronalds_Mazitis_> last error was really suspicios
[17:49] <Ronalds_Mazitis_> oh
[17:49] <Ronalds_Mazitis_> NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver. Make sure that the latest NVIDIA driver is installed and running.
[17:49] <Ronalds_Mazitis_> damn the driver died
[17:50] <Ronalds_Mazitis_> wtf
[17:50] <Ronalds_Mazitis_> sorry


[00:33] <daftykins> i reported in ops before things got too dumb
[00:33] <daftykins> :)
[00:33] <daftykins> yeah could be one of our fans!
[00:34] <pauljw> support is really weird tonight isn't it?
[00:39] <Bashing-om> Papa OerHeks said there would be days like this .
[00:39] <pauljw> :)
[00:46] <daftykins> but he never told me what to do ;_;
[00:52] <Bashing-om> daftykins: Oh dear, I bet you just were not listening ? ( dashing my mental image of daftykins -- crash )
[00:56] <daftykins> :D
[01:03] <wileee> please release me, put me in ignore ;)
[01:07] <daftykins> tgm4883: not sure why you're backing up clowns today
[01:08] <tgm4883> daftykins: I'm not?
[01:08] <tgm4883> daftykins: I suppose I'm kinda tired of people not being able to troubleshoot off script
[01:09] <daftykins> hmm?
[01:09] <Bashing-om> users ! Is this a friday, or is this a friday ?
[01:10] <daftykins> :D
[01:10] <tgm4883> daftykins: it just seems like (not you specifically) that #ubuntu has become a place where if someone asks a question about something that is a slightly non-standard way of doing something that we just give up and make them conform to our standards
[01:11] <daftykins> yeah but look what happened... user fucked up
[01:11] <daftykins> now he/she is withholding information too from being too butthurt over what i said
[01:11] <daftykins> and i might add, that's after telling two different tales about what happened :)
[01:11] <tgm4883> daftykins: probably yes, but hammering them with "why did you do that you don't need to do that" is not helpful. Asking them for the parted info is more helpful. Asking for the parted info first would have gotten us the info
[01:12] <tgm4883> daftykins: so while yes, you got to berate the user for doing it wrong, now we're in a standoff
[01:12] <daftykins> i think you're reading into it with too much emotion
[01:12] <daftykins> i asked why it was done the way it was done
[01:12] <wileee> their attitude was a stand off waiting till leaving or banned
[01:15] <tgm4883> daftykins: I'm pointing out that for 5 minutes of "troubleshooting" you could have asked for the parted info (or for the partitioner log), instead you just kept telling them they didn't need to partition first, despite that not being a reason the partitioner should fail
[01:15] <tgm4883> logs or parted output would prove what you suspected
[01:15] <tgm4883> in any case, someone should file a bug against partman if they can reproduce that
[01:16] <daftykins> we only got to the partition layout deduction once the user gave the real, second version of events
[01:16] <daftykins> so i don't greatly appreciate a judging in hindsight
[01:16] <daftykins> i'm sure all your support is perfect :)
[01:17] <shreyash> Hi, My name is Shreyash! I love Ubuntu and have been using it for a long time. I would like to contribute! Can anyone give me some guidance??
[01:17] <tgm4883> daftykins: second thing he said "guest24234> i set up a duel boot using gparted and its hanging when i choose something else" First thing he said was he was having an issue with the 15.04 installer
[01:18] <Bashing-om> shreyash: A place to start : https://wiki.ubuntu.com/ContributeToUbuntu .
[01:18] <daftykins> right which ended up being a lie
[01:18] <tgm4883> through deduction, I figured out he was having an issue with the partitioner, which leads me to believe I should look at partman logs
[01:18] <tgm4883> daftykins: was that a lie? I didn't see that anywhere
[01:18] <tgm4883> shreyash: what do you know how to do?
[01:18] <daftykins> well yeah because then we're told it's installing
[01:19] <shreyash> Installer usually appears to hang during installation if there is is a lot of drive area/multiple drives involved. I don't really know the issue but I'm pretty good with the installer. I've done some hackintosh installation as well.
[01:20] <shreyash> I'm good at programming in c++, web development, a bit of java... Also I'm familiar with git
[01:21] <tgm4883> shreyash: I agree, a good place for you to start would be that wiki page
[01:21] <shreyash> Going through it right now :)
[01:21] <tgm4883> daftykins: did I back up any other clowns today?
[01:22] <daftykins> nope just that one :)
[01:22] <tgm4883> heh ok
[01:22] <daftykins> though hopefully second guessing doesn't become a regular thing
[01:23] <tgm4883> I didn't recall, I was backing up some developers on a mailing list the last few days
[01:25] <tgm4883> oh I wasn't second guessing you, I agree the user didn't need to partition first. I just flat outl think that was bad support. It's similar to if a user said, "I'm having trouble with qbittorrent" and all you said was "hey you dummy, use transmisssion instead".
[01:26] <tgm4883> I mean, sure, tell him once, but then get on with the troubleshooting
[01:26] <tgm4883> also, I really like bringing this discussion out into this channel. Gives us a chance to see both sides
[01:29] <daftykins> i think that's a poor comparison but i know what you're getting at
[01:29] <daftykins> i was really hoping the response was going to be "well i went that way because it didn't work when i..."
[01:29] <daftykins> but we didn't get that.
[01:30] <tgm4883> heh, yea usually we get a "I did this because I thought it would be amazballs!"
[01:31] <daftykins> i suspect that one will be back after 30+ minutes of trying to create a swap partition and wondering why it's refusing
[01:32] <tgm4883> daftykins: yea probably
[01:33] <tgm4883> daftykins: sorry you were the target there. It's more a reflection of where #ubuntu is going. It just seems to be that the only thing that gets support is "This is how we've always done it, so you must do it this way or get no support".
[01:34] <tgm4883> #ubuntu has been doing that increasingly the last few years anyway
[01:35] <daftykins> hrmm can't say i've noticed that myself
[01:36] <daftykins> though i don't pay too much attention to the issues i know nothing about :>
[01:40] <tgm4883> daftykins: meh, I just like figuring out how stuff works so I'm willing to dig in a bit
[01:40] <tgm4883> my favorite was when 12.04 came around with the switch to dnsmast and resolvconf
[01:41] <tgm4883> people couldn't access certain things and rather than troubleshoot the status quo for #ubuntu was "all you have to do is uninstall dnsmasq"
[01:41] <tgm4883> like that should be a valid final answer
[01:45] <daftykins> ;)
[01:45] <daftykins> first thing i do on my servers is purge resolvconf, reboot and hardcode my DNS + set static IP :D
[01:46] <tgm4883> resolvconf isn't bad. It just generates the resolv.conf file. It's dnsmasq that makes troubleshooting more difficult
[01:46] <tgm4883> although I fixed mine from earlier (well, figured out what the issue was)
[01:48] <tgm4883> configuring static addresses in /etc/network/interfaces with dns-nameservers puts the right addresses in there anyway
[01:48] <tgm4883> in /etc/resolv.conf that is
[01:48] <daftykins> i thought it appended once, which wasn't ideal
[01:50] <tgm4883> I believe it regenerates it any time there is a network connection change, but it's easy enough to force extra info in there (whether it's in the interfaces file or in the /etc/resolv.conf.d/ files)
[01:50] <tgm4883> we ran it on all our servers without issue
[02:41]  * ObrienDave gives up
[02:50] <daftykins> this one needs euthanising
[02:50] <ObrienDave> yup ;p
[02:53] <wileee> looks like the same troll honestly
[02:54] <daftykins> same as which nick?
[02:54] <wileee> the one banned earlier and has had nics starting with k
[02:55] <wileee> probably not slight difference, there are so many out there stopping by
[02:55] <ObrienDave> k80s ?
[02:55] <wileee> kidoro or something
[02:56] <wileee> up till today there were Koning
[02:56] <wileee> then changed to koning today
[03:09] <daftykins> well i guess my first victim with the ubuntu graphics driver PPA didn't work out
[03:10] <ObrienDave> that one on you? for shame ;P
[03:13] <daftykins> XD
[09:17] <lordievader> o/
[14:26]  * daftykins groans
[14:38] <pauljw> unreal...
[16:55] <Limberian> Guys, hello.
[16:56] <Limberian> Is there any browser plugin or anything that automatically deletes history every  hour?
[16:56] <cfhowlett> why ask here?  that's a support questoiin
[16:57] <Limberian> It seemed like a which browser is better discussion to me - but okay. :(
[18:46] <tgm4883> OerHeks: am I taking crazy pills here or is #ubuntu just crazy
[18:55] <daftykins> :D
[18:55] <daftykins> i think that's why some of us aren't quite so idealistic, we get worn down by the masses
[18:56] <OerHeks> or this makes you stronger
[18:59] <daftykins> just earlier i pushed someone in the direction of a solution in another help channel, only to be told i was ignored for my attitude when i suggested that their problematic firewall software may need reconfiguring if it is to work properly
[18:59] <daftykins> i swear there's what i type, then there's what people read :D
 tokam: hmm, ideally you'd want another disk to backup to first
 ok. let's assume I did this...
[19:33] <daftykins> sums it up really doesn't it :)
[19:35] <Bashing-om> Yeah, Best practice forward. Protect important data - or the data is not important .
[20:15] <daftykins> that kairo fellow looks like the same k* angry type from the last week
[20:18] <Bashing-om> I seem to think I have seen the nick before .
[20:18] <daftykins> angry Frenchman again
[20:19] <daftykins> or French person, i should say
[20:20] <Bashing-om> American expression : "looking a gift horse in the mouth"; Will not get one very far here !
[20:20] <daftykins> :D
[20:20] <daftykins> indeed
[20:22] <OerHeks> Bashing-om, just noticed in Debian a domain got banned beiing a honeypot. same one hops in/out in ubuntu with different names too
[20:23] <daftykins> o rly
[20:24] <OerHeks> or are they just joking, as reaction on the flood?
[20:26] <Bashing-om> OerHeks: K; We standby for heavy rolls .
[20:27] <OerHeks> "ban on<EMAIL_ADDRESS>[20:36] <daftykins>  -!- kmuuc<EMAIL_ADDRESS>[20:36] <daftykins> well well.
[20:37] <daftykins> and now Izotr
[20:37] <daftykins> clearly a trouble maker
[20:38] <OerHeks> and those fbx.proxad.net i do not trust either.
[20:38]  * OerHeks looks out of the window
[20:48] <daftykins> Called "Ubuntu AFter INstall" - as in UAFIN a laugh - </London accent>
[20:52] <tgm4883> daftykins: you should also be able to get the BIOS version from dmidecode
[20:52] <tgm4883> 'sudo dmidecode | grep -i BIOS -A 5
[20:52] <tgm4883> '
[20:53] <daftykins> tgm4883: yep, but of course the user couldn't boot so i figured why make them :)
[20:53] <daftykins> well, they could boot legacy but that's not what they're after
[20:53] <tgm4883> oh didn't read back that far :)
[20:53] <daftykins> :D
[21:10] <daftykins> warning, ablest is a nasty customer
[21:13] <OerHeks> i know, a debian guy
[21:13] <daftykins> oh :(
[21:14] <OerHeks> hang in debian too man, then you notice some funny movements.
[21:15] <daftykins> that could well be handy i guess
[21:34] <daftykins> hrmm, should changnesia not be seeing a mount point on the EFI partition in his/her image? http://i.imgur.com/Mxzjgzl.jpg
[21:35] <daftykins> or does it do that later..
[21:46] <wileee> I was curious to see how this plays out, heh you got them this far.
[21:53] <shabonix> Quick Question for anyone here at the moment...Currently not happy with windows 10 and all the tracking, etc that they are doing. Want to switch to ubuntu...I have two drives in my system. Boot Drive is an ssd with windows install and the other is a 500gb storage drive. Would moving files over to the storage drive, erasing boot drive, installing ubuntu, then mounting the storage drive into ubuntu be a good way of installing?
[21:58] <wileee> shabonix, I would have an external back up no matter what. That is a UEFI install most likely, have you read the wiki?
[21:59] <shabonix> Partially, thats one of the main reasons I came to the irc.
[21:59] <wileee> this is not really a support channel as well
[21:59] <shabonix> Ok. Thanks for the info!
[21:59] <wileee> try #ubuntu