=== rkta_ is now known as rkta === The_LoudSpeaker is now known as theloudspeaker === theloudspeaker is now known as The_LoudSpeaker [08:02] ahasenack: the replies on the ZFS fallocate case seem good, lets see what further happens [08:03] it seems to get partially philosophic about "lying to userspace" :-) [08:10] jamespage: there are no ovs 2.12 release notes yet - what do you think we should add as link to our release notes? [08:25] oh the link already works http://openvswitch.org/releases/NEWS-2.12.0 [08:25] well I'lla dd this then [08:51] k, so network-manager's autopkgtest started failing on eoan/i386 because linux-headers-generic went missing [08:51] which I expect is a wanted archive change? [08:51] does anyone know the recommended alternative/what the pkg should install/do instead? [09:37] Laney, ^ can you mark the n-m i386 test buggy until I figure out what we should be doing without an i386 kernel? [09:45] seb128: guess so [09:45] you probably want vorlon for this [09:45] vorlon, ^ [09:45] help please :) [09:45] Laney, thx [09:45] I'll do the hint for now [09:46] would be good to have an update and some advice on what to do in general [09:46] thx [09:46] right [09:47] would also have been nice to some announce of such changes happening that late in the cycle but I will stop batting this drum I did it enough [11:52] xnox: thanks for your words on openssl [11:52] reads good and I feel better now [11:52] I'll give the DEFAULT@SECLEVEL a test somewhen soon [11:53] I knew you'll be the one with the best answers being involved in all of this, but it also provides a chance for anyone else to speak up :-) [11:53] cpaelzer: there is nothing new in them =) it's just repeats of things that were said in Brussels & Malta [11:53] I haven't heard about dh-keysize being known or the related potential workaround yet [11:54] maybe I haven't heard all in Brussels/Malta or was in different sessions at the time [11:59] I remember we talked in Paris (and before) about the reasoning being long term maintainability [11:59] cpaelzer: dh-keysize was not known explicitely, it was more of a general what-if given the set of new key-exchange and encryption algos introduced, and their priority / order / size has changed. [11:59] cpaelzer: and given that tlsv1.3 is siletnly enabled, so slightly higher level concern than dh-size. [11:59] yep === ricab is now known as ricab|lunch [12:03] cpaelzer: I can use a workaround of some sort: use zvols, libvirt has integration for that [12:03] each vm will get its own zvol, instead of a qcow2 image [12:04] I'd have wondered if apparmor for these work [12:04] does it? [12:04] but surely if that works for you, feel free to do so [12:05] well, I installed eoan on a vm using this scheme [12:05] without manually tweaking apparmor [12:05] nice [12:05] that was the extent of my testing, and I also snapshotted the volume, but using zfs, not libvirt's snapshot [12:05] that should be enough, then the labelling changes I did a while ago might pay off [12:05] I haven't tested it in regard to zvols back then [12:06] two positive news in sequence much better than the rest of the morning, keep going ahasenack and xnox :-) [12:25] seb128: hmm, why is valgrind expecting debug info in the shared libs, they should be stripped anyway? [12:44] doko, I don't know but those warnings might not be the issue, there is something weird going on though with glib/gtk symbols from my testing, unsure where to start to figure it out though :/ [12:47] valgrind is rebuilt after the glibc upload, so that should be ok [12:47] seb128: when did you start seeing these? [12:48] doko, I didn't do much valgrind debugging on eoan so I can't really tell, I tried to use it on gnome-calendar yesterday and it failed to give me anything useful ... could also be something to do with gnome-calendar though, I will try on some other gnome binaries [13:02] seb128: and mono/s390x, I didn't upload, just synced the python2 removal over there. contacted debian/upstream and xnox for now [13:04] doko, thx [13:19] doko: ftbfs in debian too, just attempted a rebuild in sid chroot with sbuild === ricab|lunch is now known as ricab [14:12] requestsync doesn't work for me anymore but i'd suggest to not release proposed fasttracker2 with 19.10, either take the 1.00 or don't release [14:12] dphys-config; aptitude-robot-session [14:12] https://bugs.launchpad.net/debian/+source/fasttracker2/+bug/1815447 [14:12] Launchpad bug 1815447 in fasttracker2 (Ubuntu) "upstream does not wish a stable release of the software yet" [Undecided,In progress] [15:01] doko, thanks for that next cycle archive opening email, it's useful to see what's going on! [15:27] fossfreedom, hey, did modern toolbar used to be default for rhythmbox-plugin-alternative-toolbar? it's not in 19.10 atm and I wonder if that's a regression/some distro default we lost on the way, do you know maybe? [15:38] It's the default for budgie as of a couple of days ago. I will have to look later to see what happened with ubuntu gnome... driving at the mo' [15:42] Hey guys. I'm trying to write a piece of code that can detect keypresses in background, for any application opened. Does anyone know of an API in ubuntu that can help me achieve this ? The long term goal is to map those sequential keypresses to a command, pretty much like keyboard shortcuts. Except that, keys in keyboard shortcuts need to held [15:42] down. What I want is to detect a certain sequence of keypresses and then, map that to a command [15:43] The subtlety that I am not aware of is, how to detect keypresses for all the applications in ubuntu. [15:51] HokarPokar: you're probably looking for some API against X11 or one of the toolkits that wraps it. But you're offtopic here. Try Stack Overflow maybe? [15:51] It won't be Ubuntu specific either - just specific to X probably. [16:10] HokarPokar: sounds like you are trying to implement a keylogger [16:11] HokarPokar: or look at other similar launchers, like https://en.wikipedia.org/wiki/GNOME_Do or gnome-settings-daemon [16:11] HokarPokar: cause one can setup a few keyboard shortcuts there. Study their source cod? [16:11] *code? [16:13] xnox It does look like I'm implementing a key logger sort of thing. But the intention is different. I want to map certain sequences of key press events to commands. [16:13] @xnox [16:13] Error: "xnox" is not a valid command. [16:14] xnox Can I share a question I just posted on stack overflow ? It has all the details. I hope that doesn't count as promotion [16:22] really don't care =) i don't work on graphical level stack [16:44] HokarPokar: what's your question url? I can't spot it in the list of SO questions === genii_ is now known as genii [16:53] vorlon, hey, unsure if you saw the ping earlier? I'm unsure what should happen to the network-manager i386 autopkgtest now that the kernel headers are not installable? [16:53] would welcome some help [16:54] seb128: I thought Laney had already hinted it? [16:54] seb128: I think we should add a permanent badtest hint for network-manager on i386, because running i386 as a host OS is no longer supported [16:54] vorlon, Laney said he hinted that version but was unsure what we were supposed to do [16:55] seb128: and in fact this is the hint Laney already added [16:55] vorlon, k, so nothing to do from the source? I'm asking because I want to do an upload to include a bug fix, so I was wondering if I should do any change to the autopkgtest while I'm at it [16:55] seb128: I don't think you should bother with sourceful changes [16:56] vorlon, k, wfm. L_aney reply this morning was "I'll do the hint for now, would be good to have an update and some advice on what to do in general" [16:56] ack [16:57] vorlon, sounds like 'just hint those" is what is recommended then [16:57] indeed [16:57] vorlon, thanks! [16:57] and I'll write a longer answer to a mailing list later [16:57] great [17:05] vorlon, thx for the ubiquity review, I need someone to merge for me since I don't have commit rights to that vcs if you want also to do that step... ;) [19:17] seb128: re alternative-toolbar - at some-point in this cycle gnome-shell or Ubuntu has changed this key from True to False https://lazka.github.io/pgi-docs/#Gtk-3.0/classes/Settings.html#Gtk.Settings.props.gtk_shell_shows_app_menu - the plugin is relying on that to set the CSD header - it is defaulting to the compact toolbar instead. Two ways to solve this. One: I could perhaps look instead for "GNOME" in the session [19:17] environment variable - or alternatively the distro can force the modern toolbar via a gsettings override like this https://github.com/UbuntuBudgie/budgie-desktop-environment/blob/master/debian/budgie-desktop-environment.gsettings-override#L10 [20:59] fossfreedom, thx