/srv/irclogs.ubuntu.com/2019/12/09/#ubuntu-devel.txt

cpaelzerandersk: on checking backlog, the test trigger questions of (my) late friday were all resolved right?06:20
seb128vorlon, 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.gz10:56
seb128vorlon, Package gdk-pixbuf-2.0 was not found in the pkg-config search path.10:57
seb128vorlon, it would probably make sense to stop uploading more of the same changes and figure out what's wrong/fix it before continuing10: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 python12: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/amd6412:19
locutus_any idea about what might cause an AttributeError: /usr/bin/python3: undefined symbol: magic_open12: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 fails12:23
locutus_and the test is "needs-root"12:24
locutus_strange enough:12:26
locutus_python3 /usr/sbin/kopano-search --help --> works12:26
locutus_kopano-search --help --> doesn't work12:26
locutus_ /usr/sbin/kopano-search --help --> doesn't work12:29
rafaeldtinocomorning all o/12:57
rafaeldtinocoI 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
xnoxrafaeldtinoco:  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 team13:01
rafaeldtinococool. tks xnox !13:02
xnoxas it's a partial removal, not a full src+all-debs+all-arches13:02
rafaeldtinocoI see13:02
xnoxalso13:02
xnoxrafaeldtinoco:  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
rafaeldtinocono no13:03
xnoxthey have fixed things like that for us before, although with large latency13:03
xnoxoh ok13:03
rafaeldtinocoI have a thread upstream showing13:03
rafaeldtinocothe problem13:03
rafaeldtinocomaintainer said big endian is a no go for now #)13:03
rafaeldtinocoalright, let me open the bug then. tku!13:03
xnoxwell, 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
rafaeldtinocowell, it wont hurt telling them13:04
rafaeldtinocoI'll point out the upstream thread13:04
xnoxand like s390x is available on travis13:04
rafaeldtinocoif they have no interest, they can close it13:04
xnoxtah13:04
rafaeldtinocohttps://bugs.launchpad.net/ubuntu/+source/ocfs2-tools/+bug/1745155/comments/1413:06
ubottuLaunchpad bug 1745155 in ocfs2-tools (Ubuntu Focal) "o2image fails on s390x" [Medium,In progress]13:06
rafaeldtinocodone13:06
xnoxoh that thing13:07
xnoxurgh13:07
xnox*cough* *cough*13:07
* xnox reaches for cold medicine13:07
rafaeldtinocolol13:07
=== ricab is now known as ricab|lunch
=== jdstrand_ is now known as jdstrand
=== ricab|lunch is now known as ricab
vorlonseb128: the gdk-pixbuf log you pointed to is one for the version of gdk-pixbuf that didn't have the fix15:59
seb128vorlon, ah, right, the fixed version migrated now so I retried glib2.0, thx16:02
seb128vorlon, also I think gtk+2.0 lacks handling of the -u case that you fixed for others packages16:02
vorlonok, I'll have a look16:03
seb128vorlon, 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 one16:03
vorlonseb128: that was an early iteration of the package16:04
vorlons/package/patch/16:04
seb128ah ok16:04
seb128so I guess it just need an update with what was used in other sources16:04
seb128I can do that if you want?16:04
vorlonseb128: sure :)16:05
seb128k :)16:05
seb128vorlon, 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 so16:24
seb128vorlon, feel free to let desktopish .pc ones for me but I would welcome help to resolve the ones which have to do with installability issues16:25
vorlonseb128: do you have examples of ones outstanding that have installability issues?16:25
seb128vorlon, http://autopkgtest.ubuntu.com/packages/g/gspell/focal/i38616:25
vorlonok I'll look16:26
seb128vorlon, http://autopkgtest.ubuntu.com/packages/libi/libical3/focal/i38616:26
vorlonseb128: btw there are a number of ftbfs in the packages I've uploaded, which I definitely didn't cause16:26
vorlondconf, pulseaudio, and now poppler16:26
seb128vorlon, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/v/vim/20191208_202208_f67e5@/log.gz16:26
vorlonlooks like you've fixed dconf already, thanks16:26
seb128vorlon, I fixed dconf today16:26
seb128right16:26
seb128I will fix pulseaudio, that's probably my fault16:27
seb128and can look to poppler16:27
seb128vorlon, http://autopkgtest.ubuntu.com/packages/libv/libvorbis/focal/i386 (installability)16:28
seb128vorlon, 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
vorlonseb128: I'm just checking on that now, I think the easiest way is to just use the i386 valgrind package instead of the amd64 one16:29
seb128k, thx16: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
vorlonseb128: gspell> gobject-introspection is not cross-installable; I'll badtest it17:06
seb128vorlon, thx17:06
rafaeldtinocojamespage: 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
ubottuLaunchpad bug 1790904 in simplestreams "Glance v2 required by newer versions of OpenStack" [Medium,Fix committed]17:58
rafaeldtinoco@freyes ^ fyi as well17:58
udevbotError: "freyes" is not a valid command.17:58
rafaeldtinocoand thedac ^.. i think thats it for the highlights17:59
thedacrafaeldtinoco: Hi, thanks. I'll mention this to coreycb as well for the UCA update.18:00
rafaeldtinocotks a lot!18:01
freyesrafaeldtinoco, thanks for heads up ;-)18:04
rafaeldtinocoanytime! =)18:04
coreycbrafaeldtinoco: thedac: thanks, we'll discuss more (refresh my memory at least) tomorrow with the team18:47
rafaeldtinococoreycb: 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
rafaeldtinocothat is what I remember18:48
coreycbrafaeldtinoco: ok thanks, that would make sense18:49
rafaeldtinococool18:49
ahasenackxnox: hi, if still around, do you remember the story behind this linking patch? https://git.launchpad.net/ubuntu/+source/freeipmi/commit/?id=8e5fd294968b07d9141e3f1049461383264f25c619:20
ahasenackI'm trying to determine if it's still necessary. It's part of our delta19:20
xnoxahasenack:  https://fedoraproject.org/wiki/UnderstandingDSOLinkChange & https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-Wl.2C--as-needed is the baground20:01
xnoxahasenack:  one has to specify libraries in the right order with dependencies listed after something uses it.20:01
xnoxhence i had to add freeipmi.la library to toolcommon20:02
xnoxbut also build common before libfreeipmi20:02
xnox*after20:02
xnoxahasenack:  if you drop the patch, and it still builds, it means it is no longer needed20:03
ahasenackxnox: is that a good check then?20:03
xnoxif it fails to build from source, it is still needed, and like should be upstream20:03
ahasenackdrop && build test?20:03
xnoxyes20:03
ahasenackok, will try, thanks20:03
xnoxensure you do a full clean build20:03
ahasenackdebian doesn't have it, and it seems to build fine there20:03
ahasenackmaybe they had it once upon a time, and later dropped, I'll also check that20:04
ahasenackor they don't use -Wl,--as-needed20:04
xnoxat the time, our toolchain was ahead and more strict than theirs20:29
xnoxi don't know if they are same as us now or not20:29
vorlonseb128: fwiw the vim autopkgtest failure was a one-off, no changes required20:34
seb128vorlon, ah, good to know, thx20:34
vorlonseb128: and gspell, libical3 are both badtested; and I've fixed libvorbis and libtheora20:34
seb128vorlon, thanks!20:35
ahasenackxnox: it built, all arches: https://launchpad.net/~ahasenack/+archive/ubuntu/freeipmi-merge/+packages20:35
seb128vorlon, I will deal with all the .pc not found ones tomorrow20:35
seb128well, desktop ones at least20:35
seb128but I think that's where the main part of those are20:35
vorlonseb128: 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 upower20:39
vorlonseb128: (i.e. do you know which of these are worth me looking at today)20:40
seb128vorlon, I'm going to do graphene libproxy libsecrect libsoup2.4 libwacom mir upower at least20:41
seb128vorlon, if you want to do at least the binding ones (libglib-perl and pyqt5) that would be nice20:42
vorlonright, those are more likely to be untestable anyway :)20:42
vorlonand later today I'll run statistics and send another email to ubuntu-devel to give an overview of the status20:44
xnoxahasenack:  drop it!20:46
seb128vorlon, thx for those status updates emails btw, useful to know where we stand there20:46
ahasenackxnox: yay :)20:46
seb128vorlon, 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/i38620:50
seb128(blocking cheese)20:50
seb128(sorry, dconf)20:50
vorlonseb128: 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
seb128k20:51
xnoxvorlon:  what am i supposed to do with livecd-rootfs? how come it's not installable on i386?20:53
xnoxin adt20:53
xnoxi think it can become arch:all package20:54
xnoxand depend on like qemu-utils:any and the like20:54
xnoxor even qemu-utils:amd6420:54
xnoxno?20:54
xnoxcause the only reason why it is arch:any is because it has a few missing dependencies on i38620:54
vorlonxnox: the livecd-rootfs package itself is installable, but the test dependencies may not be20:59
xnoxvorlon:  hm, don't think so21:00
vorlonxnox: so, we need to figure out if those test deps should be annotated (:native), or such21:00
vorlonxnox: https://people.canonical.com/~ubuntu-archive/proposed-migration/focal_uninst.txt livecd-rootfs is installable :)21:00
xnoxhttp://autopkgtest.ubuntu.com/packages/livecd-rootfs/focal/i38621:00
xnoxvorlon:  livecd-rootfs:i386 is not installable on an amd64 host21:00
xnoxbecause it tries to like replace apt:amd64 with apt:i38621:01
vorlonno21:01
vorlonwell21:01
vorlonok yes21:01
vorlonanyway21:01
xnoxFAIL badpkg => means fails to install21:01
xnoxi guess it should depend on "debootstrap:any"?21:02
xnoxor like debootstrap:host => is that even a keyword?!21:02
xnoxon i38621:02
vorloncan't21:02
xnoxsure it can =)21:02
vorlondebootstrap needs marked Multi-Arch: foreign21:02
vorlonapt-utils needs marked Multi-Arch: foreign21:02
xnoxurgh21:02
xnoxcan i have like local overrides?! =)21:02
vorlonno21:02
juliankI don't think apt-utils is M-a foreign21:02
juliank-able21:02
vorlonjuliank: why not?21:02
vorlondoes it provide any interfaces that aren't exec()?21:03
juliankbecause I think apt-ftparchive has an architecture-dependent database format, so you can't switch it over21:03
juliankbut not sure that counts21:03
xnoxvorlon:  i think we should move testing creating i386 things to amd64 arch autopkgtest, and like badtest livecd-rootfs on i38621:03
vorlonxnox: we should not move testing creating i386 things to amd64 arch autopkgtest21:03
vorlonbecause that is also still not a valid test of how it will actually be used21:04
vorlonthe single use of livecd-rootfs in focal now is to build the launchpad-buildd chroots21:04
vorlonwhich are built for i386 on i38621:04
xnoxbut my autopkgtest vm is not that21:04
vorloncorrect21:04
xnoxi should on amd64 host, start i386 lxd container, and then use livecd-rootfs:i386 there natively, no?21:04
vorlonbut a thing we should NOT do is do more work to craft a test which is irrelevant21:05
vorlonstart i386 lxd container> hhngh21:05
vorlonwhat image are you going to use for the container21:05
xnoxwe can have i386 lxd worker?21:05
xnoxthe buildd i386 container from launchpad =)21:05
xnoxlaunchpad-buildd one21:06
Odd_BlokeThere 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
vorlonxnox: are those currently available in streams?21:06
vorlonOdd_Bloke: community council?21:06
vorlonxnox: tbh I'd much rather do a round two of this that moves the i386 package builds in Launchpad to i386-on-amd64 cross21:08
vorlonthen the test, run, and build environments would be aligned21:08
vorlonand we could reduce the set of sources we need to maintain for i38621:08
vorlonbut that would be dependent on me demonstrating it's maintainable21:09
vorlonand in the meantime we should just badtest livecd-rootfs on i38621:09
vorlonxnox: (the latter is done now)21:10
vorlonjuliank: 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
vorlonanyway, no urgency to change anything here21:15
juliankMaybe, idk21:22
juliankvorlon: The depends I changed so that if you do apt install apt, it upgrades apt, apt-utils, and the libs, to avoid issues21:23
vorlonwell, ok21:24
juliankAh, but that's the lib depends, i did not add the apt (=) depends specifically I think21:24
vorlonjuliank: 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 needed21:24
juliankapt can also Breaks apt-utils (<< ${binary:Version})21:24
juliankugh21:25
juliankso21:25
juliankapt-utils Depends on apt like this, because apt ships the private library apt-utils uses21:25
juliankhence you can't do any multi-arching of it21:26
juliankOh, I mean, we could move libapt-private.so.0 to libapt-private.so.5.90 I guess and move it to libapt-pkg5.9021:27
juliankbut that would put stronger requirements on apt Depends libapt-pkg than now21:32
juliank(= instead of >=)21:32
cjwatsonvorlon: They're currently available in Launchpad, which is where they get consumed from22:35
cjwatson(i386 buildd lxd images)22:35
xnoxcpaelzer:  i did something naughty, but hey postgresql-common will migrate23:49
xnoxvorlon:  they were even mentioned during plenary in Vancouver =)23:50
vorloncjwatson: 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 chroot23:58
vorlonxnox: ?23:58

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!