#ubuntu-release 2010-07-01 <ScottK> http://cdimage.ubuntu.com/kubuntu/ports/daily-live/current/ still has Lucid images too. <cjwatson> fixed for next sync <cjwatson> must fix that cdimage publication bug some day <cjwatson> kubuntu-netbook and xubuntu on tracker <cjwatson> mythbuntu should be done within half an hour or so, but I'm not going to wait up for it <cjwatson> also, have queued up Ubuntu, Kubuntu, and Edubuntu DVD builds <cjwatson> though I don't think alpha-2 should block on those getting tested <GrueMaster> cjwatson: while you are updating iso.qa, could you kindly bump Ubuntu Arm Daily Preinstalled to 20100630.6? Thanks. <cjwatson> GrueMaster: done <GrueMaster> thanks. <GrueMaster> cjwatson: (or someone with admin access to iso.qa). I am unable to add more bugs beyond the default 3 fields in http://iso.qa.ubuntu.com/qatracker/result/4290/695 <Riddelll> I'm afraid I'm travelling to akademy today so won't be able to test CDs, I've asked for volunteers so hopefully it'll happen <pitti> Good morning <pitti> cjwatson: Didier mentioned that he expected netbook to be heavily oversized <pitti> cjwatson: it's actually not that bad any more with the recent package fixes, but we thought it'd be okay for alpha-2, since most folks are installing netbooks from USB sticks anyway (no CD drive) <ttx> Good morning <pitti> bonjour ttx <ttx> pitti: amd64 server is oversized <pitti> ttx: did that change over night? <ttx> the last respin made it pass the limit, yes <pitti> I have a script to compare two images <ttx> pitti: could you have a look ? <pitti> sure <pitti> so, 30.1 was 694 MB, 30.2 is 701 <ttx> which sounds like a good inflation for just a build1 <pitti> le huh <pitti> ttx: http://paste.ubuntu.com/457691/ <ttx> beeeh <pitti> seems this suddendly started pulling in half the desktop <pitti> please note that those are just differences > 200 kB <pitti> sorry, no <pitti> added packages are complete <pitti> changed packages are just > 200 kB <pitti> ttx: I blame yesterday's hplip <pitti> do you ship that? <ttx> yes <pitti> it changed things quite heavily * ttx grumbles <pitti> there's obviously some dependency problem here <ttx> we should just blacklist it * ttx looks <pitti> ttx: I think it might be the new python-notify dependency <pitti> ttx: would you mind filing a hplip bug about that, milestone it, and assign to tkamppeter? <ttx> I can do that. Though I always wondered why hplip was in server-ship in the first place <pitti> you ship cups, and HP printers are rather popular <pitti> but it should just ship the drivers, the desktopy bits should be separate <ttx> do we need a quick workaround ? Or is tkamppeter around to fix it ? <pitti> not sure whether he's awake yet <pitti> ttx: so you could unseed hplip, or we just declare it a known bug and leave it oversized <pitti> if you guys can test a respin again, I'm happy to respin, but it'd need to happen rather quickly <ttx> how much time do we have to test ? <pitti> this afternoon? <pitti> we can prepare the notes in the meantime and finish testing the other images <pitti> but we need some time to publish all the images and the announcement, etc. <ttx> well, it's not as if so much testing was done overnight <ttx> we're at 0/17 on amd64 <ttx> 6/17 on i386 <pitti> ttx: is there something in ship which we could drop? <ttx> you mean, besides hplip ? :) <pitti> i. e. that wouldn't require two publisher runs? <pitti> ttx: like, we could drop postgresql-doc for alpha-2 <pitti> which should bring us below 700 <pitti> oh, hmm <pitti> ttx: hplip is in the print-server task, and updating tasks takes two publisher <pitti> hm, so is postgresql-doc <pitti> why are all those duplicated? <ttx> is postgresql-doc usually a recommends ? <pitti> postgresql-doc is in the postgresql-server tasks, we can't easily drop it either <pitti> i. e. not more cheaply than hplip <ttx> the seed probably dates from a time when recommends were not installed by default <pitti> I mean why is server-ship so crowded? <pitti> it seems to duplicate everything in all the tasks <pitti> which makes it hard to see which bits are _only_ in ship, i. e. not installed by any task <ttx> looks like the duplication has been there for quite some time <ttx> pitti: how much do we need to free ? <ttx> there is a hplip -> sane-utils recommends but not sure that brings up enough <pitti> ttx: if we do an upload, we can just as well drop the python-notify dependency <pitti> which is a "more correct" thing to do <ttx> pitti: I was thinking about blacklisting sane-utils to avoid it on the CD without changing packages -- but I don't know if that's possible <pitti> ttx: some 1.5 MB, I think (how much to free) <pitti> ttx: no, I don't think it is <pitti> ttx: are you fine with a hplip upload and a respin? <pitti> I can do the upload <pitti> but would be nice if you could file the bug <ttx> yes, if we have until 1500 UTC for ISO test coverage <ttx> i'm filing the bug right now <pitti> gets tight, but should be doable * pitti prepares hplip <ttx> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/600504 <ubot4> Launchpad bug 600504 in cups (Ubuntu) "Dependency on python-notify makes hplip unsuitable for servers (affects: 1) (heat: 6)" [Undecided,New] <ttx> assigning to tkampetter and targeting to a3 <ttx> or to you on a2 ? <pitti> tkamppeter/a3 is fine <pitti> hplip uploaded <pitti> I'll watch the build, and stall the publisher a bit if needed <pitti> takes 12 mins to build, should make it <pitti> oh argh <pitti> amd64 builds linux and kdeedu <pitti> but kdeedu is purging already * ttx wtaches the snail race <pitti> kdeedu done now; c'mon crested, grab it <pitti> there; should just about make it :) * ttx cheers <ttx> you might have to stall the publisher a couple minutes <pitti> ttx: hm, I could rebuild amd64 only, and keep i386 with the desktopy bits <pitti> ttx: do you want a clean i386 respin as well? or keep the current one? <ttx> hm, that's tricky <ttx> on one hand I'd like to keep the already-performed tests <ttx> on the other I'd like to have minimal difference between amd64 and i386 <ttx> is there a precedent for such arch-oriented respins ? <pitti> we did that in the past, I think <ttx> I prefer we do both -- I can make ISO testing happen by 1500 UTC <pitti> sounds like a plan <pitti> ttx: also, I guess you don't need to re-test each and every task <ttx> hoping that last respin doesn't bring its own set of surprises <pitti> some on i386, some on amd64 shoudl be enough for alpha-2 <pitti> especially not tasks which we didn't change since yesterday and which were arleady tested * ttx prepares a large softfreeze-respect-stick just in case <pitti> hehe, please do :) <ttx> hah, that's my first "Orthopedic Dog Beds" spam * ttx wonders about the success rate of that one. <pitti> c'mon, purge faster <pitti> publisher on manual <pitti> there we go, publisher running, and back on auto <pitti> this also caught the new kernel build, I hope that will go well <cjwatson> fyi I won't be in action until a few hours from now - I start late on Thu due to baby sign language class <pitti> cjwatson: I think I can handle it; see you later then <ara> morning all * ara resyncs <pitti> I did a desktop and a netbook install, and they work fine now \o/ <cjwatson> good, I'd done the install but couldn't wait up for it to reboot <ara> you guys are talking about the ones that are posted? <pitti> yes <pitti> ttx: I set up a trigger to rebuild server ISOs as soon as the new hplip lands on the cdimage mirror <pitti> back in 45 mins <ttx> pitti: ok thanks <ttx> ara: we should have new 20100701 server ISOs in a few, will need your help in promoting them to the tracker <ara> ttx, sure, I'll be around :) <ara> ttx, do you happen to know if kubuntu is going to be rebuilt? <ttx> ara: I don't know <cjwatson> rebuilt for anything in particular? <ara> cjwatson, no, I was just wondering about the build number being lower than ubuntu and xubuntu desktop <cjwatson> .1 rather than .2? <cjwatson> that just means that there were fewer builds of kubuntu yesterday <ara> I know, I just wanted to double check ;-) <cjwatson> I respun everything containing ubiquity in sequence last night <pitti> mythbuntu posted as well now, FTR <ttx> pitti: server ISO still pending ? <cjwatson> DVDs should I think be ready too <cjwatson> haven't checked the tracker <pitti> ttx: yes, I'm watching them <pitti> cjwatson: will do <pitti> DVDs added to tracker <pitti> ttx: hm, not sure what's wrong -- but it seems that the publisher run somehow failed to publish it; the publisher finished minutes ago, but cocoplum still didn't update <pitti> ttx: I'll continue to watch it, but might take a bit longer <ttx> arh <pitti> cjwatson: I'll rebuild ports, unless you are already? <cjwatson> pitti: not doing so <ara> mmm, Kubuntu Desktop looks like Kubuntu Netbook * ttx gets some coffee <ttx> pitti: by "also caught the new kernel build" you mean the new i386 kernel that was just built ? <ara> I guess I'll wait for Riddell <pitti> ttx: yes <ttx> pitti: that might make a case for a amd64-only rebuild <ttx> at least they woud get the same kernel source <ttx> s/rebuild/respin <pitti> hplip was published in this publisher run <pitti> very weird * ttx wonders if keeping the old i386 spin would not actually end up being closer to the new amd64 one <pitti> ttx: the change in 6.9 was very small; do you have reason to believe that it's bad in any way? <pitti> ttx: if you don't mind having all the desktop bits on i386, we could respin amd64 only, yes <ttx> pitti: 6.9 actually fixes UEC <pitti> ttx: so why wouldn't we want to pick that up? <ttx> pitti: so we would have a fixed i386 and a broken amd64 <ttx> (UEC) <ttx> pitti: ok, let's keep the original plan <pitti> ttx: we can also wait another hour when the amd64 one is done (it's in the debhelper stage) <ttx> ah! don't tempt me <ttx> pitti: what would be the difference in ETA ? 15 vs. 75 min ? <pitti> ttx: 40 vs. 100 min <ttx> hm, I don't think we can afford that. <ttx> I can use that hour for smoketesting and making sure they are good <ttx> pitti: let's go for 40 <pitti> ttx: ack <ttx> (I'll document the need to dist-upgrade, on amd64 only <pitti> ttx: folks who install can upgrade to get the fixed kernel <ttx> ) <pitti> ttx: cheers; you'll put it into "known issues" on the tech notes? <ttx> yes <pitti> merci <ttx> pitti: if you have the URL of the maverick tech notes handy <pitti> ttx: https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview <ttx> I'll do it now <ttx> thx <pitti> ttx: cheers; please let me know when you are done, then I'll brush up the "what's new" bits for desktop <pitti> ttx: btw, if you have anything worth mentioning for server, please add it <ttx> ok <ttx> pitti: done with the techoverview <ttx> pitti: will think about what I can add for server without keeping the lock <pitti> cheers <pitti> ttx: I'm done with the first round, if you want to add stuff <ttx> ok, ack <ttx> done <ara> ScottK, around? <ttx> pitti: we are past your ETA, any new trouble ? <ttx> (if yes, let's just stick with the oversized ISO, we are lacking time now) <pitti> ttx: image is currently building <pitti> it took until 3 minutes ago until the new hplip found its way to the cdimage mirror <ttx> new ETA ~ 15 min ? <pitti> more like 5 <pitti> "a watched archive never publishes" or so <ttx> ok, let's live with that :) <pitti> image build done; now mirroring to cdimage <pitti> ttx: http://cdimage.ubuntu.com/ubuntu-server/daily/20100701/ <pitti> will hit in a minute or two <pitti> maverick-server-amd64.iso 01-Jul-2010 10:03 694M <pitti> yippie <pitti> ttx: go wild :) <ttx> ara: please promote to ISO tracker <pitti> added to tracker <pitti> ara: too late, I just did <ttx> yay <ara> pitti, thanks :D * ttx warms up his three test laptops * pitti sees ttx jumping around with six hands, controlling three laptops at once <ara> if I had more HW, ya ha deedle deedle, bubba bubba deedle deedle dum <pitti> kvm FTW? <ttx> pitti: parellizing 6 installs on KVm tends to be slow <pitti> erm, yes; I never do more than two <ara> for me, running just 1 kvm makes my laptop almost useless for the rest of my daily tasks <ara> sometimes I can't even read email <pitti> erm, yes; I never do more than two <pitti> sorry, -EFOCUS <sbeattie> Is there a known issue about compcache's ramzswap kernel module failing to laod when booting the live cds? <cjwatson> known in the sense that I'd noticed it, although I hadn't reported it anywhere <cjwatson> it wasn't something I could fix straight away when I saw it, because the kernel interface changed - so best report and milestone (alpha-3) a bug about it <cjwatson> file it on initramfs-tools and assign to me, please? <sbeattie> ah, looking at dmesg, it's comlaining about an unknown parameter "disksize_kb" <sbeattie> okay, will file. <cjwatson> right, what can I most usefully do now? <cjwatson> aha, I can test the i386 DVD, nobody's doing that * cjwatson tests btrfs via ubiquity while waiting <pitti> https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview should be reasonably up to date now wrt. features, known issues, and general "alpha 2"ness <ScottK> ara: Just passing through right now. I should be around in a couple of hours. <cjwatson> ubuntustudio tasks should be fixed; I'll check and remove <cjwatson> poo, btrfs doesn't work in the desktop image <cjwatson> no mkfs.btrfs <ttx> we might want to add bug 599450 in there <ubot4> Launchpad bug 599450 in linux (Ubuntu) "[apparmor] getattr handled incorrectly in 2.6.35-6.7 (affects: 2) (dups: 1) (heat: 18)" [High,New] https://launchpad.net/bugs/599450 <ttx> used to break the LAMP task, I'm in the process of reproducing with latest ISO <pitti> cjwatson: so we need to seed it, and then teach oem-config and ubiquity to remove it (unless used)? <cjwatson> no teaching required, it could just be handled the same way as all the other filesystems <cjwatson> I'll file a bug <pitti> just trying to understand what's necessary <cjwatson> we'll need to relnote it for maverick <pitti> I'll add it; I'll drop a stanza about that apparmor bug anyway <cjwatson> one-liner in platform.maverick/live-common <cjwatson> I'll take care of it <pitti> ttx: this looks like it'd break cups in desktop as well <ttx> pitti: sounds worthy of a TechnicalOverview note, then <pitti> ttx: I'm adding it <ttx> it's breaking mysql, according to zul -- I'm in the process of reproducing <pitti> ttx: done (also mentioned MySQL); proofreading appreciated <ttx> looking <ttx> looks good <ara> I get broken packages in kubuntu alternate i386 <ara> mmm, wrong iso <ara> *sigh* <ara> ok, the last build of kubuntu is not the candidate one <cjwatson> hmm? <cjwatson> 20100630 and 20100630.1 both have some broken packages <cjwatson> I thought we'd dealt with that; did we just forget to respin? <cjwatson> bah. I'm going to respin kubuntu alt now <doko> cjwatson, pitti: could you have a look at bug #600272 ? needed for the openjdk-6 uploads, needed for the firefox updates <ubot4> Launchpad bug 600272 in ant (Ubuntu Karmic) (and 3 other projects) "ant fix to correctly build JAX-WS (affects: 1) (heat: 10)" [High,In progress] https://launchpad.net/bugs/600272 <cjwatson> ok <cjwatson> doko: done <pitti> cjwatson: I just went through the iso-testing bugs again, and the relevant ones are now documented in the tech notes <pitti> cjwatson: it seems most images are ok, except for the untested kubuntu alternates and DVDs <pitti> cjwatson: want me to start preparing the publishing? <ScottK> ara: I'm around now. I imagine from the scrollback your question got answered? <pitti> (i. e. set it up, but not sync mirrors yet) <ara> ScottK, well, it didn't, I didn't know who else to ask <ScottK> ara: OK. Go ahead then. <ara> ScottK, in Desktop Live i386 Kubuntu, the live session shows as if it was the Netbook edition <ara> is that expected? <ScottK> ara: For small screens, yes. We are trying to combine desktop and netbook into one image and do first run based on screen size. <ara> ScottK, and once installed? <ScottK> Once installed, there's an option in systemsettings to pick which you prefer. <ScottK> Live/first run installed should be the same. <ara> ScottK, ok, then why there are still two images in the tracker? <ScottK> ara: Because we didn't finish the consolidation yet. I expect for Alpha 3 there won't be. <ara> ScottK, OK, thanks for the explanation <ScottK> You're welcome. <cjwatson> pitti: yes please, I have a presentation followed by an interview, which makes it hard :-/ <pitti> ack <pitti> cjwatson: for the record, I a-x'ed sync-mirrors <cjwatson> thanks <pitti> ttx, smoser: can you please publish the alpha-2 UEC images? (https://wiki.ubuntu.com/UEC/Images/Publishing) <smoser> pitti, yeah. will-do. <pitti> smoser: cheers <pitti> ara: do you know if someone is testing kubuntu alternates, in particular the amd64 one? <pitti> cjwatson: hm, do you know whether we usually publish-release DVDs? <pitti> (we didn't for alpha-1) <cjwatson> if they work <pitti> cjwatson: ok, thanks <ara> pitti, not that Im aware of, I will resync now and give it a try in VM <ara> pitti, I cannot access the iso tracker at this moment, can you? <pitti> no, indeed it's timing out for me as well <ara> *sigh* <seb128> launchpad doesn't respond either there <pitti> jeesh, the interweb is broken <pitti> ara: does rsync for you from cdimage? <smoser> pitti, uec images are public and amazon's ami pages have been updated. http://uec-images.ubuntu.com/releases/maverick/alpha-2/ <pitti> it seems everythin http-ish might be down, but e. g. ssh works just fine forme <pitti> smoser: nice, thanks <ara> pitti, no, I was syncing kubuntu amd64 alternate, and now it is stalled <pitti> oh, seems to be back? <pitti> works again for me <pitti> just joined the IS channel, they are on it <lamont> oh hai <pitti> ah, thanks to whoever tested kubuntu alternate <pitti> hey lamont <lamont> I have no idea which or how many builds failed from that... reenabling the farm now <pitti> ok, done with preparing the image publishing <pitti> I'm waiting for kubuntu alternate amd64 confirmation <pitti> bladernr_: hello! how is your kubuntu amd64 install? any problems with it? <bladernr_> yeah <bladernr_> fails at select and install software <bladernr_> also, in VirtualBox at least, if I go from tty1 to tty2 to run a shell command, then go back to tty1, the installer screen doesn't redraw completely, so I get a bunch of vertical lines <cjwatson> I see that in kvm from time to time; switching to tty2 and tty1 again usually clears it <cjwatson> it's not an installer bug as such, must be a bug in either bogl-bterm or the kernel <cjwatson> bladernr_: can I see the installer syslog please? <pitti> bladernr_: uh, that's still with the 20100701 image? i386 was reported to work <bladernr_> pitti: actually, I have no idea... it is whatever was up as of yesterday, was this one of the respins? <cjwatson> oh, yes, yesterday's had broken packages <pitti> bladernr_: yes, it was respun today <cjwatson> that's why we respun <bladernr_> ahhh... then disregard my angst... it took me 14 hours to rsync the images yesterday so and I just heard of respins, but wasnt sure which ones were done <bladernr_> thanks, I'll resync that and try again <pitti> cjwatson: any other blocker from your side? I have the wiki page and email announcement prepared, images publish-release'd on antimony, and newz2000 standing by <pitti> (just to re-sync on where we are) <pitti> cjwatson: syncing mirrors now, since that'll take a while; in the unlikely case that kubuntu amd64 alternate is botched, re-syncing will be faster <cjwatson> pitti: the baton is yours unless you desperately need it to be mine - I've been on the phone most of the afternoon <pitti> cjwatson: ack <pitti> cjwatson: that's fine, I have nothing particular on the evening (except an hour phone call), I'll be around for another 5 h at least <Riddell> I am downloading maverick-alternate-amd64.iso if it still needs tested but it says it won't be done for 40 minutes <pitti> Riddell: thanks <Riddell> pitti: we're not doing dvds I take it? <pitti> Riddell: if anyone tests them, we can publish them <pitti> but I guess they aren't that interesting/important for a2, what do you think? <Riddell> mm, at these download speeds that may not work for me <Riddell> it's interesting only to know that it won't be a sudden headache for alpha 3 or beta <ara> Riddell, I will start an amd64 test in 5 min <Riddell> great <bladernr_> pitti: synced kubuntu alternate amd64 and redid, and still dies at "select and install software" <bladernr_> trying one more time just to be sure... <pitti> bladernr_: can you please rescue /var/log/syslog? <pitti> bladernr_: on the iso there is a .disk/info which would have the timestamp <bladernr_> pitti: working on that, I'll let you know when I've got it. FWIW, this is a VBox VM, not bare metal (my work laptop is my only bare metal 64bit machine) <pitti> that's fine <pitti> bladernr_: on 20100630.1 it was still broken: http://cdimage.ubuntu.com/kubuntu/daily/20100630.1/report.html <pitti> bladernr_: but on 20100701 it should work (http://cdimage.ubuntu.com/kubuntu/daily/20100701/report.html) <bladernr_> Kubuntu 10.10 "Maverick Meerkat" - Alpha amd64 (20100701) <pitti> that looks right <pitti> bladernr_: if you could switch to a terminal and check /var/log/syslog what it's failing on, that'd be great <bladernr_> pitti: oddly enough, this second run on that iso seems to be working :/ perhaps the first try (which was a vbox soft reset) cached the bad iso, while a power-down and restart re-read the data? <bladernr_> but so far it is doing the software install... so far so good, at least... <pitti> bladernr_: ah, thanks; seems we got two amd64 kubuntu testers now \o/ <pitti> so, time to continue then, I guess <bladernr_> pitti: I could have sworn that I posted the result here... anyway, worked fine on the second try. Installation successful with one UI issue that I filed a bug for (600716) <pitti> bladernr_: much appreciated, thanks for testing! <bladernr_> moving on to the rest of the kubuntu alt 64 tests <pitti> announcement sent -- folks, it's officially out <pitti> thanks to all for helping with testing, bug triaging, fixing, and release engineering! <cjwatson> fantastic, thank you so much <cjwatson> I was expecting to have to do more of that than I in fact did, so sorry about that ... <cjwatson> roll on having a dedicated RM again. :) <pitti> cjwatson: don't worry, it was good teamwork <pitti> cjwatson: thanks for another nice milestone release <ttx> pitti, cjwatson: thanks for your help ! #ubuntu-release 2010-07-05 <lamont> how much pleading do I need to do to have bind9 synced from debian? <cjwatson> lamont: no pleading, just use requestsync <lamont> ta <lamont> mailserver_host = os.getenv('UBUSMTP') or os.getenv('DEBSMTP') or 'fiordland.ubuntu.com' <lamont> that makes me cry <lamont> because apparently looking up the MX host is hard? <ScottK> lamont: Patches welcom. <ScottK> ...e. <elmo> ScottK: or, you know, we could just drop fiordland.ubuntu.com from DNS ;-P <ScottK> That would work too. Since I've got severl local MTAs availalbe, it's not a real question for me. <lamont> ScottK: who is the recipient on the email? <lamont> because there's no reason it couldn't just look up the MX list and use it... <ScottK> Agreed. #ubuntu-release 2010-07-08 <ScottK> cjwatson or slangasek: Would one of you please arrange to kill the kubuntu-netbook ISO build on i386 and to switch the armel kubuntu-netbook build to kubuntu (desktop)? It seems we've successfully combined the images into one now. <cjwatson> ScottK: which armel subarchitecture(s)? <cjwatson> ScottK: and should it be "preinstalled" rather than "live", as ubuntu-netbook now is? <ScottK> cjwatson: Whichever ones are being built. I didn't follow all the Maverick changes on sub-archs. <ScottK> cjwatson: I've no idea on preinstalled. <ScottK> "Like ubuntu-netbook" sounds reasonable though. <cjwatson> mkay, I'll just make them match up <ScottK> Thanks. <ScottK> Are there ISO tracker changes needed or is it automagic based on what images get built? <cjwatson> I think the tracker will need to be changed, but I don't know how to do that <cjwatson> stgraber: ^- ? <ScottK> Thanks. <cjwatson> cdimage change made and deployed <cjwatson> I may need to clean up some stale images at some point <ScottK> cjwatson: Thanks. That should ease testing next time around. <slangasek> more massaging may be needed to get a preinstalled kubuntu-netbook image to build correctly on armel <cjwatson> yeah, I'm not sure about that, ogra would probably know better? * slangasek nods * ScottK is all ears. <ScottK> KDE is currently broken on armel anyway, so it's not urgent. * ScottK gives NCommander a kick in the shins. <NCommander> what the heck did I do this week :-P * NCommander already got dumped in a lake by Riddell <NCommander> cjwatson: it should "just work", just add the crontables to build the kubuntu-netbook image with -f ext2, and then use cron.port-dailys_preinstalled <cjwatson> that's what I did except -f ext3 to match ubuntu-netbook <ScottK> cjwatson: Except we want desktop, not netbook for Kubuntu. <NCommander> ScottK: same thing in pratice <ScottK> that's the goal. <cjwatson> uh, I missed that bit <cjwatson> so you want armel omap/omap4 preinstalled kubuntu-desktop? <ScottK> cjwatson: Yes. We're doing away with the netbook image entirely. Netbook/Desktop will get autoselected at first run based on screen size. <cjwatson> mkay, done <ScottK> cjwatson: Thanks. <ScottK> lamont: Of course, just a few hours after I hit retry, there was another upload of qt4-x11, so it might make sense to shoot https://launchpad.net/ubuntu/+source/qt4-x11/4:4.7.0~beta1+git20100706-0ubuntu1/+build/1856835 in the head to make room for something more useful. <lamont> ScottK: which builder, if you know? <lamont> meh. /me looks <ScottK> lamont: cushaw <lamont> smacked <ScottK> Thanks. <ogra> i think kubuntu-netbook shoudl just work as preinstalled image, you just need to copy the crontab line ... the prob is that one single build takes 2.5h <ScottK> ogra: Won't take that long now since it will fail. <ogra> well, then we should wait until NCommander is done with fixing kde :) <ogra> i'll tell him to ping me for a testbuild once its ready, if that succeeds i'll add a cron entry <ScottK> NCommander: That'll be done tomorrow, right? <ScottK> ;-) <ogra> lol <ogra> i'm in a call with him in 10 min, i'll ask him <ScottK> It's already a great relief that qt4-x11 died on armel because lamont killed it and he doesn't have to fix that too. #ubuntu-release 2010-07-09 <NCommander> ScottK: I know why bindings are broken, I just am not sure how to proper fix <mvo> slangasek: thanks a bunch for the aptitude merge! <mvo> slangasek: it appears you prepared the upload in bzr but did not upload just yet, correct? is it because of the missing google-mock? or is there another reason? <slangasek> mvo: I'm still preparing it, google-mock is the last outstanding issue, yes <slangasek> mvo: should be finished today and uploaded <mvo> slangasek: many thanks. I did request a sync for gtest so google-mock should build now <slangasek> but it's still in universe; do you plan to MIR? <slangasek> I was going to ignore that for right now in order to get it built <mvo> google-mock has build on i386 already, nice <mvo> I can do the MIRs early next week, that should be trivial as its just the testing stuff (gtest and google-mock AFAICS) <slangasek> mvo: aptitude uploaded; happy to revert the latest google-mock-disabling change once the MIR is approved <mvo> slangasek: sweet, thanks #ubuntu-release 2010-07-11 <stgraber> ScottK, cjwatson: I would need to check if I now have access to the new host of the iso tracker. I've been requesting access for a while now but with no news so far. <stgraber> elmo, lamont: Where is the ISO tracker now ? I just looked on quandong and the DB seems to be the one we had two days before Lucid's release so I'm guessing it's not back on that box yet. #ubuntu-release 2010-07-14 <ogra> argh <ogra> who enabled kubuntu omap3 and 4 builds <ogra> Riddell, ^^^ do you know who that was ? <ogra> cjwatson, seems that was you <ogra> that wont work <ogra> a netbook build takes 3h per subarch <Riddell> I imaging he did it because kubuntu netbook has been merged into kubuntu normal <ogra> we build two subarches fo ubuntu-netbook, that runs 6h already <ogra> we cant build other flavours unless lamont adds the second livefs builder with these build times <lamont> ogra: second builder for arm? you have acorn and sycamore... <ogra> lamont, i didnt know about sycamore and i dont think anyone enabled it in debian-cd <ogra> i always thought acorn was the only one <lamont> it got added a while back, since acorn was struggling <ogra> oh, ok <ogra> i'll check how we can spread the builds on a per subarch base <lamont> and I thought someone (slangasek?) caused it to be used at least sometimes... <ogra> hmm <cjwatson> ogra: please agree with ScottK what to do, and make the necessary changes yourself; I don't want to be involved <ogra> cjwatson, no prob, i was only trying to find out who enabled it <cjwatson> especially if it involves going back and forward between you with multi-hour delays <ogra> (and i had asked ScottK to talk to me first) <cjwatson> I think ScottK asked for that, but I wasn't very clear on the details <lamont> I take that back.. sycamore has one livecd build on it.. lucid/ubuntu from 20100621, which I'm guessing was me verifying it <ogra> lamont, yeah <ScottK> ogra: All I asked for was to get the Kubuntu netbook ISO swapped out for the desktop one since we are discontinuing the netbook ISO. <lamont> ogra: so triggering a smallish build on sycamore to confirm cocoplum loves it would not be amiss <ogra> http://paste.ubuntu.com/463485/ thats what buildlive has atm <ogra> i'll spread omap3 and 4 across the two machines <ScottK> ogra: If it's premature to have it activated, please turn it off for now. <ogra> ScottK, well, lets see if we can all be happy :) <ScottK> ogra: There are some armel porting issues unresolved in Qt/KDE right now, so it's not an immediate priority. <ScottK> ogra: We do need the armel images at some point. <ogra> i'm inclined to drop genext2fs for a loop mounted ext3 image in livecd-rootfs <ogra> that should shove off 1h or so per build <ScottK> I'm happy to let you drive the technical details. <ogra> yes, i'm just thinking aloud :) <lamont> ogra: I have some livecd tasks from UDS, would be happy to review patches to speed my life along <ogra> ScottK, dont worry, i havent forgotten you and will do my best to also get kubuntu builds <ogra> that we have to re-enable dove now wont make it easier though <ScottK> ogra: We do need them this cycle, just not necessarily right now. <ogra> ScottK, right, what arches do you plan to support btw ? i guess only stuff thats actually buyable ? <ogra> i.e. beagleboard, possibly pandaboard (will likely come out around maverick time) <ScottK> ogra: Not necessarily. We have interest from people that have pre-production hardware. <ogra> hrm, k <ogra> then we cant build cmdline images for devs on such HW <ogra> which was greatly requested, but i wont do it if we are short on buildd power <ScottK> So far we've always built Kubuntu for the same arches we've built Ubuntu for and I'd expect that should continue. <ogra> ScottK, i understand that, but with the switch to preinstalled images the build times have raised massively <ogra> adding another flavour is a real issue with 3h per image/subarch <ScottK> ogra: We aren't discussing adding anything. You're discussing removing something. <ogra> i would really prefer to only build images for HW that has a userbase <ScottK> All I asked for was a one for one swap. <ogra> we removed *all* flavours in maverick due to that restriction <ogra> and i'd really perfer if we could make some selection based on possible userbase <ScottK> Sure. I speaking in comparison to Lucid. <ogra> lucid didnt have preinstalled images <ScottK> True. <ogra> each of these eats 1.4g on the main builder per flavour and subarch atm... i dont want to make elmo cry more than he has to anyway :) <ScottK> ogra: I think if there was a possibility that Kubuntu couldn't be supported, it should have come up less than half way through the development cycle. <cjwatson> shouldn't some of the build time work items assigned to lamont apply to arm too? <ogra> i'll look into dropping genext2fs and see how much that gains us <ogra> but effectively i dont really see a reason for producing a ton of flavours for boards of which max 10 exist in the world <ogra> and on which developers wont even run the desktop sessions <ScottK> ogra: As long as you were building Kubuntu and Ubuntu for the same sub arches, then I didn't need to have an opinion on which ones might be important. Now you're asking me to have one and I've no time to deal with it. All I'm asking is that the level of support not regress. <ScottK> If it doesn't make sense for Kubuntu on those terms, it probably doesn't make sense for UNE either. Just build the server image. <ogra> we cant build preinstalled server images <ogra> (yet) <lamont> cjwatson: in the current world, arm is the predominant recipient of any benefit from build process speedup <ogra> lamont, sycamore misses the pubkey it seems <ogra> sycamore.buildd starting at Wed Jul 14 13:49:57 BST 2010 <ogra> Permission denied (publickey). <ogra> sycamore.buildd finished at Wed Jul 14 13:49:57 BST 2010 (failed) <lamont> ogra: meh. fixing <ogra> tell me when i can try again :) <ogra> i'm shoving all omap4 over to it and leave omap3 and dove on acorn <lamont> try now? <-- ogra <ogra> (dove wont be preinstalled so wont take much extra time) <ogra> lamont, looks fine <ogra> thanks <lamont> \o/ <slangasek> lamont: hrm - you told me I would get a second builder, but I'm not sure you gave me the name - if you did, I failed to follow through, sorry <lamont> slangasek: well, it didn't work until I fixed the key this morning, either... so yeah... now you have 2 <ogra> slangasek, i pushed omap and dove builds to acorn and omap4 to the new one for now <slangasek> sounds fine to me <ogra> dove will just be the old livefs builds so wont take as much processing power as the preinstalled images <lamont> slangasek: now that pkgbinarymangler has a proper test suite (in rev 70), I'm going to unhold it in the lucid and maverick chroots <slangasek> lamont: ok, cheers :) <lamont> and, assuming they build ok, pushing out new lucid and maverick chroots now <lamont> well, sometime today <lamont> new tarballs uploading now (lucid, maverick). just fyi #ubuntu-release 2010-07-15 <ogra> lamont, once livecd-rootfs 1.132 has built, can you please make acorn and sycamore make use BuildLiveCD from that version (or pull revision 363 from the branch) <ogra> so we get the logs mailed on build failures again #ubuntu-release 2010-07-16 <Daviey> Hi, what is the problem with the current daily maverick server ISO? The last 3 rolls have failed, and the report looks "odd". <Daviey> It seems odd that there are so many "produces uninstallable binaries".. <cjwatson> well, yesterday's failure was kernel versioning <cjwatson> forget about the report, use the build log <cjwatson> debian-installer has kernel ABI 2.6.35-7-generic, but no corresponding udebs are on the CD! <cjwatson> hmm, this is odd, I revved d-i <cjwatson> and the cdimage mirror has the up-to-date version <Daviey> hmm <cjwatson> ah, for amd64 it just didn't build until after today's server build run <Daviey> Ah.. so it should be resolved for tommorrow? <cjwatson> i386 has some different problem * Daviey only cares about amd64 atm tbh :) <cjwatson> tar: ./usr/lib/syslinux/isolinux.bin: Not found in archive <cjwatson> so breakage from the new syslinux <Daviey> lovely. <cjwatson> ah, needs to look at syslinux-common rather than syslinux <Daviey> That will also happen with amd64? <cjwatson> yes <cjwatson> fixed, rerunning build <Daviey> rockin' <Daviey> Thanks for the fast turnaround on that cjwatson, i expected to have to wait until tommorrow! <cjwatson> no problem. that appears to have built * cjwatson jigdos to check it works <cjwatson> seems to boot fine <doko> ubuntu-archive: please sync mpfr4 from unstable (to main), bug 605657, so that the next gcc uploads can pick it up <ubot4> Launchpad bug 605657 in mpfr (Ubuntu) "Please sync mpfr4 3.0.0-2 (main) from Debian unstable (main) (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/605657 <ogra> lamont, can i get the latest BuildLiveCD on the armel builders ? <lamont> ogra: I suppose.... <lamont> :- <ogra> should help with mailing the logs for armel again <lamont> - LOG=${PUBDIR}${NOW}/livecd-${NOW}-${ARCH}${SUBARCH:+-$SUBARCH}.out <lamont> + LOG=${PUBDIR}${NOW}/livecd-${NOW}-${ARCH}.out <lamont> ogra: ^^ that change in 2 places? <ogra> in 2 ? <ogra> should be only in one iirc <lamont> well, LOG= and PUBDIR= * ogra checks his code <lamont> http://paste.ubuntu.com/464539/ <ogra> no, i think PUBDIR is supposed to create $flavour-$subarch now <lamont> so... code in the package is b0rked then <ogra> i.e. i have ubuntu-netboo-omap4/ <ogra> *netbook <ogra> its just that the log has no subarch applied <lamont> you'll fix the package? <ogra> that would require to change everything <ogra> debian-cd and cdimage look for $PROJECT-$SUBARCH dirs <ogra> so PUBDIR shouldnt change <lamont> right. and the package's copy of BuildLiveCD is therefore wrong * ogra doesnt get what you mean <lamont> after fixing LOG= to match the package, I have: http://paste.ubuntu.com/464541/ <ogra> it works flawless <lamont> and you're telling me that I should not apply that change, correct? <ogra> yes <lamont> so please fix BuildLiveCD in the livecd-rootfs package to no longer have that change in it. <ogra> it works fine as it is, it just doesnt find the logfile since logfiles dont carry the subarch in the name <ogra> for arg in "$@"; do <ogra> PUBDIR=~/public_html/LiveCD/${STE}/${arg}/ <ogra> it doesnt have that change at all <lamont> read the diff again... that's WORKING vs PACKAGED <ogra> so you want me to add it ? <lamont> you're telling me that pubdir needs to have SUBARCH, since that's what's currently running in production <ogra> oh, now i get what you do * ogra is slow today, sorry <ogra> i'll add the change <lamont> thanks, no need to reupload, I just don't want the extra diff there for me to forget and apply on the next round <lamont> your LOG= change is now live <ogra> lamont, package adjusted and uploaded <ogra> and thanks for your patience <lamont> np <cjwatson> doko: done <doko> cjwatson: thanks, only got the NEW mail, not the accepted one <doko> ahh, now <cjwatson> you're welcome to do such syncs yourself BTW <doko> ok <lamont> if I wanted a 10.04.1~NN (well, really "today current") alternate ISO, would I find that lying around anywhere? <lamont> meh. brain engaged finally, nm #ubuntu-release 2010-07-19 <lamont> upgrade launchpad-buildd <lamont> upgrading, even #ubuntu-release 2010-07-20 <slangasek> cjwatson: can I ask you for a quick review of the horror that is lp:livecd-rootfs -r 367? <cjwatson> slangasek: needs to be 'getopts :s:d:f:pa:' rather than 'getopts :s:d:f:p' (contrary to appearances, the : follows the letter, and initial : is differently special) <cjwatson> er, rather than 'getopts :s:d:f:p:a' <cjwatson> slangasek: as you said, horrific in concept, but otherwise looks correct enough <slangasek> cjwatson: fixed, thanks <slangasek> lamont: could you manually push livecd-rootfs 1.134 to acorn and sycamore, please? <lamont> slangasek: BuildLiveCD now dist-upgrades the chroot at the start... <lamont> so kick it and you'll have it <slangasek> but I need the newer BuildLiveCD <slangasek> :) <lamont> oh... you mean "please merge BuildLiveCD from the chroot to the real root" <slangasek> sorry, that - yes <slangasek> or else I mean that I've patched the wrong thing and need to try again <lamont> heh <slangasek> let me confirm what I mean <slangasek> blast, I've patched the wrong part <lamont> yeah. was just gonna say. <lamont> -1 <lamont> BuildLiveCD chroots into a vanila chroot to run livecd.sh which builds the chroot you want <slangasek> yeah, when you say that it rings a bell :) <lamont> and thereby escapes from Seal training <slangasek> lamont: ok; can you merge the fixed BuildLiveCD from bzr, or do you need me to get it published first? <slangasek> (I need to upload anyway for the livecd.sh changes, but if you can get the merge in place at the same time, that would be peachy) <lamont> I didn't merge it <lamont> remind me of the branch I want to look at? <slangasek> right after LP acknowledges my attempt to commit :) <lamont> so did BuildLiveCD actually require changes? <slangasek> it does because I need to pass the argument all the way through from the caller on antimony <slangasek> but I'm still waiting on LP... <lamont> neat <slangasek> there we go <slangasek> lamont: lp:livecd-rootfs <lamont> live <lamont> livecd-rootfs (1.135) UNRELEASED; urgency=low <lamont> WTF? <slangasek> surely that's ok if you're just merging BuildliveCD? :) <slangasek> the changelog commit is coming, slowly just like the last one <lamont> heh <lamont> 'twas more of an attribution/citation challenge <slangasek> lamont: ok, uploaded to the archive; is the merge done, so I'll be able to kick this off in an hour? <lamont> rev 370's BuildLiveCD is live on acorn/sycamore <lamont> livecd.sh is whatever is current in the archive when you kick the pig <slangasek> lamont: yay! thanks #ubuntu-release 2010-07-21 <slangasek> cjwatson: livecd-rootfs 1.137 - thanks and argh; set -u drives me batty <cjwatson> slangasek: likewise <ogra> lamont, do you see any issues (buildd wise) with that livecd-rootfs change ? http://paste.ubuntu.com/466935/ <lamont> ogra: cleanup() needs to deal with making sure it's unmounted, if we pass that way <lamont> as in, think about when the script fails... <ogra> oh, yeah, indeed, do you see any probs beyond that ? i.e. loop mounting not being supported or some such ? <lamont> nothing else hits me in the face, no. <lamont> wut? you can do count=0 and have it do something useful? COOL <ogra> yup :) <ogra> its extremely fast too <lamont> and here I'd been doing all this work to be able to say count=1 <ogra> and doesnt really us space on the filesystem until you write to it <lamont> this is most cool <ogra> *use <lamont> yah * ogra hopes to shove off 1-2h from the current build time with that change <lamont> genext2fs is that slow? <ogra> 3h per image is simply wrong <ogra> 1h for the chroot installation, 2h for genext2fs <lamont> that will be nice <lamont> bbiab <ogra> the prob is that it allocs the whole imagesize in ram before adding the image content <ogra> which means endless swapping <lamont> wtf? AAAAAAAAAAAAAAAAAAaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa <ogra> its relatively fast on my 4G laptop ... but on the babbages it just sucks <lamont> big time <ogra> lamont, http://paste.ubuntu.com/466965/ ... better ? <ogra> (seems DEV was existing but not used by anything) <lamont> looks good <ogra> great, committing <lamont> ogra: if I wanted to steal acorn or sycamore for a bit, which one should I steal? <lamont> meh. nm - I'll just abuse kakadu <ogra> lamont, better talk to slangasek, i have nothing thats really urgent but he is rolling test images atm <lamont> that's what I'd be stealing it for :-D <ogra> ah <lamont> but kakadu will do fine <ogra> well, then any would be ok <lamont> is your change built yet? <ogra> not sure * ogra checks <ogra> built isnt the issue though, mirrored to ports.u.c takes usually long <ogra> built <lamont> published? (which rev is this?) <ogra> 1.139 <ogra> LP says Accepted <lamont> ok. actually going to use sycamore, to avoid the competition <ogra> http://ports.ubuntu.com/ubuntu-ports/pool/main/l/livecd-rootfs/ <ogra> not mirrored yet <lamont> not published yet, more to the point * lamont doesn't care about ports.u.c's copy <ogra> yeh * lamont has manually taken the livecd builder lock on sycamore. <ogra> k <ogra> i'll restrict myself to acorn for test builds * ogra just wants to do a timed build to see the gain <lamont> I believe your gain, and wish to reap its benefit <ogra> yeah, i just want to know if its faster than squashfs <ogra> since we only cp now <ogra> but its still 1.5G <lamont> I almost asked why you didn't rsync when I saw that cp... <ogra> heh, yeah, i could have done that too indeed <lamont> though cp is prolly slightly faster, given the virgin target <ogra> though i dont think it would speed up anything <lamont> wouldn't do a thing <ogra> yep #ubuntu-release 2010-07-23 <lamont> ogra: I'm curious - how much did your "copy to empty fs" change save us? <ogra> lamont, no idea yet, the archive was constantly out of sync <lamont> meh <ogra> so i had no chance to measure yet <ogra> but i suspect we'll get down to 1-2h per image <ogra> together with sharing the load between two livefs builders now that should be breezingly fast <lamont> just fyi... I'll be rolling out a new buildd to all the builders in a bit, the world will go manual at some point for a little bit #ubuntu-release 2010-07-30 <ttx> cjwatson, pitti,slangasek: any of you could re-trigger a Server ISO build ? <Daviey> Is there an ETA on the new server iso? <ttx> Daviey: it wasn't triggered yet <Daviey> :( <slangasek> ttx: looking <slangasek> ttx, Daviey: scheduled <Daviey> slangasek: rockin' <ttx> slangasek: thanks <ttx> smoser: ^ <smoser> whoowhoo. of course all will work this time around. <smoser> no wammies <Daviey> smoser: BTW you were wrong about it never, *ever* stop raining in Prague. So i'm not confident that your prediction of this roll being without warts :) <bjf> anyone else notice the daily live isos have not changed for 3 days? <slangasek> yes - failing because the kernel metapackages are uninstallable ;) <slangasek> (http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ubuntu/20100730/) <mvo> slangasek: just fyi, the apt from experimental is now in maverick, rdepends are currently building <slangasek> whoo \o/ <slangasek> now to figure out where my ppa upload of a multiarch eglibc went <slangasek> aha, it landed in the wrong ppa * slangasek fixes #ubuntu-release 2011-07-01 <skaet> hi all, it looks like we're going to not have quorum for the release meeting today (due to the Dublin rally closing meetings), so the release meeting today will be cancelled. The agenda can be found at: https://wiki.ubuntu.com/ReleaseTeam/Meeting/2011-07-01. <charlie-tca> Thank you <Laney> is someone going to send a DIF announcement? #ubuntu-release 2011-07-03 <Laney> it'd be nice if someone from ubuntu-archive processed the removal requests <persia> I suspect nothing will happen until folk get over jet lag. <persia> (unfortunately) <Laney> no massive rush #ubuntu-release 2011-07-04 <jibel> cjwatson, no installable alternate and server images today. bug 805342 <ubot4> Launchpad bug 805342 in debian-installer (Ubuntu Oneiric) (and 1 other project) "libc6 failed to install on d-i based images with error 'A copy of the C library was found in an unexpected directory '/lib/x86_64-linux-gnu/libc-2.13.so' (affects: 1) (heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/805342 <cjwatson> ok <charlie-tca> Xubuntu desktop images are failing to build, error in messages (no error log for two days): <charlie-tca> W: Failure trying to run: chroot /build/chroot dpkg --force-depends --install /var/cache/apt/archives/libc6_2.13-8ubuntu2_amd64.deb <charlie-tca> also, Xubuntu 64bit alternate shows no updates to the image since July 1, and it should. It shows the image being built everyday, but no updates to it. No errors in log. <ogra_> charlie-tca, i think cjwatson uploaded a fix for that today <ogra_> (see the libc changelog) <charlie-tca> Okay, that works. Why am I not getting any changes on the 64bit alternate, though? <ogra_> seems it was a general breakage between libc and debootstrap <cjwatson> charlie-tca: can you give me a particular package and version that should have been updated since July 1? <cjwatson> and yes, I fixed eglibc <cjwatson> note I'm on holiday tomorrow, so probably want to get all this kind of CD build system stuff fixed today for alpha 2 :-) <charlie-tca> I will have to go looking. It just seems wrong that i386 updates everyday, but 64bit has not changed at all <jibel> cjwatson, if you're on holiday tomorrow could you respin alternate with the new eglibc so I can test it today ? <cjwatson> charlie-tca: well, uh, as far as I can tell that is simply not true <seb128> speaking of new eglibc bug #805154 seems due to it <ubot4> seb128: Bug 805154 on http://launchpad.net/bugs/805154 is private <seb128> "gdm-simple-slave crashed with SIGSEGV in _nss_compat_getpwnam_r() " <cjwatson> seb128: now that part is not my problem, try doko perhaps <cjwatson> jibel: ok <jibel> thanks <cjwatson> charlie-tca: changes from 20110703 to 20110704 on amd64: <cjwatson> +/pool/main/a/app-install-data-ubuntu/app-install-data_936-429-9875_all.deb <cjwatson> +/pool/main/o/openbsd-inetd/openbsd-inetd_0.20091229-1ubuntu1_amd64.deb <cjwatson> +/pool/main/p/pppoeconf/pppoeconf_1.20ubuntu1_all.deb <seb128> cjwatson, heh, I didn't mention your name there nor suggested it was yours ;-) <cjwatson> +/pool/main/s/software-center/software-center_4.1.7_all.deb <seb128> doko, ^ <cjwatson> (corresponding - lines for older versions too, deleted for brevity) <cjwatson> charlie-tca: this exactly matches i386 <charlie-tca> I am sorry. My last zsync did update it <seb128> ups, I though that was #ubuntu-devel sorry about that <doko> seb128: why is
{'channel': 'ubuntu-release', 'month': 7}