[00:04] Alternates re-spun, if someone who knows how the ISO tracker works wants to post them. :P [00:06] infinity: all of them or just ubuntu? [00:06] stgraber: The whole shebang. [00:07] stgraber: live/desktop/preinstall/whatever images are still grinding away, but alternates should all be ready. [00:07] ok, posting them on the tracker [00:09] are none of the live images done yet? [00:12] infinity: I'm guessing that includes server too. What about the omap and omap4 build for server, was that part of it too? [00:12] nevermind, I see them on cdimage [00:12] posting [00:13] bug 855171 may be worth mentioning in here [00:13] Launchpad bug 855171 in nss (Ubuntu) (and 1 other project) "libnss3.so went missing after upgrade (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/855171 [00:14] infinity: ok, I think I got them all, only left disabled on the tracker are the upgrades (not sure why so didn't re-activate), desktop builds and dvd builds [00:16] mdeslaur: can you attach an apt term.log, which is generally more usable than a dpkg.log? [00:16] (/var/log/apt/term.log) [00:18] the file's missing here too, how incredibly rude. [00:18] convenient that I hadn't rebooted yet, I guess [00:19] slangasek: attached [00:19] thanks [00:19] mdeslaur: do you know when you last had it [00:19] ? [00:19] I had it when I booted the laptop just before doing the dist-upgrade [00:19] so, whatever you see that's dated the 20th is when it happened [00:20] bbl [00:23] I am going to be annoyed if this turns out to be a knock-on effect of running update-ca-certificates [00:23] which is looking likely [00:24] yep [00:24] arrrgh [00:33] slangasek, is there something wrong with java-ca-certificates update? [00:33] doko_: yes, the do_cleanup() function is nuking the system libnss3 [00:33] doko_: can you have a look at it? [00:34] slangasek, ok, first thing tomorrow morning. not now, just too tired [00:34] tomorrow morning is too late [00:34] if you're not free to do it now, that's fine; but this is eating users' systems in realtime [00:34] no nss3 == no network-manager [00:34] gaah [00:35] stgraber: Thanks. [00:36] * infinity goes to make some food. [00:42] slangasek, there was a suggestion to drop the libdir setting in nss.cfg. openjdk does have the multiarch path on the default libpath. [00:43] doko_: should we take this to #ubuntu-devel? RAOF is also looking at it there, probably better to not have too many people working on it in parallel [00:44] ok [00:49] Failed to fetch http://ftpmaster.internal/ubuntu/pool/main/c/ca-certificates/ca-certificates_20110502+nmu1ubuntu2_all.deb 403 Forbidden [00:49] * infinity blinks. [00:51] slangasek: Did I miss a memo? [00:51] infinity: yes [00:51] look up [00:51] Oh. [00:51] Ugh. [00:51] So, all these images are useless? :P [00:53] you can use them as virtual coasters [00:54] I need a virtual microwave to make them crackly. [00:56] infinity: btw, you should now have admin rights on the tracker [01:00] stgraber: Shiny, I suppose that means I'd need to learn how to make it go, then. [01:00] Anyhow, with ca-certificates in standard, that invalidates every image except for core. Woo. [01:00] * infinity kills the builds that were in progress still... [01:02] ooops ;( [01:03] * GrueMaster weeps for humanity [01:06] infinity: ca-certificates-java uploaded [01:06] infinity: please to reviewing [01:07] or if you prefer, I'll accept it myself (but then I should probably test it first) [01:10] slangasek: I'll review when it lands.. [01:11] so [01:11] ca-certificates-java doesn't affect all the images [01:11] but I think ca-certificates should gain a Breaks: on the old version of ca-certificates-java to enforce the upgrade in tandem [01:12] actually, Conflicts: [01:12] Which then affects all images. [01:13] yep [01:13] infinity: you're holding the baton; what do you think? [01:13] I think I have a date tonight, but the baton is relocatable. ;) [01:14] I do think we should respin for it, though. [01:14] for -java, yes [01:16] hmm, ca-certificates-java should only be on DVD images [01:16] -java tested locally, confirmed that I still have libnss3.so [01:16] slangasek: I may be coming into this discussion late, but how is it ever a good idea (even with this lovely guard in place) for a random package to delete libraries? [01:17] infinity, because it did create the link [01:17] (The code looks to do what it wants to, though) [01:17] doko_: Ahh, it's a symlink (or, it is when we want it dead)? [01:17] A -L guard might have made that more obvious too. [01:18] infinity, it's a hard coded value in nss.cfg, but we need it to run the update [01:18] doko_: it's on {kubuntu,ubuntu,edubuntu} DVDs and ubuntu-server, but the question is if we want to update ca-certificates as well for all the users who might have -java installed locally and be affected [01:18] * infinity nods. [01:18] infinity: right, it's meant to only be cleaning up symlinks created in this same script [01:18] but it, ah, missed [01:18] slangasek: Check. [01:19] slangasek, if it's safer this way, fine [01:19] the damn thing is, I *saw* the ca-certificates-java error backtrace when I was preparing the ca-certificates update, and assumed it was an innocuous pre-existing problem... I should have followed up on that error earlier :/ [01:21] slangasek: I'm just going to go on record as saying that's one hell of an ugly and opaque shell script for something that appears to accidentally nuke files, but it looks like it should do what it says on the tin, so accepted. [01:21] (Well, until the next time something weird happens) [01:21] infinity: thanks. so, you still hold the baton, what would you like to do? I can prep a ca-certificates upload with the Conflicts quickly enough... [01:21] slangasek: Well, the conflict is sane anyway, I think. [01:21] and if you need to pass the baton off to me, I can take it [01:21] slangasek: Personally, I think that warrants a rebuild. [01:21] * slangasek nods [01:22] done then [01:24] since the breakage was introduced in a narrow range of versions in oneiric, I'll probably make it an == conflict to not complicate natty->oneiric upgrades [01:26] slangasek: I already killed the arm builds, which take longer than everything else combined, so it's not like this makes things worse. [01:30] yep [01:30] ca-certificates uploaded [01:30] slangasek: There was only one broken -java version? [01:30] infinity: in Ubuntu, yes [01:30] Handy. [01:30] :) [01:52] publisher running [01:52] (or jogging in place) [02:24] ^^ that can wait until after beta 2, it's an FTBFS fix, but part of the ubuntustudio packageset [03:13] any objections from the release team for me to use the buildds for mozilla updates (all short ATM, will ask again before the long Firefox 7 ones) [03:20] micahg: Any chance you can do them serially? [03:21] I don't really feel like putting buildds on manual, not when I'm not sure how long I'll be up. [03:21] infinity: the buildd manager will max out at 60% for the PPA [03:21] so that's 1 for the 2 arch ones, 3 for i386 [03:21] When did this happen? [03:21] *2 per arch [03:21] Cause I've seen two ppa builds on the powerpc buildds before. [03:21] infinity: a year or so ago? [03:22] infinity: I'll only be using one PPA [03:22] it's per PPA [03:22] If you're sure you'll only eat one ppc buildd, go nuts. :P [03:22] I wasn't aware of this new shiny. [03:22] yeah, I'm sure :) [03:22] Of course, the kernel ppa will come bite me anyway. [03:22] I can't speak for the kernel team, anyways, my builds should only be 1.5 hrs at most on PPC [03:23] infinity: and since I don't need them until next week, I won't be upset if someone kills it [03:23] Mmkay. [07:58] ah, seems the netsplit has been fixed, according to global notice [07:58] jibel: so seems we can continue talking here [08:23] jibel, ev, cjwatson: I debugged bug 854717 and suggested a workaround [08:23] Launchpad bug 854717 in ubiquity (Ubuntu Oneiric) (and 1 other project) "Broken panel icons and dialog style during ubiquity-dm and OEM install/final user configuration (affects: 2) (heat: 12)" [Critical,Confirmed] https://launchpad.net/bugs/854717 [08:25] pitti: thanks! I'll make that change momentarily. Reviewing your other patch now, though I don't think it's quite right. If you call stop_debconf while a page is running, you'll rip debconf from under its feet. [08:25] I'll have a think about it [08:26] ev: right, I wasn't sure whether it's correct to call stop afterwards; but as it was stopped before, it seemed safer to stop it again [08:26] unless it's safe to have it there all the tiem? [08:26] ev: I'm reading i-power source right now [08:27] ev: but it seems that i-power is pretty tightly woven to g-s-d's power plugin; unfortunately it doesn't use upower directly [08:27] and actually, I'll just disable that code path for now, as we're not actually using ubiquity/online just yet [08:27] okay [08:27] so, it's still unclear why the earlier g-s-d fails to set the theme [08:28] if I disable ubiquity-dm's g-s-d launching, I just have one, but it doesn't set the theme either, so it's not just a race between two gsd's [08:28] pitti, is there anything in .xsession-errors? the usual reason is "there is a xsettings manager already running" [08:28] hmm [08:28] seb128: partially; but see the bug trail [08:28] pitti, which is what we had in natty where the gdm g-s-d was not exiting before the session one starts for some users [08:28] seb128: /var/log/installer/dm doesn't have any messages about the g-s-d spawned by i-power [08:29] presumably becuase it's dbus activated, and thus its stdout/err isn't connected anywhere [08:29] which is a pity, as as it's a pain to see what's wrong with it [08:29] well, feel free to ping jjardon about indicator-power questions [08:29] he wrote it and he knows his stuff ;-) [08:29] oh, yes [08:30] he's on #ubuntu-desktop [08:30] at the end of the day it seems to be a g-s-d problem, though [08:30] the one spawned by i-power should be able to set the theme as well [08:30] seb128: ^ or should it? does it need to be spawned by the session, or depend on environment variables? [08:31] .. like the session dbus, perhaps? [08:31] ah, no, it's spawned _by_ the session dbus, so that's definitively there [08:31] pitti, I see no reason it should fail to set the theme [08:31] it's basically just reading the gsettings value and applying the xsettings [08:32] seb128: right; but it does [08:32] so I think that's the root of the bug [08:33] can you change g-s-d by a wrapper which call g-s-d 2>&1>/tmp/log or something? [08:33] to get the g-s-d output [08:33] bonus if you call it with --debug [08:33] seb128: nice idea [08:34] you might want to include the pid number of something in the log name if you have 2 g-s-d running [08:34] I just patch away ubiquity's g-s-d spawning [08:34] ok [08:34] * pitti has become pretty used to break=casper-bottom, hacking up the root fs, and then booting :) [08:35] ;-) === doko_ is now known as doko [08:41] ev: I love the "value set" window title of ubiquity :) [08:41] pitti: yeah, my most recent commit fixes that :) [08:41] yay copy and paste [08:42] nice === chrisccoulson_ is now known as chrisccoulson [08:51] ev, seb128: ah, see https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/854717/comments/12 [08:51] Launchpad bug 854717 in ubiquity (Ubuntu Oneiric) (and 3 other projects) "Broken panel icons and dialog style during ubiquity-dm and OEM install/final user configuration (affects: 2) (heat: 12)" [Critical,Confirmed] [08:51] seb128: so, it seems that g-s-d stays running, but doesn't do anything when it can't register? [08:52] seems like a bug, I would expect it to just exit [08:56] seb128: but even if we fix that, indicator-power would just fail [08:56] pitti, do we need indicator-power in the install mode? [08:56] so a longer-term fix would be either to make i-power use upower directly (currently discussing with jjardon) [08:56] or to start g-s-d earlier than the panel in ubiquity-dm [08:57] I would go the g-s-d way [08:57] seb128: not crucial I think [08:57] seb128: but reading the g-s-d code it doesn't seem crucial that it registers; it should just go on [08:57] it doesn't make sense to make efforts to write unity desktop code without GNOME [08:58] i.e g-s-d is a basis desktop components nowadays we shouldn't try to fight to not have to use it, it's a waste of efforts [08:58] ev: long story short, I think we can just disable libupower.so in panel.c for b2; does that sound ok to you? [08:58] pitti: works for me, will do now [08:58] seb128: I was mainly curious, as I don't think the g-s-d plugin provides anything that upower doesn't [08:58] seb128: and ubiquity-dm is a very case where we want the indicator without unity [08:59] right, just convenient apis it seems [08:59] seb128: I suspect that jjardon might have missed the existence of libupower-glib, though [08:59] pitti, well, without unity yes, but maybe g-s-d can be running [08:59] right, it should be running [08:59] cf. the other solution I suggested [08:59] start g-s-d, then the panel [09:00] that would be my preferred solution [09:00] pitti, libupower-glib, maybe he missed it, but why is g-s-d duplicating that logic rather than using libupower-glib as well? [09:00] right, uploading a new ubiquity now [09:01] pitti, it's the same person who wrote upower, gpm and the gsd power code, there is probably a reason why it's done the current way ;-) [09:01] seb128: g-s-d does use libupower-glib [09:01] pitti, but anyway, not a topic for now and there, better to take that offline with jjardon [09:01] pitti, well jjardon said the g-s-d code to copy would be non trivial so I assume it's not only a few calls to libupower-glib [09:02] seb128: yeah, as I said this wasn't meant to be a blame or a bug, I was just curious why it's using g-s-d, as I didn't see a real reason to [09:02] pitti, should be let some of small applications in if we are going to respin? [09:02] things like eog, etc [09:02] or better to after beta2? [09:03] I let oneconf in, as this was small and focused [09:03] but now we have about zero margin for errors :/ [09:03] ok [09:03] seb128: if you have something in the queue which fixes a major bug and has a safe fix, that's fine [09:03] checking the queue [09:04] pitti, couchdb-glib would be nice [09:05] it fixes contacts syncing I think [09:05] hm, no bug for this? [09:05] seb128: we won't respin alternates, BTW [09:06] ok [09:06] is couchdb-glib on the CD? [09:06] no bug> hum, right, I just saw that rodrigo fixed it and chrisccoulson tested the fix yesterday [09:06] seb128: ah, seems not; so shoudl be fine [09:06] * pitti accepts [09:06] danke [09:07] pitti, everything else doesn't seem worth taking the risk [09:07] so better to delay the others to after beta2 [09:07] *nod* thanks for checking [09:07] ev: seems the window title fix is not in that upload? [09:10] ev: if that's intended it's fine, the upload looks good; just wondering whether there was something wrong with a commit [09:13] slangasek: ack, when my brain is working well enough to understand openssl code, I'll take a look [09:14] * pitti accepts ubiqity, to give it a chance to build before the next publisher [09:20] pitti: the window title fix is not setting self.custom_title to the return value of self.db.set [09:21] aah ;) === s1aden is now known as sladen [10:49] pitti, when did you start the armel builds (my log has a time skew and i need to know when i need to look after downloading them) [10:50] hey ogra_ [10:50] ogra_: at 07:23 UTC, i. e. 09:23 CEST [10:50] thanks ! [10:50] ogra_: the first two builds are done, the second two are building [10:50] so its anothe 3-4h [10:50] yeah [10:50] its ~3h per arch [10:50] after that I'll build server, then kubuntu [10:50] good [10:50] ogra_: no, 1.5/2 h [10:51] then someone did something to the buildd :) [10:51] ogra_: well, the second pair could very well take longer :) [10:51] it used to be 3h/flavour for two arches [10:51] so i assumed twice the time for 4 arches :) [10:52] indeed i'm happy if its faster ;) [10:52] ogra_: yeah; what do we care if the builders sweat more now :) [10:53] oh, whoops, I just accepted isdnutils and then realised it's in the ubuntustudio package set [10:53] well, i would love to have builders in the cluster that we can just randomly assign in situations like milestones :) [10:53] hopefully we can disregard that for image preparation purposes; it was a build fix [10:53] cjwatson: also, we don't currently plan to rebuild it [10:54] but if ISDN stops working, nobody really should notice [11:09] pitti: I'd like to get kdepim-runtime in even if we can't get it on some/all Kubuntu images since it fixes a data loss bug. I'd appreciate if you would review/accept. [11:13] ScottK: looks fine, accepted [11:13] pitti: Thanks. [11:13] ScottK: no worries, I can shuffle the build queue to build kubuntu a bit later, so that this has some time to publish [11:13] Great. [11:14] ScottK: noted so on the pad [11:21] at last! ubiquity 2.7.34 [11:21] * pitti starts the build queue of doom [11:41] jibel: so what was the thing with the "total failure" you mentinoed this morning with the alternate CD? the tracker seems have successes? [11:43] mvo, jibel: FYI, I just re-enabled the upgrade tests; should work better now with cups [11:49] ogra_: desktop builds on the buildds just finished, BTW; sycamore took 4:15 hours in total, annonaceae took 3:40 [11:56] pitti, I re-ran all the tests both manually and automatically and it passed. I don't know what happened during the night, maybe an infrastructure or network problem. [11:56] I'll retry upgrades. [11:56] pitti, wow, thats a lot less than i expected (still way to long though, we will add more builds next release) [11:57] * ogra_ waits for them to publish [11:57] ogra_: they could be built on different builders perhaps? [11:57] we have two builders and four subarches [11:57] ogra_: will still take a bit, cron.daily-preinstalled is running [11:58] we already share them between two machines, but i fezar we noeed more next release [11:59] * ogra_ really doesnt want to hit 6h build times for one flavour [12:10] ideally we need something that doesn't involve code on antimony having to explicitly select a builder [12:10] I'd rather have something that dispatches to an idle builder if available and sends us a completion indication when it's done (which we would probably just block on) [12:10] in some ways it would be easier if livefses were actual LP build jobs [12:11] that would be a big enough chunk of work to require escalation through LP stakeholders though [12:17] ogra_: http://cdimage.ubuntu.com/daily-preinstalled/20110921/ [12:17] yay [12:17] * ogra_ syncs [12:17] ogra_: will we release mx5? [12:18] if so, we need a new product in the tracker, we only have imx51 (unless that's the same) [12:18] pitti, well, that rebuild was only for mx5 :) [12:18] i'll ask janimo, he owns mx5 [12:19] i know we want to release it ... [12:19] building server and kubuntu preinstalled now [12:20] http://cdimage.ubuntu.com/daily-live/20110921.1/ published for testing [12:21] jibel: can we rename "Ubuntu Desktop armel+imx51" to "Ubuntu Desktop armel+mx5"? [12:22] and there is janimo :) [12:22] hello janimo, how are you? [12:22] pitti, hi, should have the same type of testing as the omap flavours so wherever it fits in the iso tracker namespace [12:22] janimo: is imx51 == mx5? [12:23] pitti, mx5 is a more generic name for a kernel (and eventually image) [12:23] that works with mx53 and the older mx51 too [12:23] but for now we only test on mx53 [12:23] so I'll just add it as armel+imx51, and ask jibel to rename it in the DB [12:23] pitti, what we test on now is imx53 [12:24] well, the arch name is mx5 [12:24] imx51 is an older subarch [12:24] we usually use the subarch names [12:24] jibel: right, but we only have an "armel+imx51" product; as I said, we ought to rename it in the db to match the image names [12:24] ok [12:24] yeah, that should be fine [12:24] janimo: thanks [12:24] pitti, thanks for adding it :) [12:24] janimo, you will need a tracker account btw (since you will liekly want to note down test results) [12:25] ogra_, I knew there was a trap somewhere when you asked whether I want it to be on the tracker :) [12:25] haha [12:25] yeah, it was a diplomatic trick ;) [12:26] but seriously, the person owning a subarch should indeed have a tracker account to note down test results :) [12:27] I did not intend to own it, just for it to be on the tracker. But yes, I'll get an account [12:27] you should tell david :) [12:27] i think he assume you own it [12:27] *assumes [12:29] well my panda is fried, I guess I was bound to get closer to my MX53 [12:29] pitti, I'd rather add a new product, it is a preinstalled image and test case is different from the former imx51 [12:30] jibel: ah, ok; do we already have defined test cases, or do we just copy the ones from ac100/omap? [12:32] ogra_, is the testcase for mx5 http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage like omap/ac100 ? [12:33] its the same desktoip testcase for all desktop images [12:33] (we dont build mx5 server or other images) [12:33] jibel, janimo, ogra_: ok, I delete the imx51 image from the tracker then, don't get scared [12:33] * ogra_ wont :) [12:40] Actually, AIUI our mx5 is mx53 only now, so calling it mx51 would be a mistake. [12:42] added product ubuntu desktop mx5 and posted build 20110921 [12:42] jibel: cheers [12:43] infinity, cjwatson, skaet: FYI, I just updated publish-image-set.py for the armel architecture list du jour, so please bzr update before you run this [12:43] pitti: Would you please sync thaweb 3.0.12-1 from Debian non-free. There's an upload in queue that doesn't have origin set correctly and so I'd rather get it done as a proper sync. [12:43] ScottK: ack [12:43] Thanks. [12:43] ScottK: did you already reject it? [12:44] pitti: I did. [12:44] * pitti can't see it [12:44] ah [12:44] ScottK: who requested it? [12:44] Just a sec [12:44] pitti: ta [12:45] "أحمد المحمودي (Ahmed El-Mahmoudy)" [12:46] stgraber: is POSTing to /qatracker/admin/addbuild (including hardcoding/scraping of milestone and testcase numbers) still the best way for a client script to post new builds to iso.qa? [12:46] ScottK: done [12:47] Thanks. [12:51] cjwatson: mvo skaet: the current workaround for the archive slew is as follows: [12:52] when ftpmaster triggers syncproxy, the mirroring script now waits 25 minutes after it finishes syncing before removing the lockfile, blocking any subsequent trigger for 25 minutes beyond the ~ 20 minutes it takes for the script to run. [12:53] this sucks, but it at least means that the triggered mirrors get a chance to get a consistent copy in their rsync [12:53] and gives us a little time to test and deploy something that will eliminate the slew entirely (COW is my friend) [12:55] could be worse, as workarounds go. thanks [12:56] that was kind of the thinking [12:56] but it does mean that if you're doing rapid & manual publisher runs, you can get out your marker and scratch out "rapid" [12:58] sadly, this is all futurespeak, since the current run started before the change to the script [12:58] You say that as if the publisher is likely to finish inside 25 minutes anyway [12:58] heh [12:59] I suspect what went wrong here was manual mirror triggers to force out ca-certificates munging [13:02] lamont: and I guess http://archive.ubuntu.com/ubuntu/pool/universe/d/diffutils/diff_2.8.1-18_all.deb being AWOL is another instance of this? [13:04] cjwatson: every instance will be one where there is a symlink between components [13:04] and any of them has a reasonable liklihood of being b0rked [13:04] * cjwatson nods [13:04] ah, I guess that mirror desync might be why the current live builds are failing? (hash sum mismatch) [13:10] pitti: verily [13:13] pitti: and at this point, I'm forecasting that it'll all be better about 40 minutes after the current (10 min old) publisher run finishes on cocoplum [13:14] lamont: that sounds fine, thanks; I'll just run the cron.daily-live's then [13:16] verily> have I mentioned a friend of mine's suggestion for fixing the problem that True/False Yes/No etc. don't line up in source code? [13:16] which was to use VERILY and NOWISE [13:17] and this has the bonus that it allows for tristates: VERILY NOWISE MAYHAP [13:17] cjwatson: LOL [13:18] and OHCRAP for error conditions [13:18] not quite in the right register, I feel :-) [13:18] cjwatson: that must be from the FORTH age [13:18] although I always liked dpkg's error function naming [13:18] heh, yes [13:19] fortunately few people ever see this [13:20] ohshit for die-with-error-message; ohshite for die-with-error-message-and-errno [13:21] http://cdimage.ubuntu.com/ubuntu-server/daily/20110921/ posted (including arm) [13:21] Daviey: ^ FYI [13:22] cjwatson: your last one violates your 6 character specification... maybe switch to latin? [13:22] heh [13:23] stgraber: oh, and do you think it's generally better to hardcode testcase numbers (e.g. 114) or testcase names (e.g. "Ubuntu Server EC2 EBS (Europe) amd64")? [13:27] good morning, sorry for being a bit late my ISP decided to change my IP and so I had to spend half an hour updating DNS/IPSEC/IPv6 so that I get something working again... [13:29] cjwatson: testcase number shouldn't change as often as the name. Using /addbuild is currently the best way of doing it when you don't have access to limequat.canonical.com [13:29] just thinking of writing an autoposter for cdimage [13:29] cjwatson: otherwise, I guess we could run a small service on limequat that pushes new entries directly in the DB (with a small internal only service) [13:29] I guess that means hardcoding a load of testcase numbers in cdimage code? [13:31] presumably we should also have a role user for cdimage [13:31] why do you need testcase number? don't you just need product number and milestone number? [13:32] oh, nevermind just read the backscroll properly ;) you're indeed talking about product number (though as testcase number) [13:32] so yeah, using the product number "Ubuntu Alternate amd64" should be safe and a lot more readable [13:33] it's called "isota_case" [13:33] these don't change too often and when they do, they're usually different enough that you'd want to check your code anyway [13:33] but right, I mean products [13:33] they just changed a few hours ago, btw (imx51 -> mx5) [13:33] and we did some changes during beta-1, too [13:34] publish-image-set.py has quite some bzr history for these [13:35] is heimdal on the images? or could it be approved? change to the -dev package only [13:36] pitti: from cdimage's point of view, mx5 was already a different product from imx51 [13:37] and in that case, we got a new product number as well as a new product name, anyway [13:37] so that's moot [13:40] ev, http://paste.ubuntu.com/694452/ any idea ? is it because we dont have an oem user on armel ? [13:41] (looks like it treis to query NM) [13:41] cjwatson: http://paste.ubuntu.com/694453/ [13:41] cjwatson: I guess that's something I'd need to export whenever I get an API into that thing :) [13:41] ogra_: already fixed in the new ubiquity [13:41] bah [13:41] then thats not in the current armel build [13:41] pitti,^^^ [13:42] ogra_: erk, you need ubiquity on the preinstalled ones? [13:42] ogra_: sorry, then we need a respin [13:42] so far my mental model was "no ubiquity for preinstalled" [13:43] pitti, yes, all preinstalled (including server) use oem-config [13:43] which nowadays is ubiquity :) [13:43] * ogra_ wonders who said we dont use it [13:44] there were cases of ubiquity bugs where in previous releases we didn't need to rebuild the armels [13:44] but presumably because of bugs which didn't affect oem-config [13:44] yeah, but thats just because they didnt affect arm [13:44] or oem-config, right [13:44] the fun is that i just got a success report from a user for the same image [13:45] the error doesnt look like he could have gotten past it [13:45] ogra_: it only crashes if you are offline [13:45] if you are connected to a network, it works [13:45] so it's quite possible [13:45] well, given i have wlan and it crashes before i get even access to NM ... [13:45] he might have a faster system (my rootfs goes to very slow USb media) [13:46] I disabled the ubuntu desktop armels in the tracker [13:46]