| ScottK | stgraber: Did you forget to turn the cron job back on for pending-sru? | 01:09 |
|---|---|---|
| stgraber | ScottK: yes and no, I was waiting for the load to become reasonable so the job had time to finish in its allocated time (last manual run took 102min), I see that the load is now way lower than it used to be, so I'll turn it back on | 01:16 |
| ScottK | OK. Thanks. | 01:16 |
| stgraber | done | 01:16 |
| ScottK | Nice. Pending-sru is empty again. | 04:05 |
| infinity | Grr. | 04:05 |
| StevenK | infinity: It being empty makes you cross? | 04:06 |
| infinity | StevenK: It does when it's empty because lillypilly is overloaded. | 04:06 |
| StevenK | Pfft, overloaded. Its load is still two digits. | 04:07 |
| infinity | platform 31651 33.9 20.0 2381772 1223392 ? Sl 04:00 2:10 python versions.py | 04:07 |
| infinity | HATE that script with such a passion. | 04:07 |
| infinity | StevenK: CPU load isn't the issue, it's I/O contention and swap death. | 04:08 |
| StevenK | infinity: Then kill it horribly? | 04:08 |
| infinity | I do that occasionally. Then it gets re-enabled. It's a constant battle. | 04:09 |
| infinity | Maybe I should rewrite it in Perl for the desktop team. | 04:09 |
| * StevenK quits less before his eyes start bleeding heavily. | 04:09 | |
| infinity | I've never read it. But I can't sort out a good reason why the memory usage would be that high except either (a) it was poorly written, (b) it's something Python is bad at, or (c) both. | 04:10 |
| infinity | Both seems likely. | 04:10 |
| StevenK | infinity: It creates bunches of threads | 04:11 |
| StevenK | One thread per package, if I'm reading this right. | 04:11 |
| infinity | MAX_THREADS = 30 | 04:12 |
| infinity | I wonder if dropping that would magically make it less sad. | 04:12 |
| StevenK | MAX_THREADS = 1? :-) | 04:12 |
| infinity | Or maybe, y'know, 8, to go with the number of cores the machine has. | 04:13 |
| StevenK | infinity: Pfft, sense has no place here. | 04:13 |
| * infinity commits that. | 04:15 | |
| * infinity ... and kills the current one. | 04:16 | |
| infinity | If that's all it takes to fix this problem, I'll be annoyed that I never read it until today. | 04:17 |
| ScottK | Will you be even more annoyed it took StevenK reading it first? | 04:20 |
| ScottK | Now at least part of the page is there.... | 04:35 |
| infinity | ScottK: Oh, fun. | 04:47 |
| infinity | ScottK: Also, we should collapse kde-l10n* the same way we do language-pack* | 04:48 |
| infinity | ScottK: Can I make the same assumption there, that any kde-l10n-* upload will include kde-l10n-en, and I can just keep that one as a placeholder? | 04:49 |
| stgraber | infinity: might be worth adding some kind of lock file so that we don't end up having multiple instance of pending-sru running. I wanted to do that this afternoon but with lillypilly having a load of 80 or so and vim taking 5min to load I ended up doing something else and forgetting about it ;) | 04:49 |
| infinity | stgraber: Absolutely should be flocked, yes. | 04:49 |
| infinity | stgraber: Can just be wrapped in a flock in the cronjob, that's what the kernel team does, instead of altering every script. | 04:50 |
| infinity | ScottK: Oh, there is no kde-l10n-en ... Why do you people hate my freedom? | 04:50 |
| infinity | ScottK: Fair to say there'd always be a -de? | 04:51 |
| ScottK | probably | 04:54 |
| infinity | Okay, committed. Next run will only show kde-l10n-de. | 04:54 |
| infinity | stgraber: Flocked at the cron level, assuming I didn't typo. | 05:01 |
| * infinity kills the current sru-report run so this can be a clean test at :10 | 05:01 | |
| infinity | Alright, flock magic looks good. Now it just needs to complete some day. | 05:11 |
| infinity | (Which could take awhile since I also blew away the potentially corrupt cache...) | 05:11 |
| === doko_ is now known as doko | ||
| wgrant | cjwatson, infinity: https://code.launchpad.net/~wgrant/ubuntu-archive-tools/ddebs/+merge/166456 skips ddebs in change-override/remove-package. It won't even list them, but I'm not sure if that bit is desirable from your side. | 08:02 |
| infinity | wgrant: Are they 100% tied to their binary mate? | 08:11 |
| infinity | wgrant: If that's guaranteed, I'm not sure if we care if they're listed. | 08:11 |
| wgrant | infinity: Yes, they're 100% tied | 08:12 |
| wgrant | The copier will explode if they're not copied in pairs | 08:12 |
| wgrant | It's impossible to override, supersede or delete them directly | 08:12 |
| infinity | wgrant: Kay. I mean, I feel like I personally care that they're somehow visible to me, but that's probably just me not trusting the magic. | 08:13 |
| infinity | wgrant: If they're effectively metadata, not seeing them in those teels seems like it's probably right. | 08:13 |
| infinity | s/teels/tools/ | 08:13 |
| infinity | WTF is a teel? | 08:13 |
| infinity | Seriously, fingers? | 08:13 |
| * StevenK cackles at some of the reasons infinity lists in his mail. | 08:16 | |
| StevenK | infinity: Awwww, you spoilt the fun with the PS. :-( | 08:17 |
| wgrant | No email for me? :( | 08:32 |
| wgrant | infinity: Yeah, IMO they're basically metadata | 08:32 |
| wgrant | They can't be manipulated independently. | 08:32 |
| infinity | wgrant: They do, I assume, show up on the "binaries produced in this build" download pages in the web UI and such, right? They're not completely metadata? :P | 08:34 |
| wgrant | infinity: They appear as normal publications apart from being unmodifiable, yes. | 08:34 |
| wgrant | https://dogfood.launchpad.net/ubuntu/+source/hello-debhelper/2.8-1+df1 | 08:35 |
| infinity | wgrant: Lovely. | 08:38 |
| ogra_` | bah, my last livecd-rootfs upload was nonsense ... sigh | 10:46 |
| ogra_` | cjwatson, i'm looking for the least effort way to make cdimage publish multiple bootimg files, i wonder if thats doable through clever naming without having to change cdimage | 10:48 |
| ogra_` | (i know i could change download_live_items, but i wonder if there isnt a better way) | 10:50 |
| cjwatson | I don't think you should be afraid of changing cdimage here | 10:50 |
| cjwatson | It's deliberately quite strict about which files it chooses to publish | 10:51 |
| === mmrazik is now known as mmrazik|afk | ||
| ogra_` | cjwatson, mind taking a look ? http://paste.ubuntu.com/5716730/ | 13:28 |
| cjwatson | ogra_`: some tests would be nice | 13:28 |
| ogra_` | phew ... thats throw away stuff ... is that really needed ? | 13:29 |
| cjwatson | ogra_`: and I think it might be good to move some of this logic into download_live_items(..., "bootimg") | 13:29 |
| cjwatson | ogra_`: Given how many goes all this has taken, yes | 13:29 |
| ogra_` | k | 13:29 |
| cjwatson | Plus I find it unlikely that you've run the test suite on this at all :) | 13:29 |
| cjwatson | (Pretty sure there are syntactic problems here ...) | 13:30 |
| ogra_` | (the files will vanish as soon as we integrate them in the zips during build) | 13:30 |
| cjwatson | Yep, your syntax is definitely invalid in places. | 13:30 |
| ogra_` | hmm | 13:30 |
| cjwatson | So if nothing else writing some tests will force you to run the test suite. :-P | 13:30 |
| cjwatson | Also worth installing pep8 and pyflakes, which the test suite will use | 13:32 |
| tseliot | didrocks: are you around? | 13:32 |
| didrocks | tseliot: in a hangout, but around | 13:33 |
| tseliot | didrocks: ok, I was wondering if you could approve nvidia-prime in saucy (it's a small package) | 13:34 |
| didrocks | tseliot: any urgency? Not sure i'll be around to do a full review today | 13:35 |
| tseliot | didrocks: well, yes, we need it by the end of this week i.e. tomorrow | 13:35 |
| didrocks | tseliot: that's fine, i'll have a look (probably tomorrow) | 13:35 |
| tseliot | didrocks: ok, thanks | 13:36 |
| didrocks | yw ;) | 13:36 |
| === mmrazik|afk is now known as mmrazik | ||
| ogra_` | cjwatson, pep8 clean now ... http://paste.ubuntu.com/5716852/ i noticed a lot of tracebacks for unrelated tests here though ... | 14:14 |
| ogra_` | cjwatson, from a logical POV, what would you like me to move download_live_items(..., "bootimg") additionally to the code thast there already | 14:14 |
| mlankhorst | can someone move the lts-raring packages and llvm-3.2 out of NEW? https://launchpad.net/ubuntu/precise/+queue?queue_state=0 | 14:15 |
| mlankhorst | needs to be approved or something :) | 14:17 |
| cjwatson | ogra_`: I'll withdraw my point about download_live_items, as I think I've changed my mind | 14:19 |
| ogra_` | ueu, ok | 14:19 |
| ogra_` | err | 14:19 |
| ogra_` | heh | 14:19 |
| cjwatson | ogra_`: All the tests pass for me. Make sure you have everything listed in run-tests installed, and otherwise pastebin the output for me? | 14:20 |
| ogra_` | i did install with --no-install-recommends since i definitely dont want an mta on this machine, might be related | 14:24 |
| cjwatson | Shouldn't need an MTA | 14:25 |
| cjwatson | The dependencies there are meant to be direct | 14:25 |
| cjwatson | So what are the failures? | 14:25 |
| ogra_` | one sec | 14:25 |
| ogra_` | http://paste.ubuntu.com/5716886/ | 14:26 |
| cjwatson | Well, several of those are directly related to your change | 14:27 |
| cjwatson | The test_prepare_squashfs_base failure suggests you're missing squashfs-tools | 14:27 |
| cjwatson | (which is listed in run-tests) | 14:27 |
| ogra_` | and installed here | 14:29 |
| cjwatson | And the test_extract_debootstrap failure indicates that you're missing dctrl-tools, so I've added that to the list in run-tests now | 14:29 |
| cjwatson | Ah, that was the test_prepare_squashfs_base too | 14:29 |
| cjwatson | *failure too | 14:30 |
| ogra_` | ogra@chromebook:~/branches/cdimage$ dpkg -l squashfs-tools|grep ii | 14:30 |
| ogra_` | ii squashfs-tools 1:4.2+20121212-1 armhf Tool to create and append to squashfs filesystems | 14:30 |
| * ogra_` installs dctrl-tools | 14:30 | |
| cjwatson | Yeah, I misread the test_prepare_squashfs_base failure first time round | 14:30 |
| ogra_` | ok, looks better | 14:31 |
| ogra_` | 4 failures with .bootimg-manta left | 14:32 |
| cjwatson | For the other failures, you need to use a loop variable that isn't "extension" | 14:32 |
| cjwatson | Because that comes from "extension = self.detect_image_extension(source_prefix)" above and must be preserved | 14:33 |
| cjwatson | In publish_binary, that is | 14:33 |
| seb128 | hum | 14:34 |
| seb128 | https://launchpadlibrarian.net/141099296/upload_4627413_log.txt | 14:34 |
| seb128 | "INFO Upload was rejected: | 14:34 |
| seb128 | INFO Server said: " | 14:34 |
| cjwatson | seb128: transient librarian failure, retry | 14:34 |
| seb128 | thanks launchpad, that's useful info :p | 14:34 |
| seb128 | cjwatson, thanks | 14:34 |
| === Ursinha is now known as Ursinha-afk | ||
| bdmurray | slangasek: the other day we talked about identifying SRU bugs that could possibly be verified by checking errors.ubuntu.com to ensure there are no crashes with the new version of the package. For example I'd tag bug 1104435 "errors-watch" and update sru-report to display something different (probably color) for bugs with that tag. Does that seem reasonable? | 15:55 |
| ubot2 | Launchpad bug 1104435 in xfce4-session (Ubuntu Raring) "xfce4-session crashed with SIGSEGV in g_slice_alloc()" [Undecided,In progress] https://launchpad.net/bugs/1104435 | 15:55 |
| slangasek | bdmurray: sounds good to me | 15:56 |
| === mmrazik is now known as mmrazik|afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| xnox | bdmurray: for that bug it would be very awesome! | 16:24 |
| === greyback is now known as greyback|food | ||
| === psivaa is now known as psivaa_afk | ||
| ogra_` | cjwatson, hmpf ... http://paste.ubuntu.com/5717429/ do you have any idea where the dashes come from ? (teh files clearly exist on cadejo, but indeed without the suffixed dash) | 17:13 |
| ogra_` | oh, i see, it wants to attach the regular subarch which we dont really have for touch | 17:15 |
| === greyback|food is now known as greyback | ||
| cjwatson | Indeed, flavours() wants a subarch | 17:16 |
| cjwatson | I think you should probably have separate handling for bootimg* | 17:17 |
| cjwatson | Which can then handle ubuntu-touch specially | 17:17 |
| cjwatson | You can leave kernel and initrd alone since they aren't in the output on cadejo anyway | 17:17 |
| ogra_` | right, sigh | 17:18 |
| * ogra_` wanted to be done yesterday ... | 17:18 | |
| infinity | Hrm, shouldn't all that lts-raring stuff be in main? Someone NEWed it all to universe. :/ | 17:19 |
| ogra_` | cjwatson, http://paste.ubuntu.com/5717478/ ? | 17:33 |
| cjwatson | ogra_`: I'd prefer if you split all the bootimg* ones into a separate if branch, and put that logic there | 17:34 |
| cjwatson | ogra_`: But the rest is OK | 17:34 |
| ogra_` | heh, which rest :) | 17:34 |
| cjwatson | Well, I mean the logic you added | 17:35 |
| cjwatson | I'd just like it to be in a separate if branch so that the kernel/initrd case stays fairly simple | 17:35 |
| ogra_` | ok | 17:35 |
| cjwatson | Since AIUI you don't need to change kernel/initrd behaviour | 17:35 |
| ogra_` | right, the ac100 bootimg was in there | 17:36 |
| ogra_` | which is handled the same way as initrd/kernel ... | 17:36 |
| ogra_` | i'll add an extra if for the extended bootimg-* stuff | 17:36 |
| ogra_` | cjwatson, http://paste.ubuntu.com/5717500/ is what you meant i guess | 17:44 |
| cjwatson | Depends whether you want bootimg for ubuntu-touch too. | 17:44 |
| ogra_` | nope, i dont | 17:45 |
| cjwatson | OK, in that case that's fine | 17:45 |
| ogra_` | what were the runes to prevent cdimage from doing an actual live build ? | 17:45 |
| * ogra_` always forgets | 17:45 | |
| ogra_` | i only want to test the publishing | 17:45 |
| cjwatson | Omit --live | 17:46 |
| ogra_` | thx | 17:47 |
| ogra_` | hmm, i have the feeling that was the wrong place ... nothing changed | 17:49 |
| cjwatson | Write a test case | 17:49 |
| cjwatson | Seriously, it's way easier than battering away at things in production | 17:49 |
| cjwatson | Or at least use DEBUG=1 so that it doesn't mail people and doesn't try to actually publish to cdimage.u.c | 17:51 |
| cjwatson | You can use pdb too | 17:51 |
| * ogra_` will do | 17:51 | |
| ogra_` | ah, heh | 17:55 |
| ogra_` | so i fixed tree.py which actually wasnt my probelm | 17:55 |
| ogra_` | ate least i will handle botimg-* in both places now :P | 17:56 |
| ogra_` | yay, finally | 18:05 |
| ogra_` | hmm, except that it doesnt publish them | 18:07 |
| * ogra_` digs in again | 18:07 | |
| ogra_` | hmm, i dont get it, theoretically nothing should prevent them from being published | 18:18 |
| ogra_` | argh | 18:23 |
| ogra_` | so the generic bootimg is handled in debian-cd ... not really what i want :( | 18:23 |
| ogra_` | sigh | 18:26 |
| === greyback is now known as greyback|away | ||
| ogra_` | cjwatson, you dont happen to be still around by chance ? i'm stuck with a test | 20:28 |
| ogra_` | cjwatson, http://paste.ubuntu.com/5717951/ is the code change http://paste.ubuntu.com/5717953/ is the failure | 20:30 |
| ogra_` | i dont really understand where to add the "armhf.bootimg-*" files in the test code | 20:31 |
| ogra_` | (i actually thought the first addition to the tests would be enough) | 20:31 |
| ogra_` | ot infinity ^^^ if you have a clue about cdimage test code | 20:34 |
| ogra_` | *or | 20:34 |
| stgraber | ogra_`: so it looks like the input file isn't there when the test runs. Where are those downloaded, how do you mock that in the tests? | 20:36 |
| stgraber | ogra_`: the error and the code you listed make it look like "<rootfs>.raw" exists in the test environment (second shutil.copy2) but the *.bootimg-* don't, so when calling fetch_side_effect the copy fails | 20:37 |
| ogra_` | well, in real life "armhf.bootimg-*" files are there too | 20:39 |
| ogra_` | how would i mock that in the test | 20:39 |
| ogra_` | the files live in the respective scratch dir on cdimage indeed | 20:42 |
| stgraber | looking | 20:43 |
| ogra_` | note that i'm running the test in my local bzr tree | 20:44 |
| ogra_` | so there arent any physical files indeed | 20:44 |
| stgraber | ogra_`: so the problem is that fetch_side_effect isn't called for those files | 20:46 |
| ogra_` | oh | 20:46 |
| stgraber | trying to fix that now | 20:46 |
| === greyback|away is now known as greyback | ||
| stgraber | ogra_`: http://paste.ubuntu.com/5718031/ is closer to what you want thought still failing (for another reason) | 20:56 |
| ogra_` | hmm, but why is that needed ? | 20:57 |
| stgraber | ogra_`: that code essentially mocks copy2 to create the target if it's one of those files you want to copy | 20:57 |
| ogra_` | ok | 20:57 |
| stgraber | because the source file doesn't exist | 20:57 |
| stgraber | I'm very not familiar with that part of the code, but fetch_side_effect is related to the fetch() command which does the wget. Your code change doesn't use wget, so adding the entries there wasn't doing anything. | 20:58 |
| stgraber | I suspect that the source files don't exist because they aren't technically retrieved at any point so obviously can't be copied. | 20:59 |
| stgraber | My change makes the copy work (as long as it's in the whitelist) by touching the target, but that's causing a failure a bit later on now as the listdir() doesn't appear to match what's expected | 20:59 |
| ogra_` | well, neither is rootfs.tar.gz | 21:00 |
| stgraber | but the rootfs is downloaded through fetch() isn't it? if so, then it's being touched by the mocked version of fetch() | 21:00 |
| ogra_` | not on my chromebook, no | 21:00 |
| infinity | Why isn't it all gotten via fetch/fetch_side_effect? | 21:01 |
| infinity | Surely, this is all published on a livefs builder the same as any other image/kernel/initrd/etc. | 21:01 |
| ogra_` | i'm just running ./run-tests on a machine that doesnt have any running cdimage environment to have the code checked | 21:01 |
| infinity | And so should be fetched the same way. | 21:01 |
| ogra_` | right | 21:02 |
| ogra_` | it doesnt fail for rootfs.tar.gz ... why would it for any of the other nonexisting files | 21:02 |
| ogra_` | thats what confuses me | 21:02 |
| stgraber | here are the calls to fetch() and copy2(): http://paste.ubuntu.com/5718054/ | 21:03 |
| infinity | Right, so the testsuite is right. You're failing to fetch the bootimg files. | 21:04 |
| infinity | Also, those kernel- and initrd- bits look suspect... | 21:04 |
| cjwatson | Those aren't a problem and can be ignored | 21:04 |
| ogra_` | right | 21:04 |
| cjwatson | Did you remember to set CDIMAGE_PREINSTALLED in the test config? | 21:04 |
| cjwatson | I would be inclined to suggest stepping through the test with pdb at this point, anyway. | 21:05 |
| stgraber | note that http://paste.ubuntu.com/5718061/ passes the tests properly, but I'm not sure it's right (well, I'm pretty sure it's wrong) | 21:05 |
| cjwatson | Put 'import pdb; pdb.set_trace()' just before the bit in the code you want to step through | 21:05 |
| cjwatson | e.g. whatever ends up calling download_live_filesystems | 21:05 |
| ogra_` | k | 21:07 |
| * cjwatson considers decamping to the pub for a bit | 21:08 | |
| slangasek | hmmm; lintian gives me a bunch of errors on udev about init.d scripts that aren't in the package at all. Guess the lintian checks need improving | 21:30 |
| === greyback is now known as greyback|away | ||
| === hggdh_ is now known as hggdh | ||
| === bjf is now known as bjf[afk] | ||
| === Guest57441 is now known as StevenK | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| * cjwatson rebuilds ubuntukylin images (transient failure) | 23:21 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!