| tjaalton | hey, nvidia-graphics-drivers-legacy-304xx should be removed from trusty | 05:42 |
|---|---|---|
| tjaalton | since we have our own nvidia packaging, and installing this could break things | 05:42 |
| tjaalton | hmm I'll just file a bug | 05:43 |
| infinity | tjaalton: Bug number? | 06:03 |
| tjaalton | infinity: lp1258394 | 06:06 |
| infinity | tjaalton: Ahh, found it. | 06:06 |
| tjaalton | cool | 06:06 |
| infinity | (didn't realise that was literally the source package name, I thought you meant 304*) | 06:06 |
| tjaalton | yeah, probably why it got in trusty | 06:07 |
| infinity | Well, it's new. | 06:07 |
| infinity | And we don't blacklist with a wildcard. | 06:07 |
| infinity | Not sure if auto-sync is smart enough to deal with wildcards. :P | 06:07 |
| infinity | Anyhow, I'll add it to the blacklist. | 06:08 |
| infinity | Once I remember where it lives. | 06:08 |
| tjaalton | great, thanks | 06:08 |
| infinity | lp:~ubuntu-archive/+junk/sync-blacklist looks plausibly canonical, despite the hilarious path. | 06:08 |
| infinity | Oh, and I already have that checked out. A good sign. | 06:09 |
| tjaalton | sweet | 06:11 |
| infinity | Waaait. That had an ubuntu version on it? | 06:11 |
| infinity | It was synced and then reuploaded for an ftbfs or something? :P | 06:12 |
| infinity | Oh well. | 06:12 |
| infinity | All removed now. | 06:12 |
| tjaalton | yeah | 06:12 |
| tjaalton | that's how I noticed it, by reading trusty-changes | 06:12 |
| infinity | Heh. | 06:12 |
| === penghuan_ is now known as penghuan | ||
| cjwatson_ | infinity: It wouldn't be that hard to add wildcard support to auto-sync if you wanted, though you'd probably have to add it to syncpackage too. | 09:25 |
| === ochosi_ is now known as ochsoi | ||
| === ochsoi is now known as ochosi | ||
| === cjwatson_ is now known as cjwatson | ||
| cjwatson | infinity: Any further thoughts on grub2/precise? | 09:25 |
| === yofel_ is now known as yofel | ||
| infinity | cjwatson: Doesn't really matter for Ubuntu of course, but why doesn't 10_hurd.in use gettext like the others? | 09:38 |
| cjwatson | infinity: It does in 2.00, but was apparently omitted in 1.99 | 09:39 |
| cjwatson | I assume somebody was careless | 09:39 |
| cjwatson | But didn't bother to import more general fixups for code we don't care about :-) | 09:39 |
| cjwatson | (Completism, except when it's annoying) | 09:40 |
| infinity | cjwatson: Ahh, kay. So, the only other thing I'd question is if you caught all the possible error paths for the udevadm madness. | 09:43 |
| cjwatson | Go on ... | 09:43 |
| infinity | cjwatson: Will this properly not do something stupid if udev isn't running, if udevadm doesn't exist, etc. | 09:43 |
| infinity | It looks like you catch some things, I just have no idea if it's all the things. :) | 09:43 |
| cjwatson | Well, I'm assuming that udevadm will only write a line to stdout if it actually worked | 09:44 |
| cjwatson | If it doesn't do that, then sysfs_partition_path is going to return NULL one way or another | 09:45 |
| cjwatson | (Worst case I think it produces some junk on stderr, which I'm happy to ignore) | 09:45 |
| infinity | cjwatson: It certainly seems to DTRT if the dev doesn't exist. Let me stop udevd and see if my laptop explodes... | 09:46 |
| cjwatson | And sysfs_partition_path NULL -> sysfs_partition_start 0 -> fallback to HDIO_GETGEO | 09:46 |
| cjwatson | You might be better off with a container there :-) | 09:46 |
| infinity | Nah, I live on the wild side. | 09:47 |
| infinity | That seems to do what you expect too. Good enough for me. | 09:47 |
| infinity | cjwatson: Want to follow that up with a -signed with a strict build-dep, so we don't forget and do it two weeks later? :P | 09:48 |
| cjwatson | infinity: ayup | 09:51 |
| cjwatson | infinity: Mind if it doesn't come with bug closures? | 09:52 |
| infinity | cjwatson: I think at least one of these bugs has a grub2-signed task. | 09:52 |
| cjwatson | Ah, let me check then | 09:52 |
| infinity | But I don't much care, if you prefer to ignore and invalidate the tasks and have the rebuild upload not have a bug. | 09:53 |
| cjwatson | Yeah, OK, I'll add them | 09:53 |
| infinity | linux-signed certainly never references bugs. | 09:53 |
| cjwatson | just the mega bug 1065281 by the looks of things | 09:54 |
| ubot2` | Launchpad bug 1065281 in OEM Priority Project quantal "Installer crashed when trying to partition 4k/4k sector hard disks" [High,In progress] https://launchpad.net/bugs/1065281 | 09:54 |
| cjwatson | infinity: ok, uploaded. maybe ara won't hunt me down now ... | 09:55 |
| infinity | cjwatson: Personally, I don't see much point in -signed and -meta and other such packages having bug refs unless the bug is actually a bug in THAT package, rather than the one that it depends/builds on/with. | 09:56 |
| infinity | But, YMMV. | 09:56 |
| cjwatson | me neither, but I don't want to edit that bug's metadata more than I have to :-) | 09:56 |
| infinity | Heh. | 09:56 |
| cjwatson | I'd actually like to teach sru-report about the linkage or something ... | 09:56 |
| infinity | cjwatson: Teaching sru-report about connections seems wrong. Surely, the right answer is britneyfying stables. | 09:57 |
| infinity | cjwatson: Then we enforce what we need to with blocking bugs and/or strict deps. | 09:57 |
| infinity | And sru-review is lying scum... | 09:59 |
| infinity | (base)adconrad@cthulhu:~$ PAGER=view sru-review -s precise grub2-signed | 09:59 |
| infinity | ERROR: queue does not have a debdiff | 09:59 |
| infinity | I'M STARING AT IT IN THE WEB UI. | 09:59 |
| cjwatson | infinity: mm, could do ... | 10:00 |
| cjwatson | infinity: sru-review> caching by any chance? | 10:00 |
| infinity | Ahh, possibly. It finally caught up with reality anyway. | 10:00 |
| infinity | cjwatson: Does grub2-signed still do that wonky thing where, despite a build-dep on a binary package, it then just takes the latest efi blob from ftpmaster without version checking? | 10:02 |
| cjwatson | infinity: Yes - but that will always be new enough, right? | 10:03 |
| cjwatson | (It should arguably pick the version out of the apt cache, yes.) | 10:04 |
| infinity | cjwatson: If you never build grub in a PPA (or, rather, never binary copy it), I think it probably still gets what you want. | 10:04 |
| infinity | I like linux-signed approach to versioning and version-checking a bit better. | 10:04 |
| infinity | (The binary copy thing is great, cause you'll get the .deb published, but the EFI bits in unapproved until someone notices, so your build-dep would be satisfied, but you'll get the old EFI bits) | 10:05 |
| infinity | Just one more way copies are hilariously goofy. | 10:05 |
| cjwatson | I think linux-signed was originally derived from my code, but it looks like they've spruced it up a fair bit. | 10:10 |
| cjwatson | And yeah, it's grabbing a specific version rather than using current, which is what I was vaguely suggesting above. | 10:10 |
| cjwatson | Might fix that in the next grub2-signed/trusty upload if I remember. | 10:10 |
| infinity | Which reminds me, there's a bug in linux-signed where it can't work in private PPAs. | 10:14 |
| infinity | Which is a moot point unless we also allow the security PPA to build with the archive signing key (which we won't), but it's still annoying for staging/testing. | 10:14 |
| infinity | I kept meaning to fix that after the last fiasco involving such. | 10:14 |
| barry | hi. can this migration be easily retried? https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-system-image/ | 14:03 |
| cjwatson | fwiw it's not the migration that needs to be retried, it's the autopkgtest (terminology) | 14:28 |
| cjwatson | barry: is there a reason to suppose the autopkgtest will succeed this time? it has never passed on trusty | 14:29 |
| barry | cjwatson: these are not real test failures or as previous, incorrect autopkgtest deps. these are just the intermittent test suite timeouts rearing their ugly head again. yes, we need to try to figure that out (and it's a top priority for the sprint, since i think its udm related), but a retry locally often "fixes" the problem. tl;dr we might get lucky on a retry | 14:31 |
| cjwatson | barry: well. I'm a little bit sceptical that you might be losing races that many times and succeed on a retry - but I've asked it to rebuild, we'll see how it does | 14:35 |
| xnox | barry: do note, the tests are running inside a VM and therefore a monolithic_raw clock is not available, and some syscalls "round up" to precision values which in this case is infinity (max allowed size of the variable type used) | 14:36 |
| xnox | barry: therefore e.g. for autopkgtest in upstart some timing tests are skipped. | 14:36 |
| xnox | barry: buildds have proper hardware clock, so those timing tests are executed then. So i'd suggest disabling / or marking those tests may fail if monolithic clock is not available. | 14:37 |
| barry | cjwatson, xnox: so, basically what is happening here is that si is telling udm to download a bunch of files (over localhost), and then waits for the appropriate dbus signals. yes, there's a timeout, but it's cranked up to 20 minutes during the test suite. however, for reasons none of us have ever been able to figure out, sometimes udm just stops sending its signals, so the dbus reactor will eventually timeout saying it never saw a | 14:41 |
| barry | 'finished' signal. it happens occasionally locally but is very difficult to reproduce or debug. a retry seems to fix it (oh, and it will almost never timeout when running in-tree tox, but it can when sbuilding in a chroot). thing is, the *exact* same test suite is run in the build and the dep8 tests so, yeah | 14:41 |
| barry | one of the things i hope to address at the sprint is debugging and integration tests to figure out why udm just stops responding | 14:41 |
| ogra_ | stgraber, so we had an ubuntu-touch build ... and there will be one later tonight, do you need to watch it live when it happens for the isotracker stuff ? (i can ping you when starting the build) | 15:21 |
| stgraber | ogra_: no, everything I need will either be right on the tracker or if it fails, in the logs | 15:42 |
| ogra_ | ok | 15:42 |
| stgraber | ogra_: looks like 20131206 posted fine on the tracker | 15:43 |
| ogra_ | ah, yeah, i see something there | 15:43 |
| stgraber | ogra_: can you login on http://iso.qa.ubuntu.com (if already logged in, logout and login again)? | 15:45 |
| stgraber | ogra_: you should see ubuntu-touch-release on the SSO page and then have access to the touch products | 15:45 |
| stgraber | ogra_: if that works, you should then be able to go to http://iso.qa.ubuntu.com/qatracker/milestones/308/builds, tick the touch product and then access the rebuild controls at the bottom of the page | 15:47 |
| ogra_ | yeah, i see a "Request a rebuild" pulldown | 15:47 |
| stgraber | ogra_: would be nice if you could trigger the next build that way so we can check that the tracker -> nusakan link works for touch | 15:47 |
| ogra_ | will do | 15:47 |
| ogra_ | is everyone from the CI team in ubuntu-touch-release ? | 15:47 |
| ogra_ | (if not, can we add them) | 15:48 |
| stgraber | I believe you need to be a coredev to be on ubuntu-touch-release | 15:49 |
| cjwatson | right, because it also controls access to the britney hints branch | 15:49 |
| cjwatson | but I think it makes sense for it to be the same team | 15:50 |
| ogra_ | hmm, we need to have the CI guys able to trigger builds | 15:50 |
| stgraber | ogra_: nusakan checks for rebuild requests every 5 minutes, so it can take a little while until the build actually starts | 15:50 |
| ogra_ | could we use another team for this perhaps ? | 15:50 |
| cjwatson | every single one? does it really matter that much? | 15:50 |
| stgraber | ogra_: I can easily grant the same tracker access to another team | 15:50 |
| cjwatson | it's only been you so far and while it hasn't been ideal it hasn't been *that* huge a problem | 15:50 |
| ogra_ | cjwatson, well, two in each TZ i'd say | 15:50 |
| cjwatson | I don't get why it's suddenly a critical requirement | 15:50 |
| ogra_ | not each of them | 15:50 |
| ogra_ | cjwatson, because i'm not allowed to switch on cron for european and US daytimes and they need to be able to have ad-hoc builds then | 15:51 |
| cjwatson | it'll have to be a different team then | 15:51 |
| ogra_ | (i'll have to burn vacation days from monday on) | 15:51 |
| ogra_ | didrocks, ^^^ whats the team we need to have access to trigger builds | 15:52 |
| ogra_ | (i dont need to be in it, i can do it from cmdline on the main server) | 15:53 |
| cjwatson | better if you are in it though | 15:53 |
| ogra_ | k | 15:53 |
| didrocks | ogra_: hum, not sure to follow what you are asking it as it seems to be image build, not cu2d? | 15:53 |
| cjwatson | didrocks: image build, yes | 15:53 |
| ogra_ | didrocks, right | 15:53 |
| cjwatson | didrocks: (please see the last screen or two of scrollback) | 15:54 |
| * didrocks reads | 15:54 | |
| didrocks | ubuntu-touch-release would make sense to me | 15:54 |
| ogra_ | didrocks, but not all CI people are core-dev | 15:55 |
| ogra_ | i thought the person doing the final landing before an image shoujld also be able to trigger the build | 15:55 |
| didrocks | ogra_: in theory yeah, but for now, I would say we don't need everyone to be able to kick a build, we have enough coverage with the current ones on all timezones | 15:55 |
| ogra_ | so i woulld think it makes sense to have the complete CI team allowed | 15:55 |
| didrocks | otherwise, it's ~ubuntu-unity | 15:56 |
| cjwatson | note that ~ubuntu-release can always do it too - I seriously doubt you'll have timezone coverage problems in reality | 15:56 |
| didrocks | agreed | 15:57 |
| ogra_ | k | 15:57 |
| ogra_ | so lets keep ubuntu-touch-release for now then | 15:57 |
| stgraber | ogra_: the command the tracker will trigger is "ARCHES=armhf DIST=trusty for-project ubuntu-touch cron.daily-preinstalled --live" (just did a dry-run rebuild to check), comparing to the crontab, that looks right | 16:06 |
| ogra_ | stgraber, yeah ... ARCHES shouldnt be needed though, but wont hurt | 16:10 |
| stgraber | ogra_: yeah, the tracker always sets ARCHES based on the arches, that was easier than having to parse the default arches list :) | 16:11 |
| ogra_ | well, we will add x86 tarball builds in the not so far future, then it will need to be extended | 16:12 |
| cjwatson | ogra_: that would be an extra image type which you'd also select on the tracker, then - no big deal | 16:16 |
| ogra_ | ah, k | 16:16 |
| cjwatson | or rather same image type, another architecture. another row on the tracker anyway | 16:16 |
| ogra_ | yup, i see | 16:17 |
| stgraber | ogra_: oh, one last thing, we have a rate limit in place for all tracker requested builds set at 2 builds per user per day. That limit however doesn't apply to members of ~ubuntu-release. If that actually becomes a problem for ubuntu-touch, we can probably raise it to 3 or 4 (as so far we haven't seen anyone abusing their powers). | 16:18 |
| ogra_ | heh, they will rather do to less than to many | 16:19 |
| * ogra_ is the one pushing for more ... they would likely be fine with two/day in total | 16:19 | |
| Laney | birch went to disabled | 16:57 |
| Laney | could somebody please do the needful? | 16:57 |
| bdmurray | slangasek: if you get a chance https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/jsondecodeerror/+merge/198120 | 20:00 |
| === doko_ is now known as doko | ||
| doko | infinity, cjwatson, jibel: I need python3-defaults in trusty. could somebody please unblock that? the autopkg tests hardly rely on this, maybe only when we change the default version to 3.4 | 20:30 |
| infinity | doko: Have you looked into why those tests fail? | 20:33 |
| infinity | The dh-python one looks to be legitimately failing, though maybe the test itself is wrong... | 20:33 |
| doko | did never pass | 20:35 |
| infinity | Indeed, and neither have the other two. I can wave it through. We should still fix those tests, though. | 20:36 |
| doko | python-csb did never pass | 20:37 |
| doko | jibel, ^^^ | 20:37 |
| === retoaded is now known as retoaded_biab | ||
| infinity | doko: Tests for those source/version tuples skipped. | 20:40 |
| === retoaded_biab is now known as retoaded | ||
| barry | i'm seriously considering disabling the autopkgtests for system-image. it just seems the jenkins runs are too flaky to be of any use beyond blocking proposed migration. note that it's the exactly same test suite that i run locally in tree via tox *and* in the package build d/rules. it only seems to be inside adt that we get lots of timeout errors, connections reset by peers, etc. something about that environment is causing | 22:06 |
| barry | unreliable dbus/socket problems it seems. | 22:06 |
| slangasek | bdmurray: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/jsondecodeerror/+merge/198120> why is the json decoding failing? Should this actually be handled via the http status, the way we already handle 502? | 23:22 |
| bdmurray | slangasek: I don't know as I don't have the data returned from errors | 23:25 |
| slangasek | ah; is this happening when called on errors itself? | 23:25 |
| bdmurray | slangasek: I found some cronjob email from snakefruit today with the traceback in the mp | 23:26 |
| bdmurray | I'll run the phased-updater some here and see if I can recreate the crash | 23:27 |
| slangasek | bdmurray: I would say we should check for any rate_file.getcode() >= 400, and then see if the jsondecode change is still needed at all | 23:31 |
| bdmurray | slangasek: ah, that makes sense | 23:33 |
| bdmurray | slangasek: updated | 23:42 |
| slangasek | bdmurray: merged, thanks | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!