[00:01] <nacc> xevious: thanks
[00:11] <nacc> xevious: fyi, cacti just synced, it's running its tests now
[00:12] <xevious> I found an issue with version parsing (see mediawiki), so I'm fixing that and rerunning.
[00:12] <xevious> ETA for that to hit bionic-proposed?
[00:12] <nacc> xevious: it's there now, i'm retriggering php-defautls nnow
[00:12] <xevious> Oh great.
[00:15] <nacc> xevious: monolog is also fixed (in b-p), and it should migrate with phpunit
[00:16] <xevious> That covers everything I looked at so far.
[00:16] <nacc> xevious: thanks for all your help. I'll probably be EOD soon, but after some other work tmrw AM, I will pivot back to your script's output
[00:17] <xevious> Once I have the 'excuses...' parsing issue sorted out, I'll update the gist with the current output and copy of the script.
[00:17] <nacc> xevious: thanks again
[00:17] <xevious> Glad I can help. :)
[00:34] <xevious> nacc: I updated the gist (https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16)
[00:36] <xevious> nacc: I just noticed php-codesniffer updated to version 3.2.2 in my script's output. They just introduced a new way of annotating overrides for PHP_CodeSniffer and there have been a few regressions. At least some of them will be fixed in 3.2.3.
[00:37] <xevious> (3.2.3 should be out this week)
[00:46] <nacc> xevious: ok, i can also backport it this week, if that ends up being the only thing blocking us :)
[04:43] <lotuspsychje> morning to all
[04:44] <lotuspsychje> im suffering this weird bug on 1 xenial machine, could you have a look? https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1749237
[10:52] <cpaelzer> pitti: I remember on the postgres MREs that we always had the armhf issues since the switch of lxc to lxd
[10:52] <cpaelzer> I wanted to mask the relaed tests now
[10:53] <cpaelzer> bug 1748161
[10:53] <cpaelzer> rbasak: found that the actual fix would be very small actually https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-common.git/commit/?id=fc40fc34ce
[10:53] <pitti> cpaelzer: for the old releases, you mean? AFAIK I fixed the namespace issues maybe a year or two ago
[10:53] <cpaelzer> pitti: was there a reason/blocker not to backport this or could I just group that with the next MRE?
[10:53] <cpaelzer> pitti: yeah trusty/xenial only
[10:54] <pitti> http://autopkgtest.ubuntu.com/packages/p/postgresql-9.5
[10:54] <rbasak> cpaelzer: are you responding to my MP comment? Or tell me that you also found that commit? :)
[10:54] <pitti> wow, since when do we have a *smiley* for errors?
[10:54] <cpaelzer> rbasak: I respond to your MP comment trying to clarify with pitti if there was a reason not to bring this back to T/X
[10:54] <pitti> cpaelzer: not a blocker, there just has never been a postgresql-common SRU where I could have slipped this in
[10:54] <rbasak> Oh, OK
[10:54] <rbasak> Carry on :)
[10:55] <pitti> I didn't want to SRU p-common just for this
[10:55] <pitti> but if you want to, please do of course
[10:55] <rbasak> Oh, it needs an SRU to a different package?
[10:55] <cpaelzer> yes
[10:55] <rbasak> I hadn't realised that.
[10:55] <pitti> the integration tests are in postgresql-common
[10:55] <rbasak> I do have one observation though.
[10:56] <rbasak> ATM, humans are still checking the armhf failure and verifying that it's just the stderr problem and nothing else. The test is still running.
[10:56] <pitti> so the arm64 error is infra-related, otherwise at least http://autopkgtest.ubuntu.com/packages/p/postgresql-9.4 loosk good
[10:56] <rbasak> If we force-badtest it for future MREs, then we will stop looking at the armhf test run completely, which is objectively worse.
[10:56] <pitti> right
[10:57] <rbasak> I could be persuaded that on balance it's not worth the effort to look manually and force-badtest all future armhf though, as the MP requested.
[10:57] <rbasak> I didn't realise the SRU would need to be in a different source package. I agree it's not worth an SRU just for that.
[10:57] <pitti> cpaelzer: at least precise fell off the radar by "natural cause" ☺
[10:57] <pitti> this looked quite poor
[10:58] <rbasak> Though if postgresql-common is tiny, perhaps it could be done at the same time as a postgres MRE and it wouldn't have any meaningful impact to users.
[10:58] <pitti> one more year to go for trusty
[10:58] <rbasak> (if it's trivial source package)
[10:58] <pitti> or 4 MREs
[10:58] <pitti> rbasak: yes, it's a small arch:all package
[10:58] <rbasak> Then I'm in favour of "bundling" the fix at the same time as the next SRU
[10:58] <cpaelzer> ok
[10:58] <rbasak> (to not-postgresql-common)
[10:58] <cpaelzer> taking a note for that
[10:59] <cpaelzer> rbasak: we still want to switch off mimeo thou
[10:59] <rbasak> Unless someone thinks otherwise
[10:59] <rbasak> cpaelzer: agreed
[10:59] <cpaelzer> rbasak: I'll update the MP comment and bump it to just affect mimeo
[10:59] <cpaelzer> back in a bit
[10:59] <rbasak> ack
[10:59] <pitti> cpaelzer: https://salsa.debian.org/postgresql/postgresql-common/commit/07ea2e63241c9806 FYI
[11:00] <cpaelzer> thanks
[11:12] <cpaelzer> rbasak: new MP is https://code.launchpad.net/~paelzer/britney/hints-ubuntu-xenial-postgresqlMREv2/+merge/337696
[11:12] <cpaelzer> just mimeo as discussed
[11:12] <rbasak> ack
[11:29] <rbasak> cpaelzer: one note: when you do the next postgresql MRE, get the SRU reviewer to accept postgresql-common and want for binaries to be published before accepting the others
[11:29] <rbasak> Then the dep8 test will definitely run against the new one.
[11:30] <rbasak> (I don't think a versioned dependency relationship is needed here)
[11:30] <rbasak> s/want/wait/
[11:31] <pitti> that's not true
[11:31] <pitti> dependencies are satisfied from relelase/-updates as far as possible
[11:32] <pitti> you either need a versioned test dependency, or explicitly trigger the test to run against p-common in -proposed
[11:32] <rbasak> Oh.
[11:32] <pitti> (the latter appears better to me)
[11:32] <rbasak> OK we'll do an explicit trigger
[11:32] <rbasak> Thanks
[11:32] <pitti> i. e. see it fail, re-trigger armhf tests against p-common in -proposed, that should succeed and also validate the p-common SRU
[11:33] <pitti> although bumping the test dep in postgresql's d/tests/comtrol isn't wrong
[11:33] <cpaelzer> just as I did last week with some other migrations
[11:33] <rbasak> I generally shy away from bumping versioned deps to reflect bug fixes on the other side
[11:33] <pitti> (except the typoed file name, of course - tpying is hrad!)
[11:34] <rbasak> Seems like a recipe to madness
[11:34] <pitti> yeah, and breaks the clean backports, too
[11:34] <pitti> so I think manual trigger for that one round is just fine
[11:34] <rbasak> Yep
[14:53] <mvo> xnox: hey, just wanted to ask for your opinion on 1749000 - I have a debdiff for systemd ready (trivial fix) that would help snapd to pass tests again in bionic
[15:01] <juliank> tjaalton: I think I tried reproducing your autopkgtest-build-lxd problem 2 hours ago. I don't remember doing it exactly, but I do have a freshly generated image, so I say I did it and can't reproduce it.
[15:01] <juliank> What's better to use anyway, images:ubuntu/bionic or ubuntu-daily:bionic?
[15:05] <tjaalton> juliank: ah, well that's weird
[15:05] <juliank> tjaalton: did you retry it?
[15:05] <juliank> might be timing issues...
[15:06] <tjaalton> I've tried many times on two machines
[15:06] <juliank> I know that other lxd stuff retries apt update a few times
[15:06] <tjaalton> one bionic, the other xenial
[15:07] <juliank> tjaalton: So I have the same first failure (from update), but the rest works
[15:07] <juliank> So what happens is that it should do retries
[15:08] <juliank> as the container's network is not fully up when it tries to run update
[15:11] <tjaalton> does it try to install eatmydata on your end?
[15:11] <juliank> yeah, and that works, as network is up for me at that point
[15:13] <juliank>     chroot "$root" apt-get update || (sleep 15; chroot "$root" apt-get update)
[15:13] <juliank> um yeah, that's not going to work
[15:13] <juliank> It exits with 0, saying "They have been ignored, or old ones used instead."
[15:14] <cjwatson> at various points in the past that has exited non-zero in at least some interesting failure modes
[15:15] <cjwatson> we made the same change in LP (in fact autopkgtest probably got it from LP) and it basically eradicated most of the chroot-failure builds we were seeing at the time
[15:16] <juliank> Well, yeah, some times it might. But I think we cleaned up some of that
[15:16] <juliank> so more stuff is exit 0 now than it used to be or something
[15:17] <juliank> because some stuff was wrongly classified
[15:17] <tjaalton> oh, a shell script.. I'll have a look
[15:17] <juliank> We also have another solution
[15:17] <juliank> or not
[15:18] <juliank> I thought it should set Acquire::Retries, but I'm not sure we have a time out or something, and busy retrying seems bad
[15:19] <willcooke> Could someone with mailing list admin approve my subscription please?  I want to get an email out today if possible.  Cheers!
[15:20] <willcooke> oh, wait, it told me I am already subscribed, but when I just posted it told me I wasn't
[15:20] <seb128> willcooke, same email?
[15:20] <willcooke> seb128, yeah
[15:20] <seb128> no canonical vs ubuntu ?
[15:20] <seb128> weird
[15:21] <willcooke> I'll try and post again
[15:22] <willcooke> (I cancelled the previous one)
[15:23] <willcooke> Ah, ok, it's because I'm not an Ubuntu developer.  I actually read the reply this time
[15:23] <willcooke> could a mod approve it please?
[15:24] <cjwatson> what list?
[15:25] <willcooke> cjwatson, ubuntu-devel
[15:27] <cjwatson> willcooke: done
[15:27] <willcooke> thanks a lot cjwatson
[15:29] <Odd_Bloke> juliank: I think you were playing with ddebs, I'm seeing "E: Failed to fetch http://ddebs.ubuntu.com/dists/bionic-proposed/main/binary-amd64/Packages.xz  File has unexpected size (45916 != 38288). Mirror sync in progress? [IP: 91.189.90.217 80]"
[15:30] <juliank> Odd_Bloke: updates might take some time, and are not even close to atomic
[15:30] <juliank> I think I know how to fix that.
[15:30] <Odd_Bloke> juliank: "Release file created at: Wed, 14 Feb 2018 13:07:11 +0000" <-- that long?
[15:32] <juliank> says Date: Wed, 14 Feb 2018 15:17:46 UTC here
[15:32] <juliank> ah no, wrong pocket
[15:32] <juliank> Odd_Bloke: The release file is updated last, though
[15:33] <juliank> Odd_Bloke: it seems to be indexing s390x now
[15:34] <juliank> ah no, it's on ppc64el
[15:34] <juliank> It takes about 2 minutes per architecture for main
[15:35] <juliank> I want to fix it by creating dists/bionic.new and then doing mv(bionic, bionic.old), mv(bionic.new, bionic)
[15:35] <juliank> but, it's not a priority
[15:36] <juliank> at least that's what slangasek said :)
[15:37] <juliank> I think that is testable code, thouh
[15:37] <juliank> gh
[15:37] <juliank> so it should be easily possible
[15:37] <juliank> later maybe
[15:38] <juliank> cjwatson: Is ddeb-retriever back to normal runtimes again?
[15:38] <juliank> seems to be fine from what I can tell
[15:39] <juliank> At least it did not update bionic-updates today :D
[15:43] <cjwatson> juliank: it hasn't been complaining at me in cronmail, so I assume so
[15:43] <cjwatson> I only really notice when it whinges about being unable to take its lock
[15:44] <juliank> okay
[15:46] <xnox> mvo, hey, that looks funky. I can include that in my next upload into bionic.
[15:46] <xnox> mvo, also scary stuff =)
[15:47] <juliank> Odd_Bloke: proposed should be fine now
[15:47] <Odd_Bloke> juliank: It is, thanks!
[15:47] <Odd_Bloke> juliank: Was there actually a problem, or was I being impatient?
[15:47] <Odd_Bloke> (Or both? :p)
[15:47] <juliank> you were being impatient :)
[15:49] <xnox> mvo, also, will i need that in many other .service files as well?!
[15:49] <mvo> xnox: when do you plan your next upload? its blocking snapd right now (its one of the autopkgtest failures we see currently in 2.31)
[15:49] <mvo> xnox: probably, we only care about this one service in snapd
[15:49] <xnox> mvo, today? =)
[15:49] <mvo> xnox: \o/
[15:50] <GunnarHj> Hi wgrant! Do you have an idea why LP refuses to import the .po files here:
[15:50] <GunnarHj> https://bugs.launchpad.net/ubuntu/+source/gnome-sudoku/+bug/1734545/comments/4
[15:50] <mvo> xnox: also I'm not sure what upstream dbus will do about this, its a bit of a mess IMO, so maybe the default will be "unconfined"
[15:50] <mvo> xnox: but jamie or tyler will know more
[15:50] <mvo> xnox: out of curiosity, how many dbus service files are there for systemd? i mean, dbus activatable ones?
[15:52] <xnox> loads.
[15:53] <xnox> hostanem1 locale1 login1 network1 resolve1 systemd1 timedate1
[15:53] <xnox> the only odd one out, is systemd1
[15:53] <xnox> the rest can be bus activated.
[16:15] <GunnarHj> wgrant: Please disregard my question for now. seb128 noticed that there was an obsolete upstream sharing link, so we have removed that link and will try a re-upload.
[16:17] <seb128> GunnarHj, wgrant, well +sharing-details was still stating " Translations are not enabled on the upstream project. " and " Automatic synchronization of translations is not enabled. " so unsure if that's the issue, that part of lp translations is confusing so it would still be good to know if that is what stopped the .po to be listed for import
[16:20] <Unit193> juliank: Would it make sense to call automake with --forign?  Does it do anything else other than make it a little more lax in file checking?
[16:21] <juliank> idk
[16:21] <Unit193> If, say, 'ChangeLog' is missing, autoreconf fails because of gnu stupidity.
[16:22] <juliank> I think a lot of configure.ac seit foreign in AM_INIT or something?
[16:23] <juliank> *set
[16:23] <Unit193> Ooh, nice.
[16:27] <juliank> I think it also needs an option in Makefile.am
[16:27] <juliank> SOMETHING = foreign
[16:27] <juliank> but details.......
[16:28] <xevious> nacc: I updated the gist (https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16)
[16:28] <Unit193> I wondered why autoreconf failed but autogen.sh worked on some weird package, that was it.
[16:37] <nacc> xevious: thanks, phpunit migrated overnight
[16:39] <nacc> xevious: note also, i only care about those that are currently marked as regressions, if that makes sense?
[16:40] <xevious> You don't need to retest passed packages when there's a newer version available?
[16:41] <nacc> xevious: not explicitly no (I mean, in theory, it's good), but it won't change the blocked state
[16:50] <caravena> jsalisbury: Hello, My name is Cristian Aravena Romero :-)
[16:50] <caravena> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1748470
[16:50] <caravena> Is this report okay?
[18:03] <tjaalton> mitya57: hi, do you have plans to upload the qt patch for bug 1749472 before FF?
[18:05] <tsimonq2> tjaalton: Hi, I will, yes.
[18:05]  * tsimonq2 is working on the 5.9.4 transition in Bileto now
[18:06] <tjaalton> great, it will take some time to get this through anyway so next week is fine for me
[18:06] <tsimonq2> Worst case scenario, FF doesn't apply to things already uploaded iirc.
[18:06] <tsimonq2> Sure.
[18:06] <infinity> FF also doesn't apply to bugfixes.
[18:06] <tjaalton> nvidia driver updates are still WIP and needed before it can land
[18:07] <tsimonq2> infinity: Does it apply to ABI bumps?
[18:07] <tsimonq2> i.e. I bumped ABI for qtbase for the sake of getting everything rebuilt.
[18:08] <tsimonq2> But, there's no real FF violation.
[18:08] <tsimonq2> tjaalton: Ah, OK.
[18:08] <infinity> tsimonq2: Err, you did what?
[18:08] <tsimonq2> infinity: the virtual package
[18:08] <infinity> Okay, you had me mildly terrified that you were picking package names or SONAMEs out of thin air.
[18:08] <tsimonq2> Hahahaha.
[18:08] <tsimonq2> No.
[18:16] <xevious> nacc: Has phpunit fully pushed? I see both 5.4.6-3 and 6.5.5-1ubuntu2 listed under php7.2 on the 'excuses...' page. The 6.x test is marked as a regression, but it's only because php-defaults hasn't gone through and the test script pulled in a mix of 7.1 and 7.2 packages (including php7.1-xml instead of php7.2-xml)
[18:16] <nacc> xevious: yes it has
[18:16] <nacc> xevious: the logs you see are presumably old
[18:16] <nacc> xevious: i've not retriggered much yet
[18:16] <xevious> Gotcha
[18:19] <nacc> xevious: deubgging something in php-pear first (using count() on a return value from a function that can return a string or array)
[18:19] <nacc> that's part of the php-defaults failures
[18:19] <xevious> Yeah, that's the issue I was going to mention
[18:20] <xevious> That's affecting php-console-table, php-log, php-mail-mime, and php-net-smtp.
[18:20] <nacc> yep
[18:20] <nacc> i am just trying to figure out what they *wanted* to do :)
[18:21] <xevious> php-horde-activesync and php-horde-core are showing issues related to PHPUnit. Can you rerun those now that the new version of phpunit has pushed?
[18:23] <xevious> php-crypt-chap's log is vague about its error.
[18:23] <nacc> xevious: let me look
[18:23] <nacc> xevious: i think horde-activesync is actually tied to horde-test
[18:24] <xevious> Likely. It seems like their test class just needed to be adapted to PHPUnit namespacing everything.
[18:24] <nacc> xevious: yeah, i belileve i did that already
[18:24] <xevious> *needs
[18:24] <nacc> it's what's in proposed, but the triggers nneed to be adjusted
[18:24] <nacc> (php-horde-test, that is)
[18:24] <nacc> xevious: so let's hold off on php-horde as it relates to php-defaults
[18:24] <nacc> for now
[18:25] <nacc> let's get everything else green or understood, and then i'll work on unwedging horde itself
[18:25] <nacc> similar to phpunit, it will be easier to get horde migrated, then just retrigger the new versions in bionic
[18:25] <nacc> xevious: uploading a fixed php-pear
[18:26] <xevious> Aside from the Horde_Test_Case issue, the PEAR test count() thing, and the issue in php-crypt-chap, all the other regressions should be rerun using the new PHPUnit.
[18:27] <nacc> ok i'll retrigger amd64 (which tends to work fastest) and see if they go green, then trigger the rest
[18:29] <nacc> ok, retrigged something like 30 amd64
[18:30] <nacc> i'll debug the crypt-chap one nonw
[18:30] <nacc> and once php-pear publishes, i'll retrigger the dependent tests
[18:34] <xevious> A few of the PHPUnit tests look like they'll have the same issue as the PEAR tests: `count(): Parameter must be an array or an object that implements Countable` We'll see after they rerun with PHPUnit 6.x
[18:34] <nacc> yeah, it's a pain, because sometimes it's not in the code itself, but some dependent library
[18:47] <xevious> nacc: How do you deal with php-defaults regressions that are failing because php-defaults hasn't been updated? For instance, phpunit is pulling in a mix of php7.1-* and php7.2-* packages.
[18:53] <nacc> xevious: hrm, i saw the phpunit run was using an old phpunit
[18:53] <nacc> xevious: so i retrigged it without anything
[18:54] <nacc> xevious: as php-defaults (in that section) is already a trigger
[18:54] <nacc> xevious: not sure if that answered your question
[18:56] <xevious> nacc: This build failed due to php7.1-xml being pulled in instead of php7.2-xml. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/p/phpunit/20180214_163244_07123@/log.gz
[18:56] <xevious> s/build/test/whatever
[18:57] <xevious> I don't think that's one of the ones you just kicked off though, is it?
[18:57] <nacc> xevious: which lilnk is that from? sorry, there's lots of moving pieces
[19:01] <xnox> -apt-pocket=proposed=src:php7.2 --apt-upgrade phpunit --env=ADT_TEST_TRIGGERS=php7.2/7.2.2-1ubuntu1
[19:01] <xnox> that's run of phpunit, as triggered by php7.2 without the new php-defaults
[19:02] <nacc> xnox: err, duh, thanks
[19:02] <nacc> xevious: right, so i was just retriggering a lot of php7.2's tets, with php-defautls from proposed
[19:02] <xnox> nacc, next one to migrate is php-defaults, right, or no?
[19:02] <xnox> cause once that one migrates, everything else should become easier, no?
[19:03] <nacc> xnox: yeah, the problem is php-defaults is probably wedged by php-horde*
[19:03] <nacc> and i think i see why horde is wedged
[19:03] <nacc> i'm not 100% on the why of the why, but it seems like there was a beahvior change in phpunit
[19:04] <nacc> wrt the bootstrap fille
[19:04] <nacc> xnox: so yeah, i'd *like* to unstick php-defaults, but i have a feeling it's going to actually be easier to unstick php-horde* and then retrigger php-defaults
[19:07] <nacc> and php-horde-test looks to need a bunch of changes
[19:07] <nacc> working on that now
[19:08] <nacc> xnox: that is to say, i don't think i *can* unstick php-defaults until i fix horde
[19:17] <nacc> xevious: php-crypt-chap is failing because php7.2-mcrypt is gone
[19:17] <nacc> http://php.net/manual/en/migration71.deprecated.php
[19:17] <xevious> Ah, that'll do it.
[19:17] <nacc> so i think i need to pull in a new package
[19:18] <xevious> It's available in PECL now.
[19:18] <xevious> What uses php-crypt-chap? Can it be retired?
[19:19] <nacc> xevious: php-horde-passwd :)
[19:20]  * xevious strongly dislikes Horde
[19:20] <nacc> but php-horde-passwd itself has no revdeps
[19:21] <nacc> xevious: i'm pinging the debian folks to find out if they are going to package the pecl mcrypt
[19:23] <nacc> xevious: ok, almost got horde-test working
[19:49] <nacc> xevious: and some of the retriggers i ran are going throug now (php-imagick, php-memcache)
[20:01] <nacc> xevious: horde-activesync needed a new horde-test and horde-stream-wrapper
[20:01] <nacc> (new as in either upstream or cahnges)
[20:08] <nacc> xevious: and i just retriggered the php-pear dependent ones
[20:11] <nacc> and the arches for those where amd64 passed
[21:03] <nacc> xevious: i'm going to elt excuses settle for a bit, i'll get the php-pear fixes uploaded first
[21:46] <xevious> nacc: Are these tests running on the Launchpad build farm that this channel's topic says has limited capacity?
[21:51] <cjwatson> Oh, that's out of date
[21:56] <jbicha> cjwatson: should we drop the Artful bug from the topic now?
[22:03] <cjwatson> jbicha: I dunno
[22:03] <cjwatson> ask somebody who was involved with that :)
[22:36] <rharper> nacc: I'm trying to do git ubuntu build or build-source  and I'm getting some errors when it attempts to lxc file push stuff into the ephemeral container ... is that a known issue ?
[22:39] <nacc> rharper: which snap channel?
[22:39] <nacc> rharper: and yes, possibly :)
[22:39] <rharper> nacc: looks like stable
[22:39] <rharper> on classic
[22:39] <rharper> should I move to edge ?
[22:40] <nacc> rharper: yeah
[22:40] <nacc> rharper: it's fixed in edge and i've not done a release to stable in a while
[22:40] <rharper> snap install git-ubuntu --classic --edge ?
[22:40] <nacc> it's on my todo, but we're in heavy flux on edge and ENOTIME :)
[22:40] <nacc> rharper: snap refresh --channel edge git-ubuntu
[22:40] <nacc> iirc
[22:40] <rharper> k
[22:40] <nacc> possibly just snap refresh --edge git-ubuntu
[22:41] <rharper> yeah
[22:41] <rharper> or any order snap refresh git-ubuntu --edge
[22:42] <nacc> rharper: right
[22:43] <nacc> xevious: jmespath.php fixed (it just migrated, i'll wait til it shows up in rmadison then retrigger it)
[22:43] <xevious> Good news. I was wondering about that one, since it wasn't showing up in APT at all.
[22:45] <nacc> yeah i'm working on unwedging php-pear now (I need to craft the triggers properly)
[22:50] <rharper> nacc: well, it fails *differently*
[22:50] <rharper> E: Package 'equivs' has no installation candidate
[22:51] <rharper> and similar to the stable release, it seems to ahve trouble with the temporary tarball
[23:07] <nacc> rharper: can you pastebin the command exact output/
[23:07] <nacc> *and exact output
[23:07] <nacc> rharper: the equivs thing, presuming your lxd setup is good, should go away after a few attempts
[23:07] <rharper> sure
[23:07] <nacc> (we are just waiting on network in the lxd)
[23:07] <rharper> what container are you launching? and why not give it cloud config ?
[23:07] <nacc> rharper: we just use lxc appropriately
[23:08] <nacc> rharper: i don't know what you meann by a cloud config in this context
[23:08] <nacc> rharper: we need the equivalent of an sbuild environment
[23:08] <rharper> if the lxc image you run inside has cloud-init , then whatever set of commands you want to run for like package install could do that
[23:08] <nacc> rharper: because then we'd need to trust cloud-init :-P
[23:08] <rharper> well, it waits for the network ...
[23:08] <nacc> rharper: we *could* do that too
[23:09] <nacc> rharper: feel free to file a bug
[23:09] <rharper> sure, I'm mostly interested in which image you're using the minimal, or the cloud based ones
[23:09] <nacc> cloud-based
[23:09] <nacc> we just spawn ubuntu-daily:<whatever>
[23:09] <nacc> based uponn the changelog
[23:10] <rharper> if it's bionic, then you can do something like: lxc exec <name> -- cloud-init  status --wait which will block until cloud-init is done which ensures networking is up ; that way you're not spwaning apt commands when no network has come up
[23:10] <nacc> rharper: and on trusty, xenial, artful?
[23:11] <rharper> the networkd layer is somewhat sluggish due to ipv6 mantory waits
[23:11] <rharper> cloud-init wait is back to xenial
[23:11] <rharper> not trusty
[23:11] <nacc> rharper: which then we'd have to special case :)
[23:11] <nacc> tbh, this is all experimental enough that it's not a big deal
[23:11] <rharper> y
[23:11] <nacc> and we're not doing any work on that toolingn right nnow, focusing on the importer
[23:11] <rharper> for sure
[23:11] <nacc> i have a MP up that at least silences that output so it's not so scary
[23:11] <rharper> I'm looking at my add-a-patch workflow so I can do that via git-ubuntu instead
[23:11] <nacc> ack
[23:12] <rharper> https://paste.ubuntu.com/p/q235rHvvjv/
[23:12] <rharper> there's the command and output
[23:13] <nacc> rharper: ok, yeah the equivs is just noise while it waits for network (with a backoff)
[23:13] <nacc> reading the failure bit
[23:13] <nacc> can you pass --keep-build-env and then go into the container and see what's there?
[23:13] <rharper> I do have an orig.tgz in the parent dir for the package
[23:14] <rharper> yeah
[23:14] <nacc> i wonder if for some reason the tarball is root-owned
[23:14] <nacc> bcause it's ap ermission issue, not a enofile
[23:14] <rharper> yeah
[23:14] <rharper> let's look
[23:15] <rharper> no, owned by me
[23:15] <nacc> rharper: in the container/
[23:15] <nacc> *?
[23:15] <rharper> oh
[23:15] <rharper> let's wait
[23:15] <rharper> it's thinking about retrying
[23:15] <nacc> rharper: ok :)
[23:16] <rharper> interesting, it gets the uid of my user on the host
[23:16] <rharper> -rw-rw-r--  1 1001 1001 22039 Feb 14 23:16 bcache-tools_1.0.8.orig.tar.gz '
[23:17] <rharper> -rw-------  1 1001 1001 28516 Feb 14 23:16 tmp1k_sj6kn.tar.gz
[23:17] <rharper>  
[23:17] <nacc> hrm, i guess that's probably because of `lxc file`
[23:17] <nacc> and maybe local lxd config
[23:17] <nacc> but that would be why you get an issue, as we run as the ubuntu user in the lxd
[23:17] <nacc> now the question is why are the perms like that
[23:18] <xevious> nacc: I updated the script to only flag regressions that have newer packages available. I also added a script to run it in a Docker container, in case that's convenient for you. https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16
[23:18] <nacc> xevious: thanks
[23:21] <rharper> nacc: yeah, you su - to the ubuntu user
[23:21] <nacc> rharper: is this a branch you have pushed to LP that i can test?
[23:21] <rharper> nacc: I think this is a local issue because on my system, my username is not uid=1000 like ubuntu is
[23:21] <nacc> (just to see if it's reproducible)
[23:21] <nacc> ah that would make sense
[23:21] <nacc> and is probalby then an underlying bug
[23:22] <nacc> (we should be chown'ing the files to ubuntu:ubuntu as we copy them
[23:22] <nacc> we can use --uid, i think
[23:22] <sarnold> pls no "chown as copy", but do the copy as the user in question..
[23:22] <rharper>  https://code.launchpad.net/~raharper/ubuntu/+source/bcache-tools/+git/bcache-tools/+ref/add-bcache-export-patch
[23:22] <nacc> sarnold: lxc file push --uid then?
[23:23] <nacc> rharper: thanks, but based upon what you just said, that's the issue
[23:23] <sarnold> nacc: yeah, that way if it's busted you can yell at serge and stephane :D
[23:23] <nacc> sarnold: yeah
[23:23] <rharper> nacc: right, I think that's it as well
[23:23] <nacc> rharper: do you mind fililng a bug?
[23:23] <rharper> sure, can I ubuntu-bug or what ?
[23:23] <nacc> rharper: probably not? since it's not a package
[23:23] <rharper> boo
[23:24] <nacc> https://bugs.launchpad.net/usd-importer/+filebug
[23:24] <rharper> so, what do ?
[23:24] <rharper> k
[23:24] <nacc> thanks
[23:24] <rharper> np
[23:24] <nacc> something like 'lxc file operations should set the uid'
[23:24] <rharper> git ubuntu build fails when user's uid doesn't match ubuntu user in container
[23:24] <nacc> yeah
[23:24] <nacc> that works too :)
[23:28] <xevious> nacc: I'm calling it a day.
[23:29] <rharper> https://bugs.launchpad.net/usd-importer/+bug/1749609
[23:30] <rharper> nacc: ^
[23:37] <nacc> rharper: thanks
[23:37] <nacc> xevious: have a good evening
[23:39] <xevious> nacc: If you want to give me one/several of the "update to namespaced PHPUnit 6 classes" tasks tomorrow, those are ones I could easily tackle between other things I'm working on and meetings and whatnot.
[23:41] <nacc> xevious: sure, i'll let you know