[00:24] vorlon: multipass, snapcraft, buildd images tarballs, lxd, qcow all available in a new path [00:24] can't remember if it's with or without streams, but to be consumed by things that want to build things [00:29] why does libsdl2 have an autopkgtest that rebuilds the entire package, instead of just using Restrictions: build-needed >_< [00:30] (which may or not be friendlier; does dh do anything magic with cmake and cross-compilation?) === balkamos_ is now known as balkamos [06:21] xnox: the remaining 7 test issues were real errors that the upstreams needed to work on [06:21] xnox: what exactly was "something naughty"? [06:22] xnox: https://trello.com/c/pBjTM1I8 [06:26] I found postgresql-common being migrated, but no delta on it or postgresql-12 nor did I find a force-badtest for the remaining issues [06:27] I'm really interested to learn what "something nasty" was when you are back xnox [06:27] ahasenack: ^^ FYI [06:36] "Make autopkgtest depend on the postgresql server version this extension is built for" [06:36] ok I found your changes [06:57] jamespage: coreycb: the new pytohn-six triggers a bunch of tests in python-oslo.messaging python-oslo.policy python-oslo.serialization python-oslo.service python-pyeclib [06:57] Those all seem to belong to the openstack context it seems. [06:57] Part of the Ubuntu Delta are autopkgtests that now fail - it seems mostly for the new python version. [06:57] Example: http://autopkgtest.ubuntu.com/packages/p/python-oslo.messaging/focal/amd64 [06:58] I wanted to ask if those packages are on your lists to update/merge them and fix up the tests? [08:33] seb128: re cmake, they have now backported the harfbuzz fix to the 3.15 branch, in case they happen to have another point release on that [08:44] RikMills, great [09:01] hello cyphermox can you please do an usb-modeswitch merge? it gained some new configuration features the new release, so your patch might need some adjustements [09:14] cpaelzer: so yeah, and the "make autopkgtest depend on the matching server" is reported to debian, which is a dupe. It really is pointless to hardcode build against one version, and then test against a moving default version. [09:15] cpaelzer: adding / changing the default, shouldn't require removing support for old one. Sure not everything is yet available with 12, and we can't remove 11 yet, but at least all tests pass and don't fake regress. [09:15] cpaelzer: and debian maintainer seems to agree. [09:16] cpaelzer: also this http://launchpadlibrarian.net/454980669/php-horde-db_2.4.0-4ubuntu2_2.4.0-4ubuntu3.diff.gz [09:17] xnox: is the latter from https://github.com/horde/Db/pull/4 or just doing it on your own? [09:17] sil2100, good morning! Séb told me you were looking for me yesterday, sorry I was afk sick. the thunderbird SRU in the eoan queue isn't meant to go through security, as it doesn't address any security issues [09:17] thanks for asking the Debian maintainer on it as well [09:18] xnox: I have in the meantime found all the Delta and am ok now I guess [09:18] I was first confused what was going on [09:18] cpaelzer: my own..... that pull request seems to be different for the second fallback query, and i have no idea which one is better. [09:19] the first portion seems the same. [09:19] I was concerned that this masks real errors at first, but it seems ok to "block PG-11 removal" instead of "block PG-12 appearing" [09:19] xnox: do you have a link to your discussion with the Debian maintainer(s) ? [09:21] there is debian bug and irc chat [09:21] let me find it [09:23] i filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946462 which got merged into https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944457 and I find only option 1 from that one sensible [09:23] Debian bug 946462 in postgresql-common "postgresql-common: autopkgtests should have versioned postgresql deps" [Important,Open] [09:23] Debian bug 944457 in postgresql-common "test-dependencies need to be explicit" [Important,Open] [09:23] then chatted with myon [09:24] cpaelzer: what concerned me about php-horde-db, is that seamingly mysqldb is setup, but mysqldb tests are skipped? or do i just not understand phpunit output? [09:25] I never got into the horde testing, I know bryce looked at some of it recently for the next php [09:25] But it is so huge, not sure if he can add soem detail - but if you can bryce pelase do so ^^ [09:25] thanks for the links xnox [09:26] and thnaks for doing this discussion a few hours after my first "WTF has happened grumpy mode" [09:26] I might have appreciated a ping in advance, but you might have had that with ahasenack and I missed it [09:28] but ignoring my initial hickup on it, thanks for your help on these packages [09:28] I read the bugs and like that myon agreed [09:28] so all of it should resolve sooner or later [09:28] and as I already mentioned, our TODOs to get all of these ready for PG-12 didn't change [09:36] sure, cause you do want to either remove them or upload new versions of them with PG-12 support, to remove PG-11 from the archive. [09:37] it is very odd that adding support for a new postgresql, is done in one step like that. Instead of python compiled extensions style, where support is first dual, then switch default, then mark single supported, remove obsolete extensions. [09:38] as that decouples things and makes it easier to add and remove support for any given version [10:17] oSoMoN: hey! Thanks! Was asking, since this seems to be fixing an upgrade issue, so wouldn't this affect -security enabled people too? Like, shouldn't they get the fix so that they can properly upgrade? Or is it something different? [10:17] oSoMoN: like, it's not a security fix, but it sounded to me that without this, some people might have upgrade problems or something? [10:23] sil2100, right, I didn't consider this [10:23] chrisccoulson, can you comment on this? ^ [10:28] oSoMoN, if the update fixes a regression introduced in to the security pocket, then it should probably go through security [10:28] I don't have the full context though [10:29] if it's the issue referenced in https://www.thunderbird.net/en-US/thunderbird/68.2.2/releasenotes/, then it probably should go out in -security [10:31] chrisccoulson, yes, that's the one [10:37] chrisccoulson, oSoMoN: then I guess we'd need this thunderbird upload to be built in a -security enabled PPA and then bin-synced [10:37] yeah, we'd publish it just like any other security update [10:47] vorlon, hey, so libsecret fails to be a candidate because the i386 builds is depwaiting on gjs (which I guess got deleted on i386) ... what's the correct solution in those cases? [11:07] rbasak: I have mdevctl ready for upload [11:08] rbasak: this isn't urgent per-se, but I'd see it build and migrate properly before everyone leaves to christmas break [11:09] I've understood that this might be easy with dput-ng but your setup is on classic dput [11:09] rbalint: I can ask around for other DDs if you want [11:09] rbasak: ^^ [11:09] sorry rbalint you just have the wrong name for three-char tabbing with rbasak [11:10] rbasak was first :-P [11:10] cpaelzer: I can take a look tomorrow if that works for you? [11:11] that is fine [11:11] if I catch someone else helping me before that I'll let you know [11:31] rbasak: I found someone, consider it done [11:35] ack [12:10] cpaelzer, no problem, i can live with rbasak's popularity :-) [12:21] I'm considering changing the string 'Cdrom with Ubuntu 20.04 'Focal Fossa'' to "Ubuntu 20.04 'Focal Fossa' Installation Medium" [12:21] or something like that [12:34] cpaelzer: where did you see that -pie is default in ubuntu? dpkg-buildflags doesn't show it [12:34] it doesn't even show bindnow [12:35] ahasenack: bindnow appears as -Wl,z,now [12:35] LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro [12:35] hm, but that's eoan [12:35] and pie is default in the compiler and only shows up as arg if you disable it [12:35] * ahasenack starts focal [12:35] ahasenack: the build log from your PPA has the Wl,z,now [12:35] well, because of the patch [12:36] which matches what the hardening page documents [13:00] ah, you want to keep the bindnow delta, ok, got you [13:00] s/want/agree/ [13:28] cpaelzer: is it ok to submit this to debian with the ubuntu string in the version? The change was made in debian's version 1.6.3-1.1 (and we got it in our 1.6.3-1.1ubuntu1): [13:28] +rm_conffile /etc/default/ipmidetectd 1.6.3-1.1ubuntu1~ freeipmi-ipmidetect [13:28] I think it's ok, since 1.1ubuntu1 is higher than 1.1 [13:29] vorlon, can you badtest graphene/i386? it relies on the python-gobject stack [13:36] doko: hi, where can I check if, and since when, -pie is a default option in gcc? It's not in the output of dpkg-buildflags [13:36] ahasenack: strictly speaking it is ok (for the comparison), but I usually change it to the Debian version that is next [13:36] cpaelzer: ah, so that it includes the ubuntu one? [13:37] if current Debian is 1.6.4-3 I'd set 1.6.4-4 [13:37] clean up conffile if coming from before 1.6.4-4 [13:37] vorlon, libsoup2.4/i386 fails on 'Depends: winbind:i386 but it is not going to be installed', badtest? [13:37] oh, right, they need a higher one [13:37] It's common to use 1.6.4-4~ instead, if I follow what you're doing [13:37] rbasak: yep [13:37] yep with the ~ [13:38] I was only talking about the version itself that is to be used [13:39] ok, I just would like to know how to find out if -pie is default, to point at it when submitting to debian, and also do double check debian has it as a default too [13:39] and isn't -fPIE needed together with that? [13:39] https://wiki.debian.org/Hardening#gcc_-pie_-fPIE [13:40] ahasenack: gcc -v 2>&1 | grep pie [13:40] will show --enable-default-pie [13:40] for us [13:40] not sure it does in Debian already [13:41] cpaelzer: is that a built-in default, or is some config file checked? [13:41] that is how gcc was built [13:41] essentially its configure call [13:41] root@sid-rspamd:~# gcc -v 2>&1|grep -i pie [13:41] root@sid-rspamd:~# [13:41] yep, not in sid [13:42] no pie for debian [13:42] for many other defaults I use "gcc -Q --help=target | grep ..." [13:42] hm [13:42] it helps if I have gcc installed [13:43] pie is there [13:43] ok then my assumption on the review was right \O/ [13:49] ahasenack: https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-fPIE but that looks incorrect. see debian/rules.defs in gcc-9 [13:52] seb128: why do you upload all these autopkg fixes as -Nbuild1? [13:52] doko, because I'm commited to the Debian vcs side as the same time but didn't want to do upload for those and don't want to have to remember doing the manual sync next time there is an upload in Debian [13:52] commiting* [13:53] it's a "content is staged in Debian, please override me on next upload" :) [13:53] unsure if we have a better way to achieve that? [13:54] just looking an libopenmpt, don't see anything in the debian vcs, or in a bug report [13:54] doko, right, as you see I had to iterate, I'm waiting for things to be green/confirmed to work to press send/push [13:56] doko, I expect to have things properly sent to Debian by the end of the day [14:00] ok [14:01] coreycb: you dropped xnox's patch for sqlalchemy, python2 now wanting to promote to main again ... === ricab is now known as ricab|lunch [14:03] doko: checking [14:11] doko: all the patches we were carrying in 1.2.18+ds1-2ubuntu3 are fixed in 1.3.11+ds1-1 [14:13] coreycb: no [14:13] $ apt-cache show python-sqlalchemy-doc|grep Recommends [14:13] Recommends: python-sqlalchemy [14:14] doko: got it, I'll fix that [14:32] tjaalton, I would like to upload the custodia with the pylint3 fix [14:32] can you please add me to freeipa-team so I can team upload it? [14:33] locutus_: just send a merge request [14:33] on debian [14:41] hi, I just filed https://bugs.launchpad.net/ubuntu/+source/reprotest/+bug/1855891 for reprotest has no installable candidate in focal [14:41] Launchpad bug 1855891 in reprotest (Ubuntu Focal) "reprotest has no installable candidate in focal" [Undecided,New] [14:42] is it possible to simply copy 0.7.9 from eoan first? There seem to be a 0.7.10build1 in proposed a month ago but failed to build [14:47] tjaalton, this? https://salsa.debian.org/freeipa-team/custodia/merge_requests/1 [14:48] let me know if and when I can upload === ricab|lunch is now known as ricab [15:31] locutus_: and how many packages are there still left using pylint3? [15:31] on debian [15:32] jamespage: coreycb: did you see my question in regard to six and python-oslo.messaging python-oslo.policy python-oslo.serialization python-oslo.service python-pyeclib this morning? [15:32] tjaalton, 3 or 4 [15:32] I fixed 4 this morning [15:32] and I'm fixing the others right now [15:33] fine [15:33] I think: gnome-keysign, knack, pathspider, prospector pylint-flask python-trio, ranger, uranium [15:33] probably less than that [15:35] cpaelzer: yes sorry I didn't reply. I'll take a look at those next. [15:35] thank you coreycb [15:35] just wanted to know it is covered [15:37] locutus_: merged [15:37] uploaded thanks [15:41] cpaelzer, xnox yeah I dug into php-horde a bit, the failure doesn't appear to me to be due to the database changes nor to the php 7.3, but to the phpunit 7->8 change in focal. Googling around shows it's due to a change in the setUp() call's prototype, it needs a void type specified or something. [15:42] cpaelzer, xnox it's on my todo list to work on at some point (maybe tomorrow?) but definitely feel free to work on it further if you wish [16:19] coreycb: mind giving me an okay for this change (https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/pcs/+git/pcs/+merge/376492) ? cpaelzer requested it as you're working with python3-tornado (6). [16:19] (can be a +1 or not here, just to make sure its good) [16:20] we are gonna be using pcs for ubuntu-ha related packages (ubuntu manual, etc) thats why I prefer having a working version now and I can fix it as soon as python-tornado 6 is ready. [16:23] coreycb: hes asking as you were touching it in the past and didn't want to step on your toes [16:23] :-) [16:49] rafaeldtinoco: james may be better to ask about percona-cluster [16:50] yep. we've spoken about this in last sprint, quickly. [16:58] seb128: hmm I'm very surprised that gjs was removed, it should've been picked up by germinate afaics. So to bring it back in cases like this, there's an update-i386-whitelist script in lp:ubuntu-archive-tools that can be edited for manual additions; and I'm doing a copy-package of gjs back to focal; I'll look into why it's not gotten picked up [17:05] seb128: graphene: badtested. libsoup2.4 -> winbind: should have the test annotated as winbind:native instead; but glancing at the log I also see python mentioned, so maybe there's no point? [18:39] I've been investigating the cyrus-imapd autopkgtest failure (which is blocking more than dozen of packages in proposed) and I think the failure is happening because the vm used to execute tests is running OOM [18:40] some processes are killed during the tests execution leading to failure [18:40] I've been trying to reproduce it in a vm with more resources and I can't [18:41] what is the best solution in this case? [18:47] bryce: https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/376593 is the next big MP please. Awaiting official CI results but it passes locally. [19:25] kanashiro: u know what processes are killed and why ? [19:43] vorlon, ah, @whitelist, good to know, thanks! [19:44] vorlon, libsoup2.4 let's badtest then? I will still commit the winbind:native change to the vcs [19:46] vorlon, I don't remember if I did ping about that one earlier, but speech-dispatcher depends on festival on i386 which is missing ... another case to rescue via the whitelist? or should we rather delete speech-dispatcher/i386? [19:47] vorlon, http://autopkgtest.ubuntu.com/packages/d/doc-rfc/focal/i386 ... badtest? (it's blocking poppler) [19:48] vorlon, http://autopkgtest.ubuntu.com/packages/s/sphinxbase/focal/i386 also (blocking pulseaudio) [19:48] (and enough pings for now, I go for dinner ;-) [19:59] seb128: fwiw winbind is tagged Multi-Arch: allowed, so the test dep on it can be winbind:any instead of winbind:native [20:00] seb128: speech-dispatcher-festival, I think we should be changing the source to not be generating that uninstallable binary on i386 in Ubuntu, let me take a look at that [20:01] seb128: (we can't delete speech-dispatcher as a whole, it's pulled in somewhere) [20:07] rbasak, til python's floor division operator via your patch, thanks :-) [20:10] bryce: yw :) [20:10] bryce: I'm not sure why CI failed on my branch. I'll look tomorrow. [20:12] doing the code review presently, I'll let you know on the MP if I find out [20:13] Thanks! [20:18] rafaeldtinoco, the process is smtpd and the why is that we are running OOM, look at one of the logs: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/s390x/c/cyrus-imapd/20191207_210616_44af2@/log.gz [20:20] I didn't check all the logs (there are many failures) but at least 7 have the same issue [20:21] cool gimme 15 and I'll take a look [20:24] by logs I meant log files :) [20:31] seb128: doc-rfc> oops sorry, should've already been badtested but I had failed to grab multiverse [20:34] seb128: and sphinxbase badtested [20:35] seb128: speech-dispatcher: https://paste.ubuntu.com/p/WVdHFZXt9k/ [20:35] hmm I probably should've had a new dpkg-vendor --is Ubuntu instead of reusing the dpkg-vendor --derives-from Ubuntu block, other downstreams might choose to keep i386 [20:50] kanashiro: make: *** [Makefile:390: all] Error 2 [20:50] make[2]: Entering directory '/srv/imaptest.git/src' [20:51] kanashiro: i think imaptest.git is broken [20:51] that is what happened [20:51] no ? [21:05] rafaeldtinoco, that might be an issue but I don't think this error is the responsible for killing smtpd processes [21:07] Cassandane::Unit::WorkerPool::start(Cassandane::Unit::WorkerPool=HASH(0x2aa12308728)) called at Cassandane/Unit/TestPlan.pm line 889 [21:07] i dont know the unit test but looks like they all died because the test died [21:07] the "workerpool" could be controlling the smtpd processes [21:07] but its a guess as I havent read cassandane code [21:08] at Cassandane/Unit/TestPlan.pm line 175. [21:08] you have a mainloop for the unit test [21:08] and then Test::Unit::TestRunner::do_run(Cassandane::Unit::RunnerPretty=HASH(0x2aa0f150eb8), Cassandane::Unit::TestPlan=HASH(0x2aa0f150c78), 0) called at ./testrunner.pl line 132 [21:08] do_run [21:08] and then an anonymous function being called [21:08] main::__ANON__(Cassandane::Unit::TestPlan=HASH(0x2aa0f150c78), GLOB(0x2aa0f150a80)) called at ./testrunner.pl line 315 [21:09] Running ./testrunner.pl -f pretty -j 4 Cyrus::ImapTest FAILED (at a94b77842b44bb57a73200a4ea66bdd6424c4583) [21:09] but all the unit test is around Cyrus::ImapTest [21:09] that did not compile [21:09] so I'd first look for that and then something else [21:09] kanashiro: ^ [21:09] hope it helps [21:24] rafaeldtinoco, I also don't have knowledge about the codebase but I still think the TestPlan died because OOM, during my tests in a tiny vm I got similar errors and the vm was running OOM [21:24] and I can't reproduce this imaptest error, it just works fine [21:25] vorlon, thx, other ones (blocking firefox) that could maybe use a badtest, http://autopkgtest.ubuntu.com/packages/libo/libomxil-bellagio/focal/i386 and http://autopkgtest.ubuntu.com/packages/n/nghttp2/focal/i386 [21:27] kanashiro: could be.. it doesn't say where the compilation error is.. right before it says test -f UnicodeData.txt || wget http://www.unicode.org/Public/UNIDATA/UnicodeData.txt [21:27] have u seen that ? [21:27] Proxy request sent, awaiting response... 503 Service Unavailable [21:27] make[3]: *** [Makefile:2794: UnicodeData.txt] Error 8 [21:27] make[3]: Leaving directory '/srv/dovecot.git/src/lib' [21:27] it looks the building env is/was in trouble [21:30] yeah I saw that [21:30] despite those warnings, the makefile error could come from unicodedata.txt not being get [21:31] causing other issues ahead (killing the unit test , etc) [21:31] Well I mean tests that rely on an external website are inherently unreliable [21:31] cjwatson: +1 [21:31] Make sure it has the file locally so that it doesn't need to fall back to wget [21:31] im just not seeing oom warnings there [21:33] this test also git clone a bunch of repos [21:33] yep [21:33] terrible autopkgtest =) [21:34] git clone dovecot, cyrusimap/* etc [21:34] git checkout -q 6264b51bcce8ae98efdcda3e55a765d7a13d15ed [21:34] at least they are using specific commit [21:34] and not "master" like i've seen before [21:35] the debian maintainer tried to translate upstream tests with docker to a shell script [21:35] yes [21:35] upstream should probably use something like travis [21:36] kanashiro: https://github.com/dovecot/core/blob/master/src/lib/Makefile.am [21:36] test -f $@ || wget -O $@ https://dovecot.org/res/UnicodeData.txt [21:37] thats it ^ [21:37] squid failed to give you that file [21:37] like cjwatson said, this will be a flakky test (by depending on this much external stuff) [21:38] actually they changed url [21:38] they're serving the UnicodeData from dovecot.org [21:39] kanashiro: ^ maybe it was failing too much ? =) [21:40] rafaeldtinoco, this test was triggered yesterday and it failed anyway but who knows [21:41] kanashiro: want a retry there ? [21:41] its likely that this UnicodeData.txt retrival is intermittent [21:42] we can but I wish I could be able to reproduce it [21:44] kanashiro: try setting up a http_proxy [21:44] and block https://dovecot.org/res/UnicodeData.txt [21:45] see if you get the same error #) [21:46] acl blacklist dstdom_regex "/etc/squid/blacklist.txt" [21:46] http_access deny blacklist [21:46] in squid.conf [21:46] might do the trick [23:22] bryce: cpaelzer: i fixed the phpunit compat earlier..... just retry tests with newer php-horde-db see http://launchpadlibrarian.net/454918855/php-horde-db_2.4.0-4ubuntu1_2.4.0-4ubuntu2.diff.gz then that was failing again with pg12 compat, which i fixed in the subsequent upload, but not confident about it.