| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| pitti | Good morning | 05:42 |
|---|---|---|
| gilbahat | Hi, quick question if anybody knows: what happens to ‘proposed’ yakkety packages? I think they can’t make it by now, but will they stay in some other compliant repo or something? | 05:49 |
| RAOF | gilbahat: No, everything goes through yakkety-proposed. | 05:50 |
| RAOF | gilbahat: Everything in yakkety-proposed is expected to migrate to yakkety before release. | 05:50 |
| cpaelzer | good Morning | 05:51 |
| gilbahat | RAOF: ah, really? that’s cool. I thought the current freeze state meant that by now anything that didn’t make it to main by now won’t make it in after all. | 05:51 |
| RAOF | No. We're currently in feature-freeze, but expect plenty more bugfix uploads before release. | 05:52 |
| RAOF | And *all* uploads go through yakkety-proposed. | 05:52 |
| gilbahat | it’s not a bugfix release, it’s a major upstream release (syslog-ng 3.5.6 vs 3.7.3). it’s already in proposed now and I hope it will get released with 3.7.3 | 05:53 |
| pitti | RAOF: not actually true -- stuff that gets stuck in y-proposed just gets moved to z-proposed after y's release | 05:54 |
| RAOF | pitti: But we don't *expect* things to be stuck in y-proposed; that indicates that someone has failed, right? | 05:54 |
| pitti | there's usually two metric tons of that | 05:54 |
| RAOF | Heh, OK. | 05:55 |
| pitti | RAOF: right, of course | 05:55 |
| pitti | there's still a lot of autosyncs which regressed, and nobody feels particularly attached to them | 05:55 |
| pitti | and half-finished library transitions | 05:55 |
| RAOF | gilbahat: If it was in -proposed before the freeze was announced, it should go in without further effort. If it was uploaded post feature-freeze, someone will need to explicitly request a freeze exception. | 05:55 |
| pitti | so indeed the intention is to clear it all up, it's just a lot of work | 05:55 |
| gilbahat | RAOF: any place I can check that somehow? | 05:56 |
| gilbahat | pitti: is it going to also stay in some -extra repo or something perhaps? | 05:56 |
| pitti | gilbahat: well, devel-proposed :) | 05:57 |
| pitti | i. e. we release y, open z, and move the remaining y-proposed packages into z-proposed | 05:57 |
| gilbahat | pitti: from launchpad.net I see it’s been uploaded at 16th of July. that’s over a month before the feature freeze if I’m reading it correctly. | 06:00 |
| pitti | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#syslog-ng this one? | 06:01 |
| pitti | looks like a library transition | 06:01 |
| pitti | trying: syslog-ng | 06:01 |
| pitti | skipped: syslog-ng (0, 3, 17) | 06:01 |
| pitti | got: 147+0: a-32:a-15:a-15:i-20:p-16:p-15:s-34 | 06:01 |
| pitti | * amd64: syslog-ng-mod-basicfuncs-plus, syslog-ng-mod-lua, syslog-ng-mod-perl, syslog-ng-mod-rss, syslog-ng-mod-trigger | 06:01 |
| pitti | I guess syslog-ng-incubator needs to be updated as well | 06:01 |
| pitti | or at least rebuilt against the new version, as it has strict deps like syslog-ng-core (>= 3.5.6~), syslog-ng-core (<< 3.5.7~) | 06:01 |
| pitti | https://tracker.debian.org/news/785441 looks like it fits | 06:02 |
| * pitti syncs that | 06:03 | |
| pitti | oh, it's already in -proposed, just FTBFS on s390x | 06:03 |
| pitti | gilbahat: so this is the problem: https://launchpadlibrarian.net/281969183/buildlog_ubuntu-yakkety-s390x.syslog-ng-incubator_0.5.0-1_BUILDING.txt.gz | 06:04 |
| pitti | FAIL modules/grok/tests/test_grok (exit status: 139) sounds like a segfault (signal 11) | 06:04 |
| sarnold | I suspect it's related to the warning about incorrect fprintf types mentioned right next to the test_grok build... | 06:07 |
| sarnold | (they may just be mixed in due to make -j .. but it's plausible anyway) | 06:08 |
| gilbahat | sarnold: but test_date passes. so it’s probably not it. but I can’t help unless I get an s390 machine and I have no idea how on earth to get access to one… or else report this to balabit and hope they have access to one. it could be an upstream bug as well. | 06:09 |
| pitti | the build log is a real joy of incompatible pointer types indeed | 06:10 |
| sarnold | loads of em | 06:10 |
| sarnold | glebihan: hercules may work for this | 06:11 |
| sarnold | I haven't used it myself :( | 06:11 |
| gilbahat | sarnold: there’s also support in qemu it seems. | 06:17 |
| gilbahat | but it’s weird, 3.7.3-1 is in sid, it builds correctly for s390x, but the build log doesn’t mention test_grok at all | 06:17 |
| gilbahat | or grok for that matter | 06:17 |
| gilbahat | https://buildd.debian.org/status/fetch.php?pkg=syslog-ng-incubator&arch=s390x&ver=0.5.0-1&stamp=1468967484 | 06:24 |
| sarnold | very interesting | 06:27 |
| gilbahat | are builds attempted again to account for possible transient errors (as rare as they may be)? | 06:28 |
| sarnold | 1.20110708.1-4.1ubuntu1 vs 1.20110708.1-4.1 | 06:28 |
| sarnold | libgrok-dev versions changed between the two builds, anyway | 06:28 |
| gilbahat | that looks like a very ancient and unmaintained library. or maybe solid enough not to need any changes… | 06:29 |
| sarnold | heh at least it's 2011 not 2001 :) | 06:29 |
| gilbahat | ok, so ancient not very ancient :P | 06:29 |
| gilbahat | so now I need to hunt down what patches did ubuntu1 have over vanilla | 06:31 |
| sarnold | gilbahat: https://patches.ubuntu.com/g/grok/ | 06:33 |
| gilbahat | thanks! but that brings me back to square 1 because it looks like it’s unrelated. this change would have broken the build and not the test, or cause test_grok to miss symbols and not segfault | 06:35 |
| gilbahat | ok, i’ve emailed balabit, I hope they can help, in the interim i’ll have to use the packages from proposed or keep a copy of them aside for my needs. | 06:36 |
| pitti | gilbahat: FTR, I retried the build earlier, and it still fails | 06:37 |
| gilbahat | pitti: thanks, that’s so weird. I hope someone would be able to make sense out of it. | 06:38 |
| Saviq | pitti, hey, we're down to 1h20m for a green unity8 run, so you can pop it from the list of long-running tests \o/ we've uncovered one more flaky test though... we're on it, but can you please recycle https://requests.ci-train.ubuntu.com/static/britney/landing-078/yakkety/excuses.html in the mean time? thanks | 06:48 |
| Saviq | also not sure if all the "In Progress" ones are actually running, there's been so many... | 06:50 |
| pitti | Saviq: very nice, good work! done | 06:51 |
| pitti | Saviq: yeah, queues still feel the backlog of yesterday's Qt double landing | 06:51 |
| pitti | Saviq: s390x broke yesterday (just fixed, catching up), and armhf is just, well, armhf :) | 06:52 |
| pitti | retried the two unity8 failures | 06:52 |
| Saviq | yeah, we mostly care about i386 and amd64 still - getting the tests to pass on arm* will be another feat... | 06:53 |
| Saviq | thanks! | 06:53 |
| pitti | Saviq: err, isn't unity8 what's running on the phone? | 06:55 |
| Saviq | pitti, yes, but the phone's much faster than the armhf testers, all the failures (there's only 2% afaict anyway) stem from timing issues in the tests - people have more patience than the test :) | 06:58 |
| Saviq | part of it is we're doing GL in software, so without a GPU the CPU requirements are much higher | 06:59 |
| === thegodfather is now known as fabbione | ||
| pitti | Saviq: ah, understood -- so we do care about unity8 on armhf, just not on *these* armhf boxes :) | 07:02 |
| Saviq | pitti, yeah, correct | 07:03 |
| Saviq | I looked through the failures and there's only 20-30 fails (and then a timeout after 2h50m...), out of a 1.3k+ test suite | 07:03 |
| Saviq | so it could be worse | 07:04 |
| Saviq | we might even make it work at some point | 07:04 |
| Saviq | pitti, it looks like some runs got lost for our silo, at least "running" doesn't show them - apart from the regressions you restarted earlier the only pending results for silo 078 are for armhf and s390x - do you have a way to queue the missing ones or shall I list them for you? | 08:47 |
| pitti | Saviq: I have a script for it | 08:48 |
| pitti | Saviq: what's the excuses URL? | 08:48 |
| Saviq | pitti, https://requests.ci-train.ubuntu.com/static/britney/landing-078/vivid/excuses.html https://requests.ci-train.ubuntu.com/static/britney/landing-078/xenial/excuses.html https://requests.ci-train.ubuntu.com/static/britney/landing-078/yakkety/excuses.html | 08:50 |
| pitti | Saviq: http://autopkgtest.ubuntu.com/running#pkg-unity8 still has a metric ton of running tests | 08:52 |
| Saviq | pitti, all armhf ones | 08:52 |
| pitti | vivid/i386 too | 08:52 |
| Saviq | (for that ppa) | 08:52 |
| pitti | and y/amd64 | 08:52 |
| pitti | oh, these are 73 | 08:52 |
| Saviq | pitti, not for landing-078 | 08:52 |
| Saviq | yup | 08:52 |
| pitti | there are more queued for 078 | 08:52 |
| Saviq | only s390x and armhf, too | 08:53 |
| pitti | y/i386 has two | 08:53 |
| Saviq | with the exception of the two i386 ones you restarted earlier :) | 08:53 |
| pitti | and armhf/s390x is all that is missing from https://requests.ci-train.ubuntu.com/static/britney/landing-078/yakkety/excuses.html | 08:54 |
| Saviq | pitti, yes, yakkety looks good | 08:54 |
| Saviq | on v it's amd64 with trigger ubuntu-settings-components | 08:54 |
| Saviq | and unity-scope-click/i386 and unity8/amd64 with trigger unity8 | 08:55 |
| === sakrecoe1 is now known as sakrecoer | ||
| Saviq | on x it's unity-scopes-api/i386 with trigger unity-api and qtcreator-plugin-ubuntu/i386 with trigger unity8 | 08:56 |
| Saviq | pitti, those five are missing afaict ↑ | 08:57 |
| cpaelzer | xnox: fyi we got no highlight for it by bileto yet but I've seen that the dependent autopkgtests for 1950 fail for systemd-fsck | 08:57 |
| pitti | Saviq: also, the queue view is often missing some queued items (trying to find out why); I'll let the dust settle and restart bits as necessary | 08:58 |
| Saviq | pitti, ok, wfm | 08:58 |
| pitti | smoser: found bug 1623868; do you agree to the solution? | 10:25 |
| ubottu | bug 1623868 in cloud-init (Ubuntu) "cloud-final.service does not run due to dependency cycle" [High,Confirmed] https://launchpad.net/bugs/1623868 | 10:25 |
| ogra_ | (classic)ogra@localhost:~$ sudo apt-get install vim libpython3.5 libpython3.5-stdlib | 10:27 |
| ogra_ | ... | 10:27 |
| ogra_ | The following packages have unmet dependencies: | 10:27 |
| ogra_ | libpython3.5 : Depends: libpython3.5-stdlib (= 3.5.2-2~16.01) but 3.5.2-2~16.04 is to be installed | 10:27 |
| ogra_ | E: Unable to correct problems, you have held broken packages. | 10:27 |
| ogra_ | (classic)ogra@localhost:~$ | 10:27 |
| ogra_ | hmm | 10:27 |
| pitti | libpython3.5-stdlib | 3.5.2-2~16.01 | xenial-updates | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x | 10:29 |
| pitti | LGTM? | 10:29 |
| ogra_ | did something slip out of -proposed ? | 10:29 |
| acheronuk | Do I understand correctly that a bug for a feature freeze exception can be submitted during and beyond the start of beta freeze? It's just that it won't be acted on during? | 10:30 |
| ogra_ | oooh ! | 10:30 |
| pitti | apt-cache policy? | 10:30 |
| cjwatson | acheronuk: no reason to delay submitting bugs, in general | 10:30 |
| ogra_ | well, the ubuntu-core snap in the edge channel (which i use here as rootfs) gets built against -proposed | 10:30 |
| pitti | acheronuk: reviewing freeze exception bugs is not by itself bound by freezes | 10:30 |
| ogra_ | but the classic cheoor only gets -updates in its sources.list | 10:30 |
| ogra_ | *chroot | 10:30 |
| ogra_ | hmm | 10:30 |
| ogra_ | but i use the rootfs sources.list as base ... i wonder why builds with PROPOSED=1 do not have -proposed in there then ... | 10:33 |
| acheronuk | cjwatson: I'm just asking in case the people who would not submit a FFE are not around. There are issues with their availability, so I just wanted to know if next weeks beata freeze was a hard deadline or not. I understood that it was not, but if I or someone else elnd up having to do it I want to be sure of how much time there is. | 10:33 |
| acheronuk | *would normally submit | 10:33 |
| Mirv | pitti: does it work if I construct autopkgtest request url to retry a test that is in limbo ("in progress" but not really completed, queued or running)? I think I constructed the url right http://pastebin.ubuntu.com/23181731/ but I don't get the stuck one from http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#ubuntu-ui-toolkit visible on the running page | 10:35 |
| pitti | Mirv: yes, you can do that; it's also easier to use http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/retry-autopkgtest-regressions with --state=RUNNING | 10:37 |
| Mirv | pitti: now if only I'd find run-autopkgtest from somewhere? | 10:49 |
| pitti | Mirv: oh right, sorry; nevermind | 10:49 |
| pitti | Mirv: currently needs shell access; I wanted to move it to request.cgi at some point, but didn't yet | 10:50 |
| Mirv | yes, so I've heard, I thought this might be something new :) | 10:50 |
| Mirv | anyway, it seems now it's running when I refreshed my request page, weird that I didn't get it running on first try (or so it seemed) | 10:50 |
| pitti | Mirv: the /running page is no miracle, take it with a grain of salt | 10:52 |
| Mirv | pitti: ok, I do query the completed results directly from the API to know if a "running" test is truly disappeared or not. | 10:53 |
| pitti | Mirv: the web UI has a latency of ≤ 5 mins now, btw | 10:53 |
| Mirv | oh, ok | 10:57 |
| doko_ | sil2100: robru: please could you chase down the thumbnailer uploaders to have the ftbfs fixed? | 10:58 |
| === doko_ is now known as doko | ||
| xnox | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is stuck? | 11:38 |
| cpaelzer | xnox: you mean the update on the page itself? | 11:39 |
| xnox | Generated: 2016.09.15 10:15:33 +0000 -> it is 11:41 zulu time... | 11:41 |
| xnox | horum, it is still running.... http://people.canonical.com/~ubuntu-archive/proposed-migration/log/yakkety/2016-09-15/10:37:59.log | 11:42 |
| Mirv | xnox: yeah looks like stuck | 11:47 |
| Mirv | or whatever is happening with that run that now has a size of 8 times the 30 earlier runs | 11:47 |
| Mirv | log size | 11:47 |
| === _salem is now known as salem_ | ||
| xnox | pitti, i think autopkgtest is dead =( | 12:07 |
| xnox | http://autopkgtest.ubuntu.com/statistics -> A server error occurred. Please contact the administrator. | 12:07 |
| xnox | and i guess that britney is stuck DDoS-ing autopkgtest.ubuntu.com | 12:08 |
| pitti | xnox: oh, I have some idea about /statistics | 12:12 |
| pitti | xnox: I added test IDs for vivid without any result, to make vivid queues appear on /running | 12:12 |
| pitti | xnox: smells like division by zero,checking | 12:12 |
| xnox | /o\ | 12:12 |
| xnox | we do divide by total without a check in the template | 12:12 |
| xnox | could return float('NaN') | 12:13 |
| pitti | xnox: WDYM about britney being stuck DDoSing? | 12:13 |
| xnox | well, 10:37:59 run generated 9.3M log file, instead of a usual 1.3M | 12:15 |
| xnox | http://people.canonical.com/~ubuntu-archive/proposed-migration/log/yakkety/2016-09-15/?C=M;O=D | 12:15 |
| xnox | and took like 1h22min | 12:15 |
| pitti | jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'vivid' | 12:17 |
| xnox | horum. | 12:17 |
| pitti | xnox: ah yes, I needed to delete the cache as doko wanted some results lobotomized; next run should be fine again | 12:17 |
| xnox | should do a get, and skip a column i guess, or return zeros. | 12:17 |
| pitti | xnox: I'll look into it, should be simple | 12:18 |
| Mirv | http://people.canonical.com/~ubuntu-archive/proposed-migration/log/yakkety/2016-09-15/12:09:35.log ended in KeyError: 'lava-server' | 12:18 |
| xnox | charming | 12:18 |
| pitti | Saviq: I retried the two lost ones, the others arrived now | 12:24 |
| Mirv | same error for the 12:17:40 | 12:25 |
| Saviq | pitti, ack thanks | 12:31 |
| Saviq | pitti, there's four missing in total, no? https://requests.ci-train.ubuntu.com/static/britney/landing-078/vivid/excuses.html https://requests.ci-train.ubuntu.com/static/britney/landing-078/xenial/excuses.html | 12:32 |
| pitti | Saviq: unity8 runs for two different triggers | 12:33 |
| Saviq | pitti, yeah, but there's also one vivid/unity-scope-click and xenial/qtcreator-plugin-ubuntu each | 12:33 |
| Saviq | under unity8 and ubuntu-settings-components, respectively | 12:34 |
| Saviq | ah no, both under unity8 trigger | 12:34 |
| smoser | pitti, :-( | 12:35 |
| Saviq | I just mean they're not unity8 runs, but triggered by it | 12:35 |
| smoser | how would that be transient | 12:35 |
| pitti | Saviq: WDYM? https://requests.ci-train.ubuntu.com/static/britney/landing-078/xenial/excuses.html has one qtcreator run, https://requests.ci-train.ubuntu.com/static/britney/landing-078/vivid/excuses.html has one unity8 (for two triggers) and one unity-scope-click; three in total | 12:36 |
| pitti | smoser: not transient, just depends on where the cycle gets broken -- at cloud-init.target or cloud-final.target (and that's not stable indeed) | 12:36 |
| Saviq | pitti, yes, four missing across the two releases | 12:36 |
| Saviq | if those four are queued now, we should be good | 12:37 |
| smoser | pitti, http://paste.ubuntu.com/23181973/ | 12:37 |
| smoser | right ? | 12:37 |
| pitti | smoser: I'd put it below Description=, but yes | 12:37 |
| smoser | i just dont understand how we didn't see this before | 12:38 |
| smoser | when devbugging this, you and i both did dozens of lxc boots | 12:39 |
| pitti | smoser: nothing depends on cloud-init.target, so it wasn't obvious that it's not active? | 12:39 |
| smoser | possibly. but you're seeing cloud-final.service | 12:39 |
| smoser | which is explicitly what we were testing, for package installation | 12:39 |
| smoser | well, i see the cloud-init.target issue for sure. | 12:41 |
| smoser | pitti, i think you're saying that systemd will break the cycle that it finds and sometimes kill cloud-final.service, and sometimes kill cloud-init.target | 12:45 |
| smoser | is that right | 12:45 |
| pitti | right | 12:45 |
| smoser | cpaelzer, ^ | 12:45 |
| cpaelzer | I can repro with uvtool as well | 12:45 |
| smoser | yeah, i see too. | 12:46 |
| cpaelzer | sorry already hit submit on the bug update, you might already be further in the debugging | 12:46 |
| cpaelzer | reading backlog here | 12:46 |
| smoser | somewhat obnoxious that systemd does kill(random(set-of-tasks-that-have-loop)) | 12:46 |
| smoser | cpaelzer, i'd like to see your journal in the one where it killed cloud-final.service | 12:46 |
| smoser | heres one without cloud-init.target | 12:47 |
| smoser | http://paste.ubuntu.com/23182002/ | 12:47 |
| smoser | line 464-ish | 12:47 |
| cpaelzer | smoser: well the dependency resolution kills cloud-init.target/start sa well for me | 12:47 |
| cpaelzer | smoser: I just found it not to create the /var/lib/cloud/instance/boot-finished file | 12:47 |
| cpaelzer | smoser: for what its worth http://paste.ubuntu.com/23182006/ | 12:48 |
| smoser | cpaelzer, in that vm you dont have the boot-finished ? | 12:48 |
| cpaelzer | smoser: yes | 12:49 |
| pitti | I got it in some scalingstack instances | 12:49 |
| smoser | pastebin /var/log/cloud-init.log ? | 12:49 |
| pitti | hard to reproduce, but I was wondering why some of them time out | 12:49 |
| cpaelzer | smoser: the file is missing - that just crossed my mind as uvt-kvm wait polls for it | 12:49 |
| pitti | (sorry, these are gone) | 12:49 |
| cpaelzer | smoser: http://paste.ubuntu.com/23182012/ /var/log/cloud-init.log | 12:49 |
| smoser | cpaelzer, line 587 | 12:50 |
| smoser | so i'm really confused | 12:50 |
| * cpaelzer is spawning another vm | 12:52 | |
| cpaelzer | of course after 4 times breaking this time it had to work :-/ | 12:53 |
| cpaelzer | retrying a few more | 12:53 |
| smoser | what pitti describes seems reasonable, that systemd just decided to drop cloud-final. | 12:56 |
| smoser | i'd just like to see it actually happen | 12:56 |
| smoser | s/reasonable/possible/ | 12:57 |
| cpaelzer | 4 further tests completed behaving the same way with the file being around correctly | 12:57 |
| cpaelzer | mabye some of my background load changed ... | 12:57 |
| cpaelzer | yeah sbuild is over | 12:57 |
| * cpaelzer is burning down some cpu to chck if that can reproduce it once more | 12:58 | |
| cpaelzer | smoser: no it is only deleting cloud-init.target/start now whatever the difference was | 13:00 |
| * cpaelzer is looking if any of the old guests is still around | 13:00 | |
| smoser | cpaelzer, i got it. | 13:00 |
| smoser | launched 5 uvt kvm at once | 13:00 |
| smoser | 5th failed on digglet | 13:00 |
| smoser | http://paste.ubuntu.com/23182035/ | 13:01 |
| cpaelzer | so it is load dependent | 13:01 |
| cpaelzer | or otherwise random | 13:01 |
| smoser | right. its always good to fail randomly. | 13:01 |
| smoser | that way its harder to diagnose problem.s | 13:02 |
| cpaelzer | consitently random :-) | 13:02 |
| cpaelzer | well it serves the "have you tried turning it off and on again?" | 13:02 |
| smoser | pitti, thank you. | 13:02 |
| smoser | i'll upload to ubuntu | 13:02 |
| pitti | xnox: fixed | 13:05 |
| pitti | Mirv: yes, seems stuck, looking | 13:07 |
| smoser | that is really obnoxious | 13:10 |
| smoser | journalctl | pastebinit | 13:10 |
| smoser | is *different* | 13:10 |
| smoser | than | 13:10 |
| smoser | journalctl > out | 13:10 |
| smoser | pastebinit out | 13:10 |
| smoser | http://paste.ubuntu.com/23182060/ : journalctl | pastebinit | 13:11 |
| smoser | http://paste.ubuntu.com/23182061/ : journalctl > out ; pastebinit out | 13:11 |
| smoser | hm. | 13:11 |
| smoser | maybe not. mabye user error | 13:11 |
| smoser | must be | 13:11 |
| * pitti can't see an obvious difference | 13:11 | |
| pitti | there is a difference if stdout is a tty (colors, pager, etc) | 13:12 |
| pitti | but above in both cases it's just a pipe | 13:12 |
| smoser | yeah, but i was seeing it not have 'Breaks' when i grepped | 13:12 |
| smoser | which is wierd | 13:12 |
| smoser | er.. Break | 13:13 |
| pitti | "breaking"? | 13:13 |
| smoser | anywahy | 13:13 |
| smoser | i think it must have been user error | 13:13 |
| pitti | Mirv: Fixed, I think; will watch the next run | 13:16 |
| smoser | pitti, http://paste.ubuntu.com/23182131/ | 13:32 |
| smoser | that look right ? | 13:32 |
| rharper | smoser: re your paste ^^, have you find the right incantations of systemd list-dependencies to that would show it out-of-order now (without that patch) ? | 13:36 |
| Mirv | thank you pitt_i | 13:37 |
| smoser | rharper, ? you're saying i should have been able to ask systemd about this ? | 13:37 |
| rharper | smoser: I'd really *like* to | 13:37 |
| rharper | it's a common issue for me when I'm trying to add/modify or change execution order | 13:37 |
| rharper | so I'm just asking around for any tips/pointers on finding out *before* we execut it | 13:38 |
| rharper | I really dislike that, change, reboot, look at journctl to find out what happened | 13:38 |
| rharper | rather than asking systemd to say, please tell me what you're going to do | 13:38 |
| smoser | rharper, well, systemd doesn't know what its going to do. | 13:39 |
| smoser | it decides to do one thing in one situation and another in another situation | 13:39 |
| rharper | I'm not sure if you're being cheeky or not | 13:39 |
| smoser | well, there cheeky, but truthful | 13:39 |
| rharper | evidently | 13:40 |
| smoser | same situation, it does one thing,a nd then does another. | 13:40 |
| rharper | except it has rules | 13:40 |
| rharper | like before/after/requires/wants | 13:40 |
| rharper | it *does* apply dependency resolution somehow | 13:40 |
| smoser | and it *should* be able to tell you "i'm going to have to break *something*" | 13:40 |
| smoser | but exactly which something.... i'll save that for later. | 13:40 |
| rharper | seems fitting to ask it to do that as a dry-run | 13:40 |
| tdaitx | I'm trying to collect reverse dependencies of a package in order to request it to be removed from the archive, but reverse-depends (ubuntu-dev-tools) relies on ubuntuwire which seems to be offline, is there an alternative? | 13:44 |
| rbasak | chdist and apt-cache rdepends perhaps? | 13:45 |
| dobey | pitti: if a segfault happens during autopkgtests, does that get uploaded to errors.u.c? | 13:48 |
| pitti | Mirv: there, shiny new excuses | 13:57 |
| pitti | smoser: LGTM, thanks! (I initially was going to upload myself, but then I realized I can't push to the packaging git -- and peer review is better anyway) | 13:57 |
| pitti | dobey: no, it doesn't right now; but we could think about adding those to artifacts.tar.gz at least | 13:58 |
| pitti | smoser, rharper: systemctl isolate multi-user.target might help (but not sure to what degree); that basically "re-starts" a target | 13:59 |
| smoser | pitti, i've uploaded, and am now uploading to xenial | 14:09 |
| smoser | if you coudl let it into -proposed... | 14:09 |
| smoser | hopefully this is the one. | 14:09 |
| rharper | pitti: ignoring deps IIUC (isolate) | 14:10 |
| tdaitx | rbasak, thanks for the tip... does that cover all archs? what about reverse build dependencies? | 14:17 |
| tdaitx | it seems I would need to run chdist for all archs I'm interested into | 14:18 |
| Saviq | pitti, should I be seeing the restarted runs for silo 078 in http://autopkgtest.ubuntu.com/running ? BTW - you can interrupt/restart the unity8 run for silo 73 - it's stuck - we'll have to dive into where it may be getting that way (we know which test suite, now need to find out which test and why) | 14:20 |
| pitti | Saviq: interrupted/restarted | 14:25 |
| pitti | Saviq: yes, unless they already finished | 14:25 |
| rbasak | tdaitx: right - it'd be quite manual and tedius I think. | 14:26 |
| rbasak | I'm not sure about build dependencies. | 14:27 |
| tdaitx | rbasak, what about ubuntuwire, is it off permanently or just goes out sometimes? I don't usually run reverse-depends, so I can't tell | 14:28 |
| tdaitx | couldn't find any info on it being out permanently | 14:28 |
| rbasak | I don't know, sorry. I presume it's a short term outtage. | 14:29 |
| pitti | tdaitx: still worked a few days ago, so it only broke recently (and I hope it'll come back) | 14:29 |
| tdaitx | k, that is ok then, I will wait for it to come back ;-) | 14:29 |
| rbasak | If it's a long term issue I'm sure we could replace it. | 14:29 |
| rbasak | (or fix reverse-depends or whatever) | 14:29 |
| tdaitx | pitti, k, thanks for the info | 14:29 |
| tdaitx | rbasak, thanks for the help | 14:30 |
| rbasak | You're welcome! | 14:30 |
| Saviq | pitti, hmm it's almost two hours since you ran them and none of the results popped up in excuses https://requests.ci-train.ubuntu.com/static/britney/landing-078/vivid/excuses.html https://requests.ci-train.ubuntu.com/static/britney/landing-078/xenial/excuses.html - I have not seen them running at any point... oh well, hoping they're en route to bileto | 14:30 |
| dupondje | rharper: any chance on updating strongswan? :) | 14:32 |
| rharper | dupondje: it's possible, but we're past feature-freeze; is there a specific feature in newer strongswan you'd like to see in yakkety ? | 14:34 |
| dupondje | rharper: nothing really special, but 2 patches need to be integrated, so it might be nice to update to newer version directly :) | 14:36 |
| dupondje | https://git.strongswan.org/?p=strongswan.git;a=patch;h=9e74a0952e27e3ac0055b0831919aaddfef1e1b5 & https://git.strongswan.org/?p=strongswan.git;a=patch;h=f201d86debb12731b634625a0278e289e3e05e10 | 14:37 |
| rharper | dupondje: if there are open bugs, those can be fixed for yakkety with no FFE, outside of that, we'd need a FFE for specific features | 14:37 |
| rharper | dupondje: are their ubuntu bugs for those yet ? | 14:37 |
| dupondje | https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1578193 :) | 14:37 |
| ubottu | Launchpad bug 1578193 in network-manager-strongswan (Ubuntu) "cannot load legacy-only plugin" [Undecided,Confirmed] | 14:37 |
| dupondje | network-manager-strongswan needs to get updated to 1.4.0 | 14:37 |
| dupondje | and that requires both patches to be in strongswan :) | 14:38 |
| dupondje | cause nm-strongswan is broken since xenial | 14:38 |
| rharper | dupondje: ok, thanks. | 14:38 |
| dupondje | see https://www.strongswan.org/download.html | 14:38 |
| LocutusOfBorg | doko, FYI, I'm trying to fix gitlab, and I would like to see it migrating | 14:40 |
| LocutusOfBorg | don't shoot at me, since I don't know the ruby-devise-async issue :) and I don't talk ruby | 14:40 |
| LocutusOfBorg | :) | 14:40 |
| dupondje | rharper: btw, I just uploaded a debdiff to that bug for the network-manager-strongswan 1.4.0 update | 14:41 |
| dupondje | which is really a requirement for yakkety, as the current version is just broken | 14:42 |
| rharper | dupondje: great, I'll take a look | 14:42 |
| rharper | dupondje: IIRC, you need two things. update to the plugin, and patches to strongswan itself, right ? | 14:42 |
| dupondje | I tested the debdiff on Xenial, and the GUI works again, so might want to test it on Yakkety :) | 14:42 |
| dupondje | rharper: indeed, the plugin needs update to 1.4.0, and those 2 patches needs to be added to strongswan | 14:43 |
| dupondje | rharper: dunno why all plugins are in a separate package also, better keep a bit the same like debian imo :) | 14:49 |
| rharper | dupondje: we certainly are attempting to reduce the delta between debian and ubuntu w.r.t packages; we reduced the number of subpackages significanty in the xenial release, but there remains some ubuntu use-cases which enabled some features not enabled in debian; we do have a TODO of seeing if debian would accept those changes. | 14:50 |
| pitti | Saviq: sorry, meetings back to back, will look later | 15:00 |
| Saviq | pitti, nw, thanks | 15:01 |
| coreycb | arges, hello, the packages in sru bug 1614131 are ready to promote to xenial-updates if you have a moment | 15:08 |
| ubottu | bug 1614131 in Ubuntu Cloud Archive mitaka "[SRU] OpenStack Mitaka point releases" [Undecided,New] https://launchpad.net/bugs/1614131 | 15:08 |
| arges | coreycb: k | 15:10 |
| semiosis | Odd_Bloke: livecd-rootfs 2.408.4 landed in xenial-updates. can you do your thing to update the build server? | 15:14 |
| coreycb | arges, thanks | 15:23 |
| === dpm is now known as dpm-afk | ||
| arges | coreycb: np | 15:32 |
| === dpm-afk is now known as dpm | ||
| * [gnubie] waves | 16:04 | |
| [gnubie] | anyone here can help me on my debootstrap issue? kindly take a look at http://paste.ubuntu.com/23182607/ | 16:04 |
| [gnubie] | i am wondering why i am always failing right after extracting zlib1g package.. the next step should be the installing of core packages.. | 16:04 |
| [gnubie] | anyone? | 16:06 |
| === PaulW2U_ is now known as PaulW2U | ||
| ricotz | yofel, hi, are there issues with pkg-kde-tools on yakkety ppa builder currently? | 16:17 |
| * [gnubie] is waiting and crossing fingers… | 16:18 | |
| bdmurray | Is there anybody about with a good understanding of apt's problem resolver? bug 1610756 | 16:33 |
| ubottu | bug 1610756 in ubuntu-release-upgrader (Ubuntu) "upgrade to 16.04 failed to calculate due to backuppc" [Medium,Triaged] https://launchpad.net/bugs/1610756 | 16:33 |
| bdmurray | I think its an issue with libcgi-pm-perl and libparse-debianchangelog-perl and backuppc, but I'm not certain how to fix it. | 16:35 |
| ricotz | yofel, nevermind, my fault | 16:35 |
| bdmurray | mvo: Are you about? | 16:42 |
| === Pharaoh_Atem is now known as Eleventh_Doctor | ||
| === Eleventh_Doctor is now known as Pharaoh_Atem | ||
| mvo | bdmurray: not much, a bit late, but I can reply async | 17:07 |
| bdmurray | mvo: I'm uncertain on to fix the upgrade issue in bug 1610756 | 17:19 |
| ubottu | bug 1610756 in ubuntu-release-upgrader (Ubuntu) "upgrade to 16.04 failed to calculate due to backuppc" [Medium,Triaged] https://launchpad.net/bugs/1610756 | 17:19 |
| mvo | bdmurray: I have no investigated in great detail but it looks like libparse-debianchangelog-perl, libcgi-pm-perl are the root of the issue | 17:25 |
| mvo | bdmurray: I need a bit more time | 17:28 |
| bdmurray | mvo: Yes, that was what I discovered too. Its the how to fix it bit, I'm not sure about. | 17:35 |
| mvo | bdmurray: updated the bugreport | 18:53 |
| pitti | Saviq: I saw the tests running, but https://requests.ci-train.ubuntu.com/static/britney/landing-078/vivid/excuses.html hasn't updated for several hours | 19:00 |
| Saviq | pitti, it's been accepted by QA nevertheless since, so excuses don't get updated after that | 19:46 |
| Saviq | robru, think we could do something about that ↑? is it too expensive to update all lander-approved non-landed non-auto-signedoff tickets? | 19:47 |
| robru | Saviq: I specifically stopped running britney on QA -approved tickets precisely because britney runs were taking too long and I saw no point doing automated testing on something already approved by humans | 19:48 |
| robru | pitti: ^ | 19:49 |
| Saviq | robru, I'm not saying trigger any, but could we at least pick up results from the ones that did run? | 19:49 |
| robru | Saviq: no, there's no such thing as "pick up results" I either run britney or I don't | 19:50 |
| Saviq | robru, oh so if something didn't run yet it would get triggered? | 19:50 |
| Saviq | well, ok | 19:50 |
| robru | Saviq: what? Bileto runs britney and British runs autopkgtest. | 19:51 |
| jbicha | could we ignore autopkgtests for ruby-devise-async/0.9.0-1 ? it will be removed from Debian & Ubuntu soon-ish https://bugs.debian.org/837644 | 19:52 |
| ubottu | Debian bug 837644 in ruby-devise-async "ruby-devise-async is not compatible with devise >= 4.0" [Serious,Open] | 19:52 |
| Saviq | robru, in the scenario where: Lander approves → Bileto queues tests up → QA approves before tests finish | 19:52 |
| Saviq | robru, the only step missing is → Bileto gets results for the previously ran tests | 19:52 |
| Saviq | I'm not sure how this works behind the scenes, so it may be impossible | 19:52 |
| Saviq | but doesn't bileto queue them up basically as soon as lander approves? so there's nary a case where all the tests wouldn't run anyway? | 19:53 |
| Saviq | anyway, that's just icing on the cake | 19:53 |
| Saviq | might file a bug to track it | 19:53 |
| robru | Saviq: QA isn't supposed to be approving things before autopkgtests finish, that should be very exceptional | 19:54 |
| Saviq | robru, sure, except it happens, for different reasons :) | 19:54 |
| Saviq | robru, also, this isn't "QA approved", but rather "QA ready" | 19:54 |
| Saviq | and it just feels a waste that we don't get results for the tests that did run anyway | 19:55 |
| Saviq | I think if we expected things to be green, it would still be good to get a confirmation - and even more important - info about any regressions | 19:56 |
| robru | Saviq: Bileto does not start autopkgtests and it does not inspect results either. Bileto triggers britney and britney does all that. To see the results I would have to run britney again which slows down all other tickets | 19:56 |
| Saviq | that's why I asked about about the reasoning - didn't pitti recently blog/post about an order of magnitude of speed improvements in britney btw? :) | 19:58 |
| robru | Saviq: it seems to me that if you care about the autopkgtest results you should not override the QA status | 19:58 |
| doko | crap, updating to yakkety was not a good idea ... https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1624086 | 19:59 |
| ubottu | Launchpad bug 1624086 in unity (Ubuntu) "unity desktop broken after upgrade to yakkety (release pocket only)" [High,New] | 19:59 |
| Saviq | robru, except that means waiting ;) | 19:59 |
| Saviq | robru, I get you, no worries | 20:00 |
| robru | Saviq: britney takes 2 minutes per series per PPA, this hasn't changed since I started running it in bileto and its not parallelizable due to memory consumption. I've seen OOM just running 2 at once | 20:00 |
| Saviq | robru, ouchie | 20:01 |
| mwhudson | http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html is days old, is that normal? | 20:40 |
| === ubott2 is now known as ubottu | ||
| === alecu_ is now known as alecu | ||
| === dax is now known as Guest57738 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!