#ubuntu-release 2010-05-01 <lool> Who's finishing the publishing for the remaining images? <kees> $ gpg --verify SHA256SUMS.gpg SHA256SUMS <kees> gpg: Signature made Thu 29 Apr 2010 11:48:44 PM PDT using DSA key ID FBB75451 <kees> gpg: BAD signature from "Ubuntu CD Image Automatic Signing Key <johncrosby@example.net>" <kees> ??? <kees> slangasek, cjwatson, elmo: ^^ looks like the *SUMS.gpg files were regenerated a day after the *SUMS files and are wrong now. <kees> pitti: maybe you have visibility into this too? <slangasek> lamont: oldking> no objections here <slangasek> lamont: (sorry, would've answered sooner, but the hotel in Dublin misled me with their claims of wifi into believing I could *use it to do useful things on the Internet*) <slangasek> kees: which directory is that in? <slangasek> kees: n/m, found it; fixed <lamont> slangasek: heh. #ubuntu-release 2010-05-02 <ogra> slangasek, http://cdimage.ubuntu.com/ports/releases/lucid/release/ still has no server images, are they supposed to show up somewhere else or are they just not done yet ? <elmo> ogra: umm, server images are on releases.u.c? <ogra> elmo, armel/ports :) <ogra> (steve knows i'm talking about ports i suppose :) ) <elmo> ah, yes, for all the armel servers :-P <ogra> right <ogra> not really, but for easy development systems without net connection :) <ogra> you dont really want netbook for those ona 256M beagleboard <slangasek> mmh, it looks like antimony is out of disk space <slangasek> elmo, lamont: can you cycle old-images off of antimony? <slangasek> ogra: ^^ once that's done, I can publish the ports server images #ubuntu-release 2010-05-03 <mdeslaur> The page here: http://www.ubuntu.com/getubuntu/upgrading#Upgrade%20from%208.04%20LTS%20to%2010.04%20LTS <mdeslaur> says to run "update-manager --devel-release" to upgrade to lucid, which is probably wrong... <mdeslaur> can someone correct that, please? <mdeslaur> This page also says it: https://help.ubuntu.com/community/LucidUpgrades <ScottK> mdeslaur: That last one is a wiki page. <mdeslaur> oh, hmm...it may be right, as doing a "update-manager --check-dist-upgrades" doesn't work on hardy <ajmitch> mdeslaur: I saw mention in here of LTS->LTS upgrades being enabled for 10.04.1 <mdeslaur> ajmitch: yeah, that's what I think also. I just thought "--devel-release" didn't sound like the right option :) <kraut> moin * ofirk !pastebin <lool> Cool, full/ports/releases/lucid/release/ubuntu-10.04-server-armel+omap.img published now <ogra> lool, yeah, antimony was out of space <ogra> so it took a bit <lool> Odd I dont see the image on http://cdimage.ubuntu.com/ports/releases/lucid/release/ <lool> ogra: Do you know why the OMAP server image isn't on http, but is in full/ <ogra> lool, i doubt slangasek has hit the publish button yet #ubuntu-release 2010-05-04 <kraut> moin <cjwatson> mdeslaur: indeed, --devel-release is deliberate until LTS->LTS upgrades are enabled. You can make it read -d if you like instead, if that "looks better" ... <mvo> mdeslaur: --proposed will also work, that is probably a more friendly term <lool> cjwatson: heya; would you know what needs to happen to propagate the 10.04 server armel+omap image to http://cdimage.u.c? It only appears on the cdimage machine, but not over http <lool> http://cdimage.ubuntu.com/ports/releases/lucid/release/ only has the netbook omap image <lool> but full/ has the image <cjwatson> I think you'd need to ask IS, if the mirroring isn't working properly <lool> Ok; thanks <ogra> lool, /srv on antimony still seems to only have 25M free <ogra> lool, so its likely a fallout of the out of space issue still <ogra> cjwatson, couldnt http://cdimage.ubuntu.com/releases/intrepid/release/ be removed/backed up ? <ogra> same for http://cdimage.ubuntu.com/ports/releases/intrepid/release/ <cjwatson> should be moved to old-releases <ogra> right <ogra> that should give is plenty of space again <cjwatson> but I don't see why *antimony* being low on disk space should affect rsyncs *from* antimony! <cjwatson> that's guesswork and doesn't seem likely <ogra> hmm, i thought it didnt get copied internally in the first place <ogra> but i see thats wrong <cjwatson> I don't want to touch old-releases in a rush, because the master for that is also antimony, and thus we need to be careful that we don't lose the images when removing them from antimony <ogra> right, sorry i didnt get that its in full/ already in the first place * cjwatson compresses some old log files <ogra> hmm, HEADER.html doesnt have armel server in that directory #ubuntu-release 2010-05-05 <lamont> slangasek: around yet?" <slangasek> lamont: mostly not? (contentless-ping + airport comedy -> fail) <lamont> heh <lamont> I got the amd64 livecd build down to 7 minutes... <slangasek> oh good :) <lamont> otoh, dvd failed that way.. seems it needs more than 3GB of space <lamont> tmpfs is love. <slangasek> heh <lamont> the apt-ge tinstall of minimal+++ is where we spend 23 minutes of the build on amd64, regardless of whether we're building i386 or amd64 images. <lamont> so... with a tmpfs, the entire build time drops to 7 minutes <lamont> same apt invocation on terranova was 9 min (no tmpfs) <ScottK> Thanks. <ScottK> Oops, wrong channel <lamont> slangasek: 7 minute ubuntu-dvd/amd64. I WIN <lamont> meh. reading fail. make that 15.5 min ubuntu-dvd/amd6t4 <ogra> slangasek, something is still wrong with the armel server image publishing, they sit in www/full and were properly renamed and copied, but HEADER.html doesnt have them and cdimage.u.c doesnt have them either <lamont> ogra: edubuntu-dvd amd64 livefs build time: 21 minutes <lamont> I think I'm going to upload that version of livecd-rootfs #ubuntu-release 2010-05-06 <slangasek> ogra: http://cdimage.ubuntu.com/ports/releases/lucid/release/ - I see them here? <slangasek> (perhaps you were racing me? :) <ogra> yeah <ogra> that wasnt hard given your traveling time though :) <ogra> did you arrive safely now ? <slangasek> yeah, I think you commented here *while I was publishing* <ogra> heh <slangasek> I'm safe, and I've arrived somewhere <ogra> lol <slangasek> I haven't reached GÃ¶ttingen yet, but my flight to FRA should be boarding soon <ogra> ouch <ogra> youre on the train then ? <doko> flight to FRA from Goettingen? <ogra> next stop afer gÃ¶ttingen is my home town :) wave if you pass kassel ;) <ogra> *after <ogra> doko, in an ultralight plane through the rain, eh ? * ogra doubts there is any airport like thing in GÃ¶ <slangasek> flight to FRA from *London*, train from FRA to Goettingen <ogra> *to* goetiingen ? <slangasek> yes? <ogra> where do you go from there ? <slangasek> I'm trying to get *to* Goettingen for SambaXP <ogra> oh <ogra> i thought you try to get to brussels <ogra> heh <slangasek> Brussels on Saturday <ogra> yeah <ogra> i was just a bit confused by the direction <ogra> so you passed kassel already most likely :) <slangasek> 11:04 < slangasek> [...] but my flight to FRA should be boarding soon <slangasek> so no? :) <ogra> oh, right <ogra> "I haven't reached GÃ¶ttingen yet" was the part that confused my brain <lamont> slangasek: you want livecd-rootfs 1.115 before you do your first round of CD fs images, fwiw #ubuntu-release 2010-05-08 <elleuca> hi, silly question: is the 10.04 netbook edition a LTS release or not? on www.ubuntu.com only desktop and server are marked as LTS :| #ubuntu-release 2010-05-09 <slangasek> lamont: right, looks like we have the right livecd-rootfs in, sounds good :) <lamont> yep. #ubuntu-release 2010-05-10 <ara> slangasek, are you available for the ISO testing session? <slangasek> ara: yes! #ubuntu-release 2010-05-13 <ara> slangasek, did you check if the testcase review session conflicts with any other session you may have? <ara> slangasek, it is today at 1700 <slangasek> ara: I'll be there <ara> slangasek, ok, great, thanks <slangasek> in general, marking people as attendance essential is supposed to DTRT in the summit software, though apparently I had one yesterday that overlapped and I didn't notice :( #ubuntu-release 2010-05-14 <ttx> join #ubuntu-uds-cocobolo-3 <ttx> aarh #ubuntu-release 2010-05-17 <lamont> slangasek: when the need arises, you have maverick-live chroots <slangasek> yay <ScottK> slangasek: Is it possible to remove images from the Kubuntu ports releases page? <slangasek> ScottK: I'm a little uncomfortable removing them after the fact - are they completely unusable? <ScottK> slangasek: I think it's reasonable to say the sparc one is. <ScottK> Our status is: powerpc - somewhat tested and believed to work, ia64 - untested, but may work, sparc - the entire port is broken, so no point in testing. <slangasek> howso? I heard that the conclusion last week was that sparc is busted and not going to get better, but I don't have details <ScottK> I didn't hear details beyond the kernel doesn't work. <ScottK> That was enough for me. <ScottK> Maybe lamont knows. <slangasek> lamont: do you know? <ScottK> perhaps more relevant, perhaps lamont will admit to knowing.... <lamont> heh <lamont> so... the conclusion of the "what about ia64/sparc (and ppc)?" session: keybuk to go to tech board for ratification and mailing under their from address that sparc is clearly (1) broken and (2) not being loved, therefore all y'all have until feature freeze to make it work, or it'll be removed and lucid will be the last sparc release until such time as revived. <slangasek> lamont: clearly broken how? <lamont> re: ia64: clearly neglected, but basically working. Needs a new toolchain champion (as does sparc), doko won't be spending time on it other than vetting patches and uploading for the champion(s). <lamont> slangasek: upgrading from jaunty to karmic causes a reboot in a state where the machine is unbootable. lucid lacks a kernel, I'm not sure of the state of installability from media in even karmic. <slangasek> "lacks a kernel"? <slangasek> there is one in the archive <lamont> ppc: has a strong community, seems to be doing ok, we'll address that one sometime between now and whatever will expire after the next LTS <lamont> slangasek: if only it booted <slangasek> why doesn't it boot, what range of hardware has this been verified on, is there a bug #? <lamont> slangasek: nfc here. pure hearsay <slangasek> well, hmm. Hearsay from whom? <slangasek> I'm not willing to nuke images from the release that we won't be able to get back afterwards, based on hearsay alone <lamont> my sparc box is not very happy (at least according to the guy I loaned it to last), and I haven't played with it in forever <slangasek> (well, ok, we can get those back afterwards by rebuilding from the release pocket, but) <lamont> slangasek: I don't see any reason to nuke them, given that they're clearly not supported in any case <slangasek> the reason to nuke them is that they're kubuntu images and the kubuntu folks (in person of ScottK) are asking for the nukage <ScottK> It's not essential to have it removed, but if we're going to point people at the ports directory, it would seem CoC friendly not to point them at known broken stuff. <ScottK> OTOH, the odds of anyone caring about sparc and a desktop are low enough, meh. <lamont> at least add a header to the html in the directory saying "known broken, fixes welcome"??? dunno #ubuntu-release 2010-05-18 <Riddell> hmm, mass-sync is broken :( <Riddell> (or the launchpad lib it uses) <cjwatson> broken? <Riddell> cjwatson: http://paste.ubuntu.com/435516/ <cjwatson> doesn't look particularly specific to mass-sync <Riddell> right <doko> ubuntu-archive: please promote libgraph4 libpathplan4 libxdot4 libgvc5 libgvpr1 (assume all of this are doxygen/graphviz deps) <cjwatson> doko: done <doko> cjwatson: libcdt4 libcgraph5 as well please <cjwatson> doko: done <cjwatson> doko: (feel free to do binary promotions yourself when the source package is already in main) <doko> ok <lamont> slangasek: btw, fdupes takes like 20 seconds <slangasek> lamont: this is in the context of cjwatson suggesting that should be omitted because it's an expensive no-op? <lamont> oh. thought that was you. <lamont> yeah <lamont> manifest building is a bit more <lamont> 19:10:27 301 19:05:37 68 19:11:10 201 start livefs_squash <lamont> that's a bit more interesting <lamont> king, kapok, terranova #ubuntu-release 2010-05-19 <ScottK> slangasek: We've got a new project this cycle for Kubuntu that may or may not get mature enough for ISOs in this cycle. Would you rather get images started early and get a "nevermind, not mature enough - stop" or wait and see and potentially get a request later in the cycle for new images? <slangasek> ScottK: IMHO it's better to start the images early <ScottK> slangasek: Thanks. I'll work on that. <cjwatson> could somebody who isn't me review openssh in lucid-proposed? <slangasek> cjwatson: looking <lamont> doko: your gnat-4.4 build is live on vernadsky, should succeed <lamont> doko: btw, does it make sense to let the gnat-4.4 build on buttercup finish? <lamont> (and do wait for i386 to finish before you upload a new gnat-4.4, right...) <doko> lamont: yes: still building with the older gcc-4.4 <doko> no need to upload a new gnat-4.4, just need the new gcc-4.4 to build it <lamont> ah, ok <charlie-tca> slangasek: I hate to be the bearer of bad news. The abiword-proposed fails in 64bit <slangasek> charlie-tca: fails how? <slangasek> (I tested it on 64-bit, myself) <charlie-tca> freezes the same way <slangasek> after upgrading all of the related binary packages from lucid-proposed? <slangasek> er <slangasek> it's not even *built* yet on 64-bit <charlie-tca> I only had abiword-common in proposed. The plugins were not there on 64bit <slangasek> so you can't have tested it :) <charlie-tca> well <charlie-tca> That is a great explanation! Thanks <slangasek> charlie-tca: abiword/amd64 is published now <charlie-tca> tested good, too. Thank you very much! #ubuntu-release 2010-05-20 <doko> ubuntu-archive: please could somebody accept the gnat-4.4 binaries in NEW? <cjwatson> doko: done #ubuntu-release 2010-05-21 <Riddell> cjwatson: I added one more into (presumably) your syncs <cjwatson> I was just extracting my syncs individually so that you could flush <cjwatson> go ahead <Riddell> ok <lamont> btw, new buildd rollout, hence the manual world #ubuntu-release 2010-05-24 <lamont> slangasek: how soon are you planning on daily builds? <lamont> slangasek: rolling new maverick tarballs, btw <cjwatson> installer still isn't quite ready though I'm getting close <elmo> someone should fix the topic, just sayin * cjwatson changed the topic of #ubuntu-release to: Maverick Meerkat Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release managers with beer | we accept payment in cash, check or car insurance ads | melior malum quod cognoscis <lamont> so if I send you a car insurance ad, that'll count as payment? <ScottK> lamont: remember this script you put in to make OOo not timeout on armel? Could we have something similar to get qt4-x11 built there? <lamont> ScottK: this early in the cycle, could we just fix the package please? <ScottK> It's not clear what 'fix' would mean in it's current state since the dbg really takes that long to build. <ScottK> We are promised qt4-x11 getting more modular, but it hasn't happened yet. <lamont> something that makes sure we spit something out to stdout every 120 min or so, after verifying that the build is, in fact, progressing <lamont> take a look at the compilers :-( <ScottK> Sigh. #ubuntu-release 2010-05-25 <lamont> ScottK: as in this is what I get for bending over and violating rules just to avoid rebuilding oo.o everywhere <ScottK> lamont: OK. I'll figure something out. <Riddell> someone doing New queue? <Riddell> cjwatson? <cjwatson> yes <cjwatson> just new-binary-debian-universe though, not anything more substantial <cjwatson> I was clearing it out a bit in preparation for a new-source run <cjwatson> I've filtered out everything that already had a source publishing record in the main archive (so was probably removed at some point); the rest looks OK <Riddell> cjwatson: ok, I'm going to start on reviewing the manual bits of new queue <cjwatson> Riddell: I'm dropping a new-source run (for Debian main anyway) into NEW now - I'll process it all straight away on the basis that it comes from Debian, but you'll see a temporary spike in the queue size <cjwatson> 352 source packages <Riddell> whee #ubuntu-release 2010-05-26 <Riddell> I approved libvpx for webm video codec yesterday but I read an article this morning about it not being open source because the patent licence is only for "this implementation of VP8" anyone got an opinion? http://www.webmproject.org/license/software/ <Riddell> http://www.computerworlduk.com/community/blogs/index.cfm?entryid=2973 <ogra> cjwatson, do you think its evil to wipe the image files from the scratch dir on antimony after building the actual image (i guess there is a reason we keep them around) <ogra> with the preinstalled images we'll build for omap the image spit out by livecd-rootfs will be around 1.5G, i dont want to waste the space permanently (we plan to bzip the image once debian-cd is done so the result is only ~500M) <cjwatson> ogra: up to you for this one image, but please don't purge scratch stuff in general - it's often useful for debugging <ogra> nah, not in general, but given the size constraints i dont want to have a 1.5G ext3 image around if i dont really need it <ogra> since we'll build two images (one for omap, the other for omap4) that already piles up to 3G * ogra doesnt want to make elmo cry <cjwatson> remove it if it seems most sensible, it's not worth spending time discussing it :) <ogra> indeed <ogra> i just wanted to know if there was a pressing reason to keep them <ScottK> Riddell: My understanding, which may be incorrect, is that we only worry about patents that people are actively enforcing. On that understanding, I think it's OK. <Riddell> ScottK: yes that's what I'm thinking too #ubuntu-release 2010-05-27 <seb128> nigelb, there? <seb128> nigelb, where should I look for patches to reviews? <seb128> ups <seb128> wrong channel <lamont> slangasek: not that you're using it, but kapok is not yours atm, use king if you have a need. #ubuntu-release 2010-05-28 <slangasek> liveCD builds broken due to DPKG_FSYNC? <cjwatson> heh, I hadn't actually looked at the failures yet <cjwatson> lamont: ^- could you please unhose livecd.sh in the maverick chroots? <lamont> slangasek: you're building lucid livecds then.... I thought you always forced the distro, no? <cjwatson> uh <cjwatson> certainly not intentionally building lucid <cjwatson> and I didn't change anything in how buildlive is invokved <cjwatson> *invoked <cjwatson> if we're not forcing it now, we never were <cjwatson> ah, heh, there's a DIST=lucid lying around <cjwatson> sigh - fixing <lamont> the DPKG_FSYNC hackery was just inside lucid chroots. <lamont> I've changed things to default to maverick, too. <lamont> and planning to review and land NCommander's change to actually parse options sanely <cjwatson> fixed buildlive defaults, rerunning <ogra> lamont, oh, do you plan to merge the ext2/3 stuff too (then i wont bother) <lamont> ogra: that's the part I have to review. he gagged on the command line option parsing <lamont> which I cannot blame him for <ogra> yes, i know <lamont> ogra: if you want to review and merge it, that'd be a win from my perspective <ogra> i was firstly asking him to take it back but he said you were happy about it :) <cjwatson> ah, now we have proper failures <lamont> originally, there were no options. then it grew <ogra> the other code looks fine to me, i reviewed it already but didnt find time to actually do the merge <lamont> ogra: go for it. and then toss a ticket at me to migrate BuildLiveCD out of the chroot so that you can actually pass in the options you need... <ogra> perfect, will do it before ending my day <lamont> sad to say, it's more a dev thing that a me-thing, for the current hat-of-the-day <ogra> we're still lacking debian-cd changes so there is no hurry <ogra> (i dont expect us to make A1) * cjwatson wonders whether A1 will make A1 <ogra> heh <ogra> we could hand-rool some images :) <ogra> *roll <cjwatson> ah good, there's an approved MIR here for argparse <cjwatson> fixed some archive problems that were also breaking things <ScottK> cjwatson: If I wanted to have a brief chat with the release manager, who would I talk with at this point? <cjwatson> ScottK: that's a good question <ScottK> cjwatson: OK. I'd like to have such a chat. Would you perhaps suffice? <cjwatson> possibly - although I'm just about to end-of-week <ScottK> It can wait until next week. I'll try and catch you then. #ubuntu-release 2010-05-30 * slangasek giggles at the predicted http://q-funk.blogspot.com/2010/05/ubuntu-building-its-i386-libc6-with.html #ubuntu-release 2010-05-31 <pitti> Good morning * pitti re-enables cron jobs, the uninstallabilities from last email report should all be gone now <pitti> ok, needs livecd-base first, which needs the linux kernel NEWed first, doing that now <pitti> cjwatson: sorry for the initial d-i FTBFS spam (NEWed kernel wasn't published yet), it's building now <ara> pitti, ping <pitti> hey ara, good morning! <ara> pitti, morning :-) <ara> pitti, quick question, for alpha-1, are we releasing only ubuntu alt? <pitti> ara: I don't know yet; I'm waiting for the publisher to get d-i updated, then I'll build a first set of images and see what breaks <ara> pitti, OK, thanks. Please, keep me posted :-) <pitti> ara: if they build and work, I think we should release desktops, too; they're great for testing on various hw, etc. <ara> pitti, what about other flavours? <pitti> I expect at least Kubuntu, not sure about the others <pitti> (and server) <ara> pitti, OK, thanks! <pitti> I guess we'll build them all, post them to the tracker, and see what sticks? <pitti> is that ok with you? <ara> pitti, sure, if they build... :) <pitti> ah, live cd base finally built * pitti boldly starts an ubuntu live build <pitti> meh, failed with an empty log <pitti> cjwatson: do you know why http://cdimage.ubuntu.com/daily/20100531.1/source/ also has a lucid-src? <pitti> ok, missioncontrol uninstallability sorted out <pitti> but what I don't understand is why the daily ubuntu and server .isos don't show up, just their reports.html <pitti> cjwatson: FTR, all "Release minus 6 days" stuff should be done now, except the marketing team bit <pitti> so, I fixed the seeds for the -5 kernel, but that shouldn't stop cron.daily from building at least a broken iso, or does it? <pitti> ah, seems it does, sorry <pitti> debian-installer has kernel ABI 2.6.34-5-generic, but no corresponding udebs are on the CD! <pitti> make: *** [/srv/cdimage.ubuntu.com/scratch/ubuntu/daily/tmp/maverick-amd64/bootable-stamp] Error 1 <pitti> http://cdimage.ubuntu.com/daily/20100531.2/ for your testing pleasure <pitti> ara: ^FYI * pitti rsyncs and does a smoketest first <ara> pitti, thanks <pitti> ara: I grab the amd64 one, just to see how far we'll get with a default install <ara> pitti, OK, I'll do the i386 one <pitti> ttx: FYI, http://cdimage.ubuntu.com/ubuntu-server/daily/20100531.1/ is the first maverick server build ever; mind doing a quick smoketest? (or delegating to someone :) ) <pitti> I don't know why lucid images are there as well <pitti> ara, all: http://cdimage.ubuntu.com/daily-live/20100531/ good for first smoketest (beware, oversized) <ara> pitti, OK, thanks. I will start syncing <pitti> I'll drop langpacks for tomorrow's daily <pitti> Riddell: http://cdimage.ubuntu.com/kubuntu/daily/20100531/ -> for first smoketest <pitti> building kubuntu desktop now <ttx> pitti: sure <ara> pitti, alt i386 installs correctly and reboots correctly (spanish; no-network) <pitti> ara: thanks; desktop doesn't start for me, hangs forever on usplash; will have a look after lunch <ara> pitti, same thing here (i386) <ttx> pitti: anything special to explain the suddenly oversized CD ? Looking at the package list I don't see anything that would explain +30Mb * ttx will dig deeper when the ISO will be downloaded <pitti> ara: ah, booting without splash/quiet reveals it: kernel oops in aufs * pitti files bug <ara> pitti, cool, thanks <ttx> pitti: tracked sudden size inflation it down to pool/main/l/linux/linux-image-2.6.34-5-virtual_2.6.34-5.12_amd64.deb <ttx> 12110 -r--r--r-- 4 root root 12399730 2010-04-16 16:05 pool/main/l/linux/linux-image-2.6.32-21-virtual_2.6.32-21.32_amd64.deb <ttx> 31782 -r--r--r-- 2 root root 32544062 2010-05-31 08:05 pool/main/l/linux/linux-image-2.6.34-5-virtual_2.6.34-5.12_amd64.deb <ttx> it's no longer a leaner kernel :) <pitti> ara_: filed as bug 587888 FYI, for the kernel team's enjoyment <ubot4> Launchpad bug 587888 in linux (Ubuntu Maverick) (and 1 other project) "aufs oops in au_do_open() on maverick live system boot (affects: 1) (heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/587888 * pitti waves to apw <ttx> pitti: filed bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/587893 <ubot4> Launchpad bug 587893 in linux (Ubuntu) "linux-image-2.6.34-5-virtual is oversized, results in oversized server ISO (affects: 1)" [Undecided,New] <ttx> pitti: is an oversized CD a blocker for alpha1 ? <pitti> ttx: well, not a really critical one, but this seems easy to fix <pitti> looks like a bad dependency in a metapackage somewhere? <pitti> ttx: oh, misunderstood you -- I thought you used ls on the CD pool/ to show that the CD now ships two kernels (lucid and maverick) <ttx> pitti: no, it's just the -virtual kernel that more than doubled in size <ttx> it may or may not be simple <pitti> right <ttx> pitti: I'll talk to john about it tomorrow, but if you want it fixed you should also mark it against alpha1 <pitti> ttx: is there something else we could temporarily take off the CD? <ttx> nothing easy that would spare us ~20Mb. <doko> ubuntu-archive: please accept llvm-2.7 in NEW <ttx> pitti: server CD mostly in good shape, spotted a syntax error when logging in <pitti> ttx: not bad for the very first maverick image ever <ttx> some bash-completion issue, will file bug <ttx> ev: bug 587910 <ubot4> Launchpad bug 587910 in bash-completion (Ubuntu) "[maverick] Syntax error in bash-completion.d/apt prints ugly messages at every login (affects: 1)" [Undecided,New] https://launchpad.net/bugs/587910 <ScottK> cjwatson: Around? <ogra> pitti, please skip arm images for A1 (or even dailies) we're re-rolling the build scripts for omap between A1 and A2 <pitti> ogra: right, they have a horrible list of uninstallability anyway <ogra> oh ? * ogra doesnt see anything image relevant on the ftbfs list <ogra> hmm, but i also dont see any ubuntu-netbook build logs for maverick <pitti> ogra: http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html <pitti> ogra: although most of it should just be Kubuntu due to a very low-level package (qt?) <ogra> right <ogra> there is nothing on the list that would prevent the armel netbook image on a quick look <ogra> (no armel under netbook-meta) <ScottK> qt4-x11 just got fixed on armel, so KDE should be buildable now, it's just a question of how long it will take. <ScottK> Speaking of which, pitti: would you please rescore phonon on armel? <pitti> ScottK: done <ScottK> pitti: Thanks. * ScottK is going to see how far he can get on getting the stack built.... #ubuntu-release 2011-05-01 <lamont> ScottK: only things that use apt... <ScottK> Yep. <ScottK> 'minor' <lamont> to like install build-deps or dist-upgrade or anything... <ScottK> Yep. <lamont> is there a fix for it yet, or are we still in limbo land? <ScottK> Still in limbo. <lamont> I suspect that part of my monday/tuesday will be dealing with bootstrapping the fix <ScottK> I hope it's not later in the week. <ScottK> I'm currently building oneiric's apt on natty to see what it does. <ScottK> apt-get source apt seems like a odd thing to be typing. <ogra_> the strace i did showed mmap issues, i would put my bet on libc or toolchain <ScottK> I added a gdb backtrace to the bug. <doko> ScottK, ogra: did somebody read my last comment? <ogra_> doko, yes, just now <ScottK> doko: I'm rebuilding apt with 4.5 on natty right now. <ogra_> doko, seems ScottK is on it ? <doko> apparently not rebuilding with 4.5 <ScottK> I am rebuilding with 4.5. <doko> but on natty, not oneiric <ogra_> using the natty apt in the chroot ? <ScottK> doko: If it fails on natty with 4.5 that will pretty conclusively point to apt. <ScottK> If it doesn't, then I'll try to figure out the easiest way to build apt with 4.5 on oneiric. * ogra_ is just compiling an ac100 kernel and all modules, that will take a while, but i can try a rebuild later #ubuntu-release 2011-05-05 <micahg> slangasek: would you happen to be around? <micahg> slangasek: unping #ubuntu-release 2011-05-10 <slangasek> skaet: foundations-o-releaseprocess is listed in summit as needing scheduling, but I remember sitting in that session yesterday ;) Did you need a second session scheduled for it, or did someone fatfinger? :) * skaet looking... but suspect it was a finger fumble #ubuntu-release 2011-05-13 <smoser> anyone know where skaet is ? i need here in http://summit.ubuntu.com/uds-o/meeting/server-o-cloud-images-release/ <smoser> Jokai 07 <cjwatson> smoser: I came in at :40 or so but you'd all left <smoser> yeah. i'll just work off line with kate. * cjwatson nods <slangasek> cjwatson, ev: does wubi in lucid ever use grub1 by default instead of grub2, or is bug #781628 just the classic user error? <ubot4> Launchpad bug 781628 in grub (Ubuntu) "package linux-image-2.6.32-31-generic 2.6.32-31.61 failed to install/upgrade: el subproceso instalado el script post-installation devolviÃ³ el cÃ³digo de salida de error 1 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/781628 <cjwatson> slangasek: never by default, we switched to GRUB 2 in Karmic <cjwatson> installing GRUB Legacy on Wubi is certainly an amusing way to break your system <slangasek> cjwatson: and a sadly frequent one - would love to talk to you about a path to dropping grub1 from the archive entirely <cjwatson> slangasek: *nod* I'm getting more comfortable with the possibility of migration; one thing I want to do is to review the process of migration that was documented in the latest Debian release notes, since I've read criticism of it as overcomplex <slangasek> cjwatson: I would love for us to be able to automatically rewrite the MBR on first successful boot following a chainload :) #ubuntu-release 2011-05-15 <Laney> can someone temporarily sync-blacklist haskell-dummy? or should I file a bug for this? <cjwatson> Laney: it's already in the blacklist due to overriding libghc6-agda-dev from some other source package, which broke sync-source.py -a <cjwatson> (I'd appreciate being told when that can be dropped, though) <Laney> cjwatson: cool, will do. I guess it can be removed at the end of the transition * Laney sets up a new tracking page <Laney> i see NEW has been flooded with haskell stuff :-) #ubuntu-release 2011-05-16 <cjwatson> Laney: flushed another pile of Haskell stuff through NEW <Laney> cjwatson: cheers, http://orangesquash.org.uk/~laney/transitions/ghc.html doesn't look so bad <Laney> although... <Laney> just noticed that https://launchpad.net/ubuntu/+source/haskell-hlist didn't get process-removals removed <Laney> did the buildX mess it up? <cjwatson> not sure, slangasek was handling process-removals <cjwatson> I think only an 'ubuntu' substring is meant to inhibit p-r * Laney goes blind at the p-r code :-) <Laney> http://ftp-master.debian.org/removals.822 does exist now <cjwatson> Laney: removed now <cjwatson> and haskell-hgl <cjwatson> how come stuff isn't going green on the ghc tracker, but only to unknown? <cjwatson> oh, wait, it is, I'm stupid <cjwatson> lamont: so, I'm looking at converting livecd-rootfs to live-build, and trying to figure out what would be involved * lamont has no knowledge on live-build <cjwatson> lamont: from your POV, would it be an acceptable interface for buildlive to call ssh $buildd BuildLiveCD <arguments to lb config>, and then BuildLiveCD could call lb config <args> then lb build? <cjwatson> (which is AIUI basically the normal sequence) <cjwatson> lb config has vast swathes of possible options <lamont> where does the chroot command live in that pile? <cjwatson> so we should be able to add options until it's equivalent to livecd-rootfs <cjwatson> I assume we'd have BuildLiveCD call lb * within a chroot, much as it currently calls livecd.sh <cjwatson> lb can optionally do its own chrooting, but I don't think that's useful for us <cjwatson> since we'll need to pick the right version of live-build anyway <cjwatson> Laney: I guess the ghc tracker is failing to update - do you know why? <Laney> cjwatson: I haven't cronned it yet <cjwatson> aha :-) <Laney> shamefully it was just a big && line <Laney> I'll write a proper script now that there's more than one thing to track <cjwatson> is any assistance needed with uploads, or is it all just in a giant dep-wait stack? <cjwatson> (NEW activity suggests the latter ...) <Laney> hopefully it should just be dep-waits <Laney> i'll need to do some merges/sync requests <Laney> and then if my account gets created soon I'll upload the remaining packages to debian <Laney> so from your side just keeping an eye on NEW should be enough <cjwatson> ok <cjwatson> removing haskell-network-bytestring <cjwatson> hmm, actually maybe I should leave that until haskell-network has built everywhere <cjwatson> which is ultimately down to haskell-transformers failing, which looks transient - I see you just retried that? <Laney> yep <cjwatson> any idea why haskell-transformers didn't show up on the tracker, though? it looks as though it should have done <Laney> perhaps it looked for binaries which matched the source version <Laney> it showed up as 'good' â could be a bit of a hole <cjwatson> 43 sync requests outstanding, sigh <Laney> uds hangover? <cjwatson> yeah <lamont> cjwatson: I suspect that BuildLiveCD wants to take a distroname, which it converts to a chroot name, and then chroots into that to do everything thereafter <lamont> but yeah, sounds about as sane as anything else <cjwatson> lamont: I guess I didn't want to have significant amounts of configuration encoded in BuildLiveCD, because then I either have to create a package for it (or keep livecd-rootfs around indefinitely), or we end up with the configuration hard to access by platform <cjwatson> which is why I'd rather have the lb config args passed in from somewhere else <cjwatson> if that makes sense <lamont> yeah <lamont> I concur with having a trivially simple BuildLiveCD script - possibly even thrown into live-build, 'tever <cjwatson> we'll probably want our own for a while because it'll need to handle both livecd-rootfs and live-build <lamont> yeah <cjwatson> I could make such a change in livecd-rootfs and then keep it around until we stop needing livefs builds for <oneiric <cjwatson> I guess <lamont> BuildLiveCD is actually delivered outside of the package these days <cjwatson> yeah, though copied from the package, right? <lamont> yes <lamont> copied from the package into $magicplace, from whence it is blatted out to all the builders <lamont> so as it sits, you get exactly one version of BuildLiveCD, consistently, within about 10 minutes from when I push the change live <lamont> zomg arm might catch up this week <NCommander> lamont: yay * ScottK wonders if he should upload KDE then. <slangasek> cjwatson, Laney: no clue why haskell-hlist didn't get caught in my last p-r run <cjwatson> Laney: in ghc.ben, shouldn't several of the * characters in your regexes be .* ? <SudoKing> are there any pre-alpha builds available? <cjwatson> no CD image-type builds, no <cjwatson> that's probably one of the tasks for this week <SudoKing> k <Laney> cjwatson: yes :-) #ubuntu-release 2011-05-17 <cjwatson> Laney: I'm not seeing much else in the way of Haskell stuff coming through NEW now, BTW, so I think the rest will need uploads/syncs <cjwatson> the Debian equivalent of the ghc tracker is less than 100% useful due to the lack of the .package test in is_bad <Laney> I think that haskell-dummy might be messing it up there <Laney> but I'm not sure <Laney> anyway, will look in more detail in the next few days <cjwatson> http://qa.ubuntuwire.com/ftbfs/ down about 200 from when I started attacking it earlier :-) <cjwatson> (mostly judicious retries and the odd rebuild) <cjwatson> and ocaml transition well underway <cjwatson> I think that's about two good days' work and I should go to bed <cjwatson> Laney: discussing hosting for the transition tracker with IS <Laney> cjwatson: cool. Will they want to build it (and therefore install an ocaml stack) or will shipping in a binary be ok? <cjwatson> *I'd* rather not ship in a binary :-) <cjwatson> I pushed a bzr-git clone of your branch to lp:~ubuntu-release/+junk/transition-tracker as a starting point <Laney> fair <cjwatson> not sure how we want to handle that branch - we could keep merging from your git branch, or we could move it to some team that includes at least ~ubuntu-release plus you, or we could do something else I haven't thought of ... <Laney> I'm not particularly wed to maintaining it, so if someone else wants to :-) <Laney> as in I can just do merge requests if need be <cjwatson> right, contrariwise I'm not a fan of the general approach of taking something that somebody was maintaining and putting it somewhere central where they no longer have access to it <cjwatson> maybe just an ubuntu-transition-tracker team <Laney> that works <Laney> I've heard there can be IS bureaucracy/lag around merging stuff from branches onto websites, so it'd be good to avoid that <Laney> thinking mainly of the .ben files themselves <cjwatson> it varies, most of the stuff I operate I have shell access to as well <cjwatson> though, well, maybe that's non-standard * Laney shrugs <Laney> best would be if it were automated <cjwatson> right <cjwatson> https://code.launchpad.net/~ubuntu-transition-trackers/+junk/transition-tracker now, then * Laney wonders how well bzr-git works <cjwatson> it's pretty smooth nowadays <cjwatson> that was just bzr branch; bzr push * ogra_ sees https://launchpad.net/ubuntu/+source/highlighting-kate/0.2.9-1/+build/2467254 and wonders if skaet knows that we have a package for that :) <highvoltage> lol #ubuntu-release 2011-05-18 <Laney> cjwatson: I got around to writing that script so it's easy to add new transitions now. We can add pages for the other transitions if you want. <cjwatson> Laney: oh, yes, please do. I'm using http://paste.ubuntu.com/609451/ and http://paste.ubuntu.com/609452/ <Laney> up now <doko> Laney: could you setup a page for libffi5/libffi6 too? <Laney> doko: yes, can you provide the is_affected/good/bad lines? <doko> and then there's libobjc2/libobjc3, but that can wait <doko> Laney: is there any docs for these? <Laney> not really i'm afraid <Laney> should be easy to figure out from the existing transitions <Laney> .field ~ /regexp/ | ... basically <doko> Laney: what does the .package mean? <Laney> doko: it means that there's a binary package matching regexp <Laney> usually you'll just want .build-depends and .depends <Laney> openssl is probably a good one to look at <cjwatson> Laney: yay, thanks <Laney> :-) <Laney> we'll probably want a separate branch for the .ben files i suppose <doko> Laney: http://paste.ubuntu.com/609501/ <Laney> ty <Laney> added, should show up at the next cron run <Laney> doko: http://orangesquash.org.uk/~laney/transitions/libffi.html does that look right? <doko> $ apt-cache rdepends libffi5|wc -l <doko> 205 <doko> strange ... <Laney> look at grep-dctrl -FBuild-Depends -sPackage libffi-dev ... <doko> interesting ... :-/ <Laney> haskell stuff seems to get a binary dep without BDing <doko> wondering if we can do with an empty b-d field <cjwatson> you could do is_affected = .depends ~ /libffi/; maybe <cjwatson> I assume is_affected is basically just a performance optimisation <cjwatson> or .build-depends ~ /libffi/ | .depends ~ /libffi/ <doko> interesting syntax <Laney> it's so you don't see a list of every source package <Laney> not sure if is_affected looks at binaries though <Laney> might as well try <cjwatson> you know your implementation language is too obscure when it's easier for *somebody who works on a functional language* to just try it and see what happens <Laney> the problem is more that I'm trying to do real work concurrently ;) <ScottK> What is this 'real work' you speak of? <ScottK> Oh. Right. Better get some of that done myself. <Laney> that seemed to help :-) <Laney> although you can ignore the haskell ones #ubuntu-release 2011-05-19 <doko> skaet, cjwatson: just reading allison's email; didn't we move the DebianImportFreeze? * ScottK thought we did. <cjwatson> I thought so too <cjwatson> Laney: could you change the ocaml-[a-z-] bits in the ocaml transition regexes to (ocaml-[a-z-]|camlp4-) please? <cjwatson> Laney: I think the current version actually does catch everything, but better safe than sorry <Laney> cjwatson: sure. If you want to commit it to the branch then I can just pull that. <cjwatson> Laney: which branch, the ~ubuntu-transition-trackers one? <cjwatson> or are you using git? <Laney> cjwatson: yeah, that's the one I'm using now <cjwatson> Laney: ok, cool - done <Laney> pulled, thanks <micahg> skaet: ping <skaet> hi micahg <micahg> hi skaet <micahg> I was wondering would it make sense to make alpha 2 after the platform rally? <micahg> or was it made the week of on purpose? <skaet> micahg, I was talking to jibel about it as well. <skaet> was planning on starting a discussion off on the subject after get off vacation next week. <micahg> skaet: ok, also, I was wondering why DIF was so early <skaet> key is going to make sure we have image build and testing over july holiday weekend. <skaet> micahg, it was brought up at UDS, and after looking at the back scroll, I see cjwatson, ScottK, and doko commenting as well. <micahg> ah, I must have missed that discussion <skaet> I'll take another pass at the schedule on Monday, and see if these two issues can get sorted. <micahg> skaet: I'm just curious why, if there's a good reason for DIF being so early, it's obviously fine <skaet> micahg, in maverick (https://wiki.ubuntu.com/MaverickReleaseSchedule ) it was between alpha 1 and alpha 2. Same story with Natty (its just that Natty had Christmas breaks, etc. in it so it seemed longer). Oneiric is following the same pattern as both of those (between Alpha1 and Alpha 2). I'll go back through the notes from UDS, and see what options might work. <cjwatson> I think raw elapsed time is more important to DIF than alignment with milestones <micahg> +1 <micahg> that's what I was noticing, natty was week 11, oneiric week 7 <cjwatson> since our milestones have very little effect on Debian development <micahg> on the other hand, maverick was week 8 <cjwatson> we stop autosyncing for a few days around milestones anyway <skaet> ok, this cycle is closer to maverick in terms of timing. If we push Alpha 2 out to July 7th, we can move DIF to week 8. We'd then have the rally week, to settle things down, before pushing out an image. <cjwatson> skaet: I don't see why it needs to be dependent on Alpha 2 at al <cjwatson> *all <skaet> cjwatson, desire to minimize the surprises the week before, and not have to ask folk to work the weekends to get things sorted. <cjwatson> it doesn't affect that <cjwatson> people just switch to filing big slews of manual sync requests instead <cjwatson> it really isn't a work-weekends kind of thing IMO <cjwatson> most of the worst surprises are internally generated :-) * skaet bows to your experience on that ;) <cjwatson> we quite happily do autosyncs around Alpha 1, for instance <cjwatson> and I know A1 is a bit more free-and-easy but it still isn't generally a problem - we just stop autosyncing for a few days to let things settle down <skaet> yeah, but expectations are a bit lower. <cjwatson> mostly just to free up build time * skaet nods <cjwatson> right, but I'm having a hard time thinking of problems caused by autosyncing for an A1 <Laney> related: could DIF for universe be later than for main? <cjwatson> Laney: I wouldn't recommend it <cjwatson> Laney: you'll get all sorts of awkward skew <Laney> I can see how it could cause problems <Laney> right <cjwatson> it's technically possible (if fiddly) - but I think I'd rather have manual sync requests for that <Laney> I just tend to think that on balance Universe benefits from having autosync rather than DIF <Laney> because fewer people are looking specifically at most of the packages <Laney> maybe that's true for main too.. <skaet> cjwatson, do you remember what the options/preference for DIF was from UDS? <cjwatson> Laney: it does, but there are enough subsystems spread across main+universe that it gets painful <cjwatson> skaet: I remember my opinion, but I can't remember whether it carried ... :-) <cjwatson> skaet: there are hopefully recordings? * skaet looking for them now... <skaet> cjwatson: when did you want to see it? <cjwatson> the other problem with having DIF too early is that nominally, before DIF is when most merges are supposed to happen (and it's good for the bulk of merges to happen in a period when we're autosyncing, for similar reasons of avoiding skew) <cjwatson> and I think seven weeks is too short a time to get most merges done in, especially if the argument is trying to reduce the amount people have to work weekends <Laney> of course, it's not possible to determine statically which syncs are going to cause problems <Laney> maybe I'm in favour of DIF=FF :-) * Laney ponders some more <micahg> Laney: sure, anything with lots of rdepends :) <Laney> micahg: heh, there are definitely some heuristics, but you're never going to be able to predict accurately <Laney> not that blanket autosyncing is without its problems <cjwatson> skaet: we went between weeks 8 and 9 for quite a few releases, and I think that generally worked out OK from the point of view of having just enough time to get merges done in <skaet> How about Alpha 2 July 7, DIF July 14, 10.04.3 July 21 ? Alpha 3 is on Aug 4, and FF is on Aug 11th. Any concerns? <cjwatson> alternatively, Alpha 2 June 30, DIF July 7, and leave the rest where it is <cjwatson> or DIF June 30, Alpha 2 July 7 <cjwatson> I'm not looking for *that* much extra time on DIF, just a couple of weeks - week 11 when we've done that was unusually late, I think <skaet> ok, <cjwatson> (and December is weird) * skaet nods <doko> DIF June 30 sounds better * micahg thought week 11 for natty was early, but it was a long cycle :) <skaet> doko, are we getting any toolchain changes around then? <cjwatson> Lucid was week 15, but that was because of a combination of it being an LTS and Squeeze being frozen, so we wanted as much time as possible to sync fixes in from Debian testing <cjwatson> aside from that week 11 was definitely later than normal <skaet> how does DIF interact with the Rally? <cjwatson> the other thing I often say about DIF is that it's much more when you *stop* doing something than many of the other dates on the calendar <cjwatson> it doesn't <skaet> do we want it before or at the end? <doko> Linaro has releases planned for Jun 16 and Jul 21 <micahg> cjwatson: the cycle was 2 weeks longer than normal though <cjwatson> it really doesn't matter IMO <cjwatson> micahg: even comparing with other 28-week cycles, it was late <cjwatson> I think, anyway <cjwatson> hm, maybe we haven't been doing 28-week cycles for long enough that I can say that * micahg thought it was the first <cjwatson> LTSes do tend to throw things off <cjwatson> you may be right <skaet> cjwatson, June 30 DIF, July 7 Alpha 2, July 21 10.04.3 , then rest the same. <micahg> based on this discussion, june 30 seems just right :) <cjwatson> (also, I expect the dynamics around DIF to change in the future, since people will be able to do syncs themselves in the near future rather than having to go through archive admins) <cjwatson> that's OK with me - that puts DIF at the end of the rally, right? <cjwatson> if anything that's probably better, it means we don't need to spend quite as much time processing manual sync requests through the rally <skaet> ok, lets see if anyone can spot flaws over next couple of days, and if not will send out email early next week, and adjust the schedule appropriately. #ubuntu-release 2011-05-20 <cjwatson> Laney: the data in http://orangesquash.org.uk/~laney/transitions/ocaml.html seems oddly out of date - for instance coq built everywhere hours ago <cjwatson> Laney: ah, never mind, sounds like there were publisher issues overnight <pitti> cjwatson: see #is topic -- mirroring has been broken for the last 12 hours, but ETA was said to be in 15 mins now <cjwatson> yeah, I caught up <Laney> looks like my transition tracking machine at home has packed up, sorry <Laney> will kick it tonight <Laney> oh wait, er, it's inexplicably back alive <ogra_> is there a release team meeting today ? <skaet> ogra, no release team meeting today. They'll resume next week. <ogra_> awesome ! * ogra_ will go to mow the lawn then :) <skaet> :) * charlie-tca going to put down the weed killer while it is calm outside <highvoltage> hmm, I wonder if I joined the ubuntu-release list yet... <highvoltage> skaet: ah I see it still needs the description too * skaet adds to list of things to look into on monday... #ubuntu-release 2011-05-21 <cjwatson> Laney: please pull the transition-tracker branch <Laney> cjwatson: righto <cjwatson> ta <Laney> looks easy ;-) <cjwatson> yeah <cjwatson> I may be turning into a slight NBS obsessive <Laney> there are worse things to be obsessed with than archive health <Laney> currently i'm obsessed with f5ing nm.d.o <cjwatson> meant to be RSN, eh? * cjwatson remembers that phase ... <cjwatson> (actually, *that* bit was short in my case, it was the two AMs who vanished on me that slowed things down) <cjwatson> the DAM approval stage was 10 hours or so ;-) <Laney> it's "how soon can you get enrico involved" <cjwatson> it was tbm in my day <cjwatson> https://johncrosby@example.net * cjwatson tries to work out why dvbstreamer is missing its shlibdeps <cjwatson> ... also missing its binaries, well that explains that part ... <Laney> your tin anniversary has passed :-) <Laney> alioth being down is irritating, maybe i'll join the nbs-fest <cjwatson> heh, yeah * cjwatson fixes dvbstreamer <cjwatson> poked the Debian bug for multiwatch to see if I can help with sponsorship <cjwatson> and uploaded everything else for libev <cjwatson> ocaml is done aside from the llvms #ubuntu-release 2011-05-22 <cjwatson> doko: you seem to have synced python-reportlab and tokyocabinet, but forgotten to flush them? <cjwatson> doko_: I tried to move your python-reportlab and tokyocabinet syncs aside while I did an autosync run, but flush-syncs doesn't work quite the way I remembered so I accidentally flushed them. I hope that's OK. <cjwatson> (They won't have got
{'channel': 'ubuntu-release', 'month': 5}