[00:21] jbicha: ping? [00:28] GunnarHj: hi [00:29] jbicha: Hi Jeremy! [00:29] jbicha: Saw that you removed the gcc patch 52 (languages) from the blueprint. Was it a mistake, or how are you thinking? [00:32] GunnarHj: uh I think the patch is unappliable with 3.8 [00:34] oh, never mind, darkxst refreshed it [00:34] jbicha: It is as is. Some thinks have been moved to gnome-shell etc., but someone made those mods to make it work with Ubuntu GNOME 13.04. [00:35] jbicha: Right, it was darkxst who did that refresh. [00:36] have you tried our 3.8 packaging from https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+packages?field.series_filter=raring ? [00:38] jbicha: Not yet. Have been on a hospital, etc., but as soon as my health issues are under control, I'll make myself involved. [00:40] ah ok, I'm thinking we could go with the GNOME language panel this cycle if someone could get the time to write an indicator-keyboard [00:41] Ubuntu Phone is keeping people busy this year though [00:41] jbicha: Shouldn't the language installation/removal thing be resolved also? Laney has that on his todo list, I think. [00:42] GunnarHj, I have mostly done that [00:42] jbicha: You have? [00:42] jbicha: Can it be seen somewhere? [00:42] gnome3-staging [00:43] darkxst: Is it a gcc patch, or something separate? [00:43] gcc patch [00:43] and gnome-desktop patch [00:44] darkxst: Thanks, I'll take a look soon. [00:45] it doesn't do language removal though [00:47] Hmm... People want that. Would it be hard to add the reverse of installation? [00:48] currently installation uses the PK dbus helper, but there is no such helper for removal [00:48] so removal is a little more tricky, but still possible [00:49] I guess that existing code in language-selector can be useful. Even if we drop the language-selector UI, parts of that package could serve in the background. [00:51] But it's soon 3 a.m. here, and I'm going to get some sleep. See you guys! === thumper is now known as thumper-afk === tvoss_ is now known as tvoss [05:29] thanks desrt (#701800) [05:35] hey pitti, how was your week-end? [05:36] hey didrocks; quite fine indeed, thanks! did lots of gardening, some more maths videos, and enjoyed the sun [05:36] one of these rare weekends being at home :) [05:36] didrocks: and your's? [05:37] pitti: was too short, but really good! Mostly walking within the city and a lot of cylcing when it was not running (meaning, before the evening as it started to rain both on Saturday and Sunday) [05:45] Hi pitti! [05:45] FYI, pkg-create-dbgsym does something weird with xenomai package — see build logs at https://launchpad.net/ubuntu/+source/xenomai/2.6.2.1-2ubuntu1 [05:45] (I've disabled stripping some files in -2ubuntu2 as a workaround) [05:49] pitti: comments welcome [06:13] pitti, have seen these? GVFS-WARNING **: meta_journal_iterate: found short sized entry, possible journal corruption [06:14] darkxst: yes, and it's unnerving [06:14] darkxst: colin walters fixed it a few days ago in git [06:14] https://mail.gnome.org/archives/commits-list/2013-May/msg05639.html [06:15] if hiding, is fixing! :) [06:15] https://git.gnome.org/browse/gvfs/commit/?id=eb62d9 [06:16] right, it's fixed in 1.17.1 [06:16] mitya57: hello [06:16] mitya57: would you mind filing a bug about it as a reminder? [06:21] pitti: done, bug 1189342 [06:21] Launchpad bug 1189342 in pkg-create-dbgsym (Ubuntu) "xenomai 2.6.2.1-2ubuntu1 FTBFS with pkg-create-dbgsym" [Undecided,New] https://launchpad.net/bugs/1189342 [06:22] (By the way that was a first upload I sponsored :D) [06:58] good morning [06:58] salut jibel, bon week-end? [06:58] salut didrocks , ça a été et toi? [06:59] jibel: trop court, mais bien! :) === geser_ is now known as geser [07:40] Moin! [07:41] * Sweetshark kepts his fingers crossed: LibreOffice 4.1.0~beta2 building in a ppa ... [07:42] Sweetshark: I tried that for unity tests passing, with various rates of failures :p [07:44] good morning desktopers [07:44] hey Sweetshark didrocks [07:44] hey seb128! [07:45] bonjour seb128 [07:45] * Sweetshark gives didrocks a hug about test failures and waves good morning at seb128 ... [07:45] hey Sweetshark [07:45] hey didrocks pitti Sweetshark [07:45] pitti: heya [07:45] didrocks, congrats on getting the new unity in ;-) [07:46] seb128: thanks for NEWing and reviewing all those stuffs! :) [07:46] yw ;-) [07:46] and now, even the MIRs are cleaned, happy about this! [07:46] * didrocks hugs Sweetshark back and cross fingers for him :) [07:51] * pitti still eagerly awaits NEW processing of umockdev :) [07:51] (but it's not that urgent) [07:53] pitti, I can have a look (or did you upload to Debian?) [07:53] no, to Ubuntu for now [07:53] * pitti cannot upload to Debian ATM [07:53] they still didn't follow on the key change RT? [07:54] seb128: but really, it's not that urgent, I was just teasing [07:54] not sure how regular AA is being done these days, still with archive days? [07:54] seb128: no, not yet [07:54] I can still have a look once I'm done with w.e catching up there ;-) [07:55] thanks; should be easy, same license for all files, Canonical copyright, etc. === thumper-afk is now known as thumper [08:03] pitti: are capital letters not allowed in test names? [08:03] ahoy there [08:03] mlankhorst: ah, apparently not [08:03] Test names are separated by whitespace and should contain only [08:03] characters which are legal in package names, plus `/'. [08:04] mlankhorst: we never ran into this before [08:04] hey Laney, how are yoU/ [08:04] erk [08:04] "you?" [08:05] I think the / was giving issues when I tried it [08:06] $ lintian ../xorg-integration-tests_0.0.1.20130523-0ubuntu1_source.changes [08:06] didrocks: ping [08:06] W: xorg-integration-tests source: illegal-runtime-test-name lib.libX11 [08:06] pitti: very well, thank you! [08:06] the pub had a mini music festival on saturday which was fun [08:07] veebers: pong [08:07] * mlankhorst is tempted to ignore the warning [08:08] at least report a lintian bug on it [08:10] Laney, hey [08:11] hey seb128 [08:11] how's it going? [08:11] like a monday? [08:12] happy and raring to go then [08:12] had a nice w.e, trying to kick back in "work mode" ;-) [08:12] yeah, nothing like starting the week with an hour of catching up with bug mail :) [08:12] indeed [08:13] pitti, btw I noticed that "doesn't respect lid setting" issue, and it's new since saucy for me [08:13] it was working in raring [08:13] * seb128 uses a docked laptop and closing the lid in raring was not suspending it [08:14] seb128: ah, that's something else then; that shouldn't happen regardless of the g-c-c setting [08:15] pitti, it should, the g-c-c setting as a a/c preference, that's what should be used when docked [08:15] seb128: it wasn't like that in raring, though [08:16] it was [08:16] even if you set both to "suspend" (as I usually do), it didn't suspend when it was docked [08:16] at least for me [08:16] and I think that's right [08:16] phone, brb [08:16] hum [08:16] that seemed buggy in the other way then ;-) [08:16] if there is an UI the choice should be respected [08:21] re [08:21] seb128: well, if the laptop is docked and there's an external screen, I don't expect it to suspend, ever [08:21] there was some code to figure that out [08:22] pitti, some user do, they use both the laptop screen and the external one and close the laptop lid on the evening when they cal l it a day (we received bug reports asking for that in the past) [08:22] it's just that our old g-s-d doesn't yet know about the current logind semantics of handling lid and power buttons by itself [08:22] seb128: hm, I got some bug reports in the past complaining about the suspend [08:22] yeah, that's why we have an option :p [08:22] g-s-d [08:23] seb128: we don't have an option for dock behaviour, at least I can't see it? [08:23] well, g-c-c has a "what do to on lid close when on a/c" and docked is an a/c state [08:23] anyway, we should definitively fix the behaviour of these two (i. e. not suspend when not configured so in g-c-c) [08:24] that's why I asked about g-s-d 3.8 the other day, but seems we need to backport that behaviour only [08:24] right [08:41] seb128, pretty sure 3.8 does support that [08:43] but may well be done via inhibitors from g-s [08:43] by then federico tried to do the smart behaviour pitti described [08:43] e.g https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=6e17bc786f55f283f2c721249197e7740174fd43 [08:43] but that probably changed in 3.8 [08:43] pitti, btw, that's what I remembered: https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=f10c8922ef4ead58ac0389144c2d0b16e872067e [08:44] mlankhorst: FYI, debian bug 711844 [08:44] Debian bug 711844 in autopkgtest "autopkgtest: Allow uppercase letters in test names" [Wishlist,Open] http://bugs.debian.org/711844 [08:45] pitti, https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=9c2a401f9c92307bdb5ff2baeb82b8ecbf8eadf7 is the sort of issues we will need to watch for if we update to 3.8 [08:45] "gnome-shell is now using a delay inhibitor to ensure locking happens before suspend." [08:46] not sure what happens if you don't run g-s [08:46] pitti: I just opened that ;-) [08:46] he's showing you that it got reassigned [08:47] oh that [08:47] i.e. that autopkgtest says your test name isn't allowed [08:47] yeah I wasn't sure whether the bug was in lintian, the debian spec, or autopkgtest [08:48] seb128, pitti add inhibitors to gnome-screensaver [08:50] is that a question? [08:50] or order? ;-) [08:50] seb128, its already been done [08:50] *added [08:50] oh, ok [08:51] the only outstanding issue with g-s-d that I know of is the ibus stuff [08:52] (3.8 that is) [08:54] can we update g-s-d without g-c-c ? [08:54] (I guess not) [08:57] yeah, we need to teach our 3.6 g-s-d power plugin about logind inhibitors [08:58] pitti, umockdev, would it make sense to b-d on valac rather than -0.18 | -0.16? [08:58] seb128: like, valac (>= 0.16.1)? can do, yes [08:59] I haven't tested with 0.20 yet, but I can make sure that upstream works with that [08:59] pitti, jbicha has been doing changes like that for some days to prepare the 0.20 transition [08:59] $ valac --version [08:59] Vala 0.18.1 [08:59] ah, installing -0.20 doesn't change the default yet [08:59] yeah, that's part of the transition [09:00] ok, uninstalled 0.18, works now [09:00] pitti, umockdev NEWed [09:00] seb128: merci! [09:00] pitti, you can sudo update-alternatives --config valac to change the default as well [09:00] pitti, de rien [09:01] we should take this chance to use the same alternatives priorities as Debian do [09:01] that delta always annoyed me [09:01] those numbers are a bit random [09:01] yeah, it's only the ordering that matters [09:01] it's not really a delta [09:01] it's a matter of "we updated first and picked a number and they picked a different one" [09:02] in the sense that theirs is different to ours [09:02] right, I was just saying "feel free to drop the delta there" ;-) [09:02] yeah [09:02] I'll tell jbicha about it if/when he comes on later [09:06] pitti, libumockdev-dev should depends on glib-dev since it's .pc requires it [09:06] pitti, (doing binNEW review) [09:09] seb128: added that, thanks for spotting [09:10] yw [09:10] seb128: upstream needs some tweaking for vala 0.20, working on that [09:10] (posix_extra needs to drop some definitions, my patches went upstream in 0.20) [09:10] k [09:10] binNEW done [09:10] cheers! [09:11] didrocks, Laney: ubuntu-system-settings NEWed as well btw (I pre-review for Ken friday and he got the autolanding in place) [09:11] cool [09:12] I did some packaging for my work in progress on the appearance panel [09:12] seb128: yeah, saw that, Thanks! [09:12] but we should decide on package/project names and stuff [09:12] Laney, we should also decide on what panels should be in the ubuntu-system-settings source [09:13] not sure it makes sense to split most of those [09:13] oh, I just kind of assumed it would be separate [09:13] didn't really consider it [09:13] it's like gnome-control-center, we have a few external panels where it makes sense [09:13] like ubuntuone might want to have their own tree with other part of their code [09:13] doesn't matter from a system point of view as all of the integration points can as well be used externally [09:13] or online accounts [09:13] right [09:14] seb128: fixed for vala 0.20 in https://github.com/martinpitt/umockdev/commit/681e6a04 [09:15] pitti, danke [09:15] seb128: I'll do a 0.2.5 release, adjust the build dep, and upload [09:15] then both issues will be fixed [09:15] thanks for reviewing! [09:15] yw [09:15] thanks for the quick fixes ;-) [09:15] that'll also fix the autopkgtest [09:15] I get a crash in gnome-control-center with easy steps to reproduce, bug 1188826, could anyone confirm? [09:15] Launchpad bug 1188826 in gnome-control-center-unity (Ubuntu) "gnome-control-center crashed with SIGSEGV in g_type_check_instance_cast()" [Medium,New] https://launchpad.net/bugs/1188826 [09:15] seb128: no time like the present [09:16] jibel, no segfault here [09:16] seb128: I get it as well [09:16] jibel: ^ [09:17] didrocks, great, you won the right the debug/fix it ;-) [09:17] seb128: not really :p [09:17] seb128: weird you can't reproduce it [09:17] is that only happening with appaerance? [09:17] seb128, g-c-c 3.6 could work with g-s-d 3.8 but would require cherrypicking a few patches [09:17] yeah, only appearance from the quick test I've done [09:17] darkxst, I wonder if we should do that to start, I need to look again at the number of UI changes to the new g-c-c [09:17] didrocks, (gnome-control-center:20295): gnome-control-center-unity-WARNING **: Could not fill pictures source: L'opération a été annulée [09:18] didrocks, I get that but no segfault [09:18] might be easier to just finish g-c-c, there is nothing major blocking it [09:18] (gnome-control-center:4305): GLib-GIO-CRITICAL **: g_file_new_for_path: assertion 'path != NULL' failed [09:18] darkxst, out of crap UI decisions [09:18] (gnome-control-center:4305): GLib-GIO-CRITICAL **: g_file_load_contents: assertion 'G_IS_FILE (file)' failed [09:18] didrocks, I've those as well but no segfault, anyway I will debug [09:18] seb128, yes only appearance [09:18] I've another bug to fix in there [09:19] seb128, most of the UI changes are in panels that ubuntu doesnt use [09:19] darkxst, like power? :p [09:19] yes power has changed [09:20] darkxst, well anyway I need to find some time to look at it, we might just end up have 2 sources one for 3.6 with Ubuntu patches and a 3.8 stock upstream [09:20] network, printers, region [09:20] which would make both Unity and GNOME edition happy [09:21] I would prefer to avoid have 2 g-s-d version though [09:23] you could keep 3.6 panels as external modules? [09:23] we could, but depending on the number of changes we want/don't want in 3.8 we could as easily fork 3.6 [09:25] pitti: ignoring the autopkgtest warning, does https://launchpad.net/~mlankhorst/+archive/ppa/+packages xorg-integration-tests look good to you? === tkamppeter_ is now known as tkamppeter [09:36] seb128, well let me know once you have had a look at 3.8 then [09:36] sure [09:36] thanks for the work on it! [09:37] np [09:40] mlankhorst: oh, it's just a warning, but works anyway? [09:40] mlankhorst: do you have that in VCS somewhere, or should I download and look at the .dsc? [09:43] mlankhorst: wrapped lines in debian/tests/control don't work AFAIR (or maybe jibel fixed that) [09:44] * pitti runs run-adt-test -p ppa:mlankhorst/ppa xorg-integration-tests [09:44] pitti, mlankhorst I fixed that. ipython uses it for example [09:55] pitti: not in a public git yet [09:56] Unable to locate package xorg-integration-tests [09:56] oh, it's not built yet [09:56] so I can't run the tests [09:56] oh darn [09:57] it depends on newer inputproto, it can't run with x1.13, needs the 1.14 canonical-x/x-staging ppa enabled [09:57] set a PPA dependency? [09:58] I ran the tests locally with the documentation, so I know that part works at least [09:59] pitti: it sort of requires it at runtime too, i don't know if a dependency would handle that, i can copy it to the x-staging ppa though [10:01] mlankhorst: yeah, or do that [10:02] mlankhorst: so, LGTM except the wrapping (debian bug 695797 ) [10:02] Debian bug 695797 in autopkgtest "Depends field in test control file cannot be folded" [Normal,Open] http://bugs.debian.org/695797 [10:02] mlankhorst: but if you ran it with "sudo adt-run" and it worked, fine :) [10:03] stupid glib question [10:03] how do I set a pointer to NULL when the refcount of the object reachs 0? [10:03] that's harder that it should :/ [10:04] g_clear_object() ? [10:04] oh, you mean as a kind of callback? [10:04] not sure whether that's possible [10:04] doesn't that set it to NULL in all cases? [10:04] not as a callback, notify-osd does unref objects [10:04] and then do IS_OBJECT(object) [10:04] that segfaults with the new glib [10:04] once you unref, you shouldn't touch it any more.. [10:05] I wall to set it to NULL but only if the ref reachs 0 [10:05] it's refed over 1 [10:05] ah, someone pinged me about that this morning [10:05] so if ref is 2 and it's unref-ed I don't want to NULL it [10:05] bug 1182140 [10:05] Launchpad bug 1181324 in notify-osd (Ubuntu) "duplicate for #1182140 notify-osd crashed with SIGSEGV in bubble_get_id()" [Medium,Confirmed] https://launchpad.net/bugs/1181324 [10:05] right [10:05] seb128: sounds a bit abusive though :/ [10:05] shakaran [10:05] I understand what happens and why, not sure how to fix it [10:05] seb128: so I think g_clear_object() is what you might want to use? [10:06] oh, that doesn't just do _unref() if the ref count is > 1? [10:06] either you control the refcount, and you know it will hit 0 or not in advance, or you don't but in that case you're no longer allowed to touch the object.. [10:07] pitti, I think g_clear_object == [10:07] g_object_unref + ptr =NULL [10:07] without consideration for the refcount [10:07] * seb128 checks [10:07] :/ [10:08] but checking if ref will become 0 seems racy to me :/ [10:11] that code is a bit crazy [10:11] * seb128 doesn't want to spend hours to understand the notify-osd crazy memory management [10:11] they have a [10:11] if (stack_is_slot_vacant (self, slot)) [10:11] self->slots[slot] = BUBBLE (g_object_ref ((gpointer) bubble)); [10:12] so I guess the refcount can be > 1 [10:14] yeah but if you unref that slot is vacant :/ [10:15] bah, I will just update the bug with the details of what is happening and let somebody who knows that code fix it === om26er is now known as om26er|away [10:21] pitti: woops, I also need xserver-xorg-input-wacom as a build-depend, and xorg-gtest is too old in saucy :/ === MacSlow is now known as MacSlow|lunch [12:00] I've updated from 11.10 to 13.04 via do-release-upgrade and now cannot login via gdm. After entering user/pw the screen blanks for a few seconds and returns to the logon prompt. Permission on /home are root:root 777. Perms on /home/user are user:user 755 [12:01] have you checked .xsession-errors? [12:05] .xsession-errors is dated 6/6 with no timestamp in the log. How would I know which errors are from today? [12:08] zero it, retry logging in === MacSlow|lunch is now known as MacSlow [12:21] mlankhorst: Nothing written to .xsession-errors, however, Changing the session type at the logon screen from Ubuntu (default) to Gnome was successful. Also changing it back to Ubuntu (default) is also now successful. [12:24] no idea then :/ === om26er|away is now known as om26er [13:00] tedg: hello! [13:00] Good morning sil2100 [13:02] tedg: during daily-release testing, we noticed a hud issue with the HUD not returning any results for even the obvious queries [13:02] tedg: let me show you a video [13:04] sil2100, Is this coming from an app? We didn't have support for unity-gtk-module... [13:04] sil2100, is it working with firefox? [13:05] tedg: ah! Ok, that would make sense - but I actually thought that was already in, as I saw a recent commit related to support of u-g-m [13:05] sil2100, That landed on trunk in r273 [13:05] tedg, seb128: ok guys, I'll check that, probably that's the reason [13:05] Thanks! [13:05] sil2100, I'm not sure why it didn't get released, is that part of the autopilot stuff? [13:06] tedg: I need to see what revisions are being used in the hud stack right now [13:09] sil2100, it seems like the indicator stack failed in jenkins because it installed packages that shouldn't be there? [13:10] sil2100, seems like a bug in the stack config... [13:16] seb128: yes, I'm fixing that now, it seems we also had some leftovers from appmenu-gtk [13:16] sil2100, right, it's in the apt-get install command [13:33] sil2100, The issue there is that we have some branches that need to land in order from jbicha. So that's why were waiting on the daily releases. [13:34] sil2100, It's not a big deal right now, but FYI. [13:44] Laney, tedg, larsu, didrocks: you might want join that team https://launchpad.net/~system-settings-touch membership ... it would be useful to have some people in there so we can have peer reviews, etc [13:45] seb128: ok, doing [13:45] Laney, thanks [13:45] joined [13:45] * tedg thinks it needs a cooler icon... [13:46] seb128: will do [13:46] thanks guys ;-) [13:46] tedg, larsu: oh, and good morning and happy new week ;-) [13:47] Good morning seb128. Tried that Texas wine this weekend, France is probably safe for another year or two... [13:47] tedg, haha, I'm glad to year ;-) [13:47] do [13:47] hear [13:48] dooh even [13:48] seb128: thanks, same to you! [13:54] seb128: howdy [13:55] I think we're ready to sync vala-0.20 from Debian (making it default); GNOME stuff should already work with it without problem [13:56] and the things using vala-0.18 I've tested (like Unity pieces) also work with -.20 [13:56] jbicha, hey, can you check with mhr3 and sil2100 if they feel like they are ready? mhr3 mentioned last week that we shouldn't rebuild the lenses with 0.20 because it has issues IIRC [13:57] seb128, no, there are other issues with 0.20 [13:58] seb128, it was about libunity, lenses might be fine, i didn't check them [13:58] mhr3, what's the issue for libunity? [13:59] seb128, it just fails to build [13:59] mhr3, well in any case if libunity is having issue that's a good reason to hold on the version change, until we resolve it [14:00] ah, yes libunity explicitly depends on valac-0.18 and doesn't built yet with valac-0.20 [14:00] seb128: see there's about 6 packages autosynced from Debian that won't build on Ubuntu because they need valac to be >= 0.20 [14:01] shrug [14:01] we can change the default without it affecting libunity [14:01] what do they force a version like that? [14:01] I'm sure those build with 0.18 [14:01] but yeah, if you are tested and are sure it doesn't break unity, feel free to sync it [14:02] yes, we could patch all of those packages but it didn't seem worth it [14:02] like https://git.gnome.org/browse/gupnp/commit/?id=4870e [14:03] seb128: ok, could you promote vala-0.20 to main then? [14:03] jbicha, ok [14:04] speaking of vala bugs, unity-greeter won't build with vala-0.20 yet either, bug 1186058 [14:04] Launchpad bug 1186058 in unity-greeter (Ubuntu) "fails to build from source with vala 0.20" [Undecided,New] https://launchpad.net/bugs/1186058 [14:05] better to get that fixed because syncing (no regression ;)) [14:05] or force the vala version meanwhile [14:05] it's already been forced [14:05] I know that libunity has bugs with 0.20 [14:06] mhr3 told it [14:06] jbicha: you checked that every packages forced 0.18? [14:06] yes, libunity has been pinned to 0.18 [14:06] (and vala scopes as well?) [14:19] didrocks: I checked building but not running and I didn't check everything but I did test-build the non-gnome stuff in main that builds against just valac [14:19] the gnome stuff should be fine since F19 has had vala 0.20 as default for months [14:21] I think we can definitely drop vala 0.18 this cycle, libunity & totem-plugin-arte are the only 2 explicitly b-d-ing on it that don't work with 0.20 [14:23] .14 depends on Debian but we might keep .16 around a bit longer [14:34] didrocks: ping! [14:35] sil2100: pong [14:35] didrocks: soo, I remember that when otto was being planned, one of the cool things about it was that we could take a snapshot of a given test run to see what was happening there [14:35] didrocks: is that possible right now? [14:35] sil2100: it is [14:35] of course you need the same graphic card [14:35] and architecture [14:35] didrocks: since tedg would like to fetch some logs from the rootfs [14:36] sil2100: you should have the delta attached in a .otto file referenced by the build [14:36] (it's a tar delta file) [14:38] didrocks: where can I find that file? (I found the file-name in the logs) [14:38] sil2100: ok, so in the http archive published [14:38] you have an archive/ directory [14:38] Ah! [14:39] * sil2100 noticed the link at the end of the test log [14:39] \o/ Thanks [14:39] yw :) [14:40] sil2100: not doc yet, just trying to see how clear this is without any :) [14:41] didrocks: btw. when I redeployed a stack but no packages were added, can I re-run it with 'foo' (i.e. without rebuilding) or am I forced to rebuild everything from scratch? [14:42] sil2100: depends on what you are trying to do :) [14:42] sil2100: if this has nothing to do with trunk content, you can use "foo" [14:45] didrocks: it's just the packages: list that changed [14:46] sil2100: so fine once redeployed and ran with "foo" :) [14:46] this famous famous foo package [15:01] didrocks, When we have the glib support for calling apport on gcriticals, will autopilot tests upload those to errors? [15:01] tedg: I guess it's a question for thomi [15:02] I would love to :) [15:02] Yeah, looking for the stack traces... [15:02] tedg: if you need more info, we can add more logs to look at [15:02] Or atleast we could put the crash files in the artifacts. [15:02]