[03:21] do we archive ports anywhere when they're retires, similar to old-releases.ubuntu.com? [03:21] someone's trying to build a PS3 cluster and I think would be happy to find a bunch of old lucid or similar ports stuff [04:04] sarnold: doesn't old-releases cover ports as well? [04:04] sarnold: e.g. http://old-releases.ubuntu.com/ubuntu/dists/lucid/main/ has a much of arches [04:07] sarnold: http://old-releases.ubuntu.com/ubuntu/pool/main/l/linux/ also has packages for armel etc. [08:38] sarnold, PS3 is that powerpc? or the ppc64 (big endian) which we were working on, but never shipped due to contract-deal failure? [08:44] thanks doko for the ping, taking a look [08:45] actually in bionnic it should become pg-10 anyway, but that needs a few more steps to complete [08:45] -n [08:46] oh I see it actually is a confluct with pg10 which is what we want to reach [08:51] I didn't want to look at it yet, but it seems so many things already dep on pg-10 to complete [08:51] I need to look at it now ... :-/ [09:47] xnox: PS3 was powerpc, 32-bit big-endian [09:47] xnox: shipped in feisty and gutsy [09:47] (IIRC) [09:48] cpaelzer, i have been working on postgresql-10 transition. [09:48] cpaelzer, it's currently a valid candidate [09:49] cpaelzer, and there should not be any 9.6 uploads into bionic. [09:51] xnox: yeah I've seen it [09:52] I saw your ping yesterday and checked excuses this morning to find nothing left blocking [09:52] I'm working on a related issue on postgresql-filedump but that is not a blocker [09:52] xnox: also ack that there should be no (new) 9.6 uploads at all [09:52] xnox: that is what I replied to doko this morning [09:53] I think that was pushed to B as well by accident on the last MRE [09:53] filedump is likely fixed with a rebuild (testing that atm) see bug 1733525 [09:53] bug 1733525 in postgresql-filedump (Ubuntu) "Test Regression on ppc64 in version 10.0-1" [Undecided,New] https://launchpad.net/bugs/1733525 [09:53] xnox: I've seen bug 1733341 from you - thanks [09:53] bug 1733341 in postgresql-mysql-fdw (Ubuntu) "fails to work with postgresql 10.1" [Undecided,Confirmed] https://launchpad.net/bugs/1733341 [09:54] I subscribed myself on GH as well [09:54] xnox: I started bug 1733527 to track what is left to remove src:postgresql-9.6 - but I thought pg-10 should fully migrate before I ask about that [09:54] bug 1733527 in postgresql-9.6 (Ubuntu) "Please remove postgresql-9.6 from bionic" [Undecided,New] https://launchpad.net/bugs/1733527 [09:55] that is where I try to track remaining misses for the transition [09:56] xnox: thanks for all your help on this transition [09:57] xnox: I just proved that the rebuild would fix postgresql-filedump - that would be a no change upload of postgresql-filedump 10.0-1 [09:57] xnox: I don't want to mess with the migration, I think it would not affect it but an ack by you that I can upload postgresql-filebug would be nice [09:59] cpaelzer, what is it? a new package? [09:59] bah i misspelled [09:59] cpaelzer, it should be fine, it's leaf. [10:00] normal sync from debian, just when it synced the timing was bad and it has no rdeps [10:00] cpaelzer, we turned autosync off. [10:01] cpaelzer, so if it's autosync stuff, just leave it for now. we will be turning autosync back on, after the migration of doom. [10:01] xnox: there is no newer version in Debian it would sync [10:02] upload things to debian; or upload things you do need fixes for now -> like e.g. i'm uploading systemd again, to fix more test suite failures; and stop using nested kvm.... [10:02] cpaelzer, ah. [10:02] xnox: it even built correctly, but then failed on the autopkgtest [10:02] so it would not realize it had to sync [10:02] therefor I want to upload it as no change rebuild [10:02] cpaelzer, yeap, makes sense to do that! even now! [10:04] xnox: done [10:04] xnox: I only see valid candidates on pg-10 - what is the next step to do there so that it actually moves? [10:05] it's entagled with 100s of packages at the moment... icu... qt... and a bunch of other transitions [10:06] libreoffice.... [10:07] i think we are waiting for libreoffice to build on armhf (that takes like 2 days) [10:07] and systemd which i am about to upload. [10:07] it's more like 7 hours nowadays [10:08] apart from an 19h hang last night and restart from scratch? =) [10:08] i do wonder, if we should be cross-compiling libreoffice for armhf [10:08] yes, apart from that [10:08] icu LGTM this morning, but thanks for the overview [10:09] ruby-em-http-request tests are broken, even in the build ... [10:09] cpaelzer, there is mariadb upload 8 days old with an s390x regression [10:10] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mariadb-10.1 [10:10] anybody looking into that? [10:10] it failed a test [10:43] xnox: IIRC rbasak had such an error on his radar [10:43] I checked a few details with him a while ago, need to look if those are the same [10:53] xnox: yeah I remember this pcre thing to be part of the context what I disussed with rbasak [10:53] bug 1723947 [10:53] bug 1723947 in mariadb-10.1 (Ubuntu) "Current upload for 10.1.28-1 fails dep8 unitest on s390x" [Undecided,New] https://launchpad.net/bugs/1723947 [10:54] I was lost inside pcre but had a proposal on skipping this particular test (but keeping all others) for now [10:54] and was waiting on feedback on that [10:56] rbasak: maybe you could look at that change today? [11:14] cpaelzer: I agree to force-badtest it. But that needs a release team member to actually do it. [11:23] rbasak: what did you tihnk of my suggest to only skip thta particular test [11:23] rbasak: would loose less test coverage? [11:24] rbasak, cpaelzer: is nacc online? or could you look at the kopanocore autopkg test failure? [11:25] the autopkg tests don't fail in debian apparently [11:26] cpaelzer: oh, sorry. Yes, skipping that particular test would be fine. I'd forgotten about that part. [11:26] doko: he won't be available for some time [11:27] I'm giving up to get to do what I planned for today and will take a look [11:27] :-) [15:24] cyphermox, xnox: the various network-manager/s390x failures in excuses (http://autopkgtest.ubuntu.com/packages/n/network-manager/bionic/s390x) seem to be due to the s390x testbed changes? any idea what that is? [15:25] pitti: now has isolation, I think? [15:25] pitti, used to be lxc, now openstack nova kvm. [15:25] right, that's it [15:26] and somehow testing wpa & urfkill makes little sense on big iron [15:26] there, cfg80211 isn't being bult in the kernel (for one thing), probably the same story for rfkill; someone should revise the skipping those tests on s390x [15:26] +1 [15:27] cyphermox, previously it skipped [15:27] yes, because of isolation. [15:27] wpa-dhclient SKIP Test requires machine-level isolation but testbed does not provide that [15:27] nm SKIP Test requires machine-level isolation but testbed does not provide that [15:27] killswitches-no-urfkill SKIP Test requires machine-level isolation but testbed does not provide that [15:27] urfkill-integration SKIP Test requires machine-level isolation but testbed does not provide that [15:27] autopkgtest [07:51:18]: @@@@@@@@@@@@@@@@@@@@ summary [15:27] wpa-dhclient SKIP Test requires machine-level isolation but testbed does not provide that [15:27] nm SKIP Test requires machine-level isolation but testbed does not provide that [15:27] killswitches-no-urfkill SKIP Test requires machine-level isolation but testbed does not provide that [15:27] urfkill-integration SKIP Test requires machine-level isolation but testbed does not provide that [15:27] right. [15:27] the test defines it needs it. [15:27] now we need to skip some other way, because cfg80211 and rfkill don't make all that much sense on s390x. [15:28] but also a bug in britney if this is considered a "regression" [15:28] arguably, yeah [15:29] if it was skipped before and now fails it probably should be an always-failed, but it's not wrong to mark it a regression either, we do have a change in behavior and it's good to revise the tests and see if we should keep skipping or fix something else [15:33] pitti, urgh, one cannot specify Architecture: !s390x in debian/tests/control =( [15:49] xnox: right, you have to encode that in the test itself [15:49] xnox: I suppose it's just the module build not being supported on s390x? [15:57] I know to pull something in main I'd add a dependency from a pkg in main [15:57] but if I want to add a binary pkg to a src that is in main [15:57] can I just add (and not add any stronger dep than suggest) and it will be in universe? [15:57] or would a bin from src in main appear "in main" by default? [15:57] rbasak: ^^ on my question of before [15:58] cpaelzer: it will land in binNEW, and it can be chosen there [15:58] cpaelzer: AFAIK Launchpad will default to teh same component as the source (i. e. main) [15:58] oh chosen, interesting [15:58] but it will quickly appear on http://people.canonical.com/~ubuntu-archive/component-mismatches.html and then be demoted [15:58] so it doesn't matter that much if it's NEWed wrongly [15:58] ok, that means on the transition of the NEW queue I can coordinate with someone [15:59] thanks pitti [15:59] cpaelzer, there is no coordination required on your part, it should drop down to universe via regular archive maintainance. [15:59] great, thanks [16:00] and in case it doesn't I could still reach out to someone [16:00] thank you both [18:27] hloeung,xnox: I thought old-releases would have worked for the reporter but he said apt kept reporting "no packages available" or something similar.. I got to wondering if maybe ppc details I don't know were involved, I never figured out the BE vs LE vs which PPC chips were 64bit vs 32bit .. what little I did know from my g3 ibook days is long since atrophed, hehe [18:28] it should just work(tm) [18:28] :D [18:28] maybe installer is not run at low priority to specify old-releases? [18:28] and security pocket to old releases too? [18:29] old-releases is not excatly easy to use..... [18:29] *sigh* the reporter's offline.. [18:29] indeed [18:29] but the guy had 300 PS3 slim units or something silly he wanted to cluster :) [18:29] rbalint: I feel like we should just continue to use SIGUSR1 for old unattended-upgrade versions, rather than backporting the unattended-upgrade SIGTERM change. Since we have to manually forward signals in apt-daily.service anyway, this way we don't need any coordinates SRUs at least (and it should work in Debian too). [18:29] so I figured he'd be motivated to figure it out [18:30] It should not be too hard to just send SIGUSR1 for u-u before artful :) [18:30] * juliank just needs to add another varaible to the cron job [18:32] Optimally, u-u would accept both SIGUSR1 and SIGTERM for graceful stopping [18:33] cjwatson: The apt PPA daily builds fail to upload with "[lplibrarian-public-upload.internal:10004]: [Errno 111] Connection refused" and "[lplibrarian-public-upload.internal:10004]: [Errno 113] No route to host" - what's going on? I think I had 4 emails now in a few seconds [19:08] rbasak: I wanted to check in with you again about Certbot packages [19:08] I'm curious what I can do to help finally finish out the Certbot SRU and I wanted to ask you again about potential problems for future SRUs caused by us splitting our JOSE library into a separate package [19:09] for the latter, most distros asked us to just split the package rather than continuing to vendorize it, but I wanted to make sure you're OK with this plan before I pull the trigger and do a release like thsi [19:45] infinity, stgraber, mdeslaur, kees: TB meeting in 15 [19:45] ack [19:45] will be there [20:24] juliank: one of our frontends was rebooted and it looks like the admin who did it wasn't careful to take it out of DNS first [20:25] I've left them a note [20:26] cjwatson: thx :) [20:32] i have a deb that i want to install (locally built). [20:32] dpkg -i foo.deb [20:32] can fail because of m issing packages. [20:32] apt-get -f install will normally "fix" that. [20:33] except when foo.deb is older than the version in the archive. apt will choose to upgrade it to the archive version. which isnot what i want. [20:33] i tried holding 'foo' before 'apt-get -f install' and that actually works [20:33] but only when foo is older than the version available in the archive. [20:34] if its *newer*, then apt complains about pkgProblemResolver [20:34] like https://jenkins.ubuntu.com/server/job/cloud-init-ci/536/console [20:35] i'd like to avoid 'mk-build-deps' and local package repos if i can. [20:35] any thoughts ? [20:35] smoser: can you install the dependencies first? [20:36] well, i could, but then i have to know them. [20:36] ah [20:36] i can query them , but you get stuff like [20:36] # dpkg-query --show '--showformat=${Depends}' cloud-init [20:36] init-system-helpers (>= 1.18~), python3-configobj, python3-jinja2, python3-jsonpatch, python3-jsonschema, python3-oauthlib, python3-requests, python3-six, python3-yaml, python3:any (>= 3.3.2-2~) [20:36] which is i guess not too bad here. [20:36] smoser: apt install ./path.to.deb [20:36] but when there are '|' and such. [20:37] \o/ [20:37] wow apt can do that?? neat [20:37] nowadays yes [20:37] oh. apt. [20:37] possibly apt-get too, I forget [20:41] apt-get does seem to work on 16.04, and that is old enough for me. [20:41] thanks cjwatson ! [20:42] (apt will work on 16.04 too FWIW) [20:42] np, it definitely made my life easier when that happened [20:50] i'd just generally stay away from 'apt' if i can. due to warnings i've seen it spew out when output is not a terminal. [20:50] that say "dont use this from scripts" or somethign [20:52] yeah, it's interface is not 100% stable like apt-get [20:53] but otherwise it's mostly nicer [23:19] what happened here? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/d/docker.io/20171121_211648_60458@/log.gz some infrastructure failure? [23:20] also are we not running arm64 autopkgtests for xenial yet? [23:20] i guess we don't have a baseline there...