cpaelzer | andersk: on checking backlog, the test trigger questions of (my) late friday were all resolved right? | 06:20 |
---|---|---|
seb128 | vorlon, hey, your 'Make autopkgtests cross-test-friendly.' changes seem to have issues, to pick one https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/g/gdk-pixbuf/20191209_060703_5d3e2@/log.gz | 10:56 |
seb128 | vorlon, Package gdk-pixbuf-2.0 was not found in the pkg-config search path. | 10:57 |
seb128 | vorlon, it would probably make sense to stop uploading more of the same changes and figure out what's wrong/fix it before continuing | 10:57 |
locutus_ | anybody wants to help me figuring out an autopkgtest regression? | 12:17 |
locutus_ | basically: kopanocore is regressed in autopkgtests, but I can't figure how (it switched from python to python3, but this is only part of the issue) | 12:17 |
locutus_ | I did reproduce locally, even a kopanocore-search --help gives that "magic import" issue in python | 12:18 |
locutus_ | and with strace I figured out probably why it fails: | 12:18 |
locutus_ | [pid 3172] openat(AT_FDCWD, "/proc/self/fd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) | 12:18 |
locutus_ | and with pbuilder there is no such failure... | 12:18 |
locutus_ | http://autopkgtest.ubuntu.com/packages/k/kopanocore/focal/amd64 | 12:19 |
locutus_ | any idea about what might cause an AttributeError: /usr/bin/python3: undefined symbol: magic_open | 12:19 |
locutus_ | this doesn't happen in Debian, so I suspect some autopkgtest infra "misconfiguration or similar" | 12:22 |
locutus_ | [pid 3172] openat(AT_FDCWD, "/sbin/ldconfig", O_RDONLY) = -1 EACCES (Permission denied) | 12:23 |
locutus_ | I would say "hey, I need root", but even after sudo su, it fails | 12:23 |
locutus_ | and the test is "needs-root" | 12:24 |
locutus_ | strange enough: | 12:26 |
locutus_ | python3 /usr/sbin/kopano-search --help --> works | 12:26 |
locutus_ | kopano-search --help --> doesn't work | 12:26 |
locutus_ | /usr/sbin/kopano-search --help --> doesn't work | 12:29 |
rafaeldtinoco | morning all o/ | 12:57 |
rafaeldtinoco | I removed big endian architectures from ocfs2-tools (because it doesn't support) and excuses complain about missing build. What is the step that should be taken for this case ? | 12:57 |
rafaeldtinoco | (s390x in this case) | 12:58 |
xnox | rafaeldtinoco: open the bug against the package, with RM in the title, explain / ask to remove _binaries only_ on _certain arches_ and which suites (ie. focal-release focal-proposed) and subscribe ubuntu-archive team | 13:01 |
rafaeldtinoco | cool. tks xnox ! | 13:02 |
xnox | as it's a partial removal, not a full src+all-debs+all-arches | 13:02 |
rafaeldtinoco | I see | 13:02 |
xnox | also | 13:02 |
xnox | rafaeldtinoco: open a bug report against ocfs2-tools and ping to jfh to reverse proxy to IBM and ask them to fix it upstream for big endian? | 13:03 |
rafaeldtinoco | no no | 13:03 |
xnox | they have fixed things like that for us before, although with large latency | 13:03 |
xnox | oh ok | 13:03 |
rafaeldtinoco | I have a thread upstream showing | 13:03 |
rafaeldtinoco | the problem | 13:03 |
rafaeldtinoco | maintainer said big endian is a no go for now #) | 13:03 |
rafaeldtinoco | alright, let me open the bug then. tku! | 13:03 |
xnox | well, we have pointed out things like that to IBM in the past, and sometimes they cared and send an squad of programmers to fix an upstream. | 13:04 |
rafaeldtinoco | well, it wont hurt telling them | 13:04 |
rafaeldtinoco | I'll point out the upstream thread | 13:04 |
xnox | and like s390x is available on travis | 13:04 |
rafaeldtinoco | if they have no interest, they can close it | 13:04 |
xnox | tah | 13:04 |
rafaeldtinoco | https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1745155/comments/14 | 13:06 |
ubottu | Launchpad bug 1745155 in ocfs2-tools (Ubuntu Focal) "o2image fails on s390x" [Medium,In progress] | 13:06 |
rafaeldtinoco | done | 13:06 |
xnox | oh that thing | 13:07 |
xnox | urgh | 13:07 |
xnox | *cough* *cough* | 13:07 |
* xnox reaches for cold medicine | 13:07 | |
rafaeldtinoco | lol | 13:07 |
=== ricab is now known as ricab|lunch | ||
=== jdstrand_ is now known as jdstrand | ||
=== ricab|lunch is now known as ricab | ||
vorlon | seb128: the gdk-pixbuf log you pointed to is one for the version of gdk-pixbuf that didn't have the fix | 15:59 |
seb128 | vorlon, ah, right, the fixed version migrated now so I retried glib2.0, thx | 16:02 |
seb128 | vorlon, also I think gtk+2.0 lacks handling of the -u case that you fixed for others packages | 16:02 |
vorlon | ok, I'll have a look | 16:03 |
seb128 | vorlon, thx, I looked at fixing it but I was unsure why you used DEB_HOST_MULTIARCH there vs $DEB_HOST_GNU_TYPE in other packages, and also why you did an export PKG_CONFIG_PATH only in this one | 16:03 |
vorlon | seb128: that was an early iteration of the package | 16:04 |
vorlon | s/package/patch/ | 16:04 |
seb128 | ah ok | 16:04 |
seb128 | so I guess it just need an update with what was used in other sources | 16:04 |
seb128 | I can do that if you want? | 16:04 |
vorlon | seb128: sure :) | 16:05 |
seb128 | k :) | 16:05 |
seb128 | vorlon, I can have a look at doing similar changes to the other desktop ones from the proposed report (but tomorrow at this point) if you want, I can also directly push to salsa while doing so | 16:24 |
seb128 | vorlon, feel free to let desktopish .pc ones for me but I would welcome help to resolve the ones which have to do with installability issues | 16:25 |
vorlon | seb128: do you have examples of ones outstanding that have installability issues? | 16:25 |
seb128 | vorlon, http://autopkgtest.ubuntu.com/packages/g/gspell/focal/i386 | 16:25 |
vorlon | ok I'll look | 16:26 |
seb128 | vorlon, http://autopkgtest.ubuntu.com/packages/libi/libical3/focal/i386 | 16:26 |
vorlon | seb128: btw there are a number of ftbfs in the packages I've uploaded, which I definitely didn't cause | 16:26 |
vorlon | dconf, pulseaudio, and now poppler | 16:26 |
seb128 | vorlon, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/v/vim/20191208_202208_f67e5@/log.gz | 16:26 |
vorlon | looks like you've fixed dconf already, thanks | 16:26 |
seb128 | vorlon, I fixed dconf today | 16:26 |
seb128 | right | 16:26 |
seb128 | I will fix pulseaudio, that's probably my fault | 16:27 |
seb128 | and can look to poppler | 16:27 |
seb128 | vorlon, http://autopkgtest.ubuntu.com/packages/libv/libvorbis/focal/i386 (installability) | 16:28 |
seb128 | vorlon, http://autopkgtest.ubuntu.com/packages/libt/libtheora/focal/i386 looks like a valgrind/multiarch problem, unsure what's the right way to fix that one? | 16:28 |
vorlon | seb128: I'm just checking on that now, I think the easiest way is to just use the i386 valgrind package instead of the amd64 one | 16:29 |
seb128 | k, thx | 16:30 |
vorlon | (pulling in the amd64 one was a blind change on my part, I couldn't really test this without first getting a libtheora-doc built that had Multi-Arch: foreign) | 16:30 |
vorlon | seb128: gspell> gobject-introspection is not cross-installable; I'll badtest it | 17:06 |
seb128 | vorlon, thx | 17:06 |
rafaeldtinoco | jamespage: Fyio, bionic simplestreams package has finally been released (https://bugs.launchpad.net/bugs/1790904). Based in our last talks, now would be the time to include it in Xenial cloud-archive (so it can benefit from this fix). Should I do something else here to queue this up for u ? | 17:58 |
ubottu | Launchpad bug 1790904 in simplestreams "Glance v2 required by newer versions of OpenStack" [Medium,Fix committed] | 17:58 |
rafaeldtinoco | @freyes ^ fyi as well | 17:58 |
udevbot | Error: "freyes" is not a valid command. | 17:58 |
rafaeldtinoco | and thedac ^.. i think thats it for the highlights | 17:59 |
thedac | rafaeldtinoco: Hi, thanks. I'll mention this to coreycb as well for the UCA update. | 18:00 |
rafaeldtinoco | tks a lot! | 18:01 |
freyes | rafaeldtinoco, thanks for heads up ;-) | 18:04 |
rafaeldtinoco | anytime! =) | 18:04 |
coreycb | rafaeldtinoco: thedac: thanks, we'll discuss more (refresh my memory at least) tomorrow with the team | 18:47 |
rafaeldtinoco | coreycb: alright, ive prepared this fix for xenial (keystone v2 auth) but we all agreed this should go to bionic instead (with a single fix from thedac) and serve xenial from the backport from cloud-archive (bionic) | 18:48 |
rafaeldtinoco | that is what I remember | 18:48 |
coreycb | rafaeldtinoco: ok thanks, that would make sense | 18:49 |
rafaeldtinoco | cool | 18:49 |
ahasenack | xnox: hi, if still around, do you remember the story behind this linking patch? https://git.launchpad.net/ubuntu/+source/freeipmi/commit/?id=8e5fd294968b07d9141e3f1049461383264f25c6 | 19:20 |
ahasenack | I'm trying to determine if it's still necessary. It's part of our delta | 19:20 |
xnox | ahasenack: https://fedoraproject.org/wiki/UnderstandingDSOLinkChange & https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed is the baground | 20:01 |
xnox | ahasenack: one has to specify libraries in the right order with dependencies listed after something uses it. | 20:01 |
xnox | hence i had to add freeipmi.la library to toolcommon | 20:02 |
xnox | but also build common before libfreeipmi | 20:02 |
xnox | *after | 20:02 |
xnox | ahasenack: if you drop the patch, and it still builds, it means it is no longer needed | 20:03 |
ahasenack | xnox: is that a good check then? | 20:03 |
xnox | if it fails to build from source, it is still needed, and like should be upstream | 20:03 |
ahasenack | drop && build test? | 20:03 |
xnox | yes | 20:03 |
ahasenack | ok, will try, thanks | 20:03 |
xnox | ensure you do a full clean build | 20:03 |
ahasenack | debian doesn't have it, and it seems to build fine there | 20:03 |
ahasenack | maybe they had it once upon a time, and later dropped, I'll also check that | 20:04 |
ahasenack | or they don't use -Wl,--as-needed | 20:04 |
xnox | at the time, our toolchain was ahead and more strict than theirs | 20:29 |
xnox | i don't know if they are same as us now or not | 20:29 |
vorlon | seb128: fwiw the vim autopkgtest failure was a one-off, no changes required | 20:34 |
seb128 | vorlon, ah, good to know, thx | 20:34 |
vorlon | seb128: and gspell, libical3 are both badtested; and I've fixed libvorbis and libtheora | 20:34 |
seb128 | vorlon, thanks! | 20:35 |
ahasenack | xnox: it built, all arches: https://launchpad.net/~ahasenack/+archive/ubuntu/freeipmi-merge/+packages | 20:35 |
seb128 | vorlon, I will deal with all the .pc not found ones tomorrow | 20:35 |
seb128 | well, desktop ones at least | 20:35 |
seb128 | but I think that's where the main part of those are | 20:35 |
vorlon | seb128: which of these are currently on your radar for desktop?: graphene json-glib libglib-perl libproxy libsdl2 libsecret libsoup2.4 libssh libwacom mir pyqt5 raqm umockdev upower | 20:39 |
vorlon | seb128: (i.e. do you know which of these are worth me looking at today) | 20:40 |
seb128 | vorlon, I'm going to do graphene libproxy libsecrect libsoup2.4 libwacom mir upower at least | 20:41 |
seb128 | vorlon, if you want to do at least the binding ones (libglib-perl and pyqt5) that would be nice | 20:42 |
vorlon | right, those are more likely to be untestable anyway :) | 20:42 |
vorlon | and later today I'll run statistics and send another email to ubuntu-devel to give an overview of the status | 20:44 |
xnox | ahasenack: drop it! | 20:46 |
seb128 | vorlon, thx for those status updates emails btw, useful to know where we stand there | 20:46 |
ahasenack | xnox: yay :) | 20:46 |
seb128 | vorlon, ah, other installability ones http://autopkgtest.ubuntu.com/packages/c/cheese/focal/i386 , http://autopkgtest.ubuntu.com/packages/g/gnome-shell-pomodoro/focal/i386 http://autopkgtest.ubuntu.com/packages/g/gthumb/focal/i386 | 20:50 |
seb128 | (blocking cheese) | 20:50 |
seb128 | (sorry, dconf) | 20:50 |
vorlon | seb128: right, those are all uninstallable because the packages in question have had their i386 binaries removed - I've badtested, and the next time britney will correctly skip requesting tests for these (this is the britney bug I was just talking with xnox about on #ubuntu-release) | 20:51 |
seb128 | k | 20:51 |
xnox | vorlon: what am i supposed to do with livecd-rootfs? how come it's not installable on i386? | 20:53 |
xnox | in adt | 20:53 |
xnox | i think it can become arch:all package | 20:54 |
xnox | and depend on like qemu-utils:any and the like | 20:54 |
xnox | or even qemu-utils:amd64 | 20:54 |
xnox | no? | 20:54 |
xnox | cause the only reason why it is arch:any is because it has a few missing dependencies on i386 | 20:54 |
vorlon | xnox: the livecd-rootfs package itself is installable, but the test dependencies may not be | 20:59 |
xnox | vorlon: hm, don't think so | 21:00 |
vorlon | xnox: so, we need to figure out if those test deps should be annotated (:native), or such | 21:00 |
vorlon | xnox: https://people.canonical.com/~ubuntu-archive/proposed-migration/focal_uninst.txt livecd-rootfs is installable :) | 21:00 |
xnox | http://autopkgtest.ubuntu.com/packages/livecd-rootfs/focal/i386 | 21:00 |
xnox | vorlon: livecd-rootfs:i386 is not installable on an amd64 host | 21:00 |
xnox | because it tries to like replace apt:amd64 with apt:i386 | 21:01 |
vorlon | no | 21:01 |
vorlon | well | 21:01 |
vorlon | ok yes | 21:01 |
vorlon | anyway | 21:01 |
xnox | FAIL badpkg => means fails to install | 21:01 |
xnox | i guess it should depend on "debootstrap:any"? | 21:02 |
xnox | or like debootstrap:host => is that even a keyword?! | 21:02 |
xnox | on i386 | 21:02 |
vorlon | can't | 21:02 |
xnox | sure it can =) | 21:02 |
vorlon | debootstrap needs marked Multi-Arch: foreign | 21:02 |
vorlon | apt-utils needs marked Multi-Arch: foreign | 21:02 |
xnox | urgh | 21:02 |
xnox | can i have like local overrides?! =) | 21:02 |
vorlon | no | 21:02 |
juliank | I don't think apt-utils is M-a foreign | 21:02 |
juliank | -able | 21:02 |
vorlon | juliank: why not? | 21:02 |
vorlon | does it provide any interfaces that aren't exec()? | 21:03 |
juliank | because I think apt-ftparchive has an architecture-dependent database format, so you can't switch it over | 21:03 |
juliank | but not sure that counts | 21:03 |
xnox | vorlon: i think we should move testing creating i386 things to amd64 arch autopkgtest, and like badtest livecd-rootfs on i386 | 21:03 |
vorlon | xnox: we should not move testing creating i386 things to amd64 arch autopkgtest | 21:03 |
vorlon | because that is also still not a valid test of how it will actually be used | 21:04 |
vorlon | the single use of livecd-rootfs in focal now is to build the launchpad-buildd chroots | 21:04 |
vorlon | which are built for i386 on i386 | 21:04 |
xnox | but my autopkgtest vm is not that | 21:04 |
vorlon | correct | 21:04 |
xnox | i should on amd64 host, start i386 lxd container, and then use livecd-rootfs:i386 there natively, no? | 21:04 |
vorlon | but a thing we should NOT do is do more work to craft a test which is irrelevant | 21:05 |
vorlon | start i386 lxd container> hhngh | 21:05 |
vorlon | what image are you going to use for the container | 21:05 |
xnox | we can have i386 lxd worker? | 21:05 |
xnox | the buildd i386 container from launchpad =) | 21:05 |
xnox | launchpad-buildd one | 21:06 |
Odd_Bloke | There are currently some people in #ubuntu-meeting hoping for a LoCo council meeting that hasn't happened the last couple of times it was meant to. Is there anyone I can direct them to to work out what's going on with that? | 21:06 |
vorlon | xnox: are those currently available in streams? | 21:06 |
vorlon | Odd_Bloke: community council? | 21:06 |
vorlon | xnox: tbh I'd much rather do a round two of this that moves the i386 package builds in Launchpad to i386-on-amd64 cross | 21:08 |
vorlon | then the test, run, and build environments would be aligned | 21:08 |
vorlon | and we could reduce the set of sources we need to maintain for i386 | 21:08 |
vorlon | but that would be dependent on me demonstrating it's maintainable | 21:09 |
vorlon | and in the meantime we should just badtest livecd-rootfs on i386 | 21:09 |
vorlon | xnox: (the latter is done now) | 21:10 |
vorlon | juliank: fwiw if you consider the apt-utils not interchangeable across archs, then Multi-Arch: allowed might be the right answer. Or, does apt-utils need this versioned dependency on apt? | 21:15 |
vorlon | anyway, no urgency to change anything here | 21:15 |
juliank | Maybe, idk | 21:22 |
juliank | vorlon: The depends I changed so that if you do apt install apt, it upgrades apt, apt-utils, and the libs, to avoid issues | 21:23 |
vorlon | well, ok | 21:24 |
juliank | Ah, but that's the lib depends, i did not add the apt (=) depends specifically I think | 21:24 |
vorlon | juliank: if it only had a strict versioned dep on the lib, it would hopefully still work, and then you could have apt and apt-utils from different archs as needed | 21:24 |
juliank | apt can also Breaks apt-utils (<< ${binary:Version}) | 21:24 |
juliank | ugh | 21:25 |
juliank | so | 21:25 |
juliank | apt-utils Depends on apt like this, because apt ships the private library apt-utils uses | 21:25 |
juliank | hence you can't do any multi-arching of it | 21:26 |
juliank | Oh, I mean, we could move libapt-private.so.0 to libapt-private.so.5.90 I guess and move it to libapt-pkg5.90 | 21:27 |
juliank | but that would put stronger requirements on apt Depends libapt-pkg than now | 21:32 |
juliank | (= instead of >=) | 21:32 |
cjwatson | vorlon: They're currently available in Launchpad, which is where they get consumed from | 22:35 |
cjwatson | (i386 buildd lxd images) | 22:35 |
xnox | cpaelzer: i did something naughty, but hey postgresql-common will migrate | 23:49 |
xnox | vorlon: they were even mentioned during plenary in Vancouver =) | 23:50 |
vorlon | cjwatson: sure, I still think it would be rather baroque to have the livecd-rootfs autopkgtest pull the tarballs from launchpad to feed to lxd to test the i386 build of the launchpad-buildd chroot | 23:58 |
vorlon | xnox: ? | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!