[06:20] andersk: on checking backlog, the test trigger questions of (my) late friday were all resolved right? [10:56] 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:57] vorlon, Package gdk-pixbuf-2.0 was not found in the pkg-config search path. [10:57] vorlon, it would probably make sense to stop uploading more of the same changes and figure out what's wrong/fix it before continuing [12:17] anybody wants to help me figuring out an autopkgtest regression? [12:17] 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:18] I did reproduce locally, even a kopanocore-search --help gives that "magic import" issue in python [12:18] and with strace I figured out probably why it fails: [12:18] [pid 3172] openat(AT_FDCWD, "/proc/self/fd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied) [12:18] and with pbuilder there is no such failure... [12:19] http://autopkgtest.ubuntu.com/packages/k/kopanocore/focal/amd64 [12:19] any idea about what might cause an AttributeError: /usr/bin/python3: undefined symbol: magic_open [12:22] this doesn't happen in Debian, so I suspect some autopkgtest infra "misconfiguration or similar" [12:23] [pid 3172] openat(AT_FDCWD, "/sbin/ldconfig", O_RDONLY) = -1 EACCES (Permission denied) [12:23] I would say "hey, I need root", but even after sudo su, it fails [12:24] and the test is "needs-root" [12:26] strange enough: [12:26] python3 /usr/sbin/kopano-search --help --> works [12:26] kopano-search --help --> doesn't work [12:29] /usr/sbin/kopano-search --help --> doesn't work [12:57] morning all o/ [12:57] 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:58] (s390x in this case) [13:01] 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:02] cool. tks xnox ! [13:02] as it's a partial removal, not a full src+all-debs+all-arches [13:02] I see [13:02] also [13:03] 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] no no [13:03] they have fixed things like that for us before, although with large latency [13:03] oh ok [13:03] I have a thread upstream showing [13:03] the problem [13:03] maintainer said big endian is a no go for now #) [13:03] alright, let me open the bug then. tku! [13:04] 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] well, it wont hurt telling them [13:04] I'll point out the upstream thread [13:04] and like s390x is available on travis [13:04] if they have no interest, they can close it [13:04] tah [13:06] https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1745155/comments/14 [13:06] Launchpad bug 1745155 in ocfs2-tools (Ubuntu Focal) "o2image fails on s390x" [Medium,In progress] [13:06] done [13:07] oh that thing [13:07] urgh [13:07] *cough* *cough* [13:07] * xnox reaches for cold medicine [13:07] lol === ricab is now known as ricab|lunch === jdstrand_ is now known as jdstrand === ricab|lunch is now known as ricab [15:59] seb128: the gdk-pixbuf log you pointed to is one for the version of gdk-pixbuf that didn't have the fix [16:02] vorlon, ah, right, the fixed version migrated now so I retried glib2.0, thx [16:02] vorlon, also I think gtk+2.0 lacks handling of the -u case that you fixed for others packages [16:03] ok, I'll have a look [16:03] 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:04] seb128: that was an early iteration of the package [16:04] s/package/patch/ [16:04] ah ok [16:04] so I guess it just need an update with what was used in other sources [16:04] I can do that if you want? [16:05] seb128: sure :) [16:05] k :) [16:24] 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:25] 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] seb128: do you have examples of ones outstanding that have installability issues? [16:25] vorlon, http://autopkgtest.ubuntu.com/packages/g/gspell/focal/i386 [16:26] ok I'll look [16:26] vorlon, http://autopkgtest.ubuntu.com/packages/libi/libical3/focal/i386 [16:26] seb128: btw there are a number of ftbfs in the packages I've uploaded, which I definitely didn't cause [16:26] dconf, pulseaudio, and now poppler [16:26] vorlon, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/v/vim/20191208_202208_f67e5@/log.gz [16:26] looks like you've fixed dconf already, thanks [16:26] vorlon, I fixed dconf today [16:26] right [16:27] I will fix pulseaudio, that's probably my fault [16:27] and can look to poppler [16:28] vorlon, http://autopkgtest.ubuntu.com/packages/libv/libvorbis/focal/i386 (installability) [16:28] 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:29] 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:30] k, thx [16:30] (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) [17:06] seb128: gspell> gobject-introspection is not cross-installable; I'll badtest it [17:06] vorlon, thx [17:58] 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] Launchpad bug 1790904 in simplestreams "Glance v2 required by newer versions of OpenStack" [Medium,Fix committed] [17:58] @freyes ^ fyi as well [17:58] Error: "freyes" is not a valid command. [17:59] and thedac ^.. i think thats it for the highlights [18:00] rafaeldtinoco: Hi, thanks. I'll mention this to coreycb as well for the UCA update. [18:01] tks a lot! [18:04] rafaeldtinoco, thanks for heads up ;-) [18:04] anytime! =) [18:47] rafaeldtinoco: thedac: thanks, we'll discuss more (refresh my memory at least) tomorrow with the team [18:48] 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] that is what I remember [18:49] rafaeldtinoco: ok thanks, that would make sense [18:49] cool [19:20] 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] I'm trying to determine if it's still necessary. It's part of our delta [20:01] ahasenack: https://fedoraproject.org/wiki/UnderstandingDSOLinkChange & https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed is the baground [20:01] ahasenack: one has to specify libraries in the right order with dependencies listed after something uses it. [20:02] hence i had to add freeipmi.la library to toolcommon [20:02] but also build common before libfreeipmi [20:02] *after [20:03] ahasenack: if you drop the patch, and it still builds, it means it is no longer needed [20:03] xnox: is that a good check then? [20:03] if it fails to build from source, it is still needed, and like should be upstream [20:03] drop && build test? [20:03] yes [20:03] ok, will try, thanks [20:03] ensure you do a full clean build [20:03] debian doesn't have it, and it seems to build fine there [20:04] maybe they had it once upon a time, and later dropped, I'll also check that [20:04] or they don't use -Wl,--as-needed [20:29] at the time, our toolchain was ahead and more strict than theirs [20:29] i don't know if they are same as us now or not [20:34] seb128: fwiw the vim autopkgtest failure was a one-off, no changes required [20:34] vorlon, ah, good to know, thx [20:34] seb128: and gspell, libical3 are both badtested; and I've fixed libvorbis and libtheora [20:35] vorlon, thanks! [20:35] xnox: it built, all arches: https://launchpad.net/~ahasenack/+archive/ubuntu/freeipmi-merge/+packages [20:35] vorlon, I will deal with all the .pc not found ones tomorrow [20:35] well, desktop ones at least [20:35] but I think that's where the main part of those are [20:39] 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:40] seb128: (i.e. do you know which of these are worth me looking at today) [20:41] vorlon, I'm going to do graphene libproxy libsecrect libsoup2.4 libwacom mir upower at least [20:42] vorlon, if you want to do at least the binding ones (libglib-perl and pyqt5) that would be nice [20:42] right, those are more likely to be untestable anyway :) [20:44] and later today I'll run statistics and send another email to ubuntu-devel to give an overview of the status [20:46] ahasenack: drop it! [20:46] vorlon, thx for those status updates emails btw, useful to know where we stand there [20:46] xnox: yay :) [20:50] 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] (blocking cheese) [20:50] (sorry, dconf) [20:51] 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] k [20:53] vorlon: what am i supposed to do with livecd-rootfs? how come it's not installable on i386? [20:53] in adt [20:54] i think it can become arch:all package [20:54] and depend on like qemu-utils:any and the like [20:54] or even qemu-utils:amd64 [20:54] no? [20:54] cause the only reason why it is arch:any is because it has a few missing dependencies on i386 [20:59] xnox: the livecd-rootfs package itself is installable, but the test dependencies may not be [21:00] vorlon: hm, don't think so [21:00] xnox: so, we need to figure out if those test deps should be annotated (:native), or such [21:00] xnox: https://people.canonical.com/~ubuntu-archive/proposed-migration/focal_uninst.txt livecd-rootfs is installable :) [21:00] http://autopkgtest.ubuntu.com/packages/livecd-rootfs/focal/i386 [21:00] vorlon: livecd-rootfs:i386 is not installable on an amd64 host [21:01] because it tries to like replace apt:amd64 with apt:i386 [21:01] no [21:01] well [21:01] ok yes [21:01] anyway [21:01] FAIL badpkg => means fails to install [21:02] i guess it should depend on "debootstrap:any"? [21:02] or like debootstrap:host => is that even a keyword?! [21:02] on i386 [21:02] can't [21:02] sure it can =) [21:02] debootstrap needs marked Multi-Arch: foreign [21:02] apt-utils needs marked Multi-Arch: foreign [21:02] urgh [21:02] can i have like local overrides?! =) [21:02] no [21:02] I don't think apt-utils is M-a foreign [21:02] -able [21:02] juliank: why not? [21:03] does it provide any interfaces that aren't exec()? [21:03] because I think apt-ftparchive has an architecture-dependent database format, so you can't switch it over [21:03] but not sure that counts [21:03] vorlon: i think we should move testing creating i386 things to amd64 arch autopkgtest, and like badtest livecd-rootfs on i386 [21:03] xnox: we should not move testing creating i386 things to amd64 arch autopkgtest [21:04] because that is also still not a valid test of how it will actually be used [21:04] the single use of livecd-rootfs in focal now is to build the launchpad-buildd chroots [21:04] which are built for i386 on i386 [21:04] but my autopkgtest vm is not that [21:04] correct [21:04] i should on amd64 host, start i386 lxd container, and then use livecd-rootfs:i386 there natively, no? [21:05] but a thing we should NOT do is do more work to craft a test which is irrelevant [21:05] start i386 lxd container> hhngh [21:05] what image are you going to use for the container [21:05] we can have i386 lxd worker? [21:05] the buildd i386 container from launchpad =) [21:06] launchpad-buildd one [21:06] 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] xnox: are those currently available in streams? [21:06] Odd_Bloke: community council? [21:08] 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] then the test, run, and build environments would be aligned [21:08] and we could reduce the set of sources we need to maintain for i386 [21:09] but that would be dependent on me demonstrating it's maintainable [21:09] and in the meantime we should just badtest livecd-rootfs on i386 [21:10] xnox: (the latter is done now) [21:15] 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] anyway, no urgency to change anything here [21:22] Maybe, idk [21:23] 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:24] well, ok [21:24] Ah, but that's the lib depends, i did not add the apt (=) depends specifically I think [21:24] 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] apt can also Breaks apt-utils (<< ${binary:Version}) [21:25] ugh [21:25] so [21:25] apt-utils Depends on apt like this, because apt ships the private library apt-utils uses [21:26] hence you can't do any multi-arching of it [21:27] 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:32] but that would put stronger requirements on apt Depends libapt-pkg than now [21:32] (= instead of >=) [22:35] vorlon: They're currently available in Launchpad, which is where they get consumed from [22:35] (i386 buildd lxd images) [23:49] cpaelzer: i did something naughty, but hey postgresql-common will migrate [23:50] vorlon: they were even mentioned during plenary in Vancouver =) [23:58] 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] xnox: ?