| vicamo | Hi, need sponsor https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1848922 for SRU backport-iwlwifi-dkms to Eoan (bug-1848922) | 07:02 |
|---|---|---|
| mwhudson | how much ram do the default autopkgtest runners have again? | 08:15 |
| mwhudson | guessing it's 1G | 08:16 |
| cpaelzer | kanashiro: FYI https://github.com/theupdateframework/notary/issues/1469#issuecomment-552050160 | 10:42 |
| cpaelzer | this hit your nss upload and the nspr sync | 10:42 |
| cpaelzer | you might want to check if applying https://github.com/theupdateframework/notary/pull/1514/commits/006963f1ded582c2cc5f5eb4d48dc6089ce3229b fixes notary to be a FTBFS | 10:43 |
| cpaelzer | if it does bring that to Debian which would then hopefully also resolve the dep8 test failures (which build it as well) | 10:44 |
| cpaelzer | but there seems to be more to it, so don't expect it to be a smooth ride, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944346 | 10:46 |
| ubottu | Debian bug 944346 in notary "FTBFS due API change of `github.com/docker/distribution@v2.7.1`" [Normal,Open] | 10:46 |
| cpaelzer | But with that much known you might consider adding a badtest for notary (for now) to https://code.launchpad.net/~ubuntu-release/britney/hints-ubuntu | 10:47 |
| cpaelzer | kanashiro: let me know what you think | 10:47 |
| kanashiro | cpaelzer, thanks for the pointers, I'll take a look now and I'll let you know my thoughts | 11:26 |
| cpaelzer | ok | 11:26 |
| rafaeldtinoco | good morning o/ | 11:49 |
| cpaelzer | ahasenack: postgresql-12 made it into release, but postgresql-common 209 still has test issues | 11:56 |
| cpaelzer | That is 12/23 resolved by my test triggers of last week, but leaves 11 to check what/why is breaking. | 11:56 |
| cpaelzer | Left are wal2json, rdkit, postgis@s390x (flaky in the past), php-horde-db, pgrouting, pglogical-ticker, pgl-ddl-deploy, patroni, mediawiki, hypop, cstore-fdw | 11:57 |
| cpaelzer | ahasenack: if you want to help the weirdest seems to be asyncpg (which also is important to doko IIRC) whcih fails with rather odd cython issues now exceeding my python-foo | 11:58 |
| cpaelzer | the steps so far would be in bug 1850136 | 11:58 |
| ubottu | bug 1850136 in asyncpg (Ubuntu) "FTBFS in Focal with PG-12 present" [Undecided,Confirmed] https://launchpad.net/bugs/1850136 | 11:58 |
| ahasenack | k | 12:01 |
| ahasenack | I was caught by u-a-t again, though: #1851858 | 12:01 |
| doko | o/ | 12:02 |
| cpaelzer | sorry to hear that ahasenack, I'll continue to keep you in the loop | 12:06 |
| cpaelzer | and doko, if that cython error that I linked in the bug looks familiar to you let me know any pointers that you might have | 12:06 |
| doko | cpaelzer: sorry, no. there's a new cython upstream, but nothing which looks related | 12:12 |
| cpaelzer | ok, thanks | 12:12 |
| doko | but I'll NMU that to debian, anyway | 12:13 |
| rafaeldtinoco | bryce: looks like we need python3-tornado >= 6 (pcs is blocked by that) | 12:14 |
| rafaeldtinoco | couldn't find it in the merge board, not sure if we're already on it or not | 12:14 |
| rafaeldtinoco | anyone aware ? ^ | 12:14 |
| kanashiro | rafaeldtinoco, I am on it, I didn't do the merge yet because of a bug in usd-importer | 12:15 |
| rafaeldtinoco | ah great | 12:15 |
| rafaeldtinoco | thx! | 12:15 |
| === ricab is now known as ricab|lunch | ||
| kanashiro | cpaelzer, could you please sponsor the lm-sensors package? since you reviewed it | 12:25 |
| cpaelzer | sure | 12:26 |
| gpiccoli | Hi sil2100, sorry for the ping! I was out on Friday, not sure if you checked the britney MPs, if I may need a change or anything hehe | 12:28 |
| gpiccoli | https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-bionic/+merge/375279 | 12:29 |
| gpiccoli | https://code.launchpad.net/~gpiccoli/britney/hints-ubuntu-disco/+merge/375280 | 12:29 |
| gpiccoli | Let me know your thoughts! Tnx in advance, sorry to annoy heheh | 12:29 |
| cpaelzer | kanashiro: done | 12:29 |
| kanashiro | cpaelzer, thanks! | 12:29 |
| cpaelzer | kanashiro: rafaeldtinoco: ahasenack: since you are around (and I seem to be blind atm), any good idea why "Conflicts: libapache2-mod-php7.2" in d/control doesn't make it into the built package? | 12:31 |
| cpaelzer | belongs to bug 1850933 | 12:32 |
| ubottu | bug 1850933 in apache2 (Ubuntu) "after upgrade 19.04 to 19.10, apache serves php code" [High,Confirmed] https://launchpad.net/bugs/1850933 | 12:32 |
| ahasenack | nope, use DH_VERBOSE? | 12:32 |
| cpaelzer | yeah, maybe the right next step | 12:33 |
| ahasenack | or did you add it to the source section? | 12:33 |
| cpaelzer | no it is in the binary I want it | 12:33 |
| ahasenack | cpaelzer: I got logs in pvt email for that bug, btw | 12:34 |
| cpaelzer | DH_VERBOSE was already on, but nothing helpful in the log | 12:34 |
| cpaelzer | yeah me as well | 12:34 |
| cpaelzer | based on that I found that it seems to be a real issue | 12:35 |
| cpaelzer | the reporter didn't want to share all his logs in the bug itself | 12:35 |
| ahasenack | ah, so you aren't clairvoyant | 12:35 |
| cpaelzer | nope | 12:35 |
| ahasenack | not yet, at least | 12:35 |
| ahasenack | the singularity is coming | 12:35 |
| cpaelzer | working on it | 12:35 |
| cpaelzer | bulding with conflicts+breaks over lunch and then takign a look again | 12:36 |
| kanashiro | cpaelzer, re notary: the upstream commit you mentioned fixes the current issue we have but there is another one while running the tests (not the same in Debian because they updated a b-d some weeks ago which breaks even the build) | 12:37 |
| cpaelzer | kanashiro: yes that is what the debian bug report said | 13:06 |
| cpaelzer | so we might for now mark it as badtest | 13:06 |
| cpaelzer | kanashiro: have you done that before or do you need guidance where to start with it? | 13:06 |
| cpaelzer | ahasenack: there is a d/control.in file - I guess that is the explanation ... :-/ | 13:13 |
| ahasenack | aha | 13:18 |
| vicamo | Hi, need sponsor https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1848922 for SRU backport-iwlwifi-dkms to Eoan (bug-1848922) | 13:22 |
| === ricab|lunch is now known as ricab | ||
| cpaelzer | doko: question about https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1849785/comments/28 | 13:50 |
| ubottu | Launchpad bug 1849785 in libseccomp (Ubuntu Eoan) "FTBFS on i386/ppc64/s390x (Eoan+Focal)" [Medium,Triaged] | 13:50 |
| cpaelzer | python 3.7: /usr/lib/python3.7/_sysconfigdata_m_linux_x86_64-linux-gnu.py | 13:50 |
| cpaelzer | pytohn 3.8: /usr/lib/python3.8/_sysconfigdata__linux_x86_64-linux-gnu.py | 13:50 |
| cpaelzer | see the missing "m" | 13:51 |
| cpaelzer | that is what makes libseccomp FTBFS | 13:51 |
| cpaelzer | is that something that needs/should be fixed in the python 3.8 build - and if so it is known for a bug to track | 13:51 |
| cpaelzer | or should I just modify the d/rules of libseccomp to use the name without "m" in the 3.8 case https://salsa.debian.org/debian/libseccomp/blob/debian/sid/debian/rules#L28 | 13:52 |
| cpaelzer | I know that you are on https://bugs.python.org/issue37561 which sounds very very similar to the naive me :-) | 13:53 |
| doko | cpaelzer: yes, the modifier was dropped | 14:01 |
| cjwatson | cpaelzer: https://wiki.debian.org/Python/Python3.8 | 14:01 |
| cpaelzer | thanks cjwatson and doko | 14:03 |
| cpaelzer | fixing up libseccomp then and retrying my build | 14:03 |
| sil2100 | gpiccoli: hey! Looking in a moment o/ | 14:16 |
| gpiccoli | Hi sil2100 o/ | 14:17 |
| gpiccoli | Thank you =) | 14:18 |
| kanashiro | cpaelzer, I have spent some time trying to fix notary by myself with no success, so let's mark it as a badtest (I've never done this, would appreciate some guidance) | 14:24 |
| cpaelzer | kanashiro: https://wiki.ubuntu.com/ProposedMigration#Are_there_any_exceptions.3F__I.27m_sure_acmefoo_has_just_made_it_into_the_release_pocket_despite_not_satisfying_all_of_the_requirements. | 14:31 |
| cpaelzer | which means clone, modify and propose a change to http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/changes | 14:31 |
| cpaelzer | kanashiro: when you have taken a look feel free to ask questions about the format in there | 14:31 |
| kanashiro | cpaelzer, thanks again | 14:32 |
| sil2100 | gpiccoli: commented! +1 on hinting the failures, but -1 on an unversioned hint | 14:35 |
| sil2100 | gpiccoli: those are too easy to forget about, could you modify it to a versioned one? | 14:36 |
| gpiccoli | ok sil2100, I can change that! Thanks! So, how to proceed from the MP point-of-view? We drop the current MP and do another one? | 14:37 |
| sil2100 | gpiccoli: no, just modify those MPs | 14:44 |
| sil2100 | Push commits on top of them | 14:44 |
| gpiccoli | ok, perfect! I'll do that now sil2100 =) | 14:45 |
| gpiccoli | Tnx again for the advice, as soon I finish that, I'll ping you | 14:45 |
| kanashiro | cpaelzer, do I need to update this file https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/view/head:/ubuntu-release ? I didn't get the difference among all those files | 14:48 |
| cpaelzer | kanashiro: in the past several people had their own file, but it slowly converges to a unified approach | 14:49 |
| cpaelzer | new things should be in ubuntu-release and after the release happened things will be added to ubuntu-sru | 14:49 |
| cpaelzer | the only reason to these days modify the other files if the badtest you are looking at was already in those and you only bump the number | 14:49 |
| cpaelzer | but even then you might consider moving it since you are touching it | 14:50 |
| kanashiro | cpaelzer, good, so I am on the right way :) | 14:51 |
| kanashiro | cpaelzer, can I just link this bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944346 as a comment? Or do I need to be more verbose? | 14:59 |
| ubottu | Debian bug 944346 in notary "FTBFS due API change of `github.com/docker/distribution@v2.7.1`" [Normal,Open] | 14:59 |
| gpiccoli | sil2100, done both! Now they are versioned =) | 15:12 |
| gpiccoli | Thank you for approving sil2100 =] <saw the email hehe> | 15:21 |
| gpiccoli | Now, the package goes automatically from -proposed to -updates, or should someone trigger autopkgtests again? | 15:21 |
| sil2100 | gpiccoli: so normally, for the development series, migrations happen automatically if autopkgtests and installability are fine | 15:28 |
| sil2100 | But for SRUs, someone from the SRU team needs to manually release those | 15:29 |
| sil2100 | I'll be doing my releasing shift soon, so hopefully I'll be able to do that | 15:29 |
| gpiccoli | Great sil2100, thank you very much for the help in all fronts =] | 15:29 |
| gpiccoli | We have users waiting for this kdump-tools for months heheh | 15:29 |
| gpiccoli | Had problems in the previous release, they'll appreciate much =) | 15:29 |
| === M_hc[m] is now known as _hc | ||
| ahasenack | infinity: if you are still around, if I could pick your brain for a sec | 18:05 |
| ahasenack | ubuntu@trusty-i386-ua:~$ uname -m | 18:05 |
| ahasenack | i686 | 18:05 |
| ahasenack | but | 18:05 |
| ahasenack | ubuntu@trusty-i386-ua:~$ dpkg --print-architecture | 18:05 |
| ahasenack | i386 | 18:05 |
| ahasenack | soooo... | 18:05 |
| infinity | Yes and? | 18:05 |
| infinity | Never use uname to determine dpkg arch. | 18:05 |
| ahasenack | in postinst I'm gating on i386/amd64 | 18:06 |
| ahasenack | but the ua client seems to be using uname -m | 18:06 |
| ahasenack | ubuntu@trusty-i386-ua:~$ sudo ua enable esm-infra | 18:06 |
| ahasenack | One moment, checking your subscription first | 18:06 |
| ahasenack | ESM Infra is not available for platform i686. | 18:06 |
| ahasenack | Supported platforms are: i386, x86_64 | 18:06 |
| ahasenack | bug in ua client? | 18:06 |
| infinity | The UA client is wrong. | 18:06 |
| ahasenack | ok, figured | 18:06 |
| infinity | I assume it's already rewriting amd64, or that also wouldn't work. | 18:06 |
| infinity | But it shouldn't be using uname at all. | 18:06 |
| ahasenack | oh yeah, I didn't even see x86_64 in there, thanks for pointing that out | 18:07 |
| ahasenack | I'm doing amd64/i386 in postinst, as reported by dpkg --print-architecture | 18:07 |
| infinity | Okay, so, that said, I'm not sure we want to "fix" that part of the bug if we're also fixing the mirrors. | 18:08 |
| ahasenack | I think we will want to make it clear what's supported and what isn't | 18:08 |
| infinity | I think the client warning about lack of support on !x86 is fine, but having the enabling behaviour be the same on all is less hassle. | 18:09 |
| infinity | Plus, it means we can selectively push some stuff to !x86 if we really want. | 18:09 |
| infinity | (Well, not really, but sort of) | 18:09 |
| ahasenack | infinity: in any case, the good names are i386 and amd64, right? | 18:10 |
| ahasenack | as reported by dpkg --print-architecture | 18:10 |
| infinity | The experiment we were going to try for the mirrors was to mirror tzdata and distro-info-data to all arches. | 18:10 |
| ahasenack | I haven't heard back from that rt yet, I asked if we have a staging repo to test the idea with | 18:10 |
| infinity | ahasenack: Yeah, using uname to determine userspace arch is always wrong. Always use the package manager's view. | 18:10 |
| infinity | ahasenack: I was told they'd work on it "Monday morning", which is vaguely nowish. | 18:11 |
| ahasenack | somewhere, yes :) | 18:11 |
| ahasenack | US holiday too | 18:11 |
| infinity | ahasenack: It's a bank holiday here, so I've not been working, but I'm keeping an eye on things. | 18:11 |
| infinity | Oh, it's possible that it's also a holiday for the GSA who said he'd do it Monday, not realising what day Monday was... | 18:12 |
| ahasenack | ./uaclient/util.py: platform_info["arch"] = uname.machine | 18:12 |
| ahasenack | :/ | 18:12 |
| infinity | Gross. | 18:12 |
| ahasenack | wonder how this is working since the contract server uses "amd64" | 18:13 |
| ahasenack | ah, no | 18:13 |
| infinity | They might rewrite it elsewhere. | 18:13 |
| ahasenack | the contract server is using x86_64 | 18:13 |
| infinity | Or that. Also gross. | 18:13 |
| infinity | I mean, I can see the urge to do that because x86_64 is how the modern world refers to amd64. | 18:14 |
| infinity | But that should STILL use dpkg arch, then rewrite to x86_64, if that's what they want. | 18:14 |
| infinity | Cause uname is never guaranteed to match userspace. | 18:14 |
| infinity | (i386 or armhf chroots on amd64 or arm64 hosts, just for starters, but there are any number of ways to make them not match) | 18:15 |
| ahasenack | yeah | 18:18 |
| infinity | os.system("dpkg --print-architecture | sed 's/amd64/x86_64/'") would likely get what they want. | 18:22 |
| infinity | Might also need to trim the newline. | 18:22 |
| infinity | Or, not os.system. os.popen. Derp. | 18:25 |
| infinity | os.popen("dpkg --print-architecture | sed 's/amd64/x86_64/'").read().rstrip() | 18:25 |
| infinity | ahasenack: ^-- I'd replace the uname.machine with that. | 18:26 |
| infinity | Maybe do the sed as a python regex instead for people who hate forking more than they need to, but whatever. | 18:26 |
| ahasenack | we can change this on either side, server or client | 18:26 |
| ahasenack | server is using a mix of old and new | 18:27 |
| ahasenack | server is using i386 and x86_64 | 18:27 |
| infinity | If the use of x86_64 was intentional to be "less confusing" to people who don't know what amd64 means, I could see that. | 18:27 |
| infinity | But yeah, if not, one could fix the server. | 18:27 |
| infinity | Client needs fixing either way though, so... | 18:27 |
| ahasenack | infinity: dpkg --print-architecture uses the first column of /usr/share/dpkg/cputable? | 18:42 |
| ahasenack | "<Debian name>" | 18:42 |
| ahasenack | hm, no armhf there | 18:42 |
| infinity | ahasenack: Trying to interpret how dpkg uses those tables isn't really a path to sanity. dpkg itself is the authority on its primary arch, don't reinvent that wheel. | 18:44 |
| ahasenack | I wasn't going to parse that, just checking which other names we might have wrong without booting up an instance in each one | 18:44 |
| infinity | ahasenack: 'rmadison coreutils' is always a good source of 'what dpkg arches do we have'. :) | 18:45 |
| ahasenack | ah, those names match --print-architecture? ok | 18:45 |
| infinity | ahasenack: If you want to know which ones will mismatch with uname, the answer is "most of them". | 18:45 |
| infinity | powerpc == ppc or ppc64, ppc64el == ppc64le, armhf == amrv7l, i386 == i686, arm64 == aarch64, s390x might actually match, I don't recall now. | 18:47 |
| infinity | But yeah, uname bad. | 18:47 |
| ahasenack | yeah, this need fixing | 18:48 |
| ahasenack | now it was just x86 that bit us | 18:48 |
| infinity | If we could go back in time and do it all over again, I suspect there are lots of people that would prefer dpkg arches (mostly) match kernel arches, but honestly, I think that would just muddy the waters further. | 18:52 |
| infinity | Since, (a) some kernels can run multiple ABIs, and (b) kernel and userspace are never guaranteed to match. | 18:52 |
| infinity | So, having almost all the dpkg arches mismatch is almost helpful. :P | 18:52 |
| infinity | Forces people to think a bit about which arch they're really interested in, kernel or userspace. | 18:53 |
| infinity | It would arguably be nice if there was some read-only file somewhere that just had the userspace arch in it, though, instead of having to fork a binary. | 18:55 |
| infinity | Multiarch complicates even that simple wish, though. | 18:55 |
| xnox | infinity: s390x matches | 18:59 |
| infinity | One of the few. :P | 19:02 |
| infinity | Possibly the only Ubuntu arch that matches, actually. | 19:02 |
| ahasenack | ppc64el also matches | 19:12 |
| === led_dark_2 is now known as led_dark_1 | ||
| infinity | ahasenack: No it doesn't. | 19:15 |
| ahasenack | I just checked uname -m and dpkg --print-architecture on a ppc64el instance | 19:15 |
| infinity | ahasenack: kernel arch is 'le', userspace is 'el'. | 19:15 |
| ahasenack | oh! | 19:15 |
| ahasenack | my eyes | 19:15 |
| ahasenack | oh man | 19:15 |
| ahasenack | w.t.<badford> | 19:15 |
| ahasenack | word even | 19:15 |
| infinity | BADFORD | 19:16 |
| ahasenack | :) | 19:16 |
| ahasenack | little endian, and... endian little? | 19:16 |
| infinity | Yeah, you can blame me (and Debian history) for that. | 19:16 |
| ahasenack | did they apply endianness twice? | 19:16 |
| infinity | It was a fun "joke" in Debian history when doing endian flips (I think mips might have been the first, but also arm later) where we had be on way and el the other. | 19:17 |
| infinity | I did ppc64el that way to match mipsel and armel. | 19:17 |
| infinity | But upstream chose ppc64le for the kernel, so here we are. | 19:17 |
| infinity | Again, don't really mind, the mismatch serves a strangely useful purpose. | 19:18 |
| ahasenack | haha | 19:18 |
| infinity | The original upstream kernels were just ppc64 (cause, really, they are), but Other Parties who love to use uname for evil purposes whined that it should be unique. | 19:20 |
| infinity | Fun side-note, you can endian-flip POWER8 and above at runtime. In the same address space. | 19:20 |
| infinity | It's mind-bending. | 19:20 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!