[00:33] 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] 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] like* to take a stab [01:14] gbit86__: I'm not sure why you still pound the development channel with that. [01:15] 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] I was hitting the regular ubuntu channel but was directed to go here. [01:17] 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] I tried installing ibus after the fact.. but that does not seem to be enough. [01:19] 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] That's what I meant by "not buggy" [01:19] I accept that we should do what we can for DOcker users and find a solution here [01:19] BUt to me it's Wishlist, not a bug. [01:20] 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] Though one that deserves some effort [01:20] but this is splitting hairs [01:20] Only for Debian [01:21] Anyway, sure. I was just trying to explain what I meant. [01:21] I don't care how we choose to state the problem :) [01:21] right, i don't think we actually disagree :) [01:23] 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] 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] 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] So we could provide an opt-in mechanism for Docker image builders? [01:26] the opt in mechanism is having postinst create the directories, no? [01:26] Maybe. It doesn't feel generic enough to me. [01:27] well the dockerish answer is "RUN mkdir /run/wibble" in your Dockerfile [01:27] 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] 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] Or something even more generic and not specific to systemd [01:28] Then our general recommendation could be "if FROM ubuntu, then do that" [01:28] (or Debian even) [01:29] That should work today without even needing debhelper mods I think? [01:30] (if the mechanism is implemented, of course) [01:31] 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] mwhudson: sure, hence my talk of getting Docker upstream to help with that part [01:35] mwhudson: enjoy! [01:36] mwhudson: I thought there was syntax to inject commands into whoever does FROM yourself. [01:40] mwhudson: Something like: ONBUILD echo after package installation your docker file must specify RUN systemd-tmfiles --create [01:42] 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] And we probably should install systemd-tmpfiles in the docker container. [01:46] Nice. Sounds like that could make it all magically work? [01:46] Without any in-distribution changes and only in our official Docker images? [01:47] only -> the only changes required being in, I mean [07:33] blaze[m], not sure, better ask tsimonq2 [07:36] tsimonq2, http://debomatic-amd64.debian.net/distribution#unstable/qtcreator/4.11.0-2.1/buildlog [07:48] 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] /usr/bin/ld: cannot find -lpthreads [07:55] how did that happen [08:36] seb128: the libxslt sync from experimental drops the xslt-config binary, causing a lot of ftbfs [08:36] doko, I guess those need to be fixed then [08:37] or you re-add that binary [08:38] or that [08:39] feel free to open a bug about that, might be easier to discuss the options [08:40] I don't want to discuss, I want to have it fixed ;p, just seeing the new ftbfs working on icu [08:55] 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] 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] mdeslaur dropped that patch from mysql-8.0 when importing 8.0.18 [09:06] Actually, that looks like it might have been an urelated change making the same edits to our upstream tests [09:09] 8.0.18 does have a floating point precision-related fix, though === Wryhder is now known as Lucas_Gray [12:12] rbasak: icinga2, the one with the boost fix, failed to build on s390x only [12:13] :( [12:13] xnox: have you seen these before? [12:13] /usr/bin/ld: /usr/lib/s390x-linux-gnu/libboost_coroutine.so.1.71.0: undefined reference to `jump_fcontext' [12:14] /usr/bin/ld: /usr/lib/s390x-linux-gnu/libboost_coroutine.so.1.71.0: undefined reference to `make_fcontext' [12:16] 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] http://autopkgtest.ubuntu.com/packages/m/mysql-8.0/focal/arm64 [12:17] or is it hanging in that test, hmm [12:18] I don't recall seeing it time out [12:18] the test runner times out, I mean [12:19] tinoco had to retry once in the previous upload [12:20] and it passed after 4h23min [12:20] well, better start early [12:20] yep i retried that one [12:20] we should add "quilt poop" command [12:20] when we are merging and we do wrong things [12:22] arm64 takes twice as long as amd64 [12:24] yep, that is what christian has also found [12:24] when building qemu [12:24] at least for our build servers [12:26] wow, there are libreoffice dep8 runs taking 7h+ on arm64 [12:26] 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] 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] xnox: ceph is also failing to build on s390x with a similar error? [12:35] ahasenack: yes, when it tried to use coroutine; it doesn't use coroutine on s390x anymore. [12:35] xnox: is this something you can fix for icinga2/boost? [12:36] yes, it's on my hit list for icu & boost transitions => is it blocking you somewhere else too? [12:36] cause then i can look into it earlier. [12:36] I'm using https://bugs.launchpad.net/bugs/1863371 for icinga2 [12:36] Launchpad bug 1863371 in icinga2 (Ubuntu) "FTBFS with boost 1.71" [High,In progress] [12:36] xnox: yes, it's the only build failure in my upload [12:37] ack [12:37] thanks! [12:41] rbasak: those linux-* packages I blacklisted yesterday are blocking the importer runs from importing anything else [12:41] rbasak: should we build a new snap with that config and deploy? === Wryhder is now known as Lucas_Gray [12:41] ahasenack: if you kill and restart, it shouldn't reattempt unless another upload to that package is made [12:42] ah, I'll do that then [12:42] But yes, happy for us to do another release if necessary [12:42] I never find the snap service name [12:42] 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] systemctl status --user [12:42] ah, it's a user service [12:46] 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] Mirv: the current pending image is probably failing some test which is preventing it from being promoted to "daily" [12:48] it does look troublesome, though, if it has been failing checks for 4 weeks [12:48] right, mainly the 4 weeks sounds a bit troublesome given release in 2 months [12:50] - default architecture : none aha [12:51] xnox: what was that? [12:52] probably incomplete boost port to s390x! [12:52] yay [12:56] rbasak, . [13:08] 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] if that new boost builds [13:09] xnox: nice, thanks a lot, will watch it [13:09] xnox: 6ubuntu3? [13:09] yep [13:20] LocutusOfBorg: thank you! [13:22] rbasak: restart didn't work as expected, it's trying again (linux-gke, linux-kvm, linux-gcp) [13:23] I'll ask bryce to do a new edge release and have that deployed [13:30] is anyone working on a samba merge? ahasenack? [13:30] mdeslaur: yes, I have one up for review for 4.11.5 [13:31] ahasenack: awsome, thanks [13:31] 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] mdeslaur: https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+merge/379350 [13:31] https://salsa.debian.org/samba-team/samba/merge_requests/45 for 4.11.6 [13:35] ahasenack: I'm gong to attempt a second restart [13:36] rbasak: why wouldn't it try again if the previous import didn't finish? [13:37] It gets marked as errored [13:37] And deliberately isn't retried [13:37] Until the next time a publication is made [13:37] Restarted [13:38] There were a bunch of uploads to different releases of those packages today [13:38] (not -gke, I'm confused why you saw that, but the others) [13:38] So it's possible that the future uploads kicked off new import runs even though the previous ones were errored [13:38] Hence my second restart [13:38] We'll see [13:43] 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] xnox: ack [13:43] ppc64el hasn't even started yet [13:45] ahasenack: restarted the importer and it doesn't appear to be stuck on any of the kernel packages yet [13:45] And none of them are marked 'needed' so I think we're good. [13:46] Maybe we need a different mechanism [13:46] Just blacklisting packages doesn't seem good enough if new oversized source packages keep being added like this [13:51] yep [14:01] So what's the story with the /usr/bin/python name? [14:01] From doko's email we shouldn't be using it [14:01] 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] IIRC there would be a default python late in the cycle, pointing at py3 [14:04] focal still [14:04] but doko would know for sure [14:08] rbasak: we will have two packages, one linking to 2, one to 3, but none must be used in the archive [14:09] I have to follow-up again on this [14:22] doko: what can users expect to see? [14:22] 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] python-is-python2-but-deprecated and python-is-python3 [14:25] I can point upstreams to https://www.python.org/dev/peps/pep-0394/#for-python-script-publishers I guess [14:34] ahasenack: do you have a current temlate for your regular typedef patch please? [14:35] rbasak: just the dep3 headers [14:35] rbasak: I grep for my_bool, then check if the same file includes mysql.h, and add the typedef beneath that [14:35] if mysql.h is not included there, I grep to see which other file includes it, and change that one [14:35] I was just after your standard dep3 headers and changelog text :) [14:36] just a sec [14:37] rbasak: https://pastebin.ubuntu.com/p/7XqPzbGSGj/ with a helper hack/script [14:37] Thank you! [14:38] I suppose I should replace the author? [14:41] sure [14:51] ahasenack: uploads ready for apr and apr-util: https://paste.ubuntu.com/p/SxNYxRTPbD/ and https://paste.ubuntu.com/p/NYphZ9yshg/ [14:51] rbasak: oh, I had those ready already, but cool :) [14:51] Oh [14:51] I did file an upstream bug [14:51] in my ppa, I did a test build yesterday [14:51] And for apr [14:51] (in dep3 also) [14:52] How do you want to proceed? [14:52] you go ahead [14:52] just drop the ~dev1 [14:52] rbasak: I uploaded a few packages with the mybool patch, but I really would prefer for mysql8 to mgirate first [14:52] To be clear, to upload to the archive now, with these latest pastebins, dropping the ~dev1? [14:52] but that will take a while, given the libreoffice tests take hours and hours [14:52] rbasak: yes, let me just check the second one quickly [14:53] rbasak: yeah, +1 to both [14:53] Thanks! [14:53] with the !~dev1 drop [14:53] Yep [14:55] apr uploaded [14:55] apr-util will have to wait until apr is built and published, or else it will FTBFS [14:55] yes [14:56] been there, done that :) [14:56] boost is built [14:56] * ahasenack checks if it's published [14:56] looks like it [14:57] * ahasenack rebuilds icinga2 [14:57] and that was done already [14:57] * ahasenack watches it [14:59] I'll look at zoneminder next shall I? [15:08] ahasenack: icinga has now built [15:09] (there is buildlog, meaning that it is uploading now) [15:48] infinity: do you know if 20.10 final release would be oct 15 or oct 22? [16:00] xnox: awesome, thanks again [16:49] 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] Launchpad bug 1520033 in mono (Ubuntu) "ftbfs on s390x" [Undecided,Confirmed] [16:49] otherwise nuget (the .NET package manager) will crash when running with the mono version shipped by the upcoming LTS [16:50] I understand that s390x is not a critical arch for ubuntu anyway [16:52] knocte: s390x is an official ubuntu architecture with support on-par with ppc64el amd64 arm64 [16:52] knocte: mono itself is in universe, and not supported as much as other packages in ubuntu are. [16:52] knocte: however current mono in ubuntu does not ftbfs. [16:53] knocte: so what is your question ? about which package / version and in which release? [16:54] updated that bug report to be marked as fix released [16:55] fix released? what? [16:56] 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] is there soemthing wrong with https://launchpad.net/ubuntu/+source/mono/5.18.0.240+dfsg-3/+build/17185141 ? [16:57] i see there is -5 version in unstable, not yet in ubuntu. [16:58] 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] we need 7ac7d35 in ubuntu, otherwise upcoming LTS will crash with nuget [16:58] (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] knocte: i see [16:59] (it comes from upstream's "* [d8d5d6b] Fixes __MonoCS__ handling of value types") [16:59] knocte: indeed something odd is happening [17:00] -5 got removed from eoan-proposed because of s390x build failures [17:00] you can see that on https://launchpad.net/ubuntu/+source/mono/+publishinghistory [17:00] 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] i would have expected it to roll over [17:00] * xnox syncs it again [17:00] well, both mono-packaging maintainers have agreed that the -5 fix is more important than the s390x arch [17:01] knocte: sure, i understand the issue now. It seems that we have dropped -4 and -5 uploads of mono on the floor. [17:02] which is a process / archive administration issue. [17:02] knocte: i'm now trying to get up to date mono upload into ubuntu. thank you for raising this. [17:02] thanks for your help xnox [17:03] Laney: actually i guess i need to do a binary copy from eoan-proposed, or a no change rebuild. [17:03] xnox: -5 was removed from eoan-proposed manually by infinity as 'FTBFS' [17:03] if it does fail to build on s390x then you'll have problems @ proposed-migration [17:03] right [17:03] * xnox uploads a no change rebuild to see what happens [17:03] we have now raised to z13 which might do better [17:53] coreycb, jamespage: please could you add a lasso merge on openstack's list? needed for python3 [17:53] doko: yes will do [17:54] ta [18:08] ahasenack: here's the fix for zoneminder: https://pastebin.ubuntu.com/p/GcRKP5Yyt5/ [18:09] I've sent a patch to Debian BTS, just waiting on the bug number [18:09] How do you want to integrate it? Is the paste sufficient? [18:09] Probably worth testing that in your PPA [18:09] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951600 [18:09] Debian bug 951600 in src:zoneminder ""debian/rules build" fails to call defined build-indep target, causing FTBFS" [Serious,Open] [18:13] rbasak: you rock [18:14] rbasak: the paste is sufficient [18:14] rbasak: I'll upload to my ppa [18:18] Thanks! [18:18] I do like the interesting fixes :) [18:35] rbasak: sent the python2 removal update [18:38] Thank you! [18:47] rbasak: apr has built, will you upload apr-util now? [18:50] ahasenack: sure [18:51] Sorry I'd forgotten about that [18:51] np, thanks! [18:51] Done [19:36] 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] Debian bug 951101 in src:cracklib2 "cracklib2 FTBFS: debian/rules:6: /usr/share/python/python.mk: No such file or directory" [Serious,Open] [19:36] | debian/rules:6: /usr/share/python/python.mk: No such file or directory === jdstrand_ is now known as jdstrand === ben_r_ is now known as ben_r [20:37] morning === gbit86__ is now known as gbit86