| 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 | 03:21 |
| 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:04 |
| hloeung | sarnold: http://old-releases.ubuntu.com/ubuntu/pool/main/l/linux/ also has packages for armel etc. | 04:07 |
| 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:38 |
| cpaelzer | thanks doko for the ping, taking a look | 08:44 |
| cpaelzer | actually in bionnic it should become pg-10 anyway, but that needs a few more steps to complete | 08:45 |
| cpaelzer | -n | 08:45 |
| cpaelzer | oh I see it actually is a confluct with pg10 which is what we want to reach | 08:46 |
| 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 ... :-/ | 08:51 |
| cjwatson | xnox: PS3 was powerpc, 32-bit big-endian | 09:47 |
| cjwatson | xnox: shipped in feisty and gutsy | 09:47 |
| cjwatson | (IIRC) | 09:47 |
| xnox | cpaelzer, i have been working on postgresql-10 transition. | 09:48 |
| xnox | cpaelzer, it's currently a valid candidate | 09:48 |
| xnox | cpaelzer, and there should not be any 9.6 uploads into bionic. | 09:49 |
| cpaelzer | xnox: yeah I've seen it | 09:51 |
| 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:52 |
| 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 |
| ubottu | bug 1733525 in postgresql-filedump (Ubuntu) "Test Regression on ppc64 in version 10.0-1" [Undecided,New] https://launchpad.net/bugs/1733525 | 09:53 |
| cpaelzer | xnox: I've seen bug 1733341 from you - thanks | 09:53 |
| ubottu | bug 1733341 in postgresql-mysql-fdw (Ubuntu) "fails to work with postgresql 10.1" [Undecided,Confirmed] https://launchpad.net/bugs/1733341 | 09:53 |
| 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:54 |
| ubottu | bug 1733527 in postgresql-9.6 (Ubuntu) "Please remove postgresql-9.6 from bionic" [Undecided,New] https://launchpad.net/bugs/1733527 | 09:54 |
| cpaelzer | that is where I try to track remaining misses for the transition | 09:55 |
| cpaelzer | xnox: thanks for all your help on this transition | 09:56 |
| 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:57 |
| 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. | 09:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:04 |
| xnox | it's entagled with 100s of packages at the moment... icu... qt... and a bunch of other transitions | 10:05 |
| xnox | libreoffice.... | 10:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:43 |
| 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:53 |
| ubottu | 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:53 |
| 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:54 |
| cpaelzer | rbasak: maybe you could look at that change today? | 10:56 |
| rbasak | cpaelzer: I agree to force-badtest it. But that needs a release team member to actually do it. | 11:14 |
| 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:23 |
| doko | rbasak, cpaelzer: is nacc online? or could you look at the kopanocore autopkg test failure? | 11:24 |
| doko | the autopkg tests don't fail in debian apparently | 11:25 |
| 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:26 |
| cpaelzer | I'm giving up to get to do what I planned for today and will take a look | 11:27 |
| cpaelzer | :-) | 11:27 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| xnox | but also a bug in britney if this is considered a "regression" | 15:28 |
| cyphermox | arguably, yeah | 15:28 |
| 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:29 |
| xnox | pitti, urgh, one cannot specify Architecture: !s390x in debian/tests/control =( | 15:33 |
| 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:49 |
| 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:57 |
| 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:58 |
| 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 | 15:59 |
| cpaelzer | and in case it doesn't I could still reach out to someone | 16:00 |
| cpaelzer | thank you both | 16:00 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 | |
| juliank | Optimally, u-u would accept both SIGUSR1 and SIGTERM for graceful stopping | 18:32 |
| 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 | 18:33 |
| 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:08 |
| 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:09 |
| slangasek | infinity, stgraber, mdeslaur, kees: TB meeting in 15 | 19:45 |
| mdeslaur | ack | 19:45 |
| stgraber | will be there | 19:45 |
| 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:24 |
| cjwatson | I've left them a note | 20:25 |
| juliank | cjwatson: thx :) | 20:26 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| smoser | apt-get does seem to work on 16.04, and that is old enough for me. | 20:41 |
| smoser | thanks cjwatson ! | 20:41 |
| cjwatson | (apt will work on 16.04 too FWIW) | 20:42 |
| cjwatson | np, it definitely made my life easier when that happened | 20:42 |
| 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:50 |
| juliank | yeah, it's interface is not 100% stable like apt-get | 20:52 |
| juliank | but otherwise it's mostly nicer | 20:53 |
| 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:19 |
| mwhudson | also are we not running arm64 autopkgtests for xenial yet? | 23:20 |
| mwhudson | i guess we don't have a baseline there... | 23:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!