[04:42] <gbit86__> Anyone know if there is a direct and single keycode I can use to simulate a Control+Left arrow key input that will move a cursor by word in a GUI app?
[04:43] <gbit86__> I've got a conflict on my remapping that I think can only be solved by skipping any mention of Control+Left.. because I am also remapping Control+Left to another duty.. Alt+Left as odd as that may seem..
[04:44] <gbit86__> and I need Alt+Left to actually do Control+Left.. but.. so that is my world atm.
[04:46] <gbit86__> The big issue is that chrome uses Alt+Left as a back button.. not easy to fix. I want it to ignore Alt+Left altogether and use Ctrl+[
[04:46] <gbit86__> that's really what's screwing me over.
[07:38] <cpaelzer> cjwatson: hiho - is openssh 8.2 soemthing you'd look at getting into focal https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1863447 ?
[07:39] <cpaelzer> rbasak: ^^ since you asked about 8.2 as well
[08:33] <cjwatson> cpaelzer: already working on it
[08:34] <cjwatson> but also not at work today
[08:43] <cpaelzer> thanks cjwatson I just wanted to check if it is known/under-control and that it is
[08:43] <cpaelzer> enjoy your day
[12:26] <ahasenack> rbasak: hi, I'm done with the my_bool ftbfs in my ppa: https://trello.com/c/SnUYinhZ https://launchpad.net/~ahasenack/+archive/ubuntu/mysql8-my-bool-removal/+packages
[12:26] <ahasenack> rbasak: the remaining ones are "normal" ftbfs, which, once resolved, could still require the my_bool typedef
[12:27] <ahasenack> rbasak: https://pastebin.ubuntu.com/p/PPgKpbQyrz/ standard d/changelog and dep3 patch I'm using
[12:28] <ahasenack> hm, just realized I should remove the pkg name from the bug url
[12:28] <ahasenack> so it can really be re-used
[12:29] <ahasenack> should I start with the actual uploads? What should we do about reviews?
[12:30] <ahasenack> or fix the remaining "normal" ftbfs first?
[12:54] <rbasak> ahasenack: nice job!
[12:56] <ahasenack> rbasak: thx! The usual pattern for the patch is as we discussed:
[12:56] <ahasenack>  #include <mysql.h>
[12:56] <ahasenack> +typedef bool my_bool;
[12:58] <rbasak> ahasenack: I'm happy for you to start uploads in the archive immediately. But we'll need to cover those FTBFS immediately and I don't see any big benefit to starting sooner
[12:58] <rbasak> But we'll need to cover those FTBFS _anyway ad I don't...
[12:58] <ahasenack> FF is my concern
[12:59] <rbasak> Skuggen: FYI ^
[13:00] <rbasak> ahasenack: OK, go ahead then I guess. It seems unlikely that we'll get hung up on fixing any of the remaining FTBFS as a result of this change, anywa
[13:00] <rbasak> y
[13:00] <rbasak> ahasenack: MySQL packaging is maintained in Salsa
[13:01] <ahasenack> rbasak: I was just going to "nmu" it
[13:01] <ahasenack> but the mysql one I can do properly
[13:01] <ahasenack> rbasak: so no git-ubuntu for mysql-8?
[13:01] <ahasenack> how do you keep the g-u tree in sync with salsa?
[13:02] <rbasak> I don't use the g-u tree - so I don't use upload tags and generally ignore it
[13:02] <rbasak> To catch up Salsa against "NMU"s I "borrow" the git ubuntu imported tree objects
[13:02] <rbasak> But make up the commits myself
[13:02] <rbasak> (same as a gbp workflow I guess)
[13:04] <ahasenack> how about I just use g-u for ubuntu's mysql, and then you later at some point fixup the salsa branch?
[13:20] <rbasak> ahasenack: if I catch the salsa branch up quickly for you now, would it cause any difficulty to you to use it directly instead?
[13:20] <ahasenack> url? Let me take a look
[13:20] <rbasak> https://salsa.debian.org/mariadb-team/mysql/tree/mysql-8.0/ubuntu/devel
[13:20] <ahasenack> what would I do, create a MR against it?
[13:20] <rbasak> Yes please, or I can add you to the project.
[13:21] <rbasak> I'm asking because I'd like the workflow settled, rather than me always playing catchup with "NMU"s from our own team.
[13:22] <ahasenack> ok
[13:22] <rbasak> But if you feel that you've got enough else to do already to take that on, then sure, do it how you prefer for now, but we should resolve this question later. I don't mind if you want to defer it.
[13:22] <ahasenack> let me know when the tree is up-to-date
[13:23] <rbasak> OK I'll update it now thanks
[13:23] <ahasenack> today I suppose?
[13:23] <rbasak> Next ten minutes I'm hoping
[13:23] <ahasenack> ok
[13:24] <tarzeau> how can i get back /usr/bin/python ?
[13:30] <rbasak> ahasenack: done. Note it's the mysql-8.0/ubuntu/devel branch there - that's not the default HEAD.
[13:31] <ahasenack> ok
[13:31] <rbasak> ahasenack: want to give me one of the FTBFS to investigate?
[13:31] <ahasenack> rbasak: icinga2 if you would
[13:31] <rbasak> Sure
[13:31] <ahasenack> it misdetects the boost version for some reason
[13:38] <ahasenack> rbasak: ugh, another kernel source to blacklist:
[13:38] <ahasenack> 18837 ?        S      0:02      |           \_ /usr/bin/perl /snap/git-ubuntu/464/usr/bin/dpkg-source -x /tmp/tmpiiuj19zk/.git/git-ubuntu-cache/linux-gcp_5.3.0-1008.9.dsc /tmp/tmp3ebzs916/x
[13:39] <ahasenack> I was just checking why haproxy hasn't been imported yet
[13:39] <ahasenack> that thing is probably holding the whole importer up
[13:40] <ahasenack> rbasak: +1? https://pastebin.ubuntu.com/p/ryChqz8B6p/
[13:41] <rbasak> ahasenack: +1
[13:41] <rbasak> No need to ask IMHO :)
[13:41] <ahasenack> I could have typoed it :)
[13:46] <rbasak> /usr/bin/ld: cannot find -lpthreads
[13:46] <rbasak> Shouldn't that be pthread (not plural) or is pthreads something different?
[13:48] <rbasak> Oh apparently it's a boost thing?
[13:54] <ahasenack> don't know
[13:54] <ahasenack> that could just be a ./configure check, normal
[13:55] <xnox> with cmake, look for "./debian/rules build" then look for the _first_ error from cmake, not the last one.
[13:55] <xnox> cause it tries all the pthreads things, and there is always error about not able to find one of the alternative ptreahd names
[13:55] <ahasenack> that will be the boost version check I mentioned
[13:55] <rbasak> Ah
[13:55]  * rafaeldtinoco uploaded pacemaker again (trying to fix up i386 issues blocking migration)
[13:55] <rbasak> Thanks xnox, that helps!
[13:55] <ahasenack> it wants boost 1.34, and fails to see 1.7x is higher
[13:56] <xnox> lovely
[13:56] <xnox> i think there must be a Boost_Version check too? cause it changed format from 1000000 to 1.00
[13:56] <ahasenack> that's it then
[13:56] <ahasenack> it was comparing a long number with no decimal points to "1.34"
[13:57] <ahasenack> I actually filed a bug about it, sorry I forgot to mention it: https://bugs.launchpad.net/ubuntu/+source/icinga2/+bug/1863371
[13:57] <ahasenack> rbasak: ^
[13:57] <rbasak> Thanks
[13:59] <rbasak> https://github.com/Icinga/icinga2/commit/b0b34f472ed6344d0822e9dc9e940dcc27a0751c "Fix building with Boost 1.71"
[13:59] <rbasak> Upstream just removes the check.
[13:59] <rbasak> I'll cherry-pick that
[14:07] <ahasenack> rbasak: https://salsa.debian.org/mariadb-team/mysql/merge_requests/31 ?
[14:07] <rbasak> looking
[14:09] <rbasak> ahasenack: merged, thanks!
[14:09] <rbasak> (the CI pipeline is broken and always fails currently)
[14:10] <ahasenack> what now?
[14:10] <rbasak> ahasenack: commit a changelog change, tag and upload?
[14:10] <ahasenack> tag?
[14:11] <ahasenack> oh, you mean do it again in g-u?
[14:11] <rbasak> No
[14:11] <rbasak> Just in git
[14:11] <rbasak> The tag is only informative, not used for anything else
[14:11] <ahasenack> what is the format?
[14:11] <rbasak> I just follow the previous pattern
[14:11] <ahasenack> I have too many remotes
[14:12] <ahasenack> mysql-8.0/ubuntu/8.0.19-0ubuntu2
[14:12] <ahasenack> ok, that format
[14:12] <rbasak> Right
[14:12] <ahasenack> oh, I didn't push the changelog commit, sorry
[14:13] <rbasak> Also there's https://salsa.debian.org/mariadb-team/mysql/blob/mysql-8.0/ubuntu/devel/debian/README.source that explains the git namespace
[14:15] <ahasenack> rbasak: will you cherry-pick this? https://salsa.debian.org/andreas-guest/mysql/commit/70eff4192548b52a02adcb0e004b572489066369
[14:15] <ahasenack> and I can't push the tag to your repo
[14:15] <rbasak> Let me add you to the project
[14:18] <rbasak> ahasenack: done
[14:18] <ahasenack> thx
[14:18] <rbasak> (added you)
[14:18] <rbasak> Do you still want me to cherry-pick?
[14:18] <rbasak> ahasenack: also, icinga2 patch ready: https://paste.ubuntu.com/p/G2NF3YyGX8/ - that works for me locally against your PPA.
[14:19] <rbasak> How do you want to handle these?
[14:19] <rbasak> And would you like to give me another
[14:19] <ahasenack> rbasak: get me a branch and I'll upload to that ppa
[14:19] <rbasak> ahasenack: in git-ubuntu? Do we have all those relevant universe packages imported?
[14:19] <ahasenack> rbasak: libdbi-drivers is one I didn't investigate
[14:19] <ahasenack> rbasak: no, not impored, you are right. I have local branches just
[14:20] <ahasenack> rbasak: I'll get your pastebin
[14:20] <ahasenack> thx
[14:20] <rbasak> Thanks
[14:20] <rbasak> I'll take libdbi-drivers next then
[14:20] <ahasenack> all I know about that one is that a unit test failed (run during pkg build)
[14:20] <ahasenack> could be flaky, could be a can of worms. N oidea
[14:20] <ahasenack> you can check the ppa build logs
[14:21] <rbasak> ack
[14:21] <ahasenack> https://launchpad.net/~ahasenack/+archive/ubuntu/mysql8-my-bool-removal/+build/18694052
[14:21] <ahasenack> rbasak: ^
[14:21] <ahasenack> rbasak: wrt mysql, let me exercise my new privileges, carefully
[14:22] <LocutusOfBorg> mitya57, so with libserial fixed I guess we are waiting for you to upload this? https://salsa.debian.org/python-team/modules/qscintilla2/commit/cdf70449b3dae5a7429c3f3f3c55db3d058d3da0
[14:23] <rbasak> I set a local build off to compare
[14:23]  * rbasak will be back in 20
[14:25] <seb128> vorlon, the colord/i386 hint force-badtest needs to be updated. Shouldn't that one just flagged as bad and not for a specific version? As the comment hints, it requires gnome-session&co
[14:44] <rbasak> Looks like a minor floating point mismatch
[14:48] <ahasenack> rbasak: ok, ready to upload to ubuntu
[14:49] <ahasenack> got this during source package build: dpkg-source: warning: ignoring deletion of directory source_downloads
[14:49] <ahasenack> due to the git empty directory issue, right?
[14:49] <ahasenack> I got a warning about that dir when checking this out/cloning
[14:49] <rbasak> That's normal. I did mention it to Skuggen - it's a useless empty directory in the orig tarball, yes.
[14:50] <ahasenack> ok
[14:52] <ahasenack> rbasak: uploaded, the race to fix things is on (as soon as it builds)
[14:52] <rbasak> \o/
[14:52] <rbasak> Thank you for doing this
[14:53] <seb128> vorlon, openjpeg2 is blocked in proposed due Unsatisfiable depends: spawn-fcgi (>= 1.6.1): i386 ... are you looking at that? (I see you did the previous upload to ignore some debs on i386)
[14:54] <ahasenack> rbasak: thx for helping
[15:00] <rbasak> ahasenack: quick sync on an acceptable fix for libdbi-drivers please
[15:00] <rbasak> The problem seems to be that the FLOAT4 type seems to have gotten more accurate between MySQL 8.0.16 and MySQL 8.0.19 somehow
[15:00] <rbasak> test_dbi.c:3823: unit test failure: pgsql -> libdbi connection -> Retrieving fields as -> test_dbi_result_get_as_string -> [3.402823e+38] should match [3.402820e+38] at [test_dbi.c] line [3823]
[15:00] <rbasak> The test is inserting 3.402823466E+38
[15:01] <rbasak> I don't see anything in the release notes specifically for that, but there have been some other changes in relation to float accuracy that don't specify this change.
[15:01] <ahasenack> did you find an upstream fix?
[15:01] <rbasak> No. Nothing upstream.
[15:01] <ahasenack> I remember glibc getting more accurate a while back
[15:01] <ahasenack> but that was on year ago or more
[15:01] <rbasak> Maybe it's that?
[15:02] <rbasak> 2019-10-18 was the last successful build date
[15:02] <rbasak> Anyway, I assume (not tested) that patching the test will work. Would you consider that acceptable?
[15:02] <rbasak> I can send a report upstream of course.
[15:02] <rbasak> (patching the test for the value we actually get)
[15:03] <ahasenack> can you check if there is a history of such patching?
[15:03] <ahasenack> in these tests
[15:03] <ahasenack> but sounds good with an upstream report linked to the patch
[15:03] <rbasak> The test code upstream doesn't seem to have been touched since  2017-10-27
[15:04] <rbasak> I see the occasional touch of adjustment presumably for database changes, but not many
[15:04] <ahasenack> rbasak: when was the last time it passed for us?
[15:04] <ahasenack> and what was that numeric output then?
[15:05] <rbasak> 2019-10-18
[15:05] <rbasak> The output matched then presumably - 3.402820e+38
[15:05] <rbasak> (since the same test passed then)
[15:05] <ahasenack> and that was mysql 5.7?
[15:05] <rbasak> The output is now 3.402823e+38
[15:05] <rbasak> No that was 8.0.16.
[15:05] <ahasenack> oh
[15:06] <ahasenack> Skuggen: have you seen something like that before, changing? ^
[15:06] <ahasenack> in terms of mysql releases/changes
[15:07] <rbasak> Interestingly, the expected Postgres output in the test is also the less accurate 3.402820e+38
[15:08] <rbasak> But there was only one test failure. Let me patch it and see.
[15:13] <rbasak> The Postgres test is also affected. I had to patch both. Got a successful build now.
[15:16] <ahasenack> rbasak: I'm gonna head out for lunch, thanks so far
[15:54] <rafaeldtinoco> can anyone check if /etc/modules (there is a symlink inside /etc/modules-load.d/modules.conf -> /etc/modules) still works in Focal ? My understanding is that /lib/systemd/systemd-modules-load will load modules described in /etc/modules. That is not ocurring for me, just want to confirm.
[15:54] <rafaeldtinoco> Oh, nm, its a watchdog module.. I think its blacklisted by default
[15:55] <rafaeldtinoco>  /lib/modprobe.d/blacklist_linux-5.4_5.4.0-14-generic.conf
[15:55] <rafaeldtinoco> yep it is. sorry for the noise
[17:03] <ahasenack> rbasak: https://debconf19.debconf.org/talks/63-how-mariadb-packaging-uses-salsa-ci-to-ensure-smooth-upgrades-and-avoid-regressions/
[17:03] <ahasenack> rbasak: the slides are probably in salsa somewhere
[17:05] <ahasenack> rbasak: these are the notes I took when the "workarounds" topic came up: https://pastebin.ubuntu.com/p/trGmBy9n8f/
[17:20] <rbasak> ahasenack: here's the libdbi-drivers fix: https://paste.ubuntu.com/p/NpkMY7HMfh/ - turns out only the Postgres test needed tweaking. Patching the MySQL test seems to make no difference, so I didn't.
[17:21] <ahasenack> rbasak: thanks!
[17:21] <ahasenack> rbasak: and icinga2 rebuilt just fine in the ppa
[17:24] <rbasak> ahasenack: next?
[17:26] <ahasenack> rbasak: zoneminder is harder (https://bugs.launchpad.net/ubuntu/+source/zoneminder/+bug/1859295)
[17:26] <ahasenack> rbasak: apr-util is just a matter of s/python/python2/ I believe
[17:26] <ahasenack> unless we want to move to py3, then some patches from upstream have to be cherry-picked
[17:26] <rbasak> Let me look at apr-util first then, as I don't have much of my day left
[17:26] <ahasenack> "apr-util: Depends: python:any but it is not installable"
[17:35] <rbasak> src:apr has the same issue
[17:35] <rbasak> And if I fix apr-util, then the build still fails because a file provided by src:apr has a python (not python2) shebang
[17:37] <vorlon> seb128: ok, I'll follow up on openjpeg2, apparently my removal of libopenjpip-server on i386 didn't actually take
[17:38]  * rbasak continues digging
[17:53] <rbasak> ahasenack: OK so to fix apr-util we need to patch both apr and apr-util. Here are the unpolished patches. Is the general approach the one we want: apr: https://paste.ubuntu.com/p/Kn9GHT2HpY/ apr-util: https://paste.ubuntu.com/p/kMJjRmJh8Y/
[17:54] <rbasak> ahasenack: I'm going to finish for the day soon. Feel free to pass me more to do for my morning. I haven't looked at zoneminder at all yet - I can look at that tomorrow if you like.
[17:55] <rbasak> And any coordination needed with Foundations and/or doko for Python related fixes?
[17:58] <ahasenack> rbasak: not that I know of, since python3-defaults migrated
[17:58] <ahasenack> rbasak: thanks for your help!
[18:37] <mitya57> LocutusOfBorg: well, I also need to upload pyqt5 :) I will do that when python-cogent becomes a candidate for migration to testing.
[18:37] <mitya57> I didn't mean fixing libserial is urgent, sorry if you understood me wrongly. But python-sip will be removed in 2-3 weeks at most.
[18:57] <gbit86__> Is there a faster way to change symbols of an existing loaded xkb keymap?
[19:43] <cpaelzer> Thanks kanashiro for spotting - nbdkit is odd, it seems since xenial we didn't re-build x86 binaries for dependency issues.
[19:43] <cpaelzer> Just look at the builds in https://launchpad.net/ubuntu/+source/nbdkit
[19:43] <cpaelzer> There is a bad kernel dependency to linux-image-amd64 not existing for us, but think we drop it - then how to resolve the circular dependency that is:
[19:43] <cpaelzer> CIRCLE: src:nbdkit build-depends on binaries of src:libnbd build-depends on binaries of src:nbdkit.
[19:43] <cpaelzer> If anyone here has a good recommendation how to resolve these in Focal let me and kanashiro now please.
[19:45] <cpaelzer> doko: FYI the last nbdkit upload is by you, in case you rely on it to build fine ^^
[19:51] <cpaelzer> kanashiro: libnbd needs nbdkit deps only for tests, so you could maybe do it in this order
[19:51] <cpaelzer> 1. upload a libnbd that has all test-deps dropped and the tests disabled
[19:51] <cpaelzer> 2. upload a nbdkit (-linux-* deps) that can now build finding libnbd-*
[19:51] <cpaelzer> 3. upload a libnbd that has the test deps added back (now available)
[19:52] <cpaelzer> kanashiro: you should be able to play through that in a PPA before doing the same in the archive
[19:52] <cpaelzer> also if others have better recommendations use those, I'm guessing based on what I see
[19:53] <gbit86__> ended up solving it with just using xkbcomp and skipping the setxkbmap command I was using to reset before running xkbcomp. I think xkbcomp runs a lot faster without blanking out my config first.
[19:54] <gbit86__> I just like blanking it first in the past to avoid any cache issues, but I think when changing btwn 2 very similar configs it isn't much problem (only symbols change slightly, but the type and modifier levels don't).
[19:55] <gbit86__> At least this seems to fix and avoid a looping keybinding issue I was running into.
[20:01] <kanashiro> cpaelzer, thanks, I'll try to follow what you suggested in my ppa
[20:31] <LocutusOfBorg> mitya57, I would have done that months ago, if I had noticed the switch from sourceforge to github :)
[20:36] <blaze> LocutusOfBorg: is there a reason for qtcreator not migrating from llvm8?
[22:19] <mwhudson> does anyone happen to know where in the maze of initramfs code udevd actually gets started?
[22:20] <mwhudson> oh the udev package ships hooks/scripts