| didrocks | bdmurray: daily releases are appropriate for SRUs | 05:32 |
|---|---|---|
| didrocks | bdmurray: and that one was a manual upload btw with a fixed changelog :/ | 05:32 |
| didrocks | bdmurray: having everything stalled on the SRU side for more than 2 months now and a reject with no reason, can you please explain a little bit more than: | 05:33 |
| didrocks | "Rejected by Brian Murray: Daily releases are not appropriate for an SRU." | 05:33 |
| didrocks | also, it seems the files are again deprecated (we can't expect to have the files around for 2 months :/) | 05:34 |
| didrocks | infinity: should I reupload the bamf manual upload so that it can be reviewed before being rejected based on version number? | 05:35 |
| === Noskcaj10 is now known as Noskcaj | ||
| wgrant | didrocks: Hmm, why does sru-staging need to be nonvirt? Can't you just copy the binaries? | 06:10 |
| didrocks | wgrant: would that work, that won't skip powerpc/armhf for instance? | 06:11 |
| didrocks | as we'll have: | 06:11 |
| didrocks | daily-build -> binary copy to -> sru-staging -> binary copy to -> distro | 06:11 |
| wgrant | Right, that would work fine. Non-virt-ness only affects build creation, not copies. | 06:12 |
| didrocks | ah, so fine without one I guess | 06:12 |
| didrocks | wgrant: I'll implement that today then, just need to think about the best strategy to only use that ppa for SRUs | 06:13 |
| xnox | didrocks: wgrant: everything that ends up in ubuntu archive should be compiled on non-virt. If one compiles on virt ppa, copy sources to the distro such that it's rebuild on the distro builders again. | 08:11 |
| didrocks | xnox: who is telling it's going to be compiled on non-virt? | 08:12 |
| xnox | didrocks: hm, I guess I miss read the backlog. | 08:12 |
| didrocks | xnox: we are talking about binary packages copy | 08:12 |
| didrocks | I just wanted to ensure that if the ppa is non virt and we do a binary package to it, it won't skip the archs that aren't in non virt ppas | 08:13 |
| xnox | didrocks: I see now. no compilation will happen in sru-staging, just storing the binaries. Nice =)))) | 08:13 |
| didrocks | yep :) | 08:13 |
| * xnox like & +1 | 08:13 | |
| * didrocks points to "already implemented for an hour" :p | 08:13 | |
| didrocks | (only SRUs will follow that extra copy) | 08:14 |
| cjwatson | wgrant,didrocks: I'm not totally sure I'm comfortable with binaries from virt builds being copied into the archive, what with them being built in a somewhat different environment and all ... | 10:00 |
| cjwatson | Oh | 10:00 |
| cjwatson | Sorry, read the whole backlog now :) | 10:00 |
| didrocks | :) | 10:00 |
| cjwatson | Yeah, copies through virt are fine | 10:00 |
| didrocks | I'll just do that for SRU btw for now | 10:01 |
| didrocks | see how it goes, and if we should do that unconditionnaly | 10:01 |
| didrocks | I hope we can finally have a raring SRU for unity at some point :p | 10:01 |
| cjwatson | jibel: I'm considering deploying the autopkgtest/proposed-migration integration today | 12:47 |
| cjwatson | jibel: I think I have it working, but of course it's a bit hard to tell in dry-run mode because a full test relies on going back and forward to Jenkins | 12:48 |
| cjwatson | jibel: Would you be available to watch activity on the Jenkins side and let me know if jobs are arriving correctly? | 12:48 |
| jibel | cjwatson, Yes, I'm available. I'll watch it. | 12:49 |
| cjwatson | OK. I'm just doing a few last tests ... | 12:50 |
| jibel | cjwatson, I disabled the cron entry on lillypilly, you can submit real jobs if you want. | 12:51 |
| cjwatson | I guess if we aren't doing fully-recursive dependency expansion we still want the occasional cronned run? | 12:53 |
| === mmrazik_ is now known as mmrazik | ||
| jibel | cjwatson, won't it confuse britney to receive results for tests it didn't request? | 12:57 |
| cjwatson | Shouldn't | 12:57 |
| cjwatson | As long as any causes from britney-initiated runs don't get lost | 12:58 |
| jibel | cjwatson, okay, I'll keep it disable for the moment, this way I know that all the requests received by jenkins come from britney. I'll reenable it if needed once we made sure everything is running as expected with britney. | 12:59 |
| cjwatson | jibel: You should have just got / be about to get a request for evolution-data-server 3.8.3-0ubuntu2 | 13:00 |
| jibel | cjwatson, confirmed: Found publication: evolution-data-server Proposed 3.8.3-0ubuntu2 jr jriddell@ubuntu.com | 13:01 |
| cjwatson | Hm, but nothing in excuses | 13:02 |
| === mmrazik is now known as mmrazik|afk | ||
| cjwatson | I might just not have cleared out enough state | 13:04 |
| cjwatson | Hopefully the next job will do better | 13:04 |
| cjwatson | jibel: I'm only waiting for amd64 results at the moment. Handling the multi-architecture case confused me. | 13:08 |
| cjwatson | OK, well that much seemed to work | 13:21 |
| cjwatson | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#evolution-data-server | 13:21 |
| cjwatson | autopkgtest for evolution-data-server 3.8.3-0ubuntu2: PASS | 13:21 |
| cjwatson | jibel: If I do a request, submit, and collect in quick succession, is the collect guaranteed to give me back the request I just made (even if it's just as "NEW")? | 13:22 |
| cjwatson | jibel: And for that matter can you remind me whether collect also returns old results? | 13:22 |
| jibel | cjwatson, once a result as been collected, it is archived and won't be collected a second time. | 13:23 |
| cjwatson | Ah, so it's synchronous on the collection. That should be fine | 13:24 |
| cjwatson | I have a feeling the answer to my first question may be no, though | 13:24 |
| jibel | cjwatson, if you request/submit/collect in quick succession, I have a doubt, there should be no result at all on the collection | 13:25 |
| jibel | I'm checking | 13:25 |
| jibel | cjwatson, answer to your first question is no. for a given package collect won't return any result until the tests have run on all archs. | 13:39 |
| jibel | cjwatson, but there is the information that a test is running, so I could return it if you need it. | 13:40 |
| === mmrazik|afk is now known as mmrazik | ||
| cjwatson | jibel: That would be helpful, but if you think it's the wrong thing to do I can work around it | 13:57 |
| jibel | cjwatson, not at all, the collect command is not used by anything else than britney. I can do any changes that you find helpful. | 14:05 |
| * infinity gets a giggle out of backscroll and people continually misreading the SRU PPA virt/non-virt thing. :P | 14:33 | |
| === mmrazik is now known as mmrazik|afk | ||
| bregma | hey guise who knows what the plans are for a Unity SRU in 13.04? | 15:51 |
| cjwatson | jibel: It might be an idea to check reverse-build-deps too | 16:12 |
| cjwatson | Or maybe not, I don't know | 16:13 |
| cjwatson | Since we care more about whether it breaks users | 16:13 |
| cjwatson | Yeah, never mind that :) | 16:14 |
| infinity | didrocks: Please do reupload that, yeah. I'm inclined to agree with Brian that we don't want "daily builds" as SRUs, the part he missed is that these are tested and "blessed" builds that happen to be yanked from the daily stream. | 16:23 |
| infinity | didrocks: My objection would just be ugly version numbers and end-user confidence in such, but I suspect I'd lose that argument. | 16:23 |
| didrocks | infinity: we never had any better test trigger and repetitively ensuring we don't regress than with dailies TBH :) | 16:24 |
| didrocks | infinity: we are repreparing another SRU daily round, using a sru-staging ppa this time | 16:25 |
| infinity | didrocks: Awesome. Thanks for that. I will try to get it reviewed ASAP anyway, thanks to the shell shock from previous delays. | 16:35 |
| infinity | didrocks: But I still hate relying on things that *might* disappear, so yay. | 16:36 |
| didrocks | infinity: yeah, this time it won't happen I hope, with this ppa (so 2 stage copy process) :) | 16:36 |
| infinity | didrocks: (I actually did review and attempt to accept things last week, which was what led me to throw my hands in the air and say "dude, just do the staging PPA" as I saw LP reject all my hard work) | 16:36 |
| didrocks | infinity: well, I've been busy lately and I understood from Mirv that you were going to do the review the same day than we uploaded the 2nd batch, hence the "on my too long TODO list" | 16:37 |
| didrocks | at least, we'll know soon if it's working :) | 16:37 |
| bdmurray | infinity: If I am remembering correctly, one other issue I had with the changelog for bamf was that there were two entries in it and there LP bugs in both entries and only the first ones would be auto closed by the janitor. | 17:19 |
| cjwatson | That's actually not true provided that the package has been in the relevant -proposed suite before | 17:21 |
| cjwatson | (I think) | 17:21 |
| cjwatson | Anyhow that's only a signed dpkg-genchanges away :) | 17:21 |
| infinity | bdmurray: Oh, was the .changes wrong? I hadn't gotten to looking at it yet. | 17:23 |
| infinity | bdmurray: Still, that's not what your reject message said. :) | 17:24 |
| bdmurray | It seems I should have kept better notes to be able to refer to today | 17:25 |
| infinity | bdmurray: I'm not too concerned. They're going to blat a whole new set of SRU candidates at us soon enough, and I'll get those reviewed. | 17:26 |
| infinity | bdmurray: It's just been a comedy of errors trying to get this autolanding stack in. | 17:27 |
| bdmurray | cjwatson: were you going to submit a Launchpad bug about copy package and phased update percentage? | 17:33 |
| bdmurray | infinity: okay, I'll still keep better notes next time / save the diff | 17:33 |
| Trevinho | infinity: any news on unity sru for raring? | 18:05 |
| infinity | Trevinho: There isn't one in the queue right now, I'm waiting on didrocks to fix up his staging PPA workflow, and we'll have another batch | 18:11 |
| Trevinho | infinity: ah... I was told days ago that it was in queue... | 18:12 |
| infinity | Trevinho: And that all got rejected due to the lack of staging PPA, and the files timing out. So, we're working on making it more foolproof. | 18:12 |
| Trevinho | infinity: ah, I see | 18:12 |
| Trevinho | infinity: thanks for the update | 18:13 |
| cyphermox | can someone please reject libdbusmenu_0.6.1-0ubuntu3.1 from the precise proposed queue, it's wrong... | 19:07 |
| stgraber | cyphermox: done | 19:12 |
| phillw | hi, on todays builds for lubuntu we seem to have 'lost' ZRam. Has there been an updated seed file from Julien, or is the builder just having an 'off-day'? | 22:32 |
| jbicha | phillw: it's listed in the lubuntu manifests | 22:35 |
| phillw | jbicha: zram-config ... got removed from 13.10 daily build of 17-Jun | 22:35 |
| phillw | I'll grab the ISO to my server (faster) and check it is still there. | 22:36 |
| jbicha | you can check the manifests at http://cdimage.ubuntu.com/lubuntu/daily-live/current/ | 22:37 |
| jbicha | or the build logs at http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/saucy/ if something was added or removed, it would be listed there | 22:37 |
| stgraber | phillw: it's listed in the manifest of all of today's daily, daily-live and daily-preinstalled | 22:38 |
| phillw | jbicha: stgraber thanks, I've asked the OP to zsync & am also pulling in zsync http://cdimage.ubuntu.com/lubuntu/daily-live/20130617/saucy-desktop-i386.iso.zsync | 22:43 |
| phillw | to my server | 22:43 |
| phillw | is there a way to do a diff between the build on http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/saucy/daily-live-20130610.log and http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/saucy/daily-live-20130617.log to just check if it has fallen off? The OP is adamant that it is not in today's image. | 23:42 |
| jbicha | phillw: if you look at the 0613 log you can see that zram-config was added that day and xscreensaver was dropped; if something else changed it would show up like that in the log | 23:46 |
| stgraber | phillw: I think it'll benefit everyone here if you confirm issues before bringing them to this channel | 23:48 |
| stgraber | phillw: anyway, in this specific case, as both jbicha and I have been telling you, zram-config is in your image: http://paste.ubuntu.com/5775623/ | 23:48 |
| phillw | jbicha: this is really wierd, the iso from those days was running ZRam happily, but I'm told it is not there on todays image. The zsync confirms the md5 is correct. Where in the ISO (I've got it mounted in /mnt/loop) would I see it. | 23:48 |
| phillw | stgraber: ^^ | 23:49 |
| stgraber | phillw: see the link I gave you 30s ago | 23:49 |
| phillw | stgraber: no, actually in the ISO, please? | 23:49 |
| stgraber | phillw: please read that paste again | 23:50 |
| stgraber | carefully | 23:50 |
| phillw | stgraber: there is no /etc in the ISO | 23:51 |
| stgraber | phillw: indeed, and if you actually read what I paste, you'll see why and where the listing actually comes from | 23:51 |
| phillw | stgraber: I'm sorry for being a n00b at this, I've done mount -t iso9660 -o loop ./saucy-desktop-i386.iso /mnt/loop0 | 23:57 |
| phillw | which has mounted it and 'ls -l /mt/loop0' shows stuff in the directory, but 'find /mnt/loop0 | grep zram' reports nothing | 23:57 |
| stgraber | phillw: right, and if you had read my paste, you'd have noticed I'm doing a second loop mount to actually see what's in the live file system | 23:58 |
| phillw | *ls -l /mnt/loop0* | 23:58 |
| stgraber | http://paste.ubuntu.com/5775623/ <= line 20 and line 23 | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!