[03:21] <sarnold> do we archive ports anywhere when they're retires, similar to old-releases.ubuntu.com?
[03:21] <sarnold> 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] <hloeung> sarnold: doesn't old-releases cover ports as well?
[04:04] <hloeung> sarnold: e.g. http://old-releases.ubuntu.com/ubuntu/dists/lucid/main/ has a much of arches
[04:07] <hloeung> sarnold: http://old-releases.ubuntu.com/ubuntu/pool/main/l/linux/ also has packages for armel etc.
[08:38] <xnox> 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] <cpaelzer> thanks doko for the ping, taking a look
[08:45] <cpaelzer> actually in bionnic it should become pg-10 anyway, but that needs a few more steps to complete
[08:45] <cpaelzer> -n
[08:46] <cpaelzer> oh I see it actually is a confluct with pg10 which is what we want to reach
[08:51] <cpaelzer> I didn't want to look at it yet, but it seems so many things already dep on pg-10 to complete
[08:51] <cpaelzer> I need to look at it now ... :-/
[09:47] <cjwatson> xnox: PS3 was powerpc, 32-bit big-endian
[09:47] <cjwatson> xnox: shipped in feisty and gutsy
[09:47] <cjwatson> (IIRC)
[09:48] <xnox> cpaelzer, i have been working on postgresql-10 transition.
[09:48] <xnox> cpaelzer, it's currently a valid candidate
[09:49] <xnox> cpaelzer, and there should not be any 9.6 uploads into bionic.
[09:51] <cpaelzer> xnox: yeah I've seen it
[09:52] <cpaelzer> I saw your ping yesterday and checked excuses this morning to find nothing left blocking
[09:52] <cpaelzer> I'm working on a related issue on postgresql-filedump but that is not a blocker
[09:52] <cpaelzer> xnox: also ack that there should be no (new) 9.6 uploads at all
[09:52] <cpaelzer> xnox: that is what I replied to doko this morning
[09:53] <cpaelzer> I think that was pushed to B as well by accident on the last MRE
[09:53] <cpaelzer> filedump is likely fixed with a rebuild (testing that atm) see bug 1733525
[09:53] <cpaelzer> xnox: I've seen bug 1733341 from you - thanks
[09:54] <cpaelzer> I subscribed myself on GH as well
[09:54] <cpaelzer> 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:55] <cpaelzer> that is where I try to track remaining misses for the transition
[09:56] <cpaelzer> xnox: thanks for all your help on this transition
[09:57] <cpaelzer> 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] <cpaelzer> 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] <xnox> cpaelzer, what is it? a new package?
[09:59] <xnox> bah i misspelled
[09:59] <xnox> cpaelzer, it should be fine, it's leaf.
[10:00] <cpaelzer> normal sync from debian, just when it synced the timing was bad and it has no rdeps
[10:00] <xnox> cpaelzer, we turned autosync off.
[10:01] <xnox> 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] <cpaelzer> xnox: there is no newer version in Debian it would sync
[10:02] <xnox> 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] <xnox> cpaelzer, ah.
[10:02] <cpaelzer> xnox: it even built correctly, but then failed on the autopkgtest
[10:02] <cpaelzer> so it would not realize it had to sync
[10:02] <cpaelzer> therefor I want to upload it as no change rebuild
[10:02] <xnox> cpaelzer, yeap, makes sense to do that! even now!
[10:04] <cpaelzer> xnox: done
[10:04] <cpaelzer> xnox: I only see valid candidates on pg-10 - what is the next step to do there so that it actually moves?
[10:05] <xnox> it's entagled with 100s of packages at the moment... icu... qt... and a bunch of other transitions
[10:06] <xnox> libreoffice....
[10:07] <xnox> i think we are waiting for libreoffice to build on armhf (that takes like 2 days)
[10:07] <xnox> and systemd which i am about to upload.
[10:07] <Laney> it's more like 7 hours nowadays
[10:08] <xnox> apart from an 19h hang last night and restart from scratch? =)
[10:08] <xnox> i do wonder, if we should be cross-compiling libreoffice for armhf
[10:08] <Laney> yes, apart from that
[10:08] <cpaelzer> icu LGTM this morning, but thanks for the overview
[10:09] <doko> ruby-em-http-request tests are broken, even in the build ...
[10:09] <xnox> cpaelzer, there is mariadb upload 8 days old with an s390x regression
[10:10] <xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mariadb-10.1
[10:10] <xnox> anybody looking into that?
[10:10] <xnox> it failed a test
[10:43] <cpaelzer> xnox: IIRC rbasak had such an error on his radar
[10:43] <cpaelzer> I checked a few details with him a while ago, need to look if those are the same
[10:53] <cpaelzer> xnox: yeah I remember this pcre thing to be part of the context what I disussed with rbasak
[10:53] <cpaelzer> bug 1723947
[10:54] <cpaelzer> I was lost inside pcre but had a proposal on skipping this particular test (but keeping all others) for now
[10:54] <cpaelzer> and was waiting on feedback on that
[10:56] <cpaelzer> rbasak: maybe you could look at that change today?
[11:14] <rbasak> cpaelzer: I agree to force-badtest it. But that needs a release team member to actually do it.
[11:23] <cpaelzer> rbasak: what did you tihnk of my suggest to only skip thta particular test
[11:23] <cpaelzer> rbasak: would loose less test coverage?
[11:24] <doko> rbasak, cpaelzer: is nacc online? or could you look at the kopanocore autopkg test failure?
[11:25] <doko> the autopkg tests don't fail in debian apparently
[11:26] <rbasak> cpaelzer: oh, sorry. Yes, skipping that particular test would be fine. I'd forgotten about that part.
[11:26] <cpaelzer> doko: he won't be available for some time
[11:27] <cpaelzer> I'm giving up to get to do what I planned for today and will take a look
[11:27] <cpaelzer> :-)
[15:24] <pitti> 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] <cyphermox> pitti: now has isolation, I think?
[15:25] <xnox> pitti, used to be lxc, now openstack nova kvm.
[15:25] <cyphermox> right, that's it
[15:26] <xnox> and somehow testing wpa & urfkill makes little sense on big iron
[15:26] <cyphermox> 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] <cyphermox> +1
[15:27] <xnox> cyphermox, previously it skipped
[15:27] <cyphermox> yes, because of isolation.
[15:27] <xnox> wpa-dhclient         SKIP Test requires machine-level isolation but testbed does not provide that
[15:27] <xnox> nm                   SKIP Test requires machine-level isolation but testbed does not provide that
[15:27] <xnox> killswitches-no-urfkill SKIP Test requires machine-level isolation but testbed does not provide that
[15:27] <xnox> urfkill-integration  SKIP Test requires machine-level isolation but testbed does not provide that
[15:27] <xnox> autopkgtest [07:51:18]: @@@@@@@@@@@@@@@@@@@@ summary
[15:27] <xnox> wpa-dhclient         SKIP Test requires machine-level isolation but testbed does not provide that
[15:27] <xnox> nm                   SKIP Test requires machine-level isolation but testbed does not provide that
[15:27] <xnox> killswitches-no-urfkill SKIP Test requires machine-level isolation but testbed does not provide that
[15:27] <xnox> urfkill-integration  SKIP Test requires machine-level isolation but testbed does not provide that
[15:27] <xnox> right.
[15:27] <cyphermox> the test defines it needs it.
[15:27] <cyphermox> now we need to skip some other way, because cfg80211 and rfkill don't make all that much sense on s390x.
[15:28] <xnox> but also a bug in britney if this is considered a "regression"
[15:28] <cyphermox> arguably, yeah
[15:29] <cyphermox> 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] <xnox> pitti, urgh, one cannot specify Architecture: !s390x in debian/tests/control =(
[15:49] <pitti> xnox: right, you have to encode that in the test itself
[15:49] <pitti> xnox: I suppose it's just the module build not being supported on s390x?
[15:57] <cpaelzer> I know to pull something in main I'd add a dependency from a pkg in main
[15:57] <cpaelzer> but if I want to add a binary pkg to a src that is in main
[15:57] <cpaelzer> can I just add (and not add any stronger dep than suggest) and it will be in universe?
[15:57] <cpaelzer> or would a bin from src in main appear "in main" by default?
[15:57] <cpaelzer> rbasak: ^^ on my question of before
[15:58] <pitti> cpaelzer: it will land in binNEW, and it can be chosen there
[15:58] <pitti> cpaelzer: AFAIK Launchpad will default to teh same component as the source (i. e. main)
[15:58] <cpaelzer> oh chosen, interesting
[15:58] <pitti> but it will quickly appear on http://people.canonical.com/~ubuntu-archive/component-mismatches.html and then be demoted
[15:58] <pitti> so it doesn't matter that much if it's NEWed wrongly
[15:58] <cpaelzer> ok, that means on the transition of the NEW queue I can coordinate with someone
[15:59] <cpaelzer> thanks pitti
[15:59] <xnox> cpaelzer, there is no coordination required on your part, it should drop down to universe via regular archive maintainance.
[15:59] <cpaelzer> great, thanks
[16:00] <cpaelzer> and in case it doesn't I could still reach out to someone
[16:00] <cpaelzer> thank you both
[18:27] <sarnold> 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] <xnox> it should just work(tm)
[18:28] <sarnold> :D
[18:28] <xnox> maybe installer is not run at low priority to specify old-releases?
[18:28] <xnox> and security pocket to old releases too?
[18:29] <xnox> old-releases is not excatly easy to use.....
[18:29] <sarnold> *sigh* the reporter's offline..
[18:29] <sarnold> indeed
[18:29] <sarnold> but the guy had 300 PS3 slim units or something silly he wanted to cluster :)
[18:29] <juliank> 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] <sarnold> so I figured he'd be motivated to figure it out
[18:30] <juliank> 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] <juliank> Optimally, u-u would accept both SIGUSR1 and SIGTERM for graceful stopping
[18:33] <juliank> 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] <bmw> rbasak: I wanted to check in with you again about Certbot packages
[19:08] <bmw> 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] <bmw> 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] <slangasek> infinity, stgraber, mdeslaur, kees: TB meeting in 15
[19:45] <mdeslaur> ack
[19:45] <stgraber> will be there
[20:24] <cjwatson> 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] <cjwatson> I've left them a note
[20:26] <juliank> cjwatson: thx :)
[20:32] <smoser> i have a deb that i want to install (locally built).
[20:32] <smoser> dpkg -i foo.deb
[20:32] <smoser> can fail because of m issing packages.
[20:32] <smoser> apt-get -f install will normally "fix" that.
[20:33] <smoser> 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] <smoser> i tried holding 'foo' before 'apt-get -f install' and that actually works
[20:33] <smoser> but only when foo is older than the version available in the archive.
[20:34] <smoser> if its *newer*, then apt complains about pkgProblemResolver
[20:34] <smoser> like https://jenkins.ubuntu.com/server/job/cloud-init-ci/536/console
[20:35] <smoser> i'd like to avoid 'mk-build-deps' and local package repos if i can.
[20:35] <smoser> any thoughts ?
[20:35] <sarnold> smoser: can you install the dependencies first?
[20:36] <smoser> well, i could, but then i have to know them.
[20:36] <sarnold> ah
[20:36] <smoser> i can query them , but you get stuff like
[20:36] <smoser> # dpkg-query --show '--showformat=${Depends}' cloud-init
[20:36] <smoser> 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] <smoser> which is i guess not too bad here.
[20:36] <cjwatson> smoser: apt install ./path.to.deb
[20:36] <smoser> but when there are '|' and such.
[20:37] <smoser> \o/
[20:37] <sarnold> wow apt can do that?? neat
[20:37] <cjwatson> nowadays yes
[20:37] <smoser> oh. apt.
[20:37] <cjwatson> possibly apt-get too, I forget
[20:41] <smoser> apt-get does seem to work on 16.04, and that is old enough for me.
[20:41] <smoser> thanks cjwatson !
[20:42] <cjwatson> (apt will work on 16.04 too FWIW)
[20:42] <cjwatson> np, it definitely made my life easier when that happened
[20:50] <smoser> 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] <smoser> that say "dont use this from scripts"  or somethign
[20:52] <juliank> yeah, it's interface is not 100% stable like apt-get
[20:53] <juliank> but otherwise it's mostly nicer
[23:19] <mwhudson> 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] <mwhudson> also are we not running arm64 autopkgtests for xenial yet?
[23:20] <mwhudson> i guess we don't have a baseline there...