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:14 |
---|---|---|
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:27 |
nacc | slangasek: http://autopkgtest.ubuntu.com/packages/c/cacti/yakkety/armhf/ | 00:28 |
nacc | slangasek: started failing about a week ago, it seems | 00:28 |
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:29 |
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:32 |
nacc | slangasek: ack, that makes sense to me :) | 00:33 |
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:34 |
nacc | slangasek: yeah :) | 00:35 |
nacc | slangasek: i was at quite a loss on how to figure out what was going on | 00:35 |
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:36 |
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:51 |
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:53 |
nacc | alternatively, if it's possible, we could pass DEB_BUILD_OPTIONS=nocheck to the builder for php-codecoverage and it builds fine | 00:58 |
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:01 |
nacc | slangasek: ack, i'm just verifying both build successfully afterwards | 01:02 |
nacc | slangasek: ok, this process worked for me locally: http://paste.ubuntu.com/17162006/ | 01:24 |
=== juliank is now known as Guest53138 | ||
=== juliank_ is now known as juliank | ||
nacc | note that the php-mock-object build is a needed merge (reviewed by rbasak already) | 01:25 |
=== mnepton is now known as mneptok | ||
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:03 |
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:05 |
sergiusens | ah that can explain it | 02:06 |
sergiusens | slangasek I guess this would block my SRUing | 02:07 |
slangasek | sergiusens: no reason that it should | 02:07 |
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:08 |
sergiusens | fair enough | 02:09 |
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:10 |
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:15 |
slangasek | only in libpython3.5-dev, which I didn't have installed :-) | 02:16 |
slangasek | sergiusens: ... and which is not a build-dep of snapcraft either | 02:17 |
sergiusens | slangasek yeah, I wonder how it ever worked... | 02:17 |
slangasek | probably by the previous version not unnecessarily requiring that Makefile :) | 02:18 |
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:21 |
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:23 |
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:27 |
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:32 |
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:33 |
nacc | slangasek: ack, sorry | 02:39 |
=== Spads_ is now known as Spads | ||
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:53 |
nacc | argh, i know why, nm | 02:55 |
nacc | control.in vs. control | 02:55 |
=== Spads_ is now known as Spads | ||
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:31 |
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 | 03:33 |
=== Spads_ is now known as Spads | ||
pitti | bdmurray: tgt> I'll look | 05:35 |
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:37 |
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:38 |
pitti | but I tried with --all-proposed often enough, that's not it -- something in y-proposed is really missing | 05:39 |
pitti | nacc: so php7.0 landed, nice work! so I take it your php-imagick merge can land now? | 05:40 |
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:53 |
ubottu | Launchpad bug 1556685 in oce (Ubuntu Xenial) "Wrong installation path (0.16 instead of 0.17)" [Undecided,Incomplete] https://launchpad.net/bugs/1556685 | 05:53 |
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:56 |
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:57 |
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:58 |
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 | 05:59 |
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:01 |
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:02 |
pitti | ginggs: and formulate the test case and regression potential accordingly | 06:03 |
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:04 |
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:06 |
ubottu | Launchpad bug 1556680 in oce (Ubuntu Xenial) "[SRU] Wrong library path in CMake file for 64bit system" [Undecided,Fix committed] https://launchpad.net/bugs/1556680 | 06:06 |
ubottu | Launchpad bug 1556685 in oce (Ubuntu Xenial) "Wrong installation path (0.16 instead of 0.17)" [Undecided,Incomplete] https://launchpad.net/bugs/1556685 | 06:06 |
pitti | ginggs: ah, the joy of SRU bugs; never do that, please | 06:17 |
ginggs | pitti: never do what, exactly? | 06:25 |
pitti | ginggs: open a separate bug #2 that says "SRU for bug #1" | 06:26 |
ubottu | Error: Launchpad bug 2 could not be found | 06:26 |
ubottu | bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/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:26 |
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:27 |
pitti | ginggs: ah, maybe they are different issues, sorry then; (they sound similar) | 06:28 |
ginggs | LP: #1556680 is the real bug | 06:28 |
ubottu | Launchpad bug 1556680 in oce (Ubuntu Xenial) "[SRU] Wrong library path in CMake file for 64bit system" [Undecided,Fix committed] https://launchpad.net/bugs/1556680 | 06:28 |
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 |
ubottu | Launchpad bug 1556685 in oce (Ubuntu Xenial) "Wrong installation path (0.16 instead of 0.17)" [Undecided,Incomplete] https://launchpad.net/bugs/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:31 |
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:32 |
brendand | --nocapture, great - thanks | 06:34 |
doko | slangasek, hmm, I don't see the issue yet | 06:51 |
pitti | doko: many thanks for uploading py3.5, much appreciated! | 06:58 |
* pitti feeds the Launchpad hamsters to import it | 06:58 | |
doko | pitti, hmm, see above, slangasek claims that -15 is broken. still investigating why | 07:00 |
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:45 |
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:55 |
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:56 |
pitti | infinity: so I'll add a force-badtest for amd64 for that version, to avoid asking you again next time :) | 07:57 |
pitti | bdmurray: tgt/wily was a spurious failure apparently, succeeded now | 08:01 |
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:03 |
pitti | apw: ack, thanks | 08:04 |
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:05 |
apw | infinity, which is wrong on so many levels :) | 08:06 |
xnox | pitti, huh, that looks weird... I'll check if I dropped or reordered patches... unless upstream renumbered things which is abi break.... | 08:40 |
xnox | also no clue why these syscalls are negative =/ | 08:41 |
ogra_ | just turn the around ;) | 08:44 |
ogra_ | *them | 08:44 |
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:53 |
pitti | "someone will fix it eventually" | 09:54 |
ginggs | pitti: i thought slangasek promoted libmetis5 already | 10:01 |
ginggs | pitti: LP: #1588407 | 10:02 |
ubottu | Launchpad bug 1588407 in metis (Ubuntu) "[MIR] metis" [Undecided,Fix released] https://launchpad.net/bugs/1588407 | 10:02 |
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:03 |
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:04 |
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:05 | |
bdrung_work | pitti, btw, do you know whom to talk to about the cloud images? i like to have consoleblank disabled there. | 10:09 |
rbasak | bdrung_work: bug 869017 | 10:10 |
ubottu | bug 869017 in kbd (Ubuntu) "Ubuntu server enables screenblanking, concealing crashdumps (DPMS is not used)" [Medium,Triaged] https://launchpad.net/bugs/869017 | 10:10 |
bdrung_work | thanks rbasak | 10:12 |
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 :) | 10:13 |
=== hikiko is now known as hikiko|ln | ||
=== hikiko|ln is now known as hikiko | ||
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... | 11:59 |
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:00 |
* 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:01 | |
=== zyga_ is now known as zyga | ||
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:14 |
bdrung_work | pitti, rbasak: is there any package or project that I should assign #1591166 to? | 12:18 |
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:21 |
jamespage | but its quite installable afaict | 12:22 |
pitti | ginggs: wow, you were able to decipher that? | 12:26 |
pitti | ginggs: hm, it failed on i386 too | 12:26 |
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:27 |
pitti | ... done | 12:29 |
pitti | bdrung_work: assigned to cloud-images | 12:29 |
bdrung_work | thanks | 12:30 |
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:32 |
cjwatson | jamespage: It's conceivable that the britney instance here doesn't understand versioned Provides; that was only added upstream in April | 12:41 |
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 | 12:42 |
apw | pitti, yeah lets have a bug, as i will need to SRU that i assume | 13:05 |
pitti | apw: filed bug 1591189, with hopefully quiescing the bot | 13:08 |
ubottu | bug 1591189 in linux (Ubuntu) "missing python-yaml autopkgtest dependency" [Undecided,Confirmed] https://launchpad.net/bugs/1591189 | 13:08 |
apw | pitti, thanks, i'll get that sorted out | 13:09 |
pitti | cheers! | 13:09 |
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:35 |
rbasak | That's a good question. | 13:40 |
rbasak | I have "127.0.0.1localhost.localdomainlocalhost | 13:40 |
rbasak | in /etc/hosts | 13:40 |
rbasak | getent hosts localhost.localdomain. | 13:40 |
rbasak | fails to find anything. | 13:40 |
rbasak | I'm not sure DNS semantics applies at nsswitch/hosts file level. | 13:41 |
rbasak | I'm struggling to answer the question though, in part because "my.metadata.service." is a hack. | 13:42 |
Odd_Bloke | rbasak: A hack how? | 13:45 |
rbasak | Odd_Bloke: I don't believe you have service. registered :) | 13:48 |
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:49 |
Odd_Bloke | rbasak: Yeah, it's a slightly weird interface. | 13:50 |
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:51 |
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 | 13:52 |
pitti | \o/ | 14:04 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
pitti | infinity: yeah; I need to run this with --debug to understand what's going on | 14:18 |
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:19 |
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:20 |
pitti | infinity: ... and of course this totally works when run manually | 14:24 |
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:25 |
pitti | oh, it's not exit code 100 | 14:29 |
pitti | and stderr is already shown | 14:29 |
pitti | so, apt fails with !100 with an error on stdout or nonexisting | 14:30 |
ginggs | i think singular, supercollider and openms need to be decrufted, please | 14:35 |
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:36 |
pitti | assuming of course that all remaining reverse dependencies get dropped | 14:37 |
pitti | but ICBW | 14:37 |
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:38 |
pitti | I can't explain the supercollider-supernova thing, I'm afraid | 14:39 |
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:41 |
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:43 |
cjwatson | may not be relevant here, haven't checked | 14:44 |
pitti | infinity: ah, found a way to reproduce | 14:44 |
pitti | fixing this needs to wait until Monday I'm afraid, I need to run soon; but I take that's enough | 14:45 |
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:46 |
infinity | ginggs: Erk, who removed polybori on armhf in the first place? :/ | 14:49 |
* infinity looks. | 14:49 | |
infinity | Oh, Colin. :P | 14:49 |
cjwatson | I imagine I had a reason | 14:50 |
infinity | FTBFS on armhf; also removed in Debian | 14:50 |
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:51 |
infinity | Or boost. | 14:52 |
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 |
ubottu | Launchpad bug 1590623 in php7.0 (Ubuntu) "Drop dh-php from Recommends to Suggests" [Undecided,In progress] https://launchpad.net/bugs/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:53 |
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:54 |
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 | 14:55 |
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:19 |
rbasak | I've ended up with a .git/ubuntu/yakkety "ref", which seems to override .git/refs/heads/ubuntu/yakkety. | 15:20 |
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:21 |
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:22 |
nacc | as those can't be cherry-picked the same | 15:23 |
nacc | rbasak: ack, you're right, fixing it and pushing | 15:29 |
nacc | barry: fyi, we've combined that gh repository with the lp one. And i've updated the wiki references as well | 15:31 |
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:32 |
bdmurray | pitti: How did you restart it tgt/wily? I forget how to do that. | 15:33 |
anaran | hi, will firefox be available on ubuntu phones soon, without external display connected (similar to firefox for android)? | 15:34 |
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 | 15:39 |
ubottu | Launchpad bug 1590623 in php7.0 (Ubuntu) "Drop dh-php from Recommends to Suggests" [Undecided,In progress] https://launchpad.net/bugs/1590623 | 15:39 |
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:10 |
nacc | rbasak: interesting, yeah, i wasn't notified and i hadn't seen it yet in excuses | 16:11 |
nacc | rbasak: ah probably because it's still building, got it | 16:12 |
nacc | rbasak: tahnks! i can see the proposed builds have the right deps now | 16:35 |
rbasak | No problem :) | 16:36 |
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:38 |
ogra_ | dobey, you just need a mouse,keyboard and a good looking-glass :P | 17:45 |
dobey | ogra_: well, when the keyboard integration is fixed, you won't need an external keyboard | 17:53 |
slangasek | pitti: as ginggs said, metis was already promoted, so somebody else re-demoted it without looking at component-mismatches-proposed | 18:07 |
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:55 |
* elbrus has "set -e" so can't just do it at the end of the test | 18:56 | |
=== Spads_ is now known as Spads | ||
=== Spads_ is now known as Spads | ||
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:20 |
ubottu | Debian bug 826786 in src:gcc-6-cross "gcc-6-cross: No gcc plugin headers for cross compilers" [Wishlist,Open] | 21:20 |
=== tinoco is now known as tinoco-vacation | ||
=== tinoco-vacation is now known as tinoco | ||
=== tinoco is now known as tinoco-vacation | ||
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) | 21:36 |
slangasek | nacc: I'm not going to get to it today; maybe infinity could help | 22:04 |
nacc | slangasek: ok, np | 22:04 |
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) | 22:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!