[00:04] skaet: do we want tonight's daily to be considered as candidates? (if so, I'll need to enable the milestone and someone will need to change the config on the CD image builder) [00:05] stgraber, pitti turned off the cron, so please go ahead and enable the milestone. The next set of builds should probably be posted. [00:06] skaet: ok, do you want the daily milestone completely gone from the UI or just read only (marked as released)? (I guess it depends if you want to make it easy to see the current daily results) [00:08] stgraber, I'm tempted to hide it to keep the confusion to a minimum, but think it should be jibel's call. Make it read only for now, and lets see what he says tomorrow. [00:08] skaet: done [00:08] Thanks stgraber. :) [00:09] pitti: when you start building, just set milestone to "Precise Alpha 1" in ~/.isotesting.conf [00:19] ~/.isotracker.conf actually [00:20] stgraber,pitti: I've gone ahead and done ^- that now [00:24] ah, right, isotracker.conf. Thanks === Ursinha_ is now known as Ursinha [04:18] pitti: Does your ddeb-scraping mojo handle armhf? [04:18] pitti: Cause... We're building. ;) [04:19] pitti: And I have a hello-debhelper.ddeb for you. ;) === bladernr_afk is now known as bladernr_ [04:24] infinity, \o/ [04:25] And now we wait... [04:26] And I keep sneakily seeding in more and more manually bootstrapped stuff to the stage-2 archive... [04:30] skaet: Almost done my testing here to feel good about that eglibc upload. It'll definitely be "before I got to bed". [04:31] infinity, coolio. good to hear. [04:39] ooh, armhf, pretty === bladernr_ is now known as bladernr_afk [06:39] good morning [06:41] stgraber: noted for next time [06:41] infinity: not yet, hang on [06:54] infinity: eek [06:54] IOError: [Errno 28] No space left on device [06:54] infinity: so much for mopping up the new armhf ddebs :( [06:55] pitti: Erk. [06:55] a few weeks ago I already killed some 60 GB worth of maverick ddebs [06:55] pitti: Is that on your ddebination machine, or a buildd? [06:55] infinity: on macquarie, aka ddebs.u.c. [06:55] not the builders [06:55] but this now hosts the shop, ddebs, langpacks, etc. [06:55] Ouch. [06:55] and video.u.c. [06:55] video is likely the culprit... [06:55] /dev/sda3 537G 529G 2.7G 100% / [06:56] well, ddebs are huge, too [06:56] But you might want to put in an emergency call to IS before ddebs start disappearing from the buildds. [06:56] (I gave you 7 days or something, didn't I?) [06:56] right [06:56] It's been a while since all that insanity was written. [06:57] "nothign lasts longer than a stopgap solution" [06:58] I could also kill natty ddebs [06:58] but I'll file an RT first and whine in #is [06:58] but first I kick off a1 image buildls [06:59] Killing ddebs for releases we support really seems suboptimal. [06:59] Oh, thanks for the reminder that I need to upload eglibc and screw with your Alpha1. ;) [06:59] (It shouldn't screw with anything) [07:00] yes, it's the last resort indeed; I wasn't too attached to the maverick and powerpc ones, but it's still a pity [07:00] (we stopped collecting powerpc altogether) [07:00] ... [07:01] Yeah, also not happy about that. :P [07:03] ok, all builds are running, and shoudl auto-post [07:03] noted so in the pad [07:04] * infinity uploads eglibc, as promised earlier... [07:07] meh, I was just asking for more stuff to be put on video.u.c [07:07] Those two services might need different machines. :P [07:07] Or to be moved to the NAS. [07:08] SAN? [07:08] I can never remember. [07:08] One of those. [07:08] I propose "NASAN" to end the confusion. [07:08] hm, so ddebs.u.c. weighs 308 GB [07:09] video.u.c. is just 27 GB [07:09] So, where's the other 200? [07:09] video.u.c is about 20G out of date (probably more) [07:10] langpacks? [07:10] that's also quite heavy [07:10] but there's also a mirror on there [07:10] and shop. and uds. [07:11] and bugs-mirror.d.o, debzilla, and whatnot [07:11] it's a "dump it all here" machine [07:17] infinity: RT sent [07:17] :( is there any way i can slurp down the ddebs before you start purging natty ones? i still care about those [07:17] pitti: I saw, thanks. [07:17] I don't want to remove them today [07:17] broder: I postpone armhf ddebs for the next 6 days (unless we get more space by then) [07:18] broder: but in general, it's a standard archive layout, so debmirror should do fine [07:18] hmm, ok. now /me just has to go find 300G of spare space [07:18] broder: no, 308 GB is the whole archive [07:19] that is, {lucid,natty,oneiric,precise} x {i386,amd64,armel} [07:19] oh, ok. so probably 1/4 of that for natty or so? [07:19] yes, or less if you only want one arch [07:20] my "next against the wall" is natty armel, when it comes down to "now or never" [07:20] http://91.189.93.73/qatracker/milestones/205/builds [07:20] nice, images do appear [07:20] ok. i don't personally care about armel, so maybe i'll be ok :) [07:21] ♪ It's a kind of maaaagiiiic ♩ ♫ [07:22] err, desktop livefses are built in a mere 8 minutes now!?! wow [07:22] our progress this cycle doesn't stop amazing me [07:22] if it wasn't for powerpc ruining the performance, we'd have kubuntu built by now, too [07:26] ppc will improve a bit "soon". [07:53] skaet, I'l hide dailies during a1 testing to avoid confusion [07:56] ah, thanks [07:56] jibel: bonjour [07:56] pitti, guten morgen [07:57] jibel: is there a difference between the "Precise" and "Precise daily ISOs" views? [07:57] * pitti figures it is currently autotesting the ubuntu desktops [07:59] pitti, as far as I can see, there's not much difference. Precise = Precise daily ISOs + upgrades [08:00] ah, upgrades and boot speed [08:00] right, thanks [08:00] right + boot speed [08:49] jibel: maybe I'm just too impatient, but desktop amd64 have finished testing half an hour ago, but no sign of the i386 iso tests yet; not even a failed one [08:49] or are other tests running in between? [08:50] pitti, they crashed [08:50] 'invalid argument' [08:51] ah, so that wouldn't show up as a "fail" [08:51] they will fail when the test will reach its timeout which is 60min [08:51] ah, good to know [08:51] I'll cancel the tests and run them again [08:51] merci [08:52] jibel: I'll try to find a simpler reproducer today, after I'm done with my current bug fix [08:52] * tumbleweed kicks himself for not getting the aptitude + multiarch breakage into the oneiric release notes :/ I keep seeing people hitting it [08:52] the "i386 on amd64" was a good hint, usually I'm using amd64 everywhere [08:53] infinity: hmm, what's up with https://launchpadlibrarian.net/86161322/buildlog_ubuntu-precise-armhf.net-snmp_5.4.3~dfsg-2.3ubuntu2_FAILEDTOBUILD.txt.gz ? [08:54] cjwatson: sbuild patch incoming. [08:54] oh, a cj "I ought to be on holiday" watson! [08:54] good morning [08:54] pitti, thanks. jsalisbury is on the case too. [08:54] cjwatson: base system dpkg doesn't know about armhf. Fixing sbuild to use the dpkg-architecture in the chroot seems saner than trying to upgrade dpkg in every past release that's running on all the buildds. [08:55] I am on holiday, I've just been rousted out of bed in order to make a trip to the doctor's surgery, and IRC/mail is a good way to wake up [08:55] infinity: ah, good, yes [08:56] that makes everything fail to build, yes? :) [08:56] cjwatson: No, just anything with "Architecture: any all" and anything with "foo [linux-any]" style build-deps. [09:00] ah, ok, not quite the whole world then [09:05] cjwatson: No, just large portions of it. ;) [09:09] is it ok to upload a new update-manager and software-center today (asking because of the soft freeze) [09:11] mvo: what's the nature of the changes there? [09:12] pitti: for u-m its merging back the recent security and some minor fixes, for s-c mostly the addition of the system-wide license key support [09:13] pitti: I can wait with the s-c upload as it will also bring in a new dependency (software-center-aptdaemon-plguins) [09:13] mvo: u-m sounds fine, please go ahead [09:13] for s-c, I agree, let's wait until after a1 [09:13] thc [09:13] ups, thanks [09:13] that'll need an MIR? [09:14] oh, source/bin NEW [09:14] I guess, but its really part of s-c itself, its just the twisted setuptools that made me split it into its own package [09:14] yeah, MIR should be trivial [09:15] * mvo nods [09:42] cjwatson, the logging issue with desktop tests is fixed, I'll update jenkins in the afternoon after Carlos review. [09:49] jibel: so the i386 desktop tests worked now, nice [09:51] pitti , yes, just need to run it 2 or 3 times. this bug is painful. I can't reproduce it on HW which is good news. [10:02] jibel: thanks [11:16] * pitti retries the xubuntu daily, there's no obvious reason for the bzr branch checkout failure (checked with #bzr) [11:16] looks like a glitch [11:20] that looked like temporary network trouble to me [11:26] cjwatson: right, that's what I hoped; and there it is [11:27] (i. e. both buildds succeeded) [11:38] pitti: What time was it? [11:38] LP was down from 0831-0832ish. [11:39] From cdimage@nusakan.canonical.com Tue Nov 29 09:28:58 2011 [11:39] wgrant: so, could be [11:39] Hm. [11:41] pitti: the builds should go make tea when LP is down (I think the package importer had a bug for that) === doko_ is now known as doko [12:17] can I upload kde-workspace to drop kde-wallpapers (~40 MB) from the kubuntu image again? [13:32] fine for me === bladernr_afk is now known as bladernr_ [14:35] bug 897680 [14:35] Launchpad bug 897680 in ubiquity (Ubuntu Precise) (and 1 other project) "12.04 64Bit: libc6 fails to install if "install 3rd party software" is selected (affects: 1) (heat: 6)" [Critical,Triaged] https://launchpad.net/bugs/897680 [14:36] jibel: thanks === hyperair is now known as Guest43903 [15:08] pitti, good morning [15:09] hey skaet [15:10] FYI, we have two reasons for respinning, see pad [15:10] pitti, looks like iso tracker is up, bugs getting reported, all flowing as it should, will look at the pad now. [15:16] pitti, re: libc one, ouch. Do we need to find someone to help figure it out, or are you looking into it. [15:16] ? [15:17] skaet: mterry is looking into it for now, but I'll also have a look [15:17] I spent most of the day on bug 894768 and bug 893826 [15:18] Launchpad bug 894768 in linux (Ubuntu Precise) (and 1 other project) "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument (affects: 5) (dups: 4) (heat: 44)" [High,Triaged] https://launchpad.net/bugs/894768 [15:18] Launchpad bug 893826 in qt4-x11 (Ubuntu Precise) (and 3 other projects) "symlinked docs are different between architectures, depending on dpkg-deb package order (affects: 19) (dups: 17) (heat: 172)" [High,Fix released] https://launchpad.net/bugs/893826 [15:18] skaet: I need to run out for a bit, but we'll continue to look into this [15:19] pitti: I left a comment explaining bug 897680 [15:19] Launchpad bug 897680 in ubiquity (Ubuntu Precise) (and 1 other project) "Precise Desktop 64Bit: libc6 fails to install if "install 3rd party software" is selected (affects: 1) (heat: 8)" [Critical,Triaged] https://launchpad.net/bugs/897680 [15:20] judging from the archive, a respin with no changes should fix that [15:20] I mean with no further uploads [15:20] cjwatson, mterry - thanks. :) [15:22] cjwatson: oh, splendid [15:22] pitti, so language selector appears build and published, kick off the respins? [15:22] skaet: looks like it then [15:22] :) [15:23] * skaet looking forward to seeing this new stuff in action [15:24] skaet: it's great [15:24] I basically just did the image commands on nusakan, and posting and smoketesting happened fully automatically [15:25] good to hear nothing exploded :) [15:25] so 897680 affects all desktops/DVDs [15:25] so we can keep kubuntu alternate, server, and core [15:28] won't language selector be needed for those? [15:29] right [15:30] skaet: ah, misinterpreted as "for the rebuilds" [15:30] skaet: the language-selector crash only affects the -gnome flavour [15:32] heh, time for me to do some learning, I was seeing the other binary packages built by this source, and figuring the scope was larger. [15:39] skaet: ok, all builds running; had to wait for a bit with the alternates for l-s [15:39] let the magic do its work [15:39] * pitti really needs to run out now, bbl [15:41] thanks pitti, l8r [15:45] stgraber, where should the comments be in the tracker about the reason for the rebuild? [15:46] skaet: they'll appear at the top of a build page (testcase list, result list, download information, ...) in the notice board. [15:49] stgraber, am not seeing anything about the current rebuild there right now, does the reason need to be manually added? [15:51] skaet: yes, someone to update it. It can be updated from the admin UI or when adding a new build (from either the admin UI or the API). [15:51] stgraber, ok, we'll need to make that explicit. Let me try now. [15:52] I think the best would be to have that note be on nusakan and automatically pushed through the API when the new builds are ready. This way it'll get included in the notification e-mail. [15:53] so instead of saying why something is being rebuilt (that needs manually updating from the admin UI and won't notify the testers by e-mail), we tell them what's different when the new build is announced [15:55] stgraber, yeah that seems like a better flow. [15:57] cjwatson: do you want a patch for that one ^ (basically passing the content of a file to the note parameters of builds.add, currently set to '')? [16:03] skaet (and probably stgraber) if it's not too much trouble i would prefer not to publish and test the ubuntustudio alpha 1 image since there really isn't much difference from oneiric [16:08] scott-work, no trouble and your call, we'll remove them from the alpha-1 list then. [16:09] pitti ^ ubuntu-studio removed (but may reappear from your rebuilds). [16:12] skaet: would you prefer such a notice earlier? is it bad form to ask this close to alpha1? [16:13] scott-work, earlier the better. :) I'll have the ReleaseImageContacts page sorted out soon, and you can just indicate the milestones you want to participate in on there. [16:14] i'm creating a project lead/team "playbook" for ubuntu studio parsed by milestone that lists required activities and i'll place this in there as well === shadeslayer_ is now known as shadeslayer [16:19] stgraber: sure - if we want it for a1 get somebody else to review/apply/deploy it though, I'm not really here :) [16:20] cjwatson: oh right, I forgot you're not supposed to be around today ;) [16:33] Hello! Is bug 897380 important enough to break soft freeze for? Debdiff in the bug [16:33] Launchpad bug 897380 in imagemagick (Ubuntu) "PerlMagick fails at runtime in precise (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/897380 [16:34] pitti: that's the change to isotracker_xmlrpc.py I mentioned before: http://paste.ubuntu.com/753813/ [16:34] pitti: then if present ~/.isotracker.note will be sent to the tracker, included in the notification e-mails and displayed in the header on the site [16:35] stgraber: ah, thanks === chrisccoulson_ is now known as chrisccoulson [16:48] mterry, change seems small, not sure we'll respin for just it, but if we need to respin for something else, it wouldn't hurt to have it in I think, pitti - feel free to disagree. :) [16:51] mterry: looks fine to upload [16:51] k === Ursinha is now known as Ursinha-lunch [17:17] hmm seems amarok missed the libmysqlclient transition sweep.. [17:19] SpamapS: I've uploaded amarok yesterday, what's missing? [17:20] hm never mind, its good [17:20] for some reason my system showed it still needing libmysqlclient16 [17:30] SpamapS: do you know why mysql-client-core-5.5 gained so much weight compared to 5.1 (+ 6.5 MB installed size)? [17:30] debfx: I don't, but I'll look into it. [17:31] thanks [17:33] debfx: I'm going to guess cmake has had a hand in this evil ;) [17:35] debfx: doh!!! [17:36] debfx: libmysqclient is statically linked in [17:37] nice [17:39] * SpamapS curses cmake [17:39] * SpamapS also curses mysql's source release engineering.. or lack thereof [17:42] heh [17:56] skaet: so, new builds trickle in and get properly auto-posted [17:56] and jenkins jumps at them and tests them, too [17:57] pitti, i'm seeing, and beeing delighted. MUCH MORE EFFICIENT! [17:57] you bet! [17:57] skaet: can you take it from here? [17:57] the fix for bug 897680 should be confirmed [17:57] Launchpad bug 897680 in ubiquity (Ubuntu Precise) (and 1 other project) "Precise Desktop 64Bit: libc6 fails to install if "install 3rd party software" is selected (affects: 1) (heat: 10)" [Critical,Fix released] https://launchpad.net/bugs/897680 [17:57] but otherwise I'm not aware of outstanding blockers [17:57] jibel mentioned OEM mode being slightly broken [17:57] pitti, let me check a couple of things quickly (ie. access is working ok0 [17:58] but that sounds like something we could document [17:58] * skaet nods re: OEM stuff [17:58] precise-desktop-i386_oem didn't re-test, I suppose it's another victim of the EINVAL bug [17:58] so jibel or someone else needs to poke this to have it re-run [17:58] but I can't do that eitehr [18:02] Cloud images are being respun -- eta is 22:00 UTC [18:02] thanks utlemming [18:05] pitti, ok, access check out. I've got it for now. Have a good evening. [18:05] cool, see you tomorrow! === Ursinha-lunch is now known as Ursinha [18:17] skaet: will you remove the "rebuild in progress.." note from the tracker once all images are back in? [18:18] pitti, yup, was planning on doing it after the last one landed. [18:23] skaet: currently cloud images for Alpha 1 do not boot in kvm or openstack. The fix has been identified, but would require a kernel upload. [18:23] For alpha 1, I'm not sure it's worthy of a new kernel, unless one is needed for another reason. [18:24] ogasawara said that they can have a fix queued for upload as soon as you thaw the freeze, and we can have functional images 4-5 hours later. [18:24] the -virtual kernel is never selected by the installer, is it? [18:24] no, not afaik [18:25] i did not think so, but cjwatson would know. if it is, then this is more serious as it would affect all vm install. [18:25] Daviey, yup, was following in release channel. Having it uploaded and ready in case we respin would make sense. Do we want this just for the cloud images, or for all of them? [18:25] or some subset of vm install. [18:25] the -virtual kernel is not on the media so it would not affect ISOs i would not think. [18:25] skaet: it's the virtual kernel flavour which only makes sense on kvm/xen/cloud [18:26] thanks smoser, Daviey. [18:26] Daveiy, if its only for the virtual kernel, then yes, I'm fine with the timing you and ogaswara recommend. [18:27] skaet: In perspective, this is Alpha 1. I'm really excited about rushing around to get this solid. It's a benchmark in the cycle, and we have caught the fix that can be release noted. [18:27] smoser feels it's more pressing [18:28] i feel that a -virtual kernel that is not useful in a virtual environment is a significant issue. [18:28] but we would be running around like a chicken for 20 hours probably to get it fixed. [18:29] * skaet scratches head over Daviey's comments "I'm really excited"... did he mean "I'm really not excited"? [18:30] does QA use the -virtual kernel for any of their testing ? [18:30] bjf, good point. [18:30] jibel, ^^ [18:30] the primary benefit to me is having alpha1 images that booted in openstack so we can later compare something against a known quantity. [18:30] bjf: I'd guess no, if we're just seeing this now. [18:30] if the image doesn't boot, then we can't do that. [18:31] ogasawara: i agree, but i wanted to make sure [18:31] ogasawara, i would also guess 'no', but we will be getting there with openstack testing. automatically testing latest images. [18:31] but even if we were, we found this pretty soon after it landed in the archive. [18:31] skaet: yes, really not [18:32] I can confirm that precise worked for me on sunday, under kvm/openstack [18:33] Daviey, wouldn't that have been a 3.2 kernel ? It should have had the same issues. [18:33] interesting, we did pick up a new kernel but it should have been unrelated I would have thought. [18:33] Daviey: which version? the last upload we did was on Friday. but the 3.2 kernel we've had uploaded and in the archive for a while now. [18:34] Daviey: correction, the last upload was yesterday, but that was only a config change that affected arm. [18:34] ogasawara: hmm, that doesn't make sense [18:35] ogasawara, when did you upload meta ? [18:35] tgardner: apw uploaded meta yesterday? [18:35] * ogasawara checks [18:36] ogasawara, I was just wondering when the 3.2 kernel might have actually been referenced. [18:36] the last thing know i've booted in kvm with networking was from the 22nd. [18:36] Hmm, seems i am on 3.1 kernel [18:36] ok.. [18:37] so another option we could pursue here is to respin cloud-images with a one time inclusion of 'linux-image-extra-virtual' [18:37] smoser, Daviey, tgardner: yep the first 3.2.0.1.1 linux-meta package was uploaded on Nov 23 [18:37] which woudl get us the necessary modules. and i've verified that that gets me a booting system. [18:37] it comes at a cost of 87M (per apt) of modules that we've not had before. [18:37] smoser: that wouldn't be removed on upgrades? [18:38] well, if we added the meta-package, it would pull in the -extra for new kernels on upgrade. [18:38] if we add just linux-image-extra-3.2.0-2-virtual, then we'd only get it for that kernel. [18:39] i dont think *anything* (kernels) get deleted on upgrades [18:39] smoser, that true. besides, its a development problem. what a few extra MB ? [18:40] at the moment i'm leaning towards that hack solution. [18:40] smoser: +1 [18:40] as it limits the people who are running around like chickens without a head. [18:40] I resemble that remark. [18:40] heh [18:40] and i'm thinking to just add the linux-image-extra-3.2.0-2-virtual also so that upgrades wont get the -extra. [18:41] smoser: yep, sounds good [18:41] smoser: we can still have the official fix queued and I'll immediately upload upon Alpha1's release [18:42] * skaet nods [18:43] smoser / ogasawara / tgardner: As long as it is removed on upgrades, works for me [18:44] it wont be removed on upgrades. [18:44] Daviey: it won't be removed on upgrades [18:44] kernels are never removed on upgrades [18:44] then it sucks as a hack. [18:44] (it matches linux-image, so it would not be). [18:44] no more so than kernels are a hack. [18:44] :) [18:44] i'd rather we defer the cloud image release by 24 hours TBH. [18:45] Daviey, I think smoser's hack would only apply to one kernel. The next ABI bump would be back to normal. [18:46] right. you'd only get -extra on upgrades from alpha1 cloud images for that kernel. [18:46] the 2 things that will suck about it that i can think of now are [18:47] a.) 87M of wasted space (i'm not concerned about that) [18:47] b.) you would not know that othe rmodules you needed are not going to be there later [18:48] if someone is actually upgrading all the way to release from alpha1, they're going to have work around worse than having to 'apt-get --purge remove linux-image-extra-*' [18:51] Daviey, ? [18:51] sure [18:53] stgraber: The links to images on the new tracker are off for all of armel & core. Neither have "iso" files. [18:53] jibel: ^ (want me to fix that?) [18:54] I take it back. Looks to be core only. [18:54] ok, if it's only core I can just fix them by hand now [18:55] http://cdimage.ubuntu.com/daily-preinstalled/20111129/precise-preinstalled-desktop-armel+mx5.iso should be http://cdimage.ubuntu.com/daily-preinstalled/20111129/precise-preinstalled-desktop-armel+mx5.img.gz (or whatever after the rebuild). [18:56] ac100 is perfect. Has both the bootimg & rootfs tarball linked. That is excellent. [18:56] GrueMaster: looks like ti affects desktop armel mx5 as well [18:56] ah right, just read backlog :) [18:57] so my query seems to match your list, good, fixing that now [18:57] I'm double checking the links now. Core and desktop-armel+mx5 are the only ones so far. [18:58] qatracker=> SELECT DISTINCT qatracker_product_download.filename, qatracker_product.id FROM qatracker_product_download LEFT JOIN qatracker_product ON qatracker_product.id = qatracker_product_download.productid WHERE qatracker_product_download.filename ~ '.iso' AND qatracker_product.title ~'armel'; [18:58] filename | id [18:58] --------------------------------------------+----- [18:58] omap/omap4 both look good. [18:58] precise-preinstalled-desktop-armel+mx5.iso | 229 [18:58] precise-preinstalled-core-armel.iso | 220 [18:59] precise-preinstalled-core-[armel|amd64|i386] all should be .tar.gz. [19:07] GrueMaster: ok, I think I got them all [19:08] GrueMaster: can you also confirm that it's only the ac100 that requires a separate boot image? [19:09] Yes, it is at the moment. Not sure what the future may hold if we can get more community enabled platforms. [19:09] We'll cross that when it happens. [19:09] good, just wanted to make sure I didn't forget any [19:14] GrueMaster: there you go for an ac100 image: http://91.189.93.73/qatracker/milestones/205/builds/7250/downloads [19:14] oh, interesting, seems like the table title is wrong, fixing that now [19:16] fixed [19:16] Excellent! [19:17] Now I just need to figure out the best way to test core images. Was thinking lxc, but may just use chroot for now (less confusing and quicker). [19:18] GrueMaster: want an lxc one liner to start them? [19:19] (testing the idea on my panda quickly) [19:19] If you have one, that would be cool. Need to be able to control on i386 & arm ideally. I'm creating a jenkins job here now. [19:39] GrueMaster: looks like I have something that works (not exactly one line, but one script), just re-running to test, forgot how bad my panda is at I/O :) [19:40] currently using it as a mediacenter with xbmc using a network drive so I only really notice when messing with the system :) [19:40] My pandas are all running off USB-Sata, so I can get a little better performance. [19:41] GrueMaster: so that's what it looks like http://paste.ubuntu.com/754014/ and the script (prepare.sh) is http://paste.ubuntu.com/754015/ [19:42] GrueMaster: you'll probably want to change some bits to make it entirely automated [19:42] but at least it unpacks, it boots and it shuts down [19:42] lxcguest is currently required so that mountall plays nice but we plan on fixing that this cycle so any regular Ubuntu system can boot in LXC without modification [19:43] I'll also have to ass a step to run apt-get update and install a test package, but thanks. Helps out a lot. [19:43] Erm. Add a step (sorry). [20:07] * skaet notes that everything has now been rebuilt except the arm image in less than 4 hours... sweet. [20:08] now if we can just get the builders to work that fast :) [22:12] How do the meta-release files get updated on changelogs.ubuntu.com? I ask as I just fixed a mistake in one of them [23:22] Oh, FFS. I completely forgot about the freeze and uploaded mono. [23:22] (armhf-only fix, not impact on other arches except for a version bump) [23:22] s/not/no/ [23:23] * skaet hopes those are not famous last words.... [23:23] Is mono still on images? [23:23] Oh, there's that. We may have removed it by now anyway. :P [23:24] skaet: It added one symbols file with an extension of .armhf, if that breaks other arches, then mono was already broken. ;) [23:24] :) [23:24] * skaet doesn't rule this out, but last touch rule applies ;) [23:25] Laney: mono-runtime still seems seeded for edubuntu [23:25] Yeah, I don't look forward to all the TILM I'll end up with. [23:25] * skaet hopes we won't need to rebuild then. [23:26] no blockers showing up so far this afternoon that anyone has pinged me about. [23:27] A bit of archive/image skew on alphas isn't the end of the world anyway. And if a rebuild needs to happen for some other reason, fresh mono for edubuntu for free. :P [23:27] good, I'm glad edubuntu knows what's right :-) [23:27] * infinity keeps the soft freeze in mind and stages the rest of his armhf fiddling locally. [23:29] infinity: do you have a build log perchance? [23:29] Laney: Of..? [23:29] I would be interested to see if the situation has improved since debian bug 639342 [23:29] Debian bug 639342 in mono "mono: please add armhf support [PATCH]" [Important,Open] http://bugs.debian.org/639342 [23:29] https://launchpadlibrarian.net/86215844/buildlog_ubuntu-precise-armhf.mono_2.10.5-1_FAILEDTOBUILD.txt.gz [23:30] a successful one ... [23:31] Laney: That would be successful if the symbols file was right. [23:31] Laney: (Which is what I just uploaded to fix) [23:31] thought you might have a local one [23:31] Nein. [23:31] Though I'm now wondering if I wanted that --with-fpu hack from the Debian bug... [23:32] Maybe it cleverly autoselects. [23:33] I'm not sure it will work. Upstream were talking about an armhf port the other day, which implies that mainline is not (fully) ported. [23:34] Hrm. Well, it fails a few more tests than armel, but not a lot. [23:34] Perhaps I should do some local fiddling. [23:34] I still suspect my upload will be enough to get it built and function as a build-dep. [23:34] yeah, 'least we can test [23:35] hmm, wondering why Edubuntu still has mono, thought we got rid of that... [23:36] boo [23:36] do you have gbrainy? [23:36] Laney: Going to do some local testing now. [23:36] Laney: It's that or java, and mono being installable makes it win. [23:37] we shouldn't have it, we're based on the ubuntu desktop seed, so we should have lost tomboy, banshee and gbrainy at the same time Ubuntu did [23:37] ok. vargaz in #monodev is your man btw. [23:37] oh, found it, pdfmod is probably the one pulling mono [23:38] * Laney sheds a tear for good apps [23:38] we're currently in the position where we'll drop mono for 12.04 if we are the ones who end up having to care for it for the LTS (5 years). If someone else is going to take care of mono anyway (because of bindings or whatever), then we'll seed gbrainy explicitly as well as make sure we keep pdfmod and maybe bring back tomboy (not sure about that one) [23:39] (where we means Edubuntu) [23:39] meh, we never got that much support from non-mono-team anyway [23:40] Laney: yeah, it's just that for LTS approval I have to give a list of source packages that aren't seeded and that we ship, we're expected to take care of these for the 5 years of the LTS [23:40] and my personal goal is to make sure we don't have mono, java or any programming language on that list :) [23:41] I'm fine supporting apps for 5 years, not programming language and hundreds of libraries (that last one is mostly for our java stuff ;)) [23:43] anyway, I need to clarify that for our proposal to the TB (exact list of Edubuntu-specific packages, list of these that we'll support ourselves, mostly these that aren't in main and list of these that we'll try to drop somehow) [23:44] * Laney thinks mono could be advertised to people being held on other operating systems by .NET apps as a route to migration [23:45]