=== ChanServ changed the topic of #ubuntu-release to: Quantal Quetzal Alpha 3 prep | Archive: please upload to -proposed | Quantal Quetzal Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or birdseed | melior malum quod cognoscis [00:18] infinity: how far out is d-i looking? [00:20] slangasek: Kernels are still several hours out, then promotion to -release, then d-i. [00:20] slangasek: So, it's a "when I wander past my computer tonight" thing. [00:21] infinity: ok [00:22] if it gets to be morning time for europe, check if app-install-data-ubuntu is close to being published before kicking off the builds [00:22] Perhaps I'll go find some dinner between now and then. [00:22] * skaet thinking dinner might be a good idea for herself too... [00:22] skaet: Are we expecting a new app-install-data-ubuntu sometime? [00:25] infinity, mvo kicked off the scripts for it earlier [00:25] it should show up on the link in the pad, when done. [00:26] skaet: Well, when someone uploads it, yes. :P [00:26] if its close to morning, may be worth checking with mvo how close it actually is to publishing, and hold up for it. [00:26] infinity, was under the impression his script will do that, but I could have misunderstood. [00:27] skaet: If his script automates signing and uploading it, a few of us will likely tell him to stop that. :P [00:27] skaet: But I'm pretty sure it just generates a source package that he still manually gives a once-over and uploads. [00:27] just what I was about to say ;) [00:28] infinity, ok. [00:28] if he's online, ask how close, if not, go ahead and get some images started building [00:29] or rather you, slangasek, myself, or who ever's still up when the d-i bits publish [00:30] slangasek or Laney, according to the wiki. I'm perfectly happy to pretend not to care about images this month. ;) [00:30] (But I'll make sure the kernel and d-i are ready for those who are doing releasy things) [00:31] i promise to book mark it... do you have the pad link for ubuntu-release ? [00:32] infinity, thanks. [00:32] is okay.. found it :) === bjf[afk] is now known as bjf [01:02] * skaet just cleaned up some stale data on https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive [01:17] skaet: Tidied a bit more. [02:15] hmm, I was stimied a bit on armel since it is still an official arch for natty and oneiric, and would show up in the archive that way. We may want to restructure this part a bit more for clarity about which archs are official for which releases, but what's there will do for now. thanks. [02:29] skaet: "show up in the archive that way", in what sense? [02:29] skaet: The archive makes no distinction. [02:30] skaet: And there's a list of which arches as they come in and out of officialness on that page, more or less. [02:30] skaet: (Frankly, the only people who care if natty and oneiric were official on armel are paid customers, and they already know :P) [02:30] skaet: FYI, https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures [02:31] infinity, lets just redirect that section to point to the link micahg points to. That's much clearer. [02:32] Except that the first line of that wiki section is also a lie. :) [02:33] that's true :( [02:34] It also says nothing about what's *currently* supported, which is probably more interesting. [02:34] (please give me edgy security fixed for powerpc, thx) [02:35] infinity: see footnote 1 :) [02:36] Oh. That's tiny. [02:36] BOLD AND RED! [02:38] I'll suggest it :) [02:38] infinity, by shows up in the archive, I just meant it builds to armel not armhf for specific releases. In past manifests we didn't separate between armel vs. armhf, just used arm, so it may be confusing. see:https://wiki.ubuntu.com/OneiricOcelot/ReleaseManifest [02:40] skaet: yes, in precise: https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest [02:40] ah, right no armel ther [02:40] oh, yes there is :) [02:40] micahg, actually there is armel in precise's [02:40] skaet: Turns out that's a wiki and can be edited. ;) [02:41] skaet: Anywhere where it matters from an archive perspective, armel is armel. [02:41] infinity, all the ones we're talking about are wiki's... just a matter of finding them all, and doing the edits to make them consistent. ;) [02:41] (And always was) [02:42] and yes, archive is the one place we can't change. ;) [02:42] And also the one place that's right? [02:42] :P [02:44] hmm... definition of right seems to change with time. when there was only arm variant, calling it armel then may have been confusing. :P [02:45] It depends on how much of the history you have. [02:45] There was a Debian arm port before armel. [02:45] (never in Ubuntu) [02:46] But given that history, calling armel arm was always wrong, IMO. [02:48] Looks like the only two Release Manifests with it as arm rather than armel are Natty and Oneiric. [02:49] * skaet figures may as well clean them up then. [02:49] so there's consistency there. [02:56] Natty & Oneiric Manifests are now consistent with the rest. armel used in all. [02:57] skaet: Yeah, it was never right to call it just "arm". [02:58] infinity, none of the folks doing line sign offs flagged it. :P [02:59] To be fair, they were mostly management. [03:11] skaet: sorry, I seemed to have spaced on some needed Ubuntu Studio uploads, mind if I do them now? (all smallish packages and mostly arch all) [03:12] micahg, we're still waiting for d-i so go ahead. Hopefully they'll all be sorted by the time ubuntu studio starts to build. [03:13] skaet: is that still 18:00 UTC? [03:13] or will this be a manually triggered build? [03:13] micahg, no, we're off cron now, manual triggered [03:13] * micahg will try to get it sorted in the next hour as sleep is calling [03:14] please log them on pad.ubuntu.com/ubuntu-release as opportunity targets if they don't go in, in next hour. === rsalveti` is now known as rsalveti [03:19] ok [03:52] ok, studio default settings upload, spinning up the -meta upload now [04:00] ok, new Ubuntu Studio meta uploaded, I think that's it unless there are bugs found [04:06] thanks micahg [04:08] skaet: also, xubuntu is horribly oversized, don't know if I'll have an answer tonight though [04:09] micahg: Drop the kernel, that'll solve it. [04:09] heh [04:10] ah, awesome, Qt got pulled in somehow [04:11] ubuntuone? [04:11] idk, looking [04:11] Hrm, no, that only seems to be in Ubuntu. [04:12] thunar-archive-plugin recommends ark [04:12] That's a remarkably silly recommends. [04:12] If you want to fix it, go nuts. Still two more publisher cycles until d-i's ready. [04:12] Or, rather, two more until I can upload it, 3 more until it's ready. [04:13] it's an alternate recommends, that's easily clobbered...continuing to look [04:13] infinity, looks like the kernel's finished building, d-i upload? [04:13] skaet: See above. [04:13] ah, that's not it [04:15] infinity: fglrx depends libqtcore4 [04:15] Hasn't it always done so? [04:16] hrm, yes... [04:16] slangasek, still around? [04:16] and that's not on the image [04:16] I didn't realise Xubuntu shipped non-free drivers. [04:16] Yeah, exactly. :P [04:20] Laney, if slangasek doesn't chime in before you get online, looks like you'll get to build the first set. [04:20] * skaet --> zzz [04:21] ubuntu-sso-client-qt looks to be the real culprit, blacklisting [04:22] micahg: How's it coming it? [04:22] see above :) [04:22] micahg: I don't see an above explaining where ubuntu-sso-client-qt is coming from. :) [04:23] infinity: ubuntu-sso-client recommends ubuntu-sso-client-gui (qt is the only choice now) [04:23] Ahh, erk. [04:23] You should petition to resurrect the GTK one. [04:26] hrm, I like Qt personally... [04:27] how often are the germinate-output crons generated? [04:28] s/generated/run/ [04:32] micahg: Not often, but nothing important uses that output. [04:32] micahg: Or did you just want to see it, so you could be lazy and not run it locally? :) [04:32] infinity: I just wanted to verify my work :) [04:32] 2 */4 * * * update-germinate [04:32] I can force the issue. [04:32] ok, so I can check in the morning [04:32] nah, I should go to bed [04:32] Yeah, speaking of. [04:33] Publisher's going to run over by a couple of minutes. >:( [04:33] I should just do my d-i upload on a sleep(1) delay and go do something else. [04:53] * slangasek appears [04:54] slangasek: Did you bring cookies? [04:56] micahg: They're dumping the Uone installer, so I think shipping the client-gui will be the only supported way. [04:56] infinity: no, but I'm chiming in, so [04:56] ScottK: well, IIRC, Xubuntu doesn't ship the U1 client anyways [04:57] * slangasek blinks at two new linux flavors appearing in component-mismatches [04:57] OK. Then I'm confused about what this issue was, but that's fine. I don't need to understand it. [04:57] slangasek: We're not in final freeze, so they're early. [04:58] slangasek: Hrm? You mean the -5 stuff that's NBS? [04:58] ScottK: one of them's for the n900, so I'd argue it's 3 years late ;P [04:58] Well sure. [04:58] Oh, the two heading to main. Wow. [04:59] Maybe I'll have something to do with my n900 besides let it collect dust. [04:59] infinity: linux-n900, linux-qcm-msm; strangely being pulled in via open-iscsi-udeb, vlan-udeb - either a buggy dep declaration, or a c-m bug [04:59] slangasek: That's probably just an oops from having no kernels seeded to main for a second. [04:59] ScottK: Xubuntu ships software-center which needs oneconf which needs ubuntu-sso-client which recommends ubuntu-sso-client-gui of which there is only Qt now [05:00] I see, but it doesn't need a gui? [05:00] slangasek: (In that I bumped the seeds for the mainline kernel to the new version before it was published) [05:00] ScottK: no, it has the GTK gui in it apparently [05:01] I see. [05:02] infinity: ah [05:03] NCommander: What was wrong with backporting the quantal highbank d-i support, instead ot rewriting it? :/ [05:33] Alright, d-i uploaded for both quantal and precise, that's EOD for me. [05:35] * slangasek waves [05:36] slangasek: If you feel like reviewing the precise-proposed d-i, that would be lovely. [05:36] ok [05:36] slangasek: Or, you could wait until the quantal one builds successfully and appears to publish things to sane paths, since the precise one is the same code. :P [05:37] mmm, amd64+i386 d-i builds just failed with a "disk full" error generating the netboot images [05:38] Oh, FFS. [05:38] New firmware again? :/ [05:39] no idea [05:39] Yeahp, new firmware. [05:40] Although, not a lot. [05:40] Kernels might have grown too. [05:41] the fix for which is... to bump the fs size? [05:41] I need to change the Makefile to give me the *^!% size of vmlinux and initrd after it trips over it. [05:41] are you fixing this up, or do you want me to? [05:42] I can fix it. Want to wait for the world to fail, first. [05:42] ok [05:43] Laney: fyi, looks like you get to kick off the builds from the pad then; I don't think I'll be around still when d-i catches up [05:46] Actually, I might leave the d-i image size bump to someone else. I need to try to not be awake at night tonight. [05:49] ok [05:49] And it wasn't firmware growing, same version of firmware was used in the previous d-i builds. [05:49] So, I guess the kernel grew just a bit. [05:49] Or a lot. [05:51] Or maybe everything's just been slowly growing by enough to finally hit the limit again. Don't see any obvious explosions. [05:52] Meh. [05:52] Maybe I'll just fix it. [05:53] * infinity wonders idly why the powerpc image appears to be growing in base10 units, and the x86 ones in base2... [05:56] slangasek: Testing a fix here. [05:57] ok [05:59] with the new format of server images, sources.list only contains cdrom entries. filing a bug [06:10] slangasek: The good news is that the highbank stuff from the last build spit out the way I expected it to. [06:10] slangasek: So, as soon as these amd64 and i386 local builds complete, I'll commit, upload, and go away. :) [06:21] infinity: sounds like a plan then :) [06:23] (uploaded and building) [07:37] howdy [07:50] we building all flavours for a3? [08:11] bug 1028301 with server 20120723.2 [08:11] Launchpad bug 1028301 in debian-installer "Quantal Ubuntu Server - sources.list only contains cdrom entries after a preseeded installation" [Undecided,New] https://launchpad.net/bugs/1028301 [08:21] hello [08:21] I fixed bug 1026066, I think that ought to go into alpha-3 [08:21] Launchpad bug 1026066 in aptdaemon "software-properties-gtk crashed with ImportError in /usr/lib/python3/dist-packages/aptdaemon/client.py: No module named gobject" [Critical,Fix released] https://launchpad.net/bugs/1026066 [08:21] it breaks update-manager, software-properties, and presumably lots of other stuff [08:28] agreed [08:40] added to the pad. does it affect kubuntu ? [09:18] hmm I don't know [09:21] but since we have no candidate images yet then may as well wait for that [09:24] Why is bug 1026964 listed as a rebuild trigger? It's a suspend/resume bug, importance medium, not tagged rls-q-anything. I don't see why we'd care particularly about it for image builds? [09:24] Launchpad bug 1026964 in linux "Lenovo T410s laptop suspends fine, won't resume any more" [Medium,Triaged] https://launchpad.net/bugs/1026964 [09:25] could be a confusion with bug 1027828 which was fixed in kernel 3.5.0-6.6 [09:25] Launchpad bug 1027828 in linux "[Quantal] black screen on resume on 3.5.0-5.5 (regression from 3.5.0-4.4)" [High,Fix released] https://launchpad.net/bugs/1027828 [09:27] Seems more plausible. I've changed the pad. [09:27] I added a comment to the report [09:37] Laney, is there any reason you dropped all the arm precise preinstalled lines from default-arches ? you have to explicitly call a preinstalled build anyway so nothing would attempt to build them unless you say so [09:38] (having the entry helps to keep track what arches were built when, even though nothing uses this entry) [09:39] ogra_: I was advised to do so by slangasek. [09:39] hmm, k [09:40] * ogra_ doesnt get why though, its just historical data and doesnt do any harm [09:43] * cjwatson fixes ubuntu-server/precise [09:47] cjwatson, is server completely switched to squashfs now ? [09:48] ogra_: ubuntu-server/daily is [09:48] ok [09:48] ogra_: just for the base system though [09:48] so we are depending on the live builder with it ... thats what i wanted to know [09:48] no plans to go beyond that in quantal [09:49] (bottlenecks etc :) ) [09:49] it's best looked at as a cached debootstrap (although it actually has the server seed in there too) [10:04] Any objection to me rebuilding world after the next publisher run completes (which will be in ~1hr since we're in the fastdowntime window)? I believe all the rebuild triggers are at worst pending publication. [10:25] +1 to rebuild the world [10:26] as long as you keep the weather do what you want with the world :) [10:46] cjwatson: rebuild would be good [11:15] rebuilding [11:21] Hah, the health checks are really pretty confused by squashfs-base. [11:21] I may have to turn the installability check off for server unless I can think of something clever. [11:23] Which I suppose isn't totally out of the question; maybe I can bodge something using the manifest ... [12:12] hmm, apt-setup failures on omap4 server [12:23] cjwatson, is there any way to convince live-installer to not call update-initramfs ? [12:23] ogra_: are we talking performance or what? [12:23] it calls it before flash-kernel-installer is done (which runs apt-install u-boot-tools) [12:23] so it fails missing the mkimage command [12:24] it's in the console-setup hook, I think, but let me check [12:24] i cant find a debconf key for supressing update-initramfs in live-installer :/ [12:24] it'll need (a) me to think about it (b) code changes [12:24] hang on a bit :) [12:24] need a log ? [12:25] its slightly confusing that the actual failure shown is in apt-setup ... which fails since in-target didnt return properly [12:25] wouldn't hurt but I was just doing a test install here, so if it's >0 effort don't worry about it [12:26] http://paste.ubuntu.com/1108095/ [12:27] logger thinks its from live-installer [12:27] right, yeah, the c-s hook [12:27] Jul 24 12:09:08 base-installer: warning: /usr/lib/post-base-installer.d/25live-installer-console-setup returned error code 1 [12:27] yep [12:28] surprised you didn't have the same problem with trad base-installer though [12:29] you know, you could fix this in f- [12:29] k [12:29] if you wanted [12:29] how, i cant hard depend on u-boot-tools [12:29] just have it do the apt-install earlier, say in a base-installer hook [12:29] sicne f-k deals with lots of other bootloaders too [12:29] would involve splitting it up a bit [12:30] it'd need some care with where you move flash-kernel out of the way [12:30] how about calling flash-kernel-installer as part of live-installer ? [12:31] how about not :-P [12:31] (I would very much rather live-installer not have to know about f-k) [12:31] why not? we need the bootloader setup anyway [12:31] layering [12:31] so we could as well do it early [12:31] hmm, k [12:32] the hooks are available so it's not necessary, anyway [12:33] I mean, if you want flash-kernel-installer to run as a live-installer hook, be my guest, but you're still going to need to leave flash-kernel-installer.postinst in place and figure out a way for it to notice that it's already been called [12:33] well, calling it twice wouldnt do any harm [12:33] I just don't think we should change live-installer for it [12:33] apart from wasting time [12:34] there's /usr/lib/live-installer.d/ though [12:34] * ogra_ was pondering about post-base-installer.d/20live-installer-flash-kernel [12:35] live-installer.d is better, I think - this flow is specific to live-installer so better to use a hook that's also specific to live-installere [12:35] *live-installer [12:35] ok [12:35] let me just check where direct apt-install is enabled [12:36] hmm, but live-installer.d has no ordering [12:36] never mind that, bigger problem [12:36] how do i make sure f-k is done before update-initramfs [12:36] oh ok [12:36] never mind that [12:36] apt-install only queues until install_extra is run [12:36] which isn't until after post-base-installer.d hooks are run [12:36] so this approach is a non-starter whatever way you slice it [12:37] :( [12:37] yeah [12:38] * ogra_ wonders if there is a way to just solve it thgrough seeding ... but i guess that would mean all arm images end up with u-boot-tools again [12:38] *through [12:38] I think I have a better idea [12:40] just fleshing out the details [12:40] k [12:40] add a post-base-installer.d hook with an early number (say 01) that dpkg-diverts update-initramfs and installs a symlink to /bin/true in its place [12:41] (put that in the flash-kernel-installer udeb) [12:41] then undo the diversion in flash-kernel-installer.postinst, just before you call update-initramfs [12:41] actually probably before the apt-install calls so that the nslu2-utils case mentioned there still works (although I realise that doesn't matter for Ubuntu) [12:42] that means we don't have to play whack-a-mole with anything that might indirectly call update-initramfs [12:42] ok, doesnt that also need a dep to live-installer in flash-kernel-installer ? [12:42] I don't see why - it would work just as well with the other style of base system installation [12:42] ah, well, if it isnt there the file will be a no-op [12:42] yeah, thinko :) [12:43] it would probably speed things up a bit [12:43] which I assume you don't mind [12:43] its very fasdt already :) but yeah, i dont :) [12:43] *fats [12:43] bah [12:43] so I think that's all doable entirely within flash-kernel - are you OK with fleshing out the details of that? [12:44] yes, just looking for the place the file has to go [12:44] be a bit careful about interaction with ubiquity, I guess [12:44] since that calls flash-kernel-installer and probably won't have done the diversion, unless you take steps for it to do so [12:44] ubiquity ? [12:44] yes, also normal d-i alternates wouldnt use it [12:45] they would if you used a post-base-installer hook [12:45] so you'd have to either arrange to do the same diversion in ubiquity, or else have flash-kernel-installer.postinst not mind if the diversion isn't there [12:45] f-k-i will have to check if the diversion exists first in any case [12:45] the latter's probably a good idea in any case [12:45] yeah [12:45] just check for the existence of the diverted file, probably easiest [12:45] if it doesnt it wont try to revert it ... [12:45] right [12:55] grr, one day we should make update-noifier check for the arch of a device so it doesnt always offer me to upgrade from my armhf images on my x86 desktop [12:56] * ogra_ just noticed the 50 or so popup messages behind his terminal window [13:12] ogra_: what's wrong with that, if you have qemu-user-static installed, you can totally upgrade from your armhf images ;) [13:12] stgraber, right, and that works very well, i once did that in the middle of a customer call [13:13] at the end of the call, when i rebooted my machine i noticed what had happened since it didnt boot anymore :) [13:13] hehe :) [13:14] yeah, in my experience you at least need a few important amd64 packages for it to work (upstart, libnih, mountall, iputils, isc-dhcp) [13:14] as qemu-user-static doesn't like ptrace or netlink [13:15] (and on a physical machine, you'd probably need binfmt in the initrd with the rest of the initrd being amd64) [13:15] cjwatson, http://paste.ubuntu.com/1108165/ does that look ok ? [13:17] oh, the ${ROOT} is definitely wrong [13:17] ogra_: some over-indentation, I'd spell out "flash-kernel-diverted" in full, 'set -e' in the post-base-installer hook, and please make the source file for the hook be "post-base-installer.d/01live-installer-flash-kernel-diversion" rather than under live-installer/ [13:17] ok [13:17] and actually drop "live-installer-" from that - this isn't live-installer specific [13:18] do you need --local on the undivert too? I forget [13:18] might be best to match there [13:18] i just stole the code from livecd.sh :) [13:18] there it worked like this [13:19] mm, maybe dpkg-divert was lax, I think maybe best not to rely on it always being so though [13:19] the docs say "When adding, default is --local and --divert original.distrib. When removing, --package or --local and --divert must match if specified." [13:19] which implies to me that if you add with --local then you must remove with --local too [13:20] k [13:21] good morning [13:23] cjwatson, http://paste.ubuntu.com/1108178/ [13:24] * ogra_ thinks that will fly [13:25] * ogra_ dputs [13:35] hmm [13:35] I have a work item to fix unseeded universe final freeze, but I forgot what we said [13:36] can anyone remember? [13:37] skaet, i always lose the pad url (used to be in the channel topic) ... could you add a rebuild note for armhf omap4 once flash-kernel 3.0~rc.4ubuntu11 has built [13:37] ? [13:37] was it that we asked people to use proposed after that point? [13:37] skaet, omap4 server that is [13:38] Laney, cjwaton - In looking at the pad and tracker, trying to figure out if the latest published set of images has the app-install-data-update or only some of them (am guessing its a some of them since a-i-d-u only published 2 hours ago) [13:38] ogra_, doing [13:38] some, the rest are still churning through [13:38] skaet, " Any objection to me rebuilding world after the next publisher run completes (which will be in ~1hr since we're in the fastdowntime window)? I believe all the rebuild triggers are at worst pending publication." [13:38] Laney do we know which of the built ones don't have it. [13:38] skaet, that was 3h ago, based on it i would a ssume a complete rebuild of everything [13:39] ogra_, since it published 2 hours ago, I think it was overlooked in the full trigger [13:39] s/it/a-i-d-u/ [13:39] so, some have it, some don't. [13:43] ogra_, http://pad.ubuntu.com/ubuntu-release :) have added your flash-kernel already, and I'll put the link in the topic next. [13:43] looks like the desktop images do have it === ChanServ changed the topic of #ubuntu-release to: Quantal Quetzal Alpha 3 prep: http://pad.ubuntu.com/ubuntu-release | Archive: please upload to -proposed | Quantal Quetzal Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or birdseed | melior malum quod cognoscis [13:44] thanks Laney. [13:44] skaet, thx ! [13:45] where are the logs on the server? [13:45] which server ? [13:45] nusakan ? [13:45] ye [13:45] /srv/cdimage.ubuntu.com/logs/ [13:45] ah yeah found [13:46] though if you need a live-build log that lives on the respective live builder machines [13:46] w3m celbalrai.buildd/~buildd/LiveCD ... on nusakan would give you http access to the armhf build logs [13:46] oh, they are mirrored separately? [13:47] yep [13:47] they are created on different machines [13:47] thought nusakan might fetch them back [13:47] iirc they are mirroed to the same place but with a delay [13:48] was just going to grep for the version of app-install-data-ubuntu they got [13:48] http://people.canonical.com/~ubuntu-archive/ then gets them last [13:48] just look at the manifest and list files in the image dirs on cdimage [13:48] ogra_, re: dropping arm images from precise daily builds - because they're not denoted as LTS, so keeping them automatically building with the precise dailies as we ramp up to 12.04.1 wasn't needed. [13:48] (manifest for live, list for alternate) [13:48] skaet, nothing buiolds preinstalled automated :) [13:48] Laney, other way is to just grep the manifests of the built images for the right version. [13:49] yeh [13:49] (at least for precise) [13:52] ogra_ we're turning on the automated builds for all of the LTS participants from now until 12.04.1 FF, which was motivation for making sure it reflected manifest. [13:57] skaet, right, but nothing executes daily-preinstalled in crontab for precise [13:57] so default-arches isnt relevant [13:58] anyway, its gone now, just dont blame me if in two years nobody can anser which images we built in 12.04 :) [13:59] that's why we have vcs history [13:59] ogra_, fair enough. [13:59] Laney, heh [13:59] you could tag it when we do a release [14:00] Laney, well, up to now we never touched default-arches for past releases, thats new with 12.04 [14:01] (to make sure everything works the same as it did on release day) [14:01] (in case you want to do a rebuild, which never ever happened for arm) [14:02] Laney, tagging when doing a release is a good idea, esp now that there's new hardware being added after the release. [14:02] I suppose using it would be difficult though, because you'd have to have either the old changes or the current [14:03] that might gert tricky to coordinate since the cdimage code isnt bound to ubuntu releases [14:03] *snap* :) [14:04] date of change should have the info, but tagging would make it a bit easier. yes, being able to recreate exactly what worked on release day is a goal we need to accomplish as well. [14:04] the current setup does that very well [14:05] all scripts that touch any release specific bits are also in release specifc subdirs in debian-cd [14:05] ogra_ has we ever had to try it out in ernest? ie. was there ever a case a full recreate was executed? [14:06] no, but there were rebiulds for certain oem images before they switched to OBS [14:07] and mibile images too ... many of tehse wer built out of sync with the release schedule for older releases [14:07] *mobile [14:07] sigh, my typing starts to annoy me today [14:08] so for picked images that always worked ... as well as for point releases of earlier LTSes [14:08] wubi is missing from the tracker is it building ? [14:09] ogra_, heh, its the trackpad on this machine that keeps on flipping my cursor where I don't want it to be. Thanks for the explanation. Was curious. [14:09] colin can surely give more details if needed, he designed the system with the rebuiolds in mind from the beginning [14:10] jibel_: yeah, crunching through [14:10] ack [14:10] jibel, builders are still going, and WUBI's last (see pad for order builds were kicked off in) [14:12] https://wiki.ubuntu.com/FinalFreeze check what I wrote at the end there. [14:12] separate UUFF goes away and becomes this. [14:14] Laney, looks good to me. Post to ubuntu-release maillist, with a pointer to the update, and if no issues raised by end of week, consider it done. [14:25] chrisccoulson: you realize that we're in alpha3 freeze, right? [14:25] micahg, no need to crosspost that accross channels [14:26] kenvandine, chrisccoulson: please upload to quantal-proposed during a3 time ;-) [14:26] seb128: cross post? sorry, I must have missed something :) [14:26] heh, oops ;) [14:26] micahg, doh, my IRC client played me tricks, I though that was #ubuntu-desktop [14:26] micahg, sorry about that [14:26] seb128, whoops... [14:33] Laney: What does the archive is frozen mean in the context of your wiki update? [14:34] that was preexisting, but it means frozen in the launchpad sense [14:36]