[06:20] <cpaelzer> andersk: on checking backlog, the test trigger questions of (my) late friday were all resolved right?
[10:56] <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:57] <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
[12:17] <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:18] <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:19] <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:22] <locutus_> this doesn't happen in Debian, so I suspect some autopkgtest infra "misconfiguration or similar"
[12:23] <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:24] <locutus_> and the test is "needs-root"
[12:26] <locutus_> strange enough:
[12:26] <locutus_> python3 /usr/sbin/kopano-search --help --> works
[12:26] <locutus_> kopano-search --help --> doesn't work
[12:29] <locutus_>  /usr/sbin/kopano-search --help --> doesn't work
[12:57] <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:58] <rafaeldtinoco> (s390x in this case)
[13:01] <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:02] <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:03] <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:04] <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:06] <rafaeldtinoco> https://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1745155/comments/14
[13:06] <rafaeldtinoco> done
[13:07] <xnox> oh that thing
[13:07] <xnox> urgh
[13:07] <xnox> *cough* *cough*
[13:07]  * xnox reaches for cold medicine
[13:07] <rafaeldtinoco> lol
[15:59] <vorlon> seb128: the gdk-pixbuf log you pointed to is one for the version of gdk-pixbuf that didn't have the fix
[16:02] <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:03] <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:04] <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:05] <vorlon> seb128: sure :)
[16:05] <seb128> k :)
[16:24] <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:25] <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:26] <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:27] <seb128> I will fix pulseaudio, that's probably my fault
[16:27] <seb128> and can look to poppler
[16:28] <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:29] <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:30] <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)
[17:06] <vorlon> seb128: gspell> gobject-introspection is not cross-installable; I'll badtest it
[17:06] <seb128> vorlon, thx
[17:58] <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] <rafaeldtinoco> @freyes ^ fyi as well
[17:58] <udevbot> Error: "freyes" is not a valid command.
[17:59] <rafaeldtinoco> and thedac ^.. i think thats it for the highlights
[18:00] <thedac> rafaeldtinoco: Hi, thanks. I'll mention this to coreycb as well for the UCA update.
[18:01] <rafaeldtinoco> tks a lot!
[18:04] <freyes> rafaeldtinoco, thanks for heads up ;-)
[18:04] <rafaeldtinoco> anytime! =)
[18:47] <coreycb> rafaeldtinoco: thedac: thanks, we'll discuss more (refresh my memory at least) tomorrow with the team
[18:48] <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:49] <coreycb> rafaeldtinoco: ok thanks, that would make sense
[18:49] <rafaeldtinoco> cool
[19:20] <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
[20:01] <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:02] <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:03] <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:04] <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:29] <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:34] <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:35] <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:39] <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:40] <vorlon> seb128: (i.e. do you know which of these are worth me looking at today)
[20:41] <seb128> vorlon, I'm going to do graphene libproxy libsecrect libsoup2.4 libwacom mir upower at least
[20:42] <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:44] <vorlon> and later today I'll run statistics and send another email to ubuntu-devel to give an overview of the status
[20:46] <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:50] <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:51] <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:53] <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:54] <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:59] <vorlon> xnox: the livecd-rootfs package itself is installable, but the test dependencies may not be
[21:00] <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:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:08] <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:09] <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:10] <vorlon> xnox: (the latter is done now)
[21:15] <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:22] <juliank> Maybe, idk
[21:23] <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:24] <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:25] <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:26] <juliank> hence you can't do any multi-arching of it
[21:27] <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:32] <juliank> but that would put stronger requirements on apt Depends libapt-pkg than now
[21:32] <juliank> (= instead of >=)
[22:35] <cjwatson> vorlon: They're currently available in Launchpad, which is where they get consumed from
[22:35] <cjwatson> (i386 buildd lxd images)
[23:49] <xnox> cpaelzer:  i did something naughty, but hey postgresql-common will migrate
[23:50] <xnox> vorlon:  they were even mentioned during plenary in Vancouver =)
[23:58] <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: ?