[00:00] xnox: I'm sad you left #kubuntu-devel :( [00:02] are we not kool enough for you? [00:03] https://launchpad.net/~xnox - Not Canonical - Joined 8 hours ago [00:03] shadeslayer_: ^ [00:05] that is ... news to me === timrc-afk is now known as timrc === kklimonda_ is now known as Guest58839 [01:11] ~not-kubuntu-community? [01:12] shadeslayer_: Laney: well most of my discussions on #kubuntu-devel were about ubiquity, which well should be taken to #ubuntu-installer or here =) [01:15] :P === catbus1 is now known as catbus1-afk === arrrghhh is now known as arrrghhhAWAY [03:27] Good morning [03:27] hey pitti [03:27] Laney: err, are you already aware or still? === catbus1-afk is now known as catbus1 [03:28] Laney: oh, you're in China I suppose/hope :) [03:29] pitti: 是的，我在中国 [03:29] Laney: bless you [03:30] 今天是最后一天 [03:30] :) [03:31] pitti, nihao [03:32] pitti, 你好 [03:32] this guy can type Chinese [03:32] I just copy and pasted [03:32] compose key? or with google translate? [03:32] yeah, I just keep forgetting to press space before enter [03:32] he's set up the input method [03:32] pitti, pinyin input method [03:33] pitti: next time you don't need to ask me about that anymore, :) [03:34] pitti, but you can ask happyaron about security [03:34] happyaron: heh; well, I'd expect *you* to be familiar with pinyin, nice to see that seb128 picked up some of it! [03:34] 你好小猫 [03:34] pitti: I'm familiar with that, but seb128 is good now [03:43] seb128: oh yeah let's ask stephan about security. [03:44] happyaron, yeah, you need to learn for next time :-) [03:44] yes [03:44] LOL [05:06] c [06:44] good morning [06:44] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [06:59] xnox: probably they just removed that feature in 2012 :D [07:01] sarnold: darn, time to switch to hexchat [07:08] dpm, wgrant: didn't LP translations have some functionality to search for a string? [07:09] I see some untranslated ones for current touch images, and wanted to add them, but I'm not sure which template they are from [07:09] morning pitti, there's no cross-template search functionality, unfortunately [07:09] pitti, which strings are they? [07:10] dpm: for now, the bubble dialog when you connect to a wlan in the wizard [07:10] dpm: I just started testing the current images for German (now that we have fresh langpacks) [07:10] dpm: and it seems easiest to just fix stuff rather than filing bugs for everything (unless they aren't translatable, of course) [07:11] dpm: I suppose it's indicator-network or something, but I seemed to remember that someone showed a "search" thing [07:12] pitti, my hunch would be either ubuntu-system-settings (where the other wizard strings are) or indicator-network [07:12] dpm: right, but there doesn't seem to be a *system-settings* template [07:12] I have https://translations.launchpad.net/ubuntu/utopic/+lang/de?batch=250 and https://translations.launchpad.net/ubuntu/utopic/+lang/de/+index?batch=250&memo=250&start=250 [07:12] pitti, the only search you can do is on an individual template basis. It's ubuntu-system-settings ^ [07:12] so that I see all domains on two pages [07:13] pitti, you can try http://projects.davidplanella.org/stats/utopic/de - that'll give you the phone domains only [07:14] dpm: ah, https://translations.launchpad.net/ubuntu/utopic/+source/ubuntu-system-settings/+translations doesn't have templates [07:14] dpm: which might explain why it's not on the list above [07:15] pitti, ah, it does, but on the upstream project. It's not on the list above because I only show untranslated templates [07:16] it might need the x-ubuntu-langpack thing [07:16] dpm: I mean on the two URLs I posted [07:18] pitti, yeah, you'll have to look at upstream, but we should add u-s-s to the langpacks at some point - https://translations.launchpad.net/ubuntu-system-settings/trunk/+pots/ubuntu-system-settings/de/+translate?show=untranslated [07:20] dpm: ah, so these are from packages which still didn't enable the X-Langpack thingy [07:20] exactly [07:20] dpm: ok, so we generally use the upstream translations, not the ubuntu ones [07:21] dpm: http://projects.davidplanella.org/stats/utopic/de looks nice! [07:21] dpm: that means that system-settings is already fully translated, so the thingy I see is either not from system-settings, or the strings aren't translatable [07:22] dpm: ignore me, it says "System settings"; I'm blind :) [07:22] pitti, it's not, the page updates daily and there were new strings added yesterday [07:22] let me refresh the stats... [07:24] yay timeout errors [07:25] and I keep getting them :/ [07:26] https://translations.launchpad.net/ubuntu-system-settings/trunk/+pots/ubuntu-system-settings/de/+translate?show=untranslated&memo=10&start=10 [07:35] dpm: hm, so pretty much every page times out, but at least it seems most of my updated translations come through [07:36] Oh for new database serves [07:36] *servers [07:36] wgrant: is there some DB or HW update in progress, or some regression in the code? [07:36] pitti, yeah, the timeouts are really horrible, so I'm looking forward to the new SSDs in LP to mitigate them [07:36] The machines actually have an operating system on them ... [07:36] pitti: There's a large update in progress as part of widening a librarian-related column to 64 bits [07:37] But translations was just over the edge of doom anyway [07:37] also, the English original strings are sometimes really horrible [07:37] cjwatson: ah, thanks [07:37] https://rt.admin.canonical.com/Ticket/Display.html?id=67926 [07:44] pitti: Translation searhc is absolutely dreadful, but as Colin says we have hardware coming up to fix that, and it's worse than usual for the next few hours while we performance some unrelated database migrations. [07:44] wgrant: search actually works fine, I'm talking about https://translations.launchpad.net/ubuntu-system-settings/trunk/+pots/ubuntu-system-settings/de/+translate?show=untranslated&memo=10&start=10 [07:44] wgrant: these time out in almost all cases [07:45] wgrant: but thanks for the heads-up, no worries! as long as there's something known that slows it down :) [07:45] Ah, that's suggestions being terrible. [07:45] SSDs should resolve that, fingers crossed. [07:47] * xnox uses all ppa builders for a little bit =) it's nice that there are a few of them, and they are fast [07:48] xnox: And should be more soon ... [07:48] also, that they have a post-hardy kernel [07:49] (Well, the capacity for more, at least) [08:12] dpm: ok, fun like https://code.launchpad.net/~pitti/ubuntu-system-settings/i18n/+merge/230062 :) [08:13] pitti, ah, nice! That was bug 1350921 [08:13] bug 1350921 in Ubuntu Translations "Developer mode translations are cut off" [Low,Triaged] https://launchpad.net/bugs/1350921 [08:14] dpm: oh thanks, you linked the MP? [08:14] yep [08:14] dpm: I'm glad that I asked you [08:15] pitti: Hey. [08:15] hey jpds_ === jpds_ is now known as jpds === jpds is now known as Guest15370 [08:16] pitti: How goes? [08:17] Guest15370: pretty well, thanks! and you? (I liked your previous nick better) [08:17] Yeah, Freenode happened. === Guest15370 is now known as jpds_ [08:17] pitti: I was wondering if you could push https://www.libreoffice.org/bugzilla/show_bug.cgi?id=33461 upstream. [08:17] bugs.freedesktop.org bug 33461 in general "Allow extra mount options from udev rules" [Enhancement,New] === psivaa-afk-bbl is now known as psivaa [08:19] jpds_: I add it to my TODO list (NB I'm on holiday next week) [08:19] bdmurray, pitti: so I'm chasing the reasons why my whoopsie smoke test isn't working correctly on the CI infrastructure, and have just filed bug #1354318 after talking with ev; feel free to double-check my reasoning [08:19] bug 1354318 in apport (Ubuntu) "whoopsie-upload-all has a wrong check for whether the upload is done" [Undecided,New] https://launchpad.net/bugs/1354318 [08:20] panda|z: Excellent, thank you. [08:23] bdmurray: and fwiw, from bug #1235436, it looks like this is something of an about-face on my part, sorry about that ;) [08:23] bug 1235436 in apport (Ubuntu) "/etc/init/apport-noui.conf is non-functional on the phone" [Critical,Fix released] https://launchpad.net/bugs/1235436 === vrruiz_ is now known as rvr === Sweetsha1k is now known as Sweetshark [08:43] xnox: any luck with ubiquity? [09:19] pitti, hey, re: unity8 .pot, that won't get pulled in to trunk, so won't end up in translations.lp anyway, will it? [09:20] Saviq: it will for the Ubuntu package translations (not upstream) [09:20] Saviq: but that way you can at least translate missing strings somewhere, and translation sharing will also copy them to upstream [09:21] pitti, right, but will make us even less careful about pot updates [09:21] pitti, we don't have https://translations.launchpad.net/ubuntu/+source/unity8 configured though, should it show up there? [09:21] Saviq: ah, if we don't use it, I'm happy to revert that part [09:22] pitti, one thing we were planning to do for a few generated things is to have a pre-push hook that would warn you in case your .pot is out of date [09:22] Saviq: I see out of date pots pretty much everywhere :( [09:22] Saviq: ah, that'd be great [09:22] pitti, just never got around to it [09:22] pitti, obviously CI could warn, too [09:23] pitti, so what we could do now is have a test that fails if .pot is outdated [09:23] and then the -ci run would complain [09:24] Saviq: ok, I deleted that commit and updated the MP [09:24] Saviq: so it's just the .pot update now [09:24] pitti, k, thanks [09:28] Saviq: ATM there doesn't even seem to be a standardized way to update the pot? [09:28] pitti, indeed, is there such a convention in Ubuntu? [09:29] Saviq: yes, dh_translations usually figures it out [09:29] but that won't help for upstream projects/branches [09:29] pitti, I just now thought I'd quite like the train to have a hook system where we could tell it to do that before building [09:29] pitti, this way each release would get an updated .pot pushed to trunk [09:29] and all would be golden [09:30] Saviq: autotools with intltool and also cmake have some standard invocations, though [09:30] pitti, yeah, we're using cmake's gettext support, but it's far from ideal [09:30] Saviq: right, but that still needs an automatic way to build the pot, before you can check for a diff? [09:30] pitti, oh well, we have the target [09:30] pitti, make pot_file [09:31] pitti, the hook we'd maintain [09:31] pitti, we had to do http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/po/CMakeLists.txt to get it to work with cmake's gettext support [09:31] ultimately ended up invoking the commands ourselves... [09:33] pitti, so I'm thinking scripts in citrain/ or so that would get run at certain points in the build process on the train / airline [09:33] without special knowledge of the train, just executables [09:49] infinity: want to merge openldap per chance? =) === doko_ is now known as doko === jamespag` is now known as jamespage === tvoss is now known as tvoss|errands === MacSlow is now known as MacSlow|lunch === tvoss|errands is now known as tvoss === lool- is now known as lool [11:55] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [12:11] xnox: no need to look at that ubiquity bug, I've fixed it, it was a issue in sddm [12:15] xnox, no openldap merge? === Riddelll is now known as Riddell [12:22] doko: nah, i want to drop gnutls26 from main (as promised to security team by debian import freeze....) [12:22] so didn't look into merging openldap proper. [12:24] * mdeslaur hugs xnox [12:25] mdeslaur: i think rtm branching is in progress, not sure if rtm will end up with gnutls26 however =/ [12:25] & gnutls28 [12:25] xnox: I don't support rtm, so I don't really care :P === MacSlow|lunch is now known as MacSlow [12:27] ubuntu-archive@snakefruit:~$ grep gnutls derive-ubuntu-rtm.script [12:27] gnutls26 2.12.23-15ubuntu2 [12:27] gnutls28 3.2.16-1 [12:27] sorry :) [12:27] hehe === greyback is now known as greyback|lunch === greyback|lunch is now known as greyback [13:35] pitti: Around? ubuntu-rtm is initialising on production now, so it would be a good time to flush the ubuntu-rtm ddebs stuff from dogfood and repoint it at production. [13:36] pitti: IIRC I gave you the necessary URLs, but let me know if you can't find them [13:39] stgraber: Heads-up: we'll want to configure system-image for ubuntu-rtm on production a bit later today === _salem is now known as salem_ [14:03] pitti, sergiusens rsalveti and i are looking at SD card mounting on phones ... i know there is an easy way to query udisks2 to know if a disk is removable ... is there anything like that for udev too (i cant see anything in the env vars) === jonobacon is now known as jono [14:04] ogra_: oh, you want to forward up only the removable ones? i c now :) [14:04] yeah [14:05] dont fire up stuff for HW we dont want to touch anyway [14:05] pitti: and to follow on to that mediascanner uses GVolumeMonitor but /media/$USER doesn't exist on startup (or potentially doesn't) so mediascanner just gives up [14:11] cjwatson: looks like rtm is a full blown distro =) it has auctex -> so it must have both emacs and texlive \o/ [14:11] also thanks for accept spam =) [14:12] ah, I see email is already reported in #ubuntu-release [14:13] xnox, wait, emacs ? we need to drop that for vim-full-blown :) [14:15] xnox: Yeah, sorry about the accept spam, it only covered the first few dozen packages before we noticed [14:15] ogra_, I leave you for one month [14:15] emacs? [14:16] I'm pretty sure it's just a build-dep somewhere :) [14:16] heh [14:16] yeah, we definitely dont ship it [14:16] it really doesn't take a lot of runtime to pull in a thousand packages in the full build-dependency closure [14:50] cjwatson: hey [14:51] cjwatson: what was the archive URL again? I only have derived-archive.dogfood in my browser history [14:52] sergiusens: /media/$user is created by udisks, but perhaps /media is readonly? [14:52] pitti: http://derived.archive.canonical.com/ubuntu-rtm/ [14:52] sergiusens: the upstream mode of udisks2 is to use /run/media/user/ which would work much better for the phone; but there were objections to breaking LSB compatibility, so we patched it for /meida/ [14:53] pitti: yeah, sorted the issue, /media was fine, was missing /var/lib/udisks2 and starting mediascanner a lot further in the boot process [14:53] thanks! [14:53] /run would be easier [14:53] less mounts [14:54] cjwatson: hm, did we build any package there today? I just ran it, and it didn't see anything [14:54] cjwatson: so it didn't build any indexes either [14:54] pitti: We haven't built anything, just copied [14:54] cjwatson: ah, ok [14:54] pitti: There are indexes though [14:55] cjwatson: yeah, by default it only rebuilds the indexes of pockets that it got ddebs for [14:55] pitti: Do we need to link ddebs over from ubuntu or something? [14:55] cjwatson: gee, I hope not; IMHO this should stay an overlay archive [14:56] oh wait, you said there was no guarantee of version non-clash [14:56] it also comes in handy that I need to disappear in about 20 minutes.. [14:57] cjwatson: anyway, I'll let it run like that for now, so it won't lose anything; we can switch from overlay to "full copy" in a week, too [14:57] pitti: It's explicitly not an overlay archive, because it has to be disconnected from ongoing development in Ubuntu [14:58] pitti: That's the entire reason we're doing a derived distribution rather than a PPA [14:58] ack [14:59] pitti: We'll *probably* be OK for version non-clash provided that direct uploaders don't do anything stupid [14:59] pitti: Since CI Train generates package versions based on the series version, and that happens to differ right now [14:59] for one week, anyway [14:59] For the lifetime of this series [14:59] no, I mean not having a full copy should last for the next week [14:59] But yeah, it's not guaranteed. And maybe we will have prodstack4 and unicorns soon [15:00] Oh, err [15:00] Would you mind if I got slangasek to link things around next week? [15:00] I'm a bit worried about losing things [15:00] no, of course not [15:00] OK, cool. A hardlink farm would be OK? [15:00] yes, I guess so [15:00] I think we need to make a cp -al of www/pool/ to www/ubuntu-rtm/pool/ [15:01] then run it once with building indexes, and let the archive cleanup take care of throwing out anything that's not needed [15:01] that'll probably runs for a few hours [15:01] Hm, OK [15:01] slangasek: ^- for early next week [15:02] pitti: Hi Martin, did you see the last comment at bug #1090288? [15:02] bug 1090288 in langpack-locales (Ubuntu) "The locale file for en_ZA appears to have an error" [Undecided,Confirmed] https://launchpad.net/bugs/1090288 [15:02] cjwatson: cp -al running now [15:03] today is a good day for that [15:03] * pitti packs in the meantime [15:03] Oh marvellous, thanks [15:03] I'll remind slangasek next week to check on it [15:03] Maybe eventually the derived archive publisher will finish [15:05] cjwatson: http://ddebs.ubuntu.com/ubuntu-rtm/pool/ is a full copy now [15:05] INFO: Building indexes for 14.09 [15:06] pitti, /medis is explicitly writable now [15:06] GunnarHj: sorry, -ENOTIME [15:07] pitti: Ok, it can wait. [15:07] pitti: Great, thanks [15:07] pitti, our prob is that there can be android partitions (firmware etc) that are vfat and udisks tries to mount ... we'd like to make sure we only mount removable devices [15:07] ogra_: udisks doesn't try anything; that'd be the gvfs monitor [15:07] (additionally to the mediascanner issues) [15:08] ogra_: we could change the polkit policy to disallow non-removable devices [15:08] pitti, no, thats a new tool from sergio [15:08] pitti, ciborium is our SD card only - phone- mount manager [15:10] cjwatson, slangasek: crontabs for ubuntu-rtm are set up, there you can see the full command (it's also in .bash_history, of course, with --verbose instead of --quiet) [15:15] pitti: thanks a lot [15:15] cjwatson: argh, re-running; forgot to copy the apt-ftparchive cache [15:19] dpm, hey, we encountered a thought today: we seem to be missing a convention on when/how/where to run .pot updates [15:19] dpm, KDE has a messages.sh script in the root of all projects, so tooling automagically runs those to update the templates [15:20] dpm, very many of our projects lack updated templates due to it being an easily forgotten step [15:20] cjwatson: screw it, db copy didn't help [15:20] cjwatson: presumably because the paths are differnet [15:20] cjwatson: so this will run for looong [15:20] Saviq, +1000, I was having a conversation about it yesterday with some folks in a bug thread [15:20] cjwatson: I'll check on Sunday [15:20] * pitti waves good bye, gotta run [15:21] dpm, can you come up with a convention and start forcing people to use it? :D [15:21] Saviq, I think the only challenge here is do do only updates if the contents of the .pot file changes, and ignore changes that just update the date field [15:21] dpm, then we can make the train run that after merging all branches [15:22] dpm, yeah, I agree we shouldn't run on every MP, it's just wasteful [15:22] dpm, but then line numers in comments do make sense [15:22] cjwatson: ok [15:22] Saviq, sure, I'll think of something and I'll run it past you and other folks. It will save me a lot of work filing bugs and chasing devs :) [15:22] dpm, so I'm thinking that if we left it to whatever actually releases the code (train in our case) [15:22] dpm, runs it before creating the tarball [15:23] dpm, I think at that point it doesn't even matter if only the date changed [15:23] dpm, most of the time a lot of line numbers will change as well [15:23] stgraber: May be a bit later, still waiting for the publisher to finish and I'll need to sort out image building after that [15:23] stgraber: So I'll leave you a message [15:24] Saviq, sounds sensible and doable [15:25] dpm, loop in sil2100 so he knows what to run :) [15:25] cjwatson: ok, sounds fine, I'm around for another 6 hours and 30 minutes :) [15:25] Saviq, ack, thanks. Another somehow related question I've not found the answer for yet: do you know which project in LP shows the reboot/shutdown dialog after the on/off button longpress? I'm trying to find out where to file the bug to flag that it needs internationalization [15:26] dpm, unity8 [15:26] aha [15:26] dpm, indeed, they're not i18n'd, let me fix that quickly [15:26] What where? [15:27] Saviq, ok, cool [15:27] sil2100, let's catch up on Monday on how to automate translation template updates with the ci train [15:27] dpm: ah, ok, sure :) [15:28] dpm, another reason to only do it on tarball creation... conflicts [15:28] it's basically a sure way to get yourself fooked if you update the template on every MP [15:29] ack [15:31] dpm, actually that's the reason why i18n'ing the dialog will have to wait a moment as we have a branch updating the .pot, and another updating the dialog itself, so we're screwed like that if we don't start prerequisiting branches ;) [15:31] dpm, this branch https://code.launchpad.net/~paulliu/unity8/reboot_140728/+merge/228485 will include the i18n changes needed [15:32] perfect === arrrghhhAWAY is now known as arrrghhh [15:36] Saviq, and I've got another unrelated question. Normally I'd ask mterry, but he doesn't seem to be around. We've got some tests failing on Jenkins (i.e they're run on a desktop, not a device) in file manager because they expect (I think) a .service file that is missing. Would you happen to know which package contains it? -> http://pastebin.ubuntu.com/7989673/ [15:37] dpm, that service is provided by unity8 [15:38] oh, so we'd have to install the unity8 package on jenkins to make the tests runnable [15:38] dpm, http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/plugins/LightDM/DBusGreeter.h [15:39] Saviq, if we just add a dependency to install unity8 for the tests to run, will that interfere with the regular session in any way? [15:39] dpm, that might not be a great solution, though [15:39] dpm, the service will not work unless unity8 is running [15:39] bummer [15:39] dpm, we should probably rather remove the dependency of those tests on UnityGreeter [15:41] I'm not very familiar with the code, so I don't know if that'd be a big task or if there is an alternative [15:41] dpm, yeah, unless there's a unity8 session going, nothing should depend on that service, please throw anyone who knows what's happening there our way on Monday [15:42] ok, thanks Saviq === dpm is now known as dpm-afk [16:47] rbasak: HWE upgrades and full series upgrades really don't relate. [16:49] infinity: except that the HWE EOL notification advises a full series upgrade. [16:50] rbasak: Ahh, fair point. Well, we should be flipping the switch soon anyway. [16:50] infinity: OOI, is there a particular reason why users shouldn't update to 14.04 anyway, other than the switch not being flipped? They keep asking. [16:50] bdmurray: I've lost track over the last few days, are we still tracking a potential blocker for adding trusty to meta-release-lts? [16:51] rbasak: There were a few update-manager bugs that made the upgrade explode. Those should be fixed. [16:51] infinity: OK, thanks. [16:51] rbasak: But there's no reason people shouldn't be running 14.04. [16:52] rbasak: And the majority of the more explody bugs probably also shouldn't affect server users, whose upgrades tend to be much simpler and smoother. [16:52] infinity, agreed - I was able to 'force' the update on a VM without any issue. I also upgraded my 12.04 system to the trusty kernel so that HWE message would go away :) [16:55] rbasak: Anyhow, if people are worried that there's something wrong with trusty, or the lts-trusty HWE stack, you can put their minds at ease. The real problems are/were latent bugs in precise that make the upgrade to trusty have a sad. Trusty itself is mostly awesome. [16:56] infinity, for me, it was the meta-release-lts page not being updated... and no real explanation, but I wasn't really sure where to look for an explanation... [16:57] infinity: I still need to double check those couple of bugs I found. Some recent error tracker changes took longer than I thought they would. [17:02] bdmurray: Right, well we probably don't want to flip it on a Friday anyway, but if all looks good for Monday, let's do it. [17:03] arrrghhh: I've had more than few nearly hysterical complaints about it, sadly, but there was a reason I put the word "soon" in the release announcement instead of "now". [17:04] infinity, trying to not be hysterical lol. just was curious why the drop didn't happen at the prescribed date... I just posted a comment in a launchpad bug [17:04] https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1344762 [17:04] Launchpad bug 1344762 in update-notifier (Ubuntu) "update-notifier tells me to upgrade from 12.04.4 LTS to 14.04 LTS (because of HWE), but that release is not found" [Undecided,Confirmed] [17:05] I actually ended up hosing my 12.04 system up pretty badly, which I am still scratching my head on... so I just clean installed 14.04. Working well :) === ricmm is now known as ricmm_ === ricmm_ is now known as ricmm [18:04] xnox: You'd talked about some race condition and Contents.gz before right? [18:07] bdmurray: yes. i wanted to fix it by (a) cutting down the time to generate contents.gz (patch sent to mvo) (b) make launchpad use it (no patch sent) (c) make publisher copy new contents.gz in place from contents-generation, instead of the other way around - contents-generation dropping new contents into place hopefully before publisher decides that old one is obsolete one. [18:10] xnox: okay, thanks for the update === Ursinha is now known as Ursinha-afk [18:32] infinity: upgrades look fine to me but you want to hold off until Monday correct? [18:33] bdmurray: Yeah, Monday morning is fine. Just want to have people around to deal with panic if we're wrong about being ready. === roadmr is now known as roadmr_afk [18:35] infinity: got it === cmagina_ is now known as cmagina === roadmr_afk is now known as roadmr [19:53] barry: still around? [19:53] bdmurray: yep! [19:55] barry: I've a gdb (I think) question. So apport retrace calls gdb like so http://pastebin.ubuntu.com/7991534/ and I clearly see a warning from gdb about the core file size. Do you know how I can get to generate that warning? [19:56] I ask because apport-retrace just writes a new crash report without any information about that warning. [19:58] bdmurray: probably ran out of disk space while writing the core file, or there's a ulimit that truncated it. [19:58] barry: right, I understand that. I just want to log / record this warning / error somehow. [20:00] bdmurray: ah, i see. off the top of my head, i'm not sure how you can capture that, other than stdout/stderr grepping. === Ursinha-afk is now known as Ursinha [20:01] bdmurray: there's probably a way to mimic the inspection that gdb does, but not sure how to do that off the top of my head [20:01] barry: okay, I was hoping for some show or info command that might help [20:01] bdmurray: let me poke around on the gdb docs for a few minutes. i'm running some long tests. :) [20:04] bdmurray: nothing obvious that i can tell [20:06] barry: thanks for looking, I found where apport throws away the Warnings [20:07] cool [20:27] stgraber: OK - what will happen to system-image if I delete the current ubuntu-rtm tree and start again? [20:28] cjwatson: so wiping all entries in /srv/cdimage.ubuntu.com/www/full/ubuntu-touch/ubuntu-rtm/14.09/daily-preinstalled/ and then publishing some new ones? [20:28] Right [20:28] it'll do fine [20:29] Actually just the whole ubuntu-touch/ubuntu-rtm tree [20:29] assuming the new one will have a version number higher than the current latest one [20:29] stgraber: We should make sure it restarts in a fresh channel, I think [20:29] yeah, I can wipe the rtm channel too, that's easy [20:29] stgraber: I know you had Opinions on naming and such, I'll leave it to your judgement [20:29] We shouldn [20:29] 't need the dry-run staging channel any more [20:30] Wasn't meant to stick around :) [20:30] ah right, I can kill stable-staging-proposed [20:30] stgraber: OK, so I'll wipe that now and kick a fresh build [20:30] ok, I'll destroy the s-i channel now too [20:32] so IIRC what I suggested was to import ubuntu-rtm/14.09/ into a rtm-14.09-proposed channel, which can then feed an rtm-14.09 channel once testing has passed which can then feed the stable channel (or if we are confident enough, we can just make stable an alias of rtm-14.09) [20:32] Running, fingers crossed [20:32] I don't think we need to have two layers of feeding there, one should do [20:32] An alias makes sense [20:33] yeah, the two layers always felt weird to me but that was a request from asac, so I'll leave that up to him [20:33] turning stable into an alias channel again should be trivial anyway [20:35] cjwatson: what device images should I expect with the new cdimage build? still the same set for now? (flo, generic, grouper, mako, manta, generic_x86) [20:35] Believe so [20:35] ok, going with that for now then [20:36] OK, please argue the feeding out with asac when he's back [20:36] hmm, actually I'll drop grouper from that list, for some reason we still build the android bits, but that's not supported at the moment [20:39] stgraber: OK, that's actually building now that I've fixed it. We should possibly configure an iso.qa target ... [20:40] cjwatson: what's the cdimage incantation for it? [20:41] For the build? [20:41] yeah [20:41] DIST=ubuntu-rtm/14.09 for-project ubuntu-touch cron.daily-preinstalled --live [20:42] Except I need to upload a suitable keyring to ubuntu-rtm [20:43] ok, so we'll need a series called ubuntu-rtm/14.09 on the tracker and then triggering the usual touch product from there should work [20:44] actually, let me also redo the system-image config to match what we're doing on cdimage and the tracker, that is, use ubuntu-touch/ubuntu-rtm/14.09-proposed as the channel name [20:48] stgraber: Could you also set "Redirect release pocket uploads" to True and "Alias for development series" to "devel" on ubuntu-rtm? I think it's on https://launchpad.net/ubuntu-rtm/+edit [20:48] Failing that it should be on the API [20:51] not visible in the web UI, using the API then [20:51] stgraber: The series might be mangled on the way through to the tracker - I don't quite recall [20:51] I had to fix a lot of things there [20:52] >>> rtm.redirect_release_uploads [20:52] False [20:52] >>> rtm.redirect_release_uploads = True [20:52] >>> rtm.development_series_alias [20:52] >>> rtm.development_series_alias = "devel" [20:52] >>> rtm.lp_save() [20:52] Hm, it uses config.series, but I think that ought to be config.full_series, otherwise it's potentially ambiguous [20:53] * cjwatson fixes [20:54] OK, should be ubuntu-rtm/14.09 for the tracker now [20:54] stgraber: thanks === salem_ is now known as _salem === fenris is now known as Guest9525 === fenris_ is now known as Guest17783 [22:05] cjwatson: I'm EOD now and doubt I'll have enough spare time to look into getting RTM published properly on system-image until Monday though ping me anyway once you have a build. In theory the system-image config should be right and it should auto-import but it may still need some tweaking.