| 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. | 00:33 |
|---|---|---|
| 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:08 |
| krytarik | gbit86__: I'm not sure why you still pound the development channel with that. | 01:14 |
| 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:15 |
| gbit86__ | I was hitting the regular ubuntu channel but was directed to go here. | 01:16 |
| 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:17 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| rbasak | That should work today without even needing debhelper mods I think? | 01:29 |
| rbasak | (if the mechanism is implemented, of course) | 01:30 |
| 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:31 | |
| rbasak | mwhudson: sure, hence my talk of getting Docker upstream to help with that part | 01:35 |
| rbasak | mwhudson: enjoy! | 01:35 |
| xnox | mwhudson: I thought there was syntax to inject commands into whoever does FROM yourself. | 01:36 |
| xnox | mwhudson: Something like: ONBUILD echo after package installation your docker file must specify RUN systemd-tmfiles --create | 01:40 |
| 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:42 |
| xnox | And we probably should install systemd-tmpfiles in the docker container. | 01:43 |
| 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:46 |
| rbasak | only -> the only changes required being in, I mean | 01:47 |
| LocutusOfBorg | blaze[m], not sure, better ask tsimonq2 | 07:33 |
| LocutusOfBorg | tsimonq2, http://debomatic-amd64.debian.net/distribution#unstable/qtcreator/4.11.0-2.1/buildlog | 07:36 |
| 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:48 |
| mwhudson | /usr/bin/ld: cannot find -lpthreads | 07:55 |
| mwhudson | how did that happen | 07:55 |
| 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:36 |
| doko | or you re-add that binary | 08:37 |
| seb128 | or that | 08:38 |
| seb128 | feel free to open a bug about that, might be easier to discuss the options | 08:39 |
| doko | I don't want to discuss, I want to have it fixed ;p, just seeing the new ftbfs working on icu | 08:40 |
| 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:55 |
| 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:56 |
| Skuggen | mdeslaur dropped that patch from mysql-8.0 when importing 8.0.18 | 08:58 |
| Skuggen | Actually, that looks like it might have been an urelated change making the same edits to our upstream tests | 09:06 |
| Skuggen | 8.0.18 does have a floating point precision-related fix, though | 09:09 |
| === Wryhder is now known as Lucas_Gray | ||
| ahasenack | rbasak: icinga2, the one with the boost fix, failed to build on s390x only | 12:12 |
| 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:13 |
| ahasenack | /usr/bin/ld: /usr/lib/s390x-linux-gnu/libboost_coroutine.so.1.71.0: undefined reference to `make_fcontext' | 12:14 |
| 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:16 |
| ahasenack | http://autopkgtest.ubuntu.com/packages/m/mysql-8.0/focal/arm64 | 12:17 |
| ahasenack | or is it hanging in that test, hmm | 12:17 |
| rbasak | I don't recall seeing it time out | 12:18 |
| ahasenack | the test runner times out, I mean | 12:18 |
| ahasenack | tinoco had to retry once in the previous upload | 12:19 |
| 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:20 |
| ahasenack | arm64 takes twice as long as amd64 | 12:22 |
| 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:24 |
| 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:26 | |
| 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:31 |
| 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:35 |
| 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 |
| ubottu | Launchpad bug 1863371 in icinga2 (Ubuntu) "FTBFS with boost 1.71" [High,In progress] | 12:36 |
| ahasenack | xnox: yes, it's the only build failure in my upload | 12:36 |
| xnox | ack | 12:37 |
| ahasenack | thanks! | 12:37 |
| 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 |
| === Wryhder is now known as Lucas_Gray | ||
| rbasak | ahasenack: if you kill and restart, it shouldn't reattempt unless another upload to that package is made | 12:41 |
| 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:42 |
| 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:46 |
| ahasenack | Mirv: the current pending image is probably failing some test which is preventing it from being promoted to "daily" | 12:47 |
| 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:48 |
| xnox | - default architecture : none aha | 12:50 |
| ahasenack | xnox: what was that? | 12:51 |
| xnox | probably incomplete boost port to s390x! | 12:52 |
| ahasenack | yay | 12:52 |
| LocutusOfBorg | rbasak, . | 12:56 |
| 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:08 |
| ahasenack | xnox: nice, thanks a lot, will watch it | 13:09 |
| ahasenack | xnox: 6ubuntu3? | 13:09 |
| ahasenack | yep | 13:09 |
| rbasak | LocutusOfBorg: thank you! | 13:20 |
| ahasenack | rbasak: restart didn't work as expected, it's trying again (linux-gke, linux-kvm, linux-gcp) | 13:22 |
| ahasenack | I'll ask bryce to do a new edge release and have that deployed | 13:23 |
| 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:30 |
| 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:31 |
| rbasak | ahasenack: I'm gong to attempt a second restart | 13:35 |
| ahasenack | rbasak: why wouldn't it try again if the previous import didn't finish? | 13:36 |
| 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:37 |
| 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:38 |
| 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:43 |
| 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:45 |
| 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:46 |
| ahasenack | yep | 13:51 |
| 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:01 |
| ahasenack | IIRC there would be a default python late in the cycle, pointing at py3 | 14:03 |
| ahasenack | focal still | 14:04 |
| ahasenack | but doko would know for sure | 14:04 |
| doko | rbasak: we will have two packages, one linking to 2, one to 3, but none must be used in the archive | 14:08 |
| doko | I have to follow-up again on this | 14:09 |
| 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:22 |
| doko | python-is-python2-but-deprecated and python-is-python3 | 14:23 |
| rbasak | I can point upstreams to https://www.python.org/dev/peps/pep-0394/#for-python-script-publishers I guess | 14:25 |
| rbasak | ahasenack: do you have a current temlate for your regular typedef patch please? | 14:34 |
| 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:35 |
| ahasenack | just a sec | 14:36 |
| ahasenack | rbasak: https://pastebin.ubuntu.com/p/7XqPzbGSGj/ with a helper hack/script | 14:37 |
| rbasak | Thank you! | 14:37 |
| rbasak | I suppose I should replace the author? | 14:38 |
| ahasenack | sure | 14:41 |
| 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:51 |
| 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:52 |
| ahasenack | rbasak: yeah, +1 to both | 14:53 |
| rbasak | Thanks! | 14:53 |
| ahasenack | with the !~dev1 drop | 14:53 |
| rbasak | Yep | 14:53 |
| 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:55 |
| 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:56 |
| * ahasenack rebuilds icinga2 | 14:57 | |
| ahasenack | and that was done already | 14:57 |
| * ahasenack watches it | 14:57 | |
| rbasak | I'll look at zoneminder next shall I? | 14:59 |
| xnox | ahasenack: icinga has now built | 15:08 |
| xnox | (there is buildlog, meaning that it is uploading now) | 15:09 |
| coreycb | infinity: do you know if 20.10 final release would be oct 15 or oct 22? | 15:48 |
| ahasenack | xnox: awesome, thanks again | 16:00 |
| 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 |
| ubottu | Launchpad bug 1520033 in mono (Ubuntu) "ftbfs on s390x" [Undecided,Confirmed] | 16:49 |
| knocte | otherwise nuget (the .NET package manager) will crash when running with the mono version shipped by the upcoming LTS | 16:49 |
| knocte | I understand that s390x is not a critical arch for ubuntu anyway | 16:50 |
| 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:52 |
| xnox | knocte: so what is your question ? about which package / version and in which release? | 16:53 |
| xnox | updated that bug report to be marked as fix released | 16:54 |
| knocte | fix released? what? | 16:55 |
| 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:56 |
| xnox | i see there is -5 version in unstable, not yet in ubuntu. | 16:57 |
| 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:58 |
| 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 | 16:59 |
| 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:00 |
| xnox | knocte: sure, i understand the issue now. It seems that we have dropped -4 and -5 uploads of mono on the floor. | 17:01 |
| 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:02 |
| 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:03 |
| 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:53 |
| doko | ta | 17:54 |
| rbasak | ahasenack: here's the fix for zoneminder: https://pastebin.ubuntu.com/p/GcRKP5Yyt5/ | 18:08 |
| 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:09 |
| ubottu | Debian bug 951600 in src:zoneminder ""debian/rules build" fails to call defined build-indep target, causing FTBFS" [Serious,Open] | 18:09 |
| ahasenack | rbasak: you rock | 18:13 |
| ahasenack | rbasak: the paste is sufficient | 18:14 |
| ahasenack | rbasak: I'll upload to my ppa | 18:14 |
| rbasak | Thanks! | 18:18 |
| rbasak | I do like the interesting fixes :) | 18:18 |
| doko | rbasak: sent the python2 removal update | 18:35 |
| rbasak | Thank you! | 18:38 |
| ahasenack | rbasak: apr has built, will you upload apr-util now? | 18:47 |
| rbasak | ahasenack: sure | 18:50 |
| rbasak | Sorry I'd forgotten about that | 18:51 |
| ahasenack | np, thanks! | 18:51 |
| rbasak | Done | 18:51 |
| 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 |
| ubottu | 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 |
| seb128 | | debian/rules:6: /usr/share/python/python.mk: No such file or directory | 19:36 |
| === jdstrand_ is now known as jdstrand | ||
| === ben_r_ is now known as ben_r | ||
| mwhudson | morning | 20:37 |
| === gbit86__ is now known as gbit86 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!