[00:14] <nacc> elbrus: yeah the 500s seems to be something (i'm guessing it's a php error?) -- but i'm not sure i can find the apache logs to see
[00:27] <nacc> slangasek: would you have any advice for debugging the armhf regression in cacti? it's causing php7.0 to not update currently and I really don't know how to reproduce it (the tests need root)?
[00:27] <slangasek> nacc: pointer?
[00:28] <nacc> slangasek: http://autopkgtest.ubuntu.com/packages/c/cacti/yakkety/armhf/
[00:28] <nacc> slangasek: started failing about a week ago, it seems
[00:29] <nacc> symptomatically, timeouts are occurring (I think), but the logs indicate the webserver is getting 500s ... but I don't think autopkgtest stores the apache logs (cmiiw) so I'm not sure how to verify if it's something obvious
[00:32] <slangasek> nacc: this regressed without any relevant changes to the dependencies; so it's currently a badtest and we should mark it as such to remove the migration blocker
[00:33] <nacc> slangasek: ack, that makes sense to me :)
[00:34] <nacc> slangasek: is that something you can do for me?
[00:34] <slangasek> yes (already done)
[00:34] <nacc> slangasek: great, thanks! this should allow dh-php to demote to universe (once php7.0 propogates to release), which will remove a component mismatch and let dh-php update as well
[00:34] <slangasek> pretty unhelpful that none of the output goes into the test log :P
[00:35] <nacc> slangasek: yeah :)
[00:35] <nacc> slangasek: i was at quite a loss on how to figure out what was going on
[00:36] <slangasek> nacc: I'm assuming you care about cacti not blocking php7.0's migration, and that you don't particularly care about the cacti in -proposed right now
[00:36] <nacc> slangasek: ack
[00:36] <slangasek> ok. then I'm leaving the cacti in -proposed blocked by its own test failure, and someone who does care about that package can figure it out
[00:36] <nacc> yep, that'd be elbrus --^ presumably :)
[00:51] <nacc> slangasek: feel free to ignore my question until it's convenient for you, but phpunit in yakkety-proposed currently fails to build (https://launchpadlibrarian.net/263777009/buildlog_ubuntu-yakkety-amd64.phpunit_5.4.2+dfsg-1_BUILDING.txt.gz) because the Debian package is not properly versioning the deps on php-codecoverage (so what could be a build-dep failure is instead expressed as a build failure).
[00:51] <nacc> But the dep in question (php-codecoverage) will fail to build if resubmitted currently because it depends on a newer phpunit than is in yakkety (in fact, I think the version that is currently not building). I am really not sure how these two packages got into this state, and if Debian did manually overriding knowing it would be overcome once they were both built
[00:53] <nacc> slangasek: but my question is: are you ok if i submit a patch like was done in 16.04 to add a build profile that disables the tests (and we possibly use that to bootstrap this tight loop)?
[00:58] <nacc> alternatively, if it's possible, we could pass DEB_BUILD_OPTIONS=nocheck to the builder for php-codecoverage and it builds fine
[01:01] <nacc> using that .deb file (--extra-package), phpunit also now builds
[01:01] <slangasek> nacc: if DEB_BUILD_OPTIONS=nocheck is sufficient to let us bootstrap, we can reasonably do that and shove it into the bootstrap archive
[01:01] <slangasek> easier than having to change packages
[01:02] <nacc> slangasek: ack, i'm just verifying both build successfully afterwards
[01:24] <nacc> slangasek: ok, this process worked for me locally: http://paste.ubuntu.com/17162006/
[01:25] <nacc> note that the php-mock-object build is a needed merge (reviewed by rbasak already)
[02:03] <sergiusens> slangasek still around? is this a known issue https://launchpadlibrarian.net/264431731/buildlog_ubuntu-yakkety-amd64.snapcraft_2.11+16.10_BUILDING.txt.gz ?
[02:05] <slangasek> sergiusens: nothing that's known to me, but I see there's been a new version of python3.5 synced to yakkety-proposed today
[02:06] <sergiusens> ah that can explain it
[02:07] <sergiusens> slangasek I guess this would block my SRUing
[02:07] <slangasek> sergiusens: no reason that it should
[02:08] <sergiusens> ah, I thought we always had to push to the devel series first :-)
[02:08] <slangasek> sergiusens: you did push it to the devel series; it's not required that it migrate out of -proposed when it's been blocked by an unrelated bug...
[02:09] <sergiusens> fair enough
[02:10] <slangasek> fwiw I can't see any reason something is looking for a Makefile at that path... it might be a python3.5 regression, but that file doesn't exist in the previous version of the python3.5 package either
[02:15] <sergiusens> slangasek it does on xenial $ dpkg -S /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/Makefilelibpython3.5-dev:amd64: /usr/lib/python3.5/config-3.5m-x86_64-linux-gnu/Makefile
[02:15] <slangasek> ah
[02:16] <slangasek> only in libpython3.5-dev, which I didn't have installed :-)
[02:17] <slangasek> sergiusens: ... and which is not a build-dep of snapcraft either
[02:17] <sergiusens> slangasek yeah, I wonder how it ever worked...
[02:18] <slangasek> probably by the previous version not unnecessarily requiring that Makefile :)
[02:21] <slangasek> doko: ^^ python3.5 3.5.1-15 in -proposed is definitely broken wrt pybuild; I'm going to drop it out of -proposed to unblock package builds until a fix is available
[02:23] <sergiusens> at least I know the same package built fine on xenial https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily/+build/9896202
[02:23] <slangasek> sergiusens: ^^ and having removed that, snapcraft can be retried in about an hour
[02:27] <sergiusens> thanks, I'll be in bed by then, but I'll make sure to retry in the morning, in the meantime I'll leave the upload on xenial ;-)
[02:32] <nacc> slangasek: can you demote dh-php to universe?
[02:32] <nacc> slangasek: php7.0-dev should now only suggest it, and that's the only revdep in main
[02:33] <slangasek> nacc: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed claims it's still used in main; until it shows up on that report I won't fiddle with it, that just encourages archive admins to get into accidental revert wars
[02:39] <nacc> slangasek: ack, sorry
[02:53] <nacc> slangasek: hrm, when i look at that page it says it wants to move xml2 to main (since dh-php depends on it and dh-php is in main). I'm suggesting we demote dh-php to universe -- did I misunderstand? Also, i'm really confused, the debdiff rbasak uploaded for me and diff at https://launchpadlibrarian.net/264339273/php7.0_7.0.7-4_7.0.7-4ubuntu1.diff.gz indicate dh-php is now in Suggests (or should be).
[02:53] <nacc> But my chdist apt-cache does not?
[02:55] <nacc> argh, i know why, nm
[02:55] <nacc> control.in vs. control
[03:31] <slangasek> nacc: right, so if all the changes were done and dh-php would be ready to drop, you would see dh-php under "move sources from main to universe" instead of a dependency of dh-php under "move sources from universe to main"
[03:33] <mwhudson> when SRUing something directly from yakkety to xenial, do i just stick a xenial changelog on the top of whatever's in yakkety?
[03:33] <mwhudson> slangasek: ^
[03:33] <slangasek> mwhudson: that's usually ok
[05:35] <pitti> bdmurray: tgt> I'll look
[05:37] <pitti> slangasek: plasma-workspace> rather looks like the uninstallability of -proposed is locked up with the other KDE packages; http://autopkgtest.ubuntu.com/packages/p/plasma-workspace/yakkety/armhf/ just succeeded in current y-release
[05:37] <pitti> slangasek: so I don't think the "force-badtest plasma-workspace/armhf/4:5.5.5.2-0ubuntu1" is justified actually
[05:38] <pitti> slangasek: and consequently, I don't think we should ignore the failure for 4:5.6.4-0ubuntu1 either
[05:38] <pitti> slangasek: it didn't promote as it's still blocked by dependencies
[05:39] <pitti> but I tried with --all-proposed often enough, that's not it -- something in y-proposed is really missing
[05:40] <pitti> nacc: so php7.0 landed, nice work! so I take it your php-imagick merge can land now?
[05:53] <ginggs> morning pitti! sorry, i didn't see your question on LP: #1556685 Is my answer reasonable, or do i need to dig deeper?
[05:56] <pitti> ginggs: ok, you now said it's cosmetic and has no actual impact on its rdepends; but a test case is still necessary, i. e. how can someone verify that the update still works
[05:56] <pitti> infinity: the glibc FTBFS on amd64, is that known? (hidden symbol `__stack_chk_fail_local' isn't defined)
[05:57] <pitti> http://autopkgtest.ubuntu.com/packages/g/glibc/yakkety/amd64/
[05:57] <ginggs> pitti: well, i did check that freecad and gmsh still open and after upgrading, but not being familiar with the applications did not do extensive testing
[05:58] <pitti> ginggs: but these wouldn't use cmake files at runtime, right?
[05:58] <ginggs> correct
[05:58] <pitti> ginggs: i. e. "test that freecad and gmsh still start" is a good part of the test and should be mentioned
[05:59] <pitti> but e. g. "test that they still build" might be another?
[05:59] <pitti> (sorry, I have absolutely no idea what oce is)
[05:59] <ginggs> ok, i'll expand on that.  they *only* build after the upgrade
[06:01] <ginggs> pitti: so when i'm done with that, do i need to upload the same version again?
[06:01] <pitti> ginggs: I didn't reject it, just held it in the queue
[06:02] <pitti> oh, but vorlon did
[06:02] <pitti> ginggs: yeah, easiest to just reupload the same thing
[06:02] <ginggs> pitti: danke!
[06:02] <pitti> ginggs: thanks
[06:02] <pitti> ginggs: so, put yourself into the position of someone not knowing oce who is supposed to decide "is that an update which does not cause regressions and actually fixes the bug?"
[06:03] <pitti> ginggs: and formulate the test case and regression potential accordingly
[06:04] <pitti> xnox: FYI, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libseccomp is blocked as it regresses on i386 and s390x
[06:06] <ginggs> ginggs: i tried doing that in the SRU bug LP: #1556680, but i see i should have been more explicit in LP: #1556685
[06:17] <pitti> ginggs: ah, the joy of SRU bugs; never do that, please
[06:25] <ginggs> pitti: never do what, exactly?
[06:26] <pitti> ginggs: open a separate bug #2 that says "SRU for bug #1"
[06:26]  * pitti smirks at ubottu
[06:26] <pitti> just adding a trusty/xenial/etc. task to the actual bug is much preferred
[06:27] <pitti> it avoids smearing out the info between the two, and the originally affected people can help testing, etc.
[06:27] <pitti> and the tasks don't need to be kept in sync manually
[06:27] <ginggs> pitti: understood, https://wiki.ubuntu.com/StableReleaseUpdates#Fixing_several_bugs_in_one_upload says to avoid creating meta-bugs, but that's not what happened here
[06:28] <pitti> ginggs: ah, maybe they are different issues, sorry then; (they sound similar)
[06:28] <ginggs> LP: #1556680 is the real bug
[06:31] <ginggs> pitti: but i agree that the way it was done is confusing for someone trying to review, and i will fix that by being more explicit in LP: #1556685
[06:31] <pitti> ginggs: thanks muchly for cleaning up!
[06:31] <brendand> if i run some tests via adt-run with nose, and i have logging.info statements (using logging module) in them, and the logging level set to INFO, should i see that output in the adt log? right now i just see the test names, no more detail than that
[06:32] <mgedmin> nose suppresses logging output by default and only shows it if a test fails
[06:32] <mgedmin> you can ask nose not to do that with a command-line switch
[06:32] <mgedmin> -s, IIRC
[06:34] <brendand> --nocapture, great - thanks
[06:51] <doko> slangasek, hmm, I don't see the issue yet
[06:58] <pitti> doko: many thanks for uploading py3.5, much appreciated!
[06:58]  * pitti feeds the Launchpad hamsters to import it
[07:00] <doko> pitti, hmm, see above, slangasek claims that -15 is broken. still investigating why
[07:45] <pitti>  linux | 4.4.0-24.43   | xenial-updates   | source
[07:45] <pitti>  linux | 4.4.0-23.41   | yakkety          | source
[07:45] <pitti> apw: ^ apparently there's some forward copying missing?
[07:45] <pitti> apw: or is that on purpose somehow?
[07:55] <infinity> pitti: Yeah, I just didn't have any overwhelming urge to fix it until I had a better reason (like new upstream version) for an upload.
[07:55] <infinity> pitti: And I did all the kernel forward copies just now.
[07:56] <pitti> infinity: ok, thanks; I ignored the  failure as it didn't seem triggered by the new cdebconf
[07:56] <infinity> https://launchpad.net/ubuntu/+source/linux/4.4.0-24.43/+publishinghistory
[07:57] <pitti> infinity: so I'll add a force-badtest for amd64 for that version, to avoid asking you again next time :)
[08:01] <pitti> bdmurray: tgt/wily was a spurious failure apparently, succeeded now
[08:03] <apw> pitti, no not on purpose, it was on my list to confirm done this morning, and it seems infinity has beat me to it
[08:04] <pitti> apw: ack, thanks
[08:05] <infinity> apw: Heh, yeah, it was on my "when I wake up" list too, and we seem to have woken up at the same time.
[08:06] <apw> infinity, which is wrong on so many levels :)
[08:40] <xnox> pitti, huh, that looks weird... I'll check if I dropped or reordered patches... unless upstream renumbered things which is abi break....
[08:41] <xnox> also no clue why these syscalls are negative =/
[08:44] <ogra_> just turn the around ;)
[08:44] <ogra_> *them
[09:53] <pitti> xnox, slangasek: so poppler/gdal/gp2ls/tinyxml2 transition all hinge on suitesparse, which built because we now build against universe deps, but is not installable because its new libmetis5 dep is in universe
[09:53] <pitti> xnox, slangasek: that's one of the hairy scenarios that I was afraid of.. :-(
[09:54] <pitti> "someone will fix it eventually"
[10:01] <ginggs> pitti: i thought slangasek promoted libmetis5 already
[10:02] <ginggs> pitti: LP: #1588407
[10:03] <pitti>  libmetis5     | 5.1.0.dfsg-4 | yakkety/universe | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
[10:03] <pitti>  metis         | 5.1.0.dfsg-4 | yakkety/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
[10:03] <pitti> ginggs: thanks, I missed the MIR as it was already closed
[10:03] <bdrung_work> pitti, whom can i poke to get the cpu+ram hotplug into the kernel?
[10:04] <pitti> bdrung_work: my favourite go-to kernel person is apw, he should know whom to give this to
[10:04] <pitti> apw: sorry Andy
[10:04] <apw> heh, i ahve many fine victim^Wpeople to pass this on to
[10:05] <pitti> ginggs: hm, so if this was promoted and demoted later on, I wonder why it still didn't land then
[10:05] <pitti> well, let's find out at the next publisher/britney run
[10:05] <pitti> ginggs: thanks
[10:05] <apw> bdrung_work, you might want to ask on #ubuntu-kernel so we can discuss
[10:05]  * pitti joins too
[10:09] <bdrung_work> pitti, btw, do you know whom to talk to about the cloud images? i like to have consoleblank disabled there.
[10:10] <rbasak> bdrung_work: bug 869017
[10:12] <bdrung_work> thanks rbasak
[10:13] <rbasak> bdrung_work: Wesley (an intern on the Canonical Server team) was looking into it, mainly to scratch his own itch I think. I still have him down as driving the bug. Looks like it needs an updated patch.
[10:13] <rbasak> bdrung_work: might be worth coordinating with him. He's not in here but is magicalChicken in #ubuntu-server.
[10:13] <rbasak> bdrung_work: but feel free to take the bug and patch it :)
[11:59] <elbrus> nacc: do you know of any changes in the armhf autopkgtest setup, because the same version of cacti that passed in the past, now fails...
[12:00] <elbrus> nacc: so it is either a real regression due to php (and very weird also cdebconf) or the testing framework is borking for whatever reason
[12:01]  * elbrus will copy more logs to the artifacts; nacc do you have suggestions next to the cacti.log and apache2/access.log & error.log?
[12:14] <ginggs> pitti: regarding suitesparse, if i understand update_output.txt correctly, it is the missing arm64 build of gammaray that blocking things.  Can we kill that?
[12:18] <bdrung_work> pitti, rbasak: is there any package or project that I should assign #1591166 to?
[12:21] <jamespage> apologies if I'm duping existing question but is there something wonky with the proposed migration for dependencies on python-cffi (and its versioned backends)
[12:21] <jamespage> python-oslo.privsep is wedged with
[12:21] <jamespage> python-oslo.privsep/amd64 unsatisfiable Depends: python-cffi-backend-api-min (<= 9729)
[12:21] <jamespage> python-oslo.privsep/amd64 unsatisfiable Depends: python-cffi-backend-api-max (>= 9729)
[12:22] <jamespage> but its quite installable afaict
[12:26] <pitti> ginggs: wow, you were able to decipher that?
[12:26] <pitti> ginggs: hm, it failed on i386 too
[12:27] <pitti> ginggs: gammaray has zero rdepends, so I'm just going to remove it from yakkety, keeping the y-proposed version
[12:27] <ginggs> pitti: i could be completely wrong
[12:27] <pitti> we might just retry the builds
[12:27] <pitti> ginggs: not sure if it's the only cause, but it's certainly *a* cause
[12:29] <pitti> ... done
[12:29] <pitti> bdrung_work: assigned to cloud-images
[12:30] <bdrung_work> thanks
[12:32] <pitti> apw: want a bug for the missing python-yaml test dep? (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/ppc64el/l/linux/20160610_110617@/log.gz)
[12:32] <pitti> apw: such things are a bit hard to spot as the kernel tests have failed for quite some time (but differently)
[12:41] <cjwatson> jamespage: It's conceivable that the britney instance here doesn't understand versioned Provides; that was only added upstream in April
[12:42] <cjwatson> jamespage: somebody in ~ubuntu-release will have the exciting job of sorting out a merge
[12:42] <jamespage> cjwatson, the comment in the newer python-cffi would indicate that might be required as well
[13:05] <apw> pitti, yeah lets have a bug, as i will need to SRU that i assume
[13:08] <pitti> apw: filed bug 1591189, with hopefully quiescing the bot
[13:09] <apw> pitti, thanks, i'll get that sorted out
[13:09] <pitti> cheers!
[13:35] <Odd_Bloke> I have a machine running a DNS server, and /etc/resolv.conf points at localhost.  When cloud-init runs on reboot, it does a getaddrinfo('my.metadata.service.', None) _before_ the DNS server is up (note the trailing dot).  'my.metadata.service' is defined in /etc/hosts, but that isn't found (because the trailing dot isn't stripped off before looking in to /etc/hosts), so cloud-init errors out.
[13:35] <Odd_Bloke> Is the fact that the un-dotted form is not found in /etc/hosts a bug?
[13:40] <rbasak> That's a good question.
[13:40] <rbasak> I have "127.0.0.1	localhost.localdomain	localhost
[13:40] <rbasak> in /etc/hosts
[13:40] <rbasak> getent hosts localhost.localdomain.
[13:40] <rbasak> fails to find anything.
[13:41] <rbasak> I'm not sure DNS semantics applies at nsswitch/hosts file level.
[13:42] <rbasak> I'm struggling to answer the question though, in part because "my.metadata.service." is a hack.
[13:45] <Odd_Bloke> rbasak: A hack how?
[13:48] <rbasak> Odd_Bloke: I don't believe you have service. registered :)
[13:49] <rbasak> Odd_Bloke: the more I think about it, the more I think that it isn't defined that you're speaking DNS, so you can't expect DNS semantics. I'm not sure though.
[13:50] <Odd_Bloke> rbasak: Yeah, it's a slightly weird interface.
[13:51] <rbasak> Odd_Bloke: you could be using NIS :)
[13:51] <rbasak> (what's this "DNS" think you speak of?)  :-)
[13:51] <rbasak> thing
[13:51]  * rbasak can't type today
[13:51] <ginggs> pitti i think you did it - suitesparse is through \o/
[13:52] <pitti> ginggs: ooh! not yet on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt, I was watching it
[13:52] <pitti> but indeed https://launchpad.net/ubuntu/+source/suitesparse/1:4.5.3-1 is landing
[13:52] <ginggs> i'm getting mails of all the packages being accepted
[14:04] <pitti> \o/
[14:13] <infinity> pitti: Yo, what's the deal when britney claims a test is running, but it hasn't shown as running for hours?  Do things sometimes just get lost?
[14:13] <pitti> infinity: which test?
[14:13] <infinity> pitti: (linux-raspi2)
[14:13] <pitti> infinity: there's a few blacklisted ones which can't run, and a corner-case bug which sometimes causes lost  requests
[14:14] <infinity> pitti: It ran and broke 4h ago, but there's no indication that it was restarted.  Doesn't show as failed, though, shows as running.
[14:14] <pitti> ah, this one: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/armhf/l/linux-raspi2/20160610_095800@/log.gz
[14:14] <pitti> it didn't get as far as deciphering a version number, so britney can't match it
[14:15] <infinity> pitti: Ahh, hence "version: n/a" on the result list.
[14:15] <infinity> Seems to have happened fairly regularly.  Weird.
[14:15] <pitti> so, that's an interesting question
[14:16] <pitti> shoudl we somehow get this across to britney as a (failed) test result; but then, how *do* you define an approriate version number
[14:17] <infinity> pitti: Well, if it never even grabbed the source to get a version, shouldn't that be an auto-give-back?  Looks like it's the infra's fault, not the package.
[14:17] <infinity> Or, put another way, if you can blame the package, you surely have a version number.
[14:17] <ginggs> update_excuses.html shows supercollider - old binaries left on armhf: supercollider-supernova (from 1:3.7.0~repack-1)  - what needs to happen there?
[14:18] <pitti> infinity: yeah; I need to run this with --debug to understand what's going on
[14:19] <pitti> infinity: I actually did have that as "tmpfail" for a fair while, but that then caused eternal tmpfail loops/worker killing sprees on packages that were actually not existing or broken
[14:19] <pitti> apt really only gives you one exit code 100 for both transient and permanent issues
[14:19] <pitti> so that needs some more error message parsing fine-tuning
[14:20] <infinity> pitti: Fair enough.  In this case, I can requeue it.  Unless you already have?
[14:20] <pitti> infinity: no, let me first do a manual run to see what's going on
[14:20] <infinity> pitti: Or that.  Go for it.  I'll leave it.
[14:20] <infinity> pitti: The other security kernels got through, I'm less fussed about raspi2 on yakkety.
[14:24] <pitti> infinity: ... and of course this totally works when run manually
[14:25] <infinity> pitti: Of course it does.
[14:25] <infinity> pitti: I mean, historically, it works some of the time. :P
[14:25] <infinity> pitti: But it also seems to fail a lot.
[14:25] <infinity> So, whee.
[14:25] <pitti> infinity: I guess I'll add some logging verbosity then
[14:29] <pitti> oh, it's not exit code 100
[14:29] <pitti> and stderr is already shown
[14:30] <pitti> so, apt fails with !100 with an error on stdout or nonexisting
[14:35] <ginggs> i think singular, supercollider and openms need to be decrufted, please
[14:36] <pitti> ginggs: what does that mean? not on http://people.canonical.com/~ubuntu-archive/nbs.html
[14:36] <ginggs> sorry, maybe wrong term
[14:36]  * pitti wasn't aware that we need to remove NBS from -proposed
[14:36] <pitti> they should just become NBS in -release
[14:37] <pitti> assuming of course that  all remaining reverse dependencies get dropped
[14:37] <pitti> but ICBW
[14:38] <pitti> ginggs: for e. g. singular that just means that it's not built on armhf, and indeed https://launchpad.net/ubuntu/+source/singular/4.0.3-p1+ds-2build2/+build/9804780 is depwwait
[14:39] <pitti> I can't explain the supercollider-supernova thing, I'm afraid
[14:41] <ginggs> ok so for singular then, can we remove the armhf binaries so it can migrate, and it will build when python-polybori becomes available again?
[14:43] <cjwatson> we need to remove NBS from -proposed in the corner case where a source package drops binaries that were previously part of another publication to yakkety-proposed since the last version in yakkety
[14:44] <cjwatson> may not be relevant here, haven't checked
[14:44] <pitti> infinity: ah, found a way to reproduce
[14:45] <pitti> fixing this needs to wait until Monday I'm afraid, I need to run soon; but I take that's  enough
[14:46] <nacc> elbrus: that's what i would start with for sure (re: cacti logs). But note the first regression point happened w/o any change to php proper (afaict) ... so it's hard for me to debug why :)
[14:49] <infinity> ginggs: Erk, who removed polybori on armhf in the first place? :/
[14:49]  * infinity looks.
[14:49] <infinity> Oh, Colin. :P
[14:50] <cjwatson> I imagine I had a reason
[14:50] <infinity> FTBFS on armhf; also removed in Debian
[14:51] <cjwatson> ah yeah, I reckoned that if Debian had given up on it then there was no sense trying *too* hard
[14:51] <infinity> The part where no code changed and it started failing, though, leads one to wonder if polybori is really the problem or if we just papered over something worse.
[14:51] <infinity> (ie: I'd assume it's libpng's fault somehow)
[14:52] <infinity> Or boost.
[14:53] <nacc> rbasak: i made a thinko in my php7.0 upload so it didn't actually change anything (d/control.in vs. d/control). Would you be willing to re-sponsor the debdiff in LP: #1590623
[14:53] <nacc> pitti: yes, once that is done --^ and goes through, php-imagick can go in (i can actually test it once dh-php updates) and that will unblock php-defaults
[14:54] <rbasak> nacc: yep, looking.
[14:54] <nacc> rbasak: thanks!
[14:54]  * pitti waves good bye and happy weekend
[14:54] <infinity> pitti: See you soon
[14:55] <infinity> pitti: Oh, what's the deal with that raspi2?  Is it handled, or do I need to do things to it?
[14:55] <ginggs> bye pitti
[15:19] <rbasak> nacc: I have to run (early EOD to catch a train) but I think there's a bug in usd-merge.
[15:19] <rbasak> It's quite confusing. I tried to "undo" a "usd-merge commit" while experimenting.
[15:20] <rbasak> I've ended up with a .git/ubuntu/yakkety "ref", which seems to override .git/refs/heads/ubuntu/yakkety.
[15:21] <rbasak> So when I reset the ubuntu/yakkety branch back to its original hash, "git-rev-parse ubuntu/yakkety" and thus "usd-merge commit" both don't see it, which causes a bunch of extra merge commits as I redo each time, IYSWIM.
[15:21] <rbasak> I think the problem is that the call to "git update-ref" needs to be "refs/heads/ubuntu/yakkety" rather than just "ubuntu/yakkety".
[15:22] <nacc> rbasak: hrm, i'll re-read the man-page
[15:22] <nacc> and test locally
[15:22] <rbasak> Thanks!
[15:22] <nacc> rbasak: i know there's also a bug with `usd-merge reconstruct` and upload/ tags
[15:23] <nacc> as those can't be cherry-picked the same
[15:29] <nacc> rbasak: ack, you're right, fixing it and pushing
[15:31] <nacc> barry: fyi, we've combined that gh repository with the lp one. And i've updated the wiki references as well
[15:32] <barry> nacc: cool.  did rbasak land pr#2 yet?
[15:32] <nacc> barry: i just pulled it in to our combined repository. I think rbasak will close the gh one eventually. So since i have write access to the lp one, i was able to commit the changes directly :)
[15:32] <barry> nacc: cool :)
[15:33] <bdmurray> pitti: How did you restart it tgt/wily?  I forget how to do that.
[15:34] <anaran> hi, will firefox be available on ubuntu phones soon, without external display connected (similar to firefox for android)?
[15:39] <nacc> i think rbasak wasn't able to get to it before he left, but could someone help sponsor the latest debdiff in LP: #1590623 ? Needed to help unblock one set of php* in excuses
[16:10] <rbasak> nacc: I did upload it, sorry I didn't say. I guess you don't get the email? Anyway, it's in proposed :)
[16:11] <nacc> rbasak: interesting, yeah, i wasn't notified and i hadn't seen it yet in excuses
[16:12] <nacc> rbasak: ah probably because it's still building, got it
[16:35] <nacc> rbasak: tahnks! i can see the proposed builds have the right deps now
[16:36] <rbasak> No problem :)
[17:38] <dobey> anaran: an external display isn't required, but it's not particularly useful to run firefox on a phone. if you want to know if mozilla is going to ship a version of firefox suited for use on phones/tablets, in the ubuntu store, you'd have to ask mozilla.
[17:45] <ogra_> dobey, you just need a mouse,keyboard and a good looking-glass :P
[17:53] <dobey> ogra_: well, when the keyboard integration is fixed, you won't need an external keyboard
[18:07] <slangasek> pitti: as ginggs said, metis was already promoted, so somebody else re-demoted it without looking at component-mismatches-proposed
[18:55] <elbrus> does anybody here no a good example of autopkgtest tests that add log files to the artifacts?
[18:55] <elbrus> s/no/know/
[18:56]  * elbrus has "set -e" so can't just do it at the end of the test
[21:20] <kees> doko: any chance you can take a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826786 ? I'm really not sure how it's best solved, but it's blocking upstream kernel testing of the new gcc plugin infrastructure
[21:36] <nacc> slangasek: would you be able to assist me with the bootstrap for phpunit? I've verified the steps needed, and I think this will unblock the majority of the stuck php packages (as phpunit will be updated and installabe)
[22:04] <slangasek> nacc: I'm not going to get to it today; maybe infinity could help
[22:04] <nacc> slangasek: ok, np
[22:05] <nacc> infinity: if you're around, i need to bootstrap build 3 packages with DEB_BUILD_OPTIONS as they all interdepend (but the end-result, which we'd want to copy to the archive doesn't require any DEB_BUILD_OPTIONS and builds successfully in my testing)