[08:02] <cpaelzer> ahasenack: the replies on the ZFS fallocate case seem good, lets see what further happens
[08:03] <cpaelzer> it seems to get partially philosophic about "lying to userspace" :-)
[08:10] <cpaelzer> 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] <cpaelzer> oh the link already works http://openvswitch.org/releases/NEWS-2.12.0
[08:25] <cpaelzer> well I'lla dd this then
[08:51] <seb128> k, so network-manager's autopkgtest started failing on eoan/i386 because linux-headers-generic went missing
[08:51] <seb128> which I expect is a wanted archive change?
[08:51] <seb128> does anyone know the recommended alternative/what the pkg should install/do instead?
[09:37] <seb128> 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] <Laney> seb128: guess so
[09:45] <Laney> you probably want vorlon for this
[09:45] <seb128> vorlon, ^
[09:45] <seb128> help please :)
[09:45] <seb128> Laney, thx
[09:45] <Laney> I'll do the hint for now
[09:46] <Laney> would be good to have an update and some advice on what to do in general
[09:46] <seb128> thx
[09:46] <seb128> right
[09:47] <seb128> 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] <cpaelzer> xnox: thanks for your words on openssl
[11:52] <cpaelzer> reads good and I feel better now
[11:52] <cpaelzer> I'll give the DEFAULT@SECLEVEL a test somewhen soon
[11:53] <cpaelzer> 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] <xnox> cpaelzer:  there is nothing new in them =) it's just repeats of things that were said in Brussels & Malta
[11:53] <cpaelzer> I haven't heard about dh-keysize being known or the related potential workaround yet
[11:54] <cpaelzer> maybe I haven't heard all in Brussels/Malta or was in different sessions at the time
[11:59] <cpaelzer> I remember we talked in Paris (and before) about the reasoning being long term maintainability
[11:59] <xnox> 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] <xnox> cpaelzer:  and given that tlsv1.3 is siletnly enabled, so slightly higher level concern than dh-size.
[11:59] <cpaelzer> yep
[12:03] <ahasenack> cpaelzer: I can use a workaround of some sort: use zvols, libvirt has integration for that
[12:03] <ahasenack> each vm will get its own zvol, instead of a qcow2 image
[12:04] <cpaelzer> I'd have wondered if apparmor for these work
[12:04] <cpaelzer> does it?
[12:04] <cpaelzer> but surely if that works for you, feel free to do so
[12:05] <ahasenack> well, I installed eoan on a vm using this scheme
[12:05] <cpaelzer> without manually tweaking apparmor
[12:05] <cpaelzer> nice
[12:05] <ahasenack> that was the extent of my testing, and I also snapshotted the volume, but using zfs, not libvirt's snapshot
[12:05] <cpaelzer> that should be enough, then the labelling changes I did a while ago might pay off
[12:05] <cpaelzer> I haven't tested it in regard to zvols back then
[12:06] <cpaelzer> two positive news in sequence much better than the rest of the morning, keep going ahasenack and xnox :-)
[12:25] <doko> seb128: hmm, why is valgrind expecting debug info in the shared libs, they should be stripped anyway?
[12:44] <seb128> 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] <doko> valgrind is rebuilt after the glibc upload, so that should be ok
[12:47] <doko> seb128: when did you start seeing these?
[12:48] <seb128> 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] <doko> seb128: and mono/s390x, I didn't upload, just synced the python2 removal over there. contacted debian/upstream and xnox for now
[13:04] <seb128> doko, thx
[13:19] <xnox> doko:  ftbfs in debian too, just attempted a rebuild in sid chroot with sbuild
[14:12] <tarzeau> 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] <tarzeau> dphys-config; aptitude-robot-session
[14:12] <tarzeau> https://bugs.launchpad.net/debian/+source/fasttracker2/+bug/1815447
[15:01] <seb128> doko, thanks for that next cycle archive opening email, it's useful to see what's going on!
[15:27] <seb128> 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] <fossfreedom> 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] <HokarPokar> 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] <HokarPokar> down. What I want is to detect a certain sequence of keypresses and then, map that to a command
[15:43] <HokarPokar> The subtlety that I am not aware of is, how to detect keypresses for all the applications in ubuntu.
[15:51] <rbasak> 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] <rbasak> It won't be Ubuntu specific either - just specific to X probably.
[16:10] <xnox> HokarPokar:  sounds like you are trying to implement a keylogger
[16:11] <xnox> HokarPokar:  or look at other similar launchers, like https://en.wikipedia.org/wiki/GNOME_Do or gnome-settings-daemon
[16:11] <xnox> HokarPokar:  cause one can setup a few keyboard shortcuts there. Study their source cod?
[16:11] <xnox> *code?
[16:13] <HokarPokar> 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] <HokarPokar> @xnox
[16:13] <udevbot> Error: "xnox" is not a valid command.
[16:14] <HokarPokar> 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] <xnox> really don't care =) i don't work on graphical level stack
[16:44] <sarnold> HokarPokar: what's your question url? I can't spot it in the list of SO questions
[16:53] <seb128> 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] <seb128> would welcome some help
[16:54] <vorlon> seb128: I thought Laney had already hinted it?
[16:54] <vorlon> 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] <seb128> vorlon, Laney said he hinted that version but was unsure what we were supposed to do
[16:55] <vorlon> seb128: and in fact this is the hint Laney already added
[16:55] <seb128> 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] <vorlon> seb128: I don't think you should bother with sourceful changes
[16:56] <seb128> 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] <vorlon> ack
[16:57] <seb128> vorlon, sounds like 'just hint those" is what is recommended then
[16:57] <vorlon> indeed
[16:57] <seb128> vorlon, thanks!
[16:57] <vorlon> and I'll write a longer answer to a mailing list later
[16:57] <seb128> great
[17:05] <seb128> 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] <fossfreedom> 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] <fossfreedom> 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] <seb128> fossfreedom, thx