[07:40] <cpaelzer> @pilot in
[09:04] <Laney> slangasek: nacc: Not sure what you're talking about?
[09:05] <Laney> I pointed out the historical change that gives rise to this failure --- what's up?
[11:14] <javier4>  I setup a chroot to crosscompile a package in armhf for Ubuntu-Touch. Inside the cage I ran apt-get build-dep wpa to satisfy the deps needed by my package, but the system installed them all in amd64 instead than armhf. Why?
[11:35] <javier4> ok. As usual: look for a solution for 24 hours, give up and decide to ask on irc, find the solution after 10 minutes...
[11:36] <Unit193> qemu-debootstrap?  pbuilder works with it.
[12:01] <cpaelzer> javier4: was that just like "--build=amd64 --host=armhf" args?
[12:11] <mdeslaur> nacc: re: php, thanks
[12:20] <javier4> cpaelzer: no, it was just needed to pass -aarmhf to apt-get build-dep. But, even now that dependencies are correctk satisfied I keep getting the same error
[12:21] <javier4> sbuild -A -d vivid-amd64-armhf --host armhf wpa_2.3-1+deb8u4.dsc
[12:21] <javier4> https://www.irccloud.com/pastebin/DEMPiUvh/
[12:22] <javier4> root@UbuBox:/home/Ubuntu/javier#  find /var/lib/schroot/chroots/vivid-amd64-armhf -name *libpcsclite.pc
[12:22] <javier4> /var/lib/schroot/chroots/vivid-amd64-armhf/usr/lib/arm-linux-gnueabihf/pkgconfig/libpcsclite.pc
[12:25] <cpaelzer> javier4: testing ...
[12:31] <cpaelzer> javier4: I had no vivid around, so I just tried to cross build latest zesty the way I sometimes do - I see similar issues but with Package libnl-3.0
[13:53] <javier4> Do you think there's a better channel where I can ask for this kind of help?
[14:08] <cpaelzer> javier4: you are at the tight spot
[14:08] <cpaelzer> uh
[14:08] <cpaelzer> right I wanted to say
[14:10] <cpaelzer> javier4: maybe summarize how you setup your sbuild and the command you use, put it to a pastebin and link it here
[14:10] <cpaelzer> javier4: with the question being less specific like "failing to cross build wpa .deb for arm64"
[14:10] <cpaelzer> javier4: also compiling for vivid might always raise questions, so you might explain why right away
[14:12] <cpaelzer> javier4: also the version you are building is from debian, are you trying to backport that to vivid?
[14:19]  * javier4 It's a bit more complex: I'm trying to port Ubuntu-Touch to another device. This device is Mediatek based, and in its Android source tree there's a mtk-customized version of wpa based on the 2.3 one. I'm tryng to build mtk-wpa source for Vivid (actual ub-touch stable), that instead use 2.1, upgraded to 2.4 through Stable Phone Overlay PPA. That's why I had
[14:19]  * javier4 to use the debian one as a base.
[14:40] <cpaelzer> javier4: I see, sorry that I'm not the cross build master you need :-/
[14:44] <javier4> cpaelzer: you've already been helpful. Thanks for your time. :)
[14:52]  * javier4 I realized that the problem must be about pkg-config dealing with multi-arch. Strange that's not configured to this by default.
[15:33] <cpaelzer> @pilot out
[15:51] <nacc> Laney: nm, I probably mis-spoke in referring to your contribution to the discussion; it's resolved now (I think)
[15:51] <nacc> mdeslaur: np, I got confirmation from the user overnight, will upload today
[15:52] <Laney> nacc: Ok, I was worried I was being accused of giving bad advice. :)
[15:54] <nacc> Laney: not at all, and I apologize if that's how I ended up characterizing it :)
[16:11] <nacc> rbasak: have maybe a few minutes (here) after the meeting?
[16:11] <bdmurray> cpaelzer: This report might be helpful if you run out of things to sponsor https://launchpad.net/~ubuntu-server/+patches
[16:12] <bdmurray> cpaelzer: those are any bugs w/ a patch attachment while the sponsoring report is bugs w/ ubuntu-sponsors subscribed
[16:12] <nacc> bdmurray: handy! thanks!
[16:12] <cpaelzer> bdmurray: thanks, can be really useful
[16:13] <bdmurray> no problem, that report isn't well advertised
[16:17] <tsimonq2> cpaelzer: <3 thanks for doing patch pilot, I appreciate some sort of sign that it's still going! :)
[16:18] <cpaelzer> thanks tsimonq2
[16:19] <tsimonq2> :)
[16:32] <tsimonq2> TheMuso, bdmurray: Patch pilot too? :) :) :)
[16:35] <rbasak> nacc: a bit later if that's OK?
[16:35] <nacc> rbasak: ack, just ping
[16:46] <mdeslaur> slangasek, stgraber, kees, infinity: TB in 15 min
[16:47] <slangasek> mdeslaur: ack
[17:14] <smoser> nacc, around ?
[17:14] <smoser> so if i do :
[17:14] <smoser>  usd import -v --directory=nova-lxd --lp-user=smoser  nova-lxd
[17:14] <smoser> that will import it, and push it up tthere.
[17:14] <smoser> but will it then get magically synced ?
[17:17] <nacc> smoser: pong
[17:18] <nacc> smoser: that will still push to usd-import-team
[17:18] <nacc> smoser: presuming that's what you want
[17:18] <nacc> smoser: by magic sync what do you mean? the regular imports?
[17:19] <nacc> smoser: no, that needs an update to the usd-cron-packages.txt file and then I need to restart the importer
[17:19] <smoser> "that needs an update to the usd-cron-packages.txt"
[17:19] <smoser> thats what i was asking.
[17:19] <smoser> would it not make sense to just update anythign that is already present ?
[17:20] <nacc> smoser: not sure i follow?
[17:20] <nacc> smoser: the importer doesn't care about the git repositories on lp
[17:20] <nacc> smoser: it is looking at publishing records
[17:23] <nacc> smoser: it looks at what has been published since the last run and compares to that list of packages
[17:23] <smoser> right.
[17:23] <smoser> but it has some list of "i care about these packages"
[17:24] <nacc> smoser: yes, that you provided :)
[17:24] <smoser> but wouldnt it be simpler if at this point it cared about the list of  packages for which a import had been previously done.
[17:24] <nacc> we haven't imported the list yet
[17:24] <nacc> smoser: so no
[17:25] <smoser> ok. i think it'd still be simpler. at least then the list is maintained in one specific place.
[17:25] <nacc> smoser: and querying lp  for the list of repositories would be more code changes
[17:26] <nacc> smoser: and would miss any new source pacakges
[17:26] <smoser> well, which are missed now also
[17:26] <nacc> right, so it's not better :)
[17:26] <smoser> well, i think its still better.
[17:27] <nacc> smoser: you're welcome to work on it
[17:27] <smoser> :)
[17:27] <nacc> smoser: right now, beyond fixing imports that are broken, i am not working on it
[17:27] <smoser> theres probably a api to list
[17:27] <smoser> right
[17:27] <smoser> so if i want a package added, i propose a  merge to usd-cron-packages ?
[17:27] <nacc> smoser: yeah, i think so
[17:27] <nacc> smoser: also, you ahve push rights, i'm pretty sure
[17:27] <nacc> smoser: so feel free to just update it :)
[17:27] <smoser> well, yes.
[17:28] <nacc> smoser: and then ping me and I'll restart the importer
[17:28] <nacc> smoser: but that, on its own, doesn't import it, of course (it's useful to do what you did above first, so it's 'caught up', i think)
[17:35] <bdmurray> tinoco: Do you recall if bug 1556653 is fixed in Yakkety or Zesty?
[17:37] <tinoco> bdmurray: nope :\
[17:38] <smoser> nacc, i pushed
[17:38] <smoser> nova-lxd to the list, and then started an import here
[17:39] <nacc> smoser: thanks -- let me switch on the vpn so i can kick the importer
[17:39] <bdmurray> tinoco: I looked and figured it out
[17:40] <tinoco> bdmurray: tks
[17:40] <nacc> smoser: restarted
[17:46] <nacc> smoser: i agree it's not ideal, but we're also going to be changing the trees a bit again...
[17:46] <smoser> oh
[17:52] <nacc> smoser: i mean, that's why i haven't yet imported the list
[17:52] <nacc> smoser: it won't really affect end-users, but it affects the 'project' in terms of reproducible impotws
[17:52] <nacc> *imports
[17:57] <nacc> stgraber: if `newnet` is used to run a process, are ports in use shared betweeen the namespaces?
[17:59] <stgraber> nacc: I don't know newnet, but assuming it does the same as "unshare -n", then you won't have any network interfaces in there except for lo and that lo is specific to that namespace so you can bind the same ports as outside of it (and won't be able to connect to it from the outside)
[18:00] <nacc> jbicha: --^ that's why plproxy is failing. they are passing -p 5432, which is the postgres default port (and so postgres is already running on it), but using `newnet` and the newnet process is complaining about the port being in use
[18:00] <nacc> stgraber: ok, thanks
[18:13] <nacc> jbicha: it's a bug in /usr/share/perl5/PgCommon.pm
[18:13] <nacc> jbicha: it assumes that if a conf file is defined for a postgres installation with a port in it, that it's reserved that port
[18:13] <nacc> jbicha: which ignores network namespaces altogether
[18:18] <nacc> jbicha: well, it might be that pg_createcluster is only looking at the ocnfiguration -- so less a bug and more a mismatch
[18:18] <nacc> simplest fix is to not pass -p
[18:19] <jbicha> nacc: would you like to work on that? it sounds like you understand that a lot better than I would
[18:20] <nacc> jbicha: yep i'm sending an e-mail to debian, i think they should just drop their changes, it's the easiest
[18:20] <nacc> while it seems 'cool' to use newnet, i have no reason to think it's necessary for these tests :)
[18:20] <jbicha> the rebuild worked for postgresql-filedump's autopkgtest
[18:20] <nacc> jbicha: cool, thanks
[18:41] <javier4> Should I do something to make pkg-config search for libs in multi-arch directories?
[21:00] <Unit193> So /usr/lib/NetworkManager/conf.d/10-globally-managed-devices.conf is due to integration with nplan right?  If one doesn't have nplan, "unexpectedly" NM seems broken.  Is there a reason this isn't actually in nplan itself, since the config is useless or even detrimental without nplan installed?
[23:17] <nacc> jbicha: i wonder if the multicorn regression is due to our older sqlalchemy, am going to test locally
[23:17] <memeka> gnome-shell (zesty) crashes (so gdm3 and gnome3 won't start) in libmozjs38 ToBooleanSlow() - same crash as reported here: https://bugzilla.mozilla.org/show_bug.cgi?id=1334314
[23:17] <memeka> on armhf
[23:23] <jbicha> ok
[23:27] <jbicha> nacc: actually, -multicorn has been failing on Debian and Ubuntu since 2015
[23:27] <jbicha> see https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/view/head:/pitti#L164
[23:27] <jbicha> https://ci.debian.net/packages/p/postgresql-multicorn/unstable/amd64/
[23:27] <nacc> jbicha: ah so taht just needs an update to 1.3.3-1?
[23:28] <jbicha> yes if we ignore those 2 packages, I think pg 9.6 will migrate
[23:28] <nacc> well, plproxy doesn't need to be ignored
[23:28] <nacc> it works now
[23:28] <nacc> but we should ignore multicorn
[23:28] <nacc> slangasek: --^ can you help here?
[23:29] <nacc> jbicha: but also note that multicorn is not holding pg-9.6
[23:29] <nacc> its the multicorn update itself that's help
[23:29] <nacc> *held
[23:30] <nacc> jgrimm: --^ i note that int he above hint, python-boto is also marked as a bad test
[23:31] <jgrimm> nacc, ahhhhh
[23:31] <nacc> jgrimm: not sure fully on the context, but specifically it was for the prior version, it seems?
[23:32] <jgrimm> nacc, possibly.. i don't think anything's new with respect to tests there
[23:33] <nacc> jgrimm: right, i think that it failed with 2.40.0-1ubuntu1 as well, but it was allowed by the hints
[23:33] <slangasek> nacc: I see postgresql-multicorn already listed as 'ignored failure'?
[23:33] <jgrimm> nacc, indeed it did, i didn't know about that file
[23:33] <nacc> slangasek: yes, for  postgresql-9.6 itself, but not for it's own update
[23:33] <jgrimm> so along those lines may just need updated again??
[23:33] <nacc> slangasek: trying to get stuff ready to go through once pg-9.6 itself does (hopefully soon)
[23:34] <slangasek> nacc: oh. why do we care about ignoring it for its own update, as opposed to making whoever uploaded the new version fix the test failure in that new version?
[23:34] <nacc> slangasek: it's not a new failure :/
[23:34] <slangasek> oh, because it's a sync grr
[23:34] <nacc> yeah
[23:34] <slangasek> nacc: yeah, but I'm generally in favor of making such packages stuck in -proposed the problem of the uploader... doesn't work when it's a sync :)
[23:35] <slangasek> nacc: leeloo dallas multicorn - hint added
[23:35] <nacc> slangasek: ah got you, agreed in principle
[23:35] <Unit193> Paha.
[23:35] <nacc> slangasek: and thanks!
[23:41] <sarnold> multicorn!
[23:42] <nacc> barry: do we care about pycxx in excuses? it would appear to be also failing in debian and has been since the update to 7.0.1?
[23:50] <jbicha> nacc: plproxy's autopkgtest failed on armhf, is that arch unusual for autopkgtest?
[23:52] <nacc> jbicha: always :)
[23:52] <nacc> jbicha: let me look
[23:52] <nacc> jbicha: might be a testbed failure, let me retry it