[00:33] <rbasak> cpaelzer, kanashiro: yeah - figure out a way to break the cycle temporarily. I've been asked to avoid doing that live in the archive. An archive admin will be able to advise.
[01:08] <gbit86__> If anyone would look to take a stab at this problem I just posted.. then please do! https://stackoverflow.com/questions/60272229/detect-status-of-an-input-caret-under-any-or-most-linux-des
[01:08] <gbit86__> like* to take a stab
[01:14] <krytarik> gbit86__: I'm not sure why you still pound the development channel with that.
[01:15] <gbit86__> lol.. because I am relentless in wanting to find an answer. Pretty sure it is the last thing I need to solve to button this project up.
[01:16] <gbit86__> I was hitting the regular ubuntu channel but was directed to go here.
[01:17] <gbit86__> And someone in the ubuntu channel was actually very helpful, pointed me to look at ibus, which did and does work on ubuntu 19.10, but not all ubuntu/debian based systems though.
[01:17] <gbit86__> I tried installing ibus after the fact.. but that does not seem to be enough.
[01:19] <rbasak> mwhudson: systemd is not present in docker containers> well yes, but that's not soemthing that Debian/Ubuntu developers have ever formally considered a use case that they have to maintain. We may have to change that now, but until now Docker's use has effectively been an unsupported hack from our perspective.
[01:19] <rbasak> That's what I meant by "not buggy"
[01:19] <rbasak> I accept that we should do what we can for DOcker users and find a solution here
[01:19] <rbasak> BUt to me it's Wishlist, not a bug.
[01:20] <mwhudson> rbasak: if you depend on a feature from a package that you don't depend on and that package that's not essential, it's a bug per debian policy
[01:20] <rbasak> Though one that deserves some effort
[01:20] <mwhudson> but this is splitting hairs
[01:20] <rbasak> Only for Debian
[01:21] <rbasak> Anyway, sure. I was just trying to explain what I meant.
[01:21] <rbasak> I don't care how we choose to state the problem :)
[01:21] <mwhudson> right, i don't think we actually disagree :)
[01:23] <rbasak> mwhudson: nothing will process the tmpfiles fragments when the container starts> any chance of getting Docker upstream to provide a mechanism for that?
[01:24] <rbasak> If we had a common language to tell Docker what it needs, and Docker understood that language, then that might be a clean way of making it all work end-to-end
[01:25] <mwhudson> rbasak: i doubt it, but apparently the fact that /run and /tmp are not tmpfs in containers is sort of intended to make this sort of thing work
[01:25] <rbasak> So we could provide an opt-in mechanism for Docker image builders?
[01:26] <mwhudson> the opt in mechanism is having postinst create the directories, no?
[01:26] <rbasak> Maybe. It doesn't feel generic enough to me.
[01:27] <mwhudson> well the dockerish answer is "RUN mkdir /run/wibble" in your Dockerfile
[01:27] <rbasak> I'm not sure there's a guarantee that in every case it's appropriate for the postinst to create all tmpfiles immediately, even if that's the default behaviour.
[01:27] <rbasak> Yeah sure, but what I'm suggesting is "RUN mk-tmpfiles.d" rather than the image builder having to know specifics of each package
[01:28] <rbasak> Or something even more generic and not specific to systemd
[01:28] <rbasak> Then our general recommendation could be "if FROM ubuntu, then do that"
[01:28] <rbasak> (or Debian even)
[01:29] <rbasak> That should work today without even needing debhelper mods I think?
[01:30] <rbasak> (if the mechanism is implemented, of course)
[01:31] <mwhudson> rbasak: i have to run, but the idea of a solution that requires people writing dockerfiles to remember to do some extra thing to have things happen that happen automatically on installation on normal systems doesn't really appeal
[01:31]  * mwhudson --> big blue (or rather dark grey today) room
[01:35] <rbasak> mwhudson: sure, hence my talk of getting Docker upstream to help with that part
[01:35] <rbasak> mwhudson: enjoy!
[01:36] <xnox> mwhudson: I thought there was syntax to inject commands into whoever does FROM yourself.
[01:40] <xnox> mwhudson: Something like: ONBUILD echo after package installation your docker file must specify RUN systemd-tmfiles --create
[01:42] <xnox> I do wonder if we should drop the /run/systemd/systemd guard, or like make systemd-tmpfiles allow to fail when not booted. And make debhelper to start generating depends on tmpfiles.d (== 210) depending on which directives where added when.
[01:43] <xnox> And we probably should install systemd-tmpfiles in the docker container.
[01:46] <rbasak> Nice. Sounds like that could make it all magically work?
[01:46] <rbasak> Without any in-distribution changes and only in our official Docker images?
[01:47] <rbasak> only -> the only changes required being in, I mean
[07:33] <LocutusOfBorg> blaze[m], not sure, better ask tsimonq2
[07:36] <LocutusOfBorg> tsimonq2, http://debomatic-amd64.debian.net/distribution#unstable/qtcreator/4.11.0-2.1/buildlog
[07:48] <mwhudson> xnox: turns out systemd-tmpfiles is linked to libsystem-shared.so which is linked to THE ENTIRE UNIVERSE but that's a solvable problem i guess
[07:55] <mwhudson> /usr/bin/ld: cannot find -lpthreads
[07:55] <mwhudson> how did that happen
[08:36] <doko> seb128: the libxslt sync from experimental drops the xslt-config binary, causing a lot of ftbfs
[08:36] <seb128> doko, I guess those need to be fixed then
[08:37] <doko> or you re-add that binary
[08:38] <seb128> or that
[08:39] <seb128> feel free to open a bug about that, might be easier to discuss the options
[08:40] <doko> I don't want to discuss, I want to have it fixed ;p, just seeing the new ftbfs working on icu
[08:55] <Skuggen> ahasenack: I think we've seen floating accuracy test failures before (but IIRC it was because of different maths library on PPC), yeah
[08:56] <Skuggen> Let me see if I can dig out some of those tests in MySQL itself, and I can see if they've changed recently
[08:58] <Skuggen> mdeslaur dropped that patch from mysql-8.0 when importing 8.0.18
[09:06] <Skuggen> Actually, that looks like it might have been an urelated change making the same edits to our upstream tests
[09:09] <Skuggen> 8.0.18 does have a floating point precision-related fix, though
[12:12] <ahasenack> rbasak: icinga2, the one with the boost fix, failed to build on s390x only
[12:13] <rbasak> :(
[12:13] <ahasenack> xnox: have you seen these before?
[12:13] <ahasenack>  /usr/bin/ld: /usr/lib/s390x-linux-gnu/libboost_coroutine.so.1.71.0: undefined reference to `jump_fcontext'
[12:14] <ahasenack>  /usr/bin/ld: /usr/lib/s390x-linux-gnu/libboost_coroutine.so.1.71.0: undefined reference to `make_fcontext'
[12:16] <ahasenack> rbasak: the mysql8 tests seem to take longer than the allotted timeout on arm*, do you remember how this was handled in the past? There is no existing hint for mysql-8
[12:17] <ahasenack> http://autopkgtest.ubuntu.com/packages/m/mysql-8.0/focal/arm64
[12:17] <ahasenack> or is it hanging in that test, hmm
[12:18] <rbasak> I don't recall seeing it time out
[12:18] <ahasenack> the test runner times out, I mean
[12:19] <ahasenack> tinoco had to retry once in the previous upload
[12:20] <ahasenack> and it passed after 4h23min
[12:20] <ahasenack> well, better start early
[12:20] <rafaeldtinoco> yep i retried that one
[12:20] <rafaeldtinoco> we should add "quilt poop" command
[12:20] <rafaeldtinoco> when we are merging and we do wrong things
[12:22] <ahasenack> arm64 takes twice as long as amd64
[12:24] <rafaeldtinoco> yep, that is what christian has also found
[12:24] <rafaeldtinoco> when building qemu
[12:24] <rafaeldtinoco> at least for our build servers
[12:26] <ahasenack> wow, there are libreoffice dep8 runs taking 7h+ on arm64
[12:26] <rbasak> LocutusOfBorg: fancy merging lighttpd please? It's only on my list because of a no change rebuild :-/
[12:26]  * rbasak doesn't understand why it must have such an extensive delta
[12:31] <xnox> ahasenack:  so, coroutine is new in 1.71 on s390x. and I have seen a couple of places like that. I somehow think, I have miss-cherrypicked boost patches for boost on s390x hence it doesn't work for neither ceph nor icinga
[12:31] <ahasenack> xnox: ceph is also failing to build on s390x with a similar error?
[12:35] <xnox> ahasenack:  yes, when it tried to use coroutine; it doesn't use coroutine on s390x anymore.
[12:35] <ahasenack> xnox: is this something you can fix for icinga2/boost?
[12:36] <xnox> yes, it's on my hit list for icu & boost transitions => is it blocking you somewhere else too?
[12:36] <xnox> cause then i can look into it earlier.
[12:36] <ahasenack> I'm using https://bugs.launchpad.net/bugs/1863371 for icinga2
[12:36] <ahasenack> xnox: yes, it's the only build failure in my upload
[12:37] <xnox> ack
[12:37] <ahasenack> thanks!
[12:41] <ahasenack> rbasak: those linux-* packages I blacklisted yesterday are blocking the importer runs from importing anything else
[12:41] <ahasenack> rbasak: should we build a new snap with that config and deploy?
[12:41] <rbasak> ahasenack: if you kill and restart, it shouldn't reattempt unless another upload to that package is made
[12:42] <ahasenack> ah, I'll do that then
[12:42] <rbasak> But yes, happy for us to do another release if necessary
[12:42] <ahasenack> I never find the snap service name
[12:42] <rbasak> There's also a command line option to override the blacklist locally, but I'd prefer to avoid that if possible to avoid it getting out of sync
[12:42] <rbasak> systemctl status --user
[12:42] <ahasenack> ah, it's a user service
[12:46] <Mirv> can someone point me to (if exists) some explanation why daily-live 'current' points to 4 week old focal image? it seems a bit weird starting point for testing.
[12:47] <ahasenack> Mirv: the current pending image is probably failing some test which is preventing it from being promoted to "daily"
[12:48] <ahasenack> it does look troublesome, though, if it has been failing checks for 4 weeks
[12:48] <Mirv> right, mainly the 4 weeks sounds a bit troublesome given release in 2 months
[12:50] <xnox> - default architecture     : none aha
[12:51] <ahasenack> xnox: what was that?
[12:52] <xnox> probably incomplete boost port to s390x!
[12:52] <ahasenack> yay
[12:56] <LocutusOfBorg> rbasak, .
[13:08] <xnox> ahasenack:  uploaded new boost1.71 into the archive, once that builds & publishes, it might be better on s390x, and then just a retry on icinga might fix it
[13:08] <xnox> if that new boost builds
[13:09] <ahasenack> xnox: nice, thanks a lot, will watch it
[13:09] <ahasenack> xnox: 6ubuntu3?
[13:09] <ahasenack> yep
[13:20] <rbasak> LocutusOfBorg: thank you!
[13:22] <ahasenack> rbasak: restart didn't work as expected, it's trying again (linux-gke, linux-kvm, linux-gcp)
[13:23] <ahasenack> I'll ask bryce to do a new edge release and have that deployed
[13:30] <mdeslaur> is anyone working on a samba merge? ahasenack?
[13:30] <ahasenack> mdeslaur: yes, I have one up for review for 4.11.5
[13:31] <mdeslaur> ahasenack: awsome, thanks
[13:31] <ahasenack> I pinged debian for 4.11.6, even proposed a pristine-tar branch to them so we at least get the same tarball
[13:31] <ahasenack> mdeslaur: https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+merge/379350
[13:31] <ahasenack> https://salsa.debian.org/samba-team/samba/merge_requests/45 for 4.11.6
[13:35] <rbasak> ahasenack: I'm gong to attempt a second restart
[13:36] <ahasenack> rbasak: why wouldn't it try again if the previous import didn't finish?
[13:37] <rbasak> It gets marked as errored
[13:37] <rbasak> And deliberately isn't retried
[13:37] <rbasak> Until the next time a publication is made
[13:37] <rbasak> Restarted
[13:38] <rbasak> There were a bunch of uploads to different releases of those packages today
[13:38] <rbasak> (not -gke, I'm confused why you saw that, but the others)
[13:38] <rbasak> So it's possible that the future uploads kicked off new import runs even though the previous ones were errored
[13:38] <rbasak> Hence my second restart
[13:38] <rbasak> We'll see
[13:43] <xnox> ahasenack:  so the new boost build looks a lot better; now just need to wait for it to publish, and then retry icinga
[13:43] <ahasenack> xnox: ack
[13:43] <ahasenack> ppc64el hasn't even started yet
[13:45] <rbasak> ahasenack: restarted the importer and it doesn't appear to be stuck on any of the kernel packages yet
[13:45] <rbasak> And none of them are marked 'needed' so I think we're good.
[13:46] <rbasak> Maybe we need a different mechanism
[13:46] <rbasak> Just blacklisting packages doesn't seem good enough if new oversized source packages keep being added like this
[13:51] <ahasenack> yep
[14:01] <rbasak> So what's the story with the /usr/bin/python name?
[14:01] <rbasak> From doko's email we shouldn't be using it
[14:01] <rbasak> But how do I explain this to upstreams? Is this in preparation for a future pointer to Python 3, or are we doing that immediately in Focal?
[14:03] <ahasenack> IIRC there would be a default python late in the cycle, pointing at py3
[14:04] <ahasenack> focal still
[14:04] <ahasenack> but doko would know for sure
[14:08] <doko> rbasak: we will have two packages, one linking to 2, one to 3, but none must be used in the archive
[14:09] <doko> I have to follow-up again on this
[14:22] <rbasak> doko: what can users expect to see?
[14:22] <rbasak> Because if we have something by default, they'll inevitably start using that in upstream shebangs, so we'll have be be permanently patching
[14:23] <doko> python-is-python2-but-deprecated and python-is-python3
[14:25] <rbasak> I can point upstreams to https://www.python.org/dev/peps/pep-0394/#for-python-script-publishers I guess
[14:34] <rbasak> ahasenack: do you have a current temlate for your regular typedef patch please?
[14:35] <ahasenack> rbasak: just the dep3 headers
[14:35] <ahasenack> rbasak: I grep for my_bool, then check if the same file includes mysql.h, and add the typedef beneath that
[14:35] <ahasenack> if mysql.h is not included there, I grep to see which other file includes it, and change that one
[14:35] <rbasak> I was just after your standard dep3 headers and changelog text :)
[14:36] <ahasenack> just a sec
[14:37] <ahasenack> rbasak: https://pastebin.ubuntu.com/p/7XqPzbGSGj/ with a helper hack/script
[14:37] <rbasak> Thank you!
[14:38] <rbasak> I suppose I should replace the author?
[14:41] <ahasenack> sure
[14:51] <rbasak> ahasenack: uploads ready for apr and apr-util: https://paste.ubuntu.com/p/SxNYxRTPbD/ and https://paste.ubuntu.com/p/NYphZ9yshg/
[14:51] <ahasenack> rbasak: oh, I had those ready already, but cool :)
[14:51] <rbasak> Oh
[14:51] <rbasak> I did file an upstream bug
[14:51] <ahasenack> in my ppa, I did a test build yesterday
[14:51] <rbasak> And for apr
[14:51] <rbasak> (in dep3 also)
[14:52] <rbasak> How do you want to proceed?
[14:52] <ahasenack> you go ahead
[14:52] <ahasenack> just drop the ~dev1
[14:52] <ahasenack> rbasak: I uploaded a few packages with the mybool patch, but I really would prefer for mysql8 to mgirate first
[14:52] <rbasak> To be clear, to upload to the archive now, with these latest pastebins, dropping the ~dev1?
[14:52] <ahasenack> but that will take a while, given the libreoffice tests take hours and hours
[14:52] <ahasenack> rbasak: yes, let me just check the second one quickly
[14:53] <ahasenack> rbasak: yeah, +1 to both
[14:53] <rbasak> Thanks!
[14:53] <ahasenack> with the !~dev1 drop
[14:53] <rbasak> Yep
[14:55] <rbasak> apr uploaded
[14:55] <rbasak> apr-util will have to wait until apr is built and published, or else it will FTBFS
[14:55] <ahasenack> yes
[14:56] <ahasenack> been there, done that :)
[14:56] <ahasenack> boost is built
[14:56]  * ahasenack checks if it's published
[14:56] <ahasenack> looks like it
[14:57]  * ahasenack rebuilds icinga2
[14:57] <ahasenack> and that was done already
[14:57]  * ahasenack watches it
[14:59] <rbasak> I'll look at zoneminder next shall I?
[15:08] <xnox> ahasenack:  icinga has now built
[15:09] <xnox> (there is buildlog, meaning that it is uploading now)
[15:48] <coreycb> infinity: do you know if 20.10 final release would be oct 15 or oct 22?
[16:00] <ahasenack> xnox: awesome, thanks again
[16:49] <knocte> can a maintainer help here? https://bugs.launchpad.net/ubuntu/+source/mono/+bug/1520033 we need to drop an arch (s390x) so that mono can get a hotfix that will make nuget work
[16:49] <knocte> otherwise nuget (the .NET package manager) will crash when running with the mono version shipped by the upcoming LTS
[16:50] <knocte> I understand that s390x is not a critical arch for ubuntu anyway
[16:52] <xnox> knocte:  s390x is an official ubuntu architecture with support on-par with ppc64el amd64 arm64
[16:52] <xnox> knocte:  mono itself is in universe, and not supported as much as other packages in ubuntu are.
[16:52] <xnox> knocte:  however current mono in ubuntu does not ftbfs.
[16:53] <xnox> knocte:  so what is your question ? about which package / version and in which release?
[16:54] <xnox> updated that bug report to be marked as fix released
[16:55] <knocte> fix released? what?
[16:56] <xnox> knocte:  Click https://launchpad.net/ubuntu/+source/mono/5.18.0.240+dfsg-3 look at the builds portion of the page: note how it is built correctly on all 6 architectures including s390x
[16:56] <xnox> is there soemthing wrong with https://launchpad.net/ubuntu/+source/mono/5.18.0.240+dfsg-3/+build/17185141 ?
[16:57] <xnox> i see there is -5 version in unstable, not yet in ubuntu.
[16:58] <xnox> bug report and its status was out of date, w.r.t. reality. Do you have any other concerns around mono or nuget in Ubuntu?
[16:58] <knocte> we need 7ac7d35 in ubuntu, otherwise upcoming LTS will crash with nuget
[16:58] <knocte> (that git commit I mentioned above is taken from https://code.launchpad.net/~usd-import-team/ubuntu/+source/mono/+git/mono/+ref/ubuntu/eoan-proposed )
[16:59] <xnox> knocte:  i see
[16:59] <knocte> (it comes from upstream's "* [d8d5d6b] Fixes __MonoCS__ handling of value types")
[16:59] <xnox> knocte:  indeed something odd is happening
[17:00] <Laney> -5 got removed from eoan-proposed because of s390x build failures
[17:00] <Laney> you can see that on https://launchpad.net/ubuntu/+source/mono/+publishinghistory
[17:00] <xnox> vorlon:  infinity: looking at https://launchpad.net/ubuntu/+source/mono/+publishinghistory it seems like at archive opening we have dropped -5 upload from eoan-proposed, but did not publish it into focal-proposed
[17:00] <xnox> i would have expected it to roll over
[17:00]  * xnox syncs it again
[17:00] <knocte> well, both mono-packaging maintainers have agreed that the -5 fix is more important than the s390x arch
[17:01] <xnox> knocte:  sure, i understand the issue now. It seems that we have dropped -4 and -5 uploads of mono on the floor.
[17:02] <xnox> which is a process / archive administration issue.
[17:02] <xnox> knocte:  i'm now trying to get up to date mono upload into ubuntu. thank you for raising this.
[17:02] <knocte> thanks for your help xnox
[17:03] <xnox> Laney:  actually i guess i need to do a binary copy from eoan-proposed, or a no change rebuild.
[17:03] <vorlon> xnox: -5 was removed from eoan-proposed manually by infinity as 'FTBFS'
[17:03] <Laney> if it does fail to build on s390x then you'll have problems @ proposed-migration
[17:03] <xnox> right
[17:03]  * xnox uploads a no change rebuild to see what happens
[17:03] <xnox> we have now raised to z13 which might do better
[17:53] <doko> coreycb, jamespage: please could you add a lasso merge on openstack's list? needed for python3
[17:53] <coreycb> doko: yes will do
[17:54] <doko> ta
[18:08] <rbasak> ahasenack: here's the fix for zoneminder: https://pastebin.ubuntu.com/p/GcRKP5Yyt5/
[18:09] <rbasak> I've sent a patch to Debian BTS, just waiting on the bug number
[18:09] <rbasak> How do you want to integrate it? Is the paste sufficient?
[18:09] <rbasak> Probably worth testing that in your PPA
[18:09] <rbasak> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951600
[18:13] <ahasenack> rbasak: you rock
[18:14] <ahasenack> rbasak: the paste is sufficient
[18:14] <ahasenack> rbasak: I'll upload to my ppa
[18:18] <rbasak> Thanks!
[18:18] <rbasak> I do like the interesting fixes :)
[18:35] <doko> rbasak: sent the python2 removal update
[18:38] <rbasak> Thank you!
[18:47] <ahasenack> rbasak: apr has built, will you upload apr-util now?
[18:50] <rbasak> ahasenack: sure
[18:51] <rbasak> Sorry I'd forgotten about that
[18:51] <ahasenack> np, thanks!
[18:51] <rbasak> Done
[19:36] <seb128> doko, does the patch on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951101 looks fine? your cracklib2 upload failed to build...
[19:36] <seb128> | debian/rules:6: /usr/share/python/python.mk: No such file or directory
[20:37] <mwhudson> morning