[04:58] <pitti> Good morning
[06:14] <mlankhorst> bonjour
[06:19] <didrocks> bonjour mlankhorst, ça va?
[06:19] <mlankhorst> no!
[06:19] <didrocks> oh, why?
[06:20] <mlankhorst> I did my amount of french for the week
[06:21] <didrocks> roh, you can't never do enough french in a week :)
[06:21] <mlankhorst> -> can ever
[06:21] <didrocks> yeah, I need to do more english I guess :)
[06:23] <bratsche> I should try to learn French again.
[06:23] <bratsche> I bought a viola bow by a maker in Paris, and when I was first contacting him to try to buy a bow I learned enough French to write to him.  It must have been terrible though, because he responded in English. :)
[06:24] <didrocks> ahah :)
[06:24] <didrocks> and then, you responded again in French because his English was terrible too… :)
[06:24] <bratsche> haha
[06:25] <bratsche> My friend Jenny moved to Austria and then to Germany, and when she was trying to learn German nobody would talk to her in German.  She would speak German, everyone would respond in English.  She would respond then in German, they in English.. back and forth.  Finally they would give up and speak to her in German.
[06:26] <bratsche> But she said it was very difficult because basically every conversation with every person went this way, and it made it hard to learn German.
[06:27] <didrocks> well, at least, you have more luck in France, German people are too good speaking English, so they can answer in that language :) In France, fewer people speak English, so they will let you try to speak French at least and answer into that language because… hell… you are in France, you have to speak French :p
[06:28] <bratsche> I would like to go visit Paris sometime and visit my bow maker.
[06:28] <bratsche> And there is a famous instrument maker whose shop is on the same street.
[06:29] <didrocks> heh :) (well, I have another view of Paris having lived there, but I think it's a great city for visiting)
[06:29] <bratsche> Étienne Vatelot is the instrument maker I'd like to visit.  He's a very famous modern maker.
[06:30] <didrocks> oh, it rings me a bell, he's building violin IIRC…
[06:31] <bratsche> Yes, and viola.
[06:31] <didrocks> it can be a fun visit :)
[06:31] <bratsche> Stéphane Thomachot is the bow maker.  He's very famous as a modern bow maker.
[06:33] <didrocks> my bow reference is limited to Doctor Who TBH :)
[06:34] <bratsche> :)
[06:34] <tvoss> didrocks, ping
[06:34] <didrocks> hey tvoss
[06:35] <bratsche> Okay, I'm off to bed.  Have a good night!
[06:35] <didrocks> bratsche: have a good night! ttyl :)
[06:35] <tvoss> didrocks, good morning and happy new week :) is sil2100 taking care of google-mock in the archive?
[06:36] <didrocks> tvoss: well, nobody is taking care of it, there is no maintainership attribution, remember? :)
[06:36] <didrocks> tvoss: need to have anything sponsored?
[06:37] <tvoss> didrocks, yup, https://code.google.com/p/googlemock/issues/detail?id=79
[06:37] <tvoss> didrocks, or better: the patch for it :)
[06:38] <didrocks> https://codereview.appspot.com/5267041/ it seems
[06:38] <didrocks> tvoss: however, google mock FTBFS
[06:38] <didrocks> tvoss: in saucy right now
[06:39] <tvoss> didrocks, oh
[06:39] <didrocks> classic new gcc I guess (pthread issue)
[06:39] <didrocks> tvoss: I'll fix both in a few
[06:39] <tvoss> didrocks, ack, and thx
[06:39] <didrocks> yw :)
[06:40] <tvoss> didrocks, once that is in I can remove mir's local gmock version
[06:40] <didrocks> tvoss: ah great! :)
[07:10] <jibel> good morning
[07:16] <didrocks> salut jibel, ça va?
[07:17] <jibel> didrocks, salut! Coincé tout le w.e. avec un enfant atteint de varicelle mais à part ça, ça va pas trop mal et toi?
[07:18] <didrocks> jibel: ça va plutôt bien. Par contre, bataille avec pthread depuis ce matin…
[07:24] <didrocks> jibel: you didn't answer on the topic for perf testing, was it on purpose?
[07:24] <didrocks> (as I asked you some inputs there)
[07:25] <czajkowski> aloha
[07:25] <jibel> didrocks, not yet, will do this morning
[07:25] <didrocks> thanks!
[07:25] <didrocks> hey czajkowski, back in Europe? :)
[07:27] <czajkowski> yup and still awake at this hour ;)
[07:28] <czajkowski> back to the land of propper tea!
[07:31] <didrocks> :)
[07:45] <seb128> good morning desktopers
[07:46] <sil2100> seb128: morning!
[07:46] <seb128> sil2100, hey, happy monday!
[07:46] <sil2100> seb128: do you remember the libdbusmenu armhf failure on Friday we had? Do you know if Ted was able to figure out what was going on?
[07:48] <seb128> sil2100, I don't know...
[07:48] <seb128> sil2100, is it still failing the exact same test?
[07:52] <robru> didrocks, ping (and good morning)
[07:54] <didrocks> hey robru! good morning :)
[07:54] <didrocks> salut seb128, sil2100!
[07:54] <seb128> lut didrocks ;-)
[07:54] <robru> didrocks, need to ask you about SRUs if you get a sec
[07:54] <sil2100> didrocks: morning!
[07:54] <sil2100> seb128: yes...
[07:56] <robru> didrocks, so remember all that bootstrapping trouble we had with unity-webapps-dev? well webapps team asked me to SRU a handful of webapps. So... how do I go about bootstrapping these SRUs? How do I SRU a brand new package into raring?
[07:57] <didrocks> robru: we don't SRU new packages
[07:57] <didrocks> robru: as we don't do packaging changes in SRU for infrastucture
[07:57] <didrocks> (only if the packaging change fix a bug)
[07:57] <didrocks> robru: so I'm afraid that you will have to push manually the SRU, as we can't use your awesome work there :)
[07:57] <robru> didrocks, so then I guess I have to hand pick patches for backporting? There's no way to just dump the saucy webapps stack into raring, is there?
[07:57] <didrocks> (see why I was pushing last cycle to get that under dailies? we would have use that already ;))
[07:58] <didrocks> robru: yeah, unfortunately, no way for that…
[07:58] <robru> bah. it's all so clear to me now...
[07:59] <didrocks> robru: is it fixing important bugs?
[08:00] <robru> didrocks, yes, there are at least 5 or 6 webapps that are actually outright broken (because the sites in question changed and the userscript is no longer compatible). so it's very important to get those fixes out. in fact I'm very behind on this and ashamed at how badly I've let this slip)
[08:00] <robru> didrocks, but I was hoping I could just basically upload the whole saucy stack as-is into raring and not have to fuss too much about it.
[08:00] <didrocks> robru: ok, makes sense to fix those 5/6.
[08:00] <didrocks> robru: yeah, that's what we are doing for unity (there are maintaince branch, but it's building daily, automatically, and so on…)
[08:01] <Laney> morning!
[08:01] <robru> didrocks, ok, thanks. I'm going to sleep now, and when I wake up I will spend all day picking patches by hand. bah.
[08:01] <robru> didrocks, g'night
[08:02] <didrocks> robru: good luck! and good night :)
[08:08] <didrocks> sil2100: there was an issue on the armhf builders tonight, I relaunched the settings stack and now publish it, you can deal with the rest? :)
[08:08] <sil2100> didrocks: could you approve? ;) https://code.launchpad.net/~sil2100/libsignon-glib/fix_linking_again/+merge/171027
[08:08] <sil2100> didrocks: aye aye!
[08:09] <czajkowski> If I buy a brand newlaptop to wipe and install Ubuntu on it, will I run into any issues with secure boot?
[08:09] <didrocks> sil2100: interesting, -lpthread? isn't -pthread with our linker?
[08:09] <sil2100> didrocks: it did not work ;) He didn't recognize that!
[08:09] <didrocks> sil2100: as long as our builders seems to be happy, I'm fine anyway :)
[08:09] <didrocks> sil2100: ok, this is all mystery and shadows :p
[08:09] <Laney> hmm
[08:09] <seb128> czajkowski, better ask #ubuntu-devel about secure boot, but 12.04.2 and > 13.04 should just work with it
[08:09] <seb128> Laney, good morning
[08:10] <didrocks> hey Laney!
[08:10] <Laney> new gnome-session broke my xmonad session!
[08:10] <Laney> hey
[08:10] <seb128> haha
[08:10] <Laney> because of: https://bugzilla.gnome.org/show_bug.cgi?id=691663
[08:10] <ubot2> Gnome bug 691663 in gnome-session "session: Remove RequiredProviders support" [Normal,Resolved: fixed]
[08:10] <Laney> good weekends?
[08:11] <seb128> yes, the weather is a bit colder that you would like for a start of summer but we didn't get too much rain at least
[08:11] <czajkowski> seb128: thanks
[08:11] <czajkowski> seb128: want to get a X1 Carbon and just wipe it so just checking before it's bought
[08:11] <seb128> the music festivals they do for the start of the summer got lucky, they could play and there was quite some people who came
[08:11] <seb128> so that was nice ;-)
[08:12] <Laney> sounds cool
[08:12] <Laney> wtf, there's an ice cream van going around
[08:12] <seb128> and you? good w.e?
[08:12] <Laney> at 09:12?!?!?!
[08:13] <seb128> lol
[08:13] <Laney> was nice, went to visit the parents and got well fed :-)
[08:13] <seb128> haha
[08:14]  * pitti waves to seb128, didrocks, Laney, and czajkowski -- good morning!
[08:14] <didrocks> bonjour pitti, tu as passé un bon week-end? :)
[08:15] <seb128> pitti, salut, ça va bien ?
[08:15] <pitti> didrocks: oui, c'était calme
[08:15] <pitti> we had a really nice BBQ with 9 people on Saturday, it was quite sunny then
[08:16] <pitti> FTR, French people invent French words for just about everything else, why not "fin de semaine"? :-)
[08:16] <pitti> or is "week-end" slang for younger people?
[08:17] <didrocks> pitti: no, it's widespread for years
[08:17] <czajkowski> pitti: ello :)
[08:17] <didrocks> pitti: "fin de semaine" would be more associated to Thursday/Friday I guess :)
[08:18] <pitti> didrocks: btw, I'm adding test cases to autopilot-gtk; I currently call them through dbus-launch/xvfb-run in debian/rules, is that the right way to do that?
[08:18] <pitti> didrocks: or do the autolanding tests already run in an X session?
[08:18] <Laney> jbicha: So, http://paste.ubuntu.com/5794843/ seems to fix it for xmonad. Is that the right thing to do? (or anyone else)
[08:18] <pitti> (I need dbus-luanch/xvfb so that it builds in sbuild)
[08:19] <didrocks> pitti: well, depends if you want to run them at build time or when you want to run them during integration tests
[08:19] <didrocks> pitti: you can even do both, one with this mock/subsession, one for integration tests :)
[08:19] <Laney> jbicha: (probably ought to check nothing else is using that feature)
[08:19] <pitti> didrocks: so autolanding tests just call something like "autopilot discover"?
[08:20] <didrocks> pitti: well, that doesn't exist AFAIK, so we list the packages to install (the -autopilot packages) and then, list the autopilot test suites we want to run in a configuration file
[08:20] <didrocks> for each stack
[08:20] <didrocks> if you add them, please ping us and we'll add it
[08:21] <pitti> ah, I see
[08:21] <pitti> I didrocks I added cmake integration, i. e. "make test" or "ctest" just works (it calls GTK_PATH=lib python -m testtools.run discover ...)
[08:21] <didrocks> pitti: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/view/head:/stacks/head/qa.cfg#L8
[08:21] <didrocks> for instance
[08:22] <didrocks> pitti: we only support autopilot for integration tests (running in a real installation) for now as PS wanted to standardize around that
[08:24] <pitti> they don't work very well in xvfb, so maybe I revert that again and instead ask you to add them to above config
[08:25] <didrocks> pitti: that's fine, just 2 lines to add :)
[08:25] <pitti> not that I'd be able to decipher how that runs the tests
[08:25] <didrocks> pitti: in a nutshell, they need to be shipped in a separate binary package from the same source and can be run by autopilot for now
[08:26] <didrocks> sil2100: libsignon merged!
[08:26] <pitti> didrocks: oh, that needs to be done for each and every package?
[08:26] <pitti> like, every indicator, autopilot-gtk-tests, and so on?
[08:26] <didrocks> pitti: every one shipping some integration tests, right
[08:27] <didrocks> pitti: not that for all the unity stack, all integration tests are shipped by only the unity source package
[08:27] <didrocks> even if it exercises scopes, libunity…
[08:27] <didrocks> (this is how upstream wanted to ship them)
[08:28] <pitti> didrocks: so would you recommend that I create an entirely new autopilot-gtk-tests binary package just to ship the three test files, or continue to go with just "make test"?
[08:28] <sil2100> \o/
[08:28] <didrocks> pitti: the new binary package is cheap, the more complicated part would be I guess to turn them into autopilot tests
[08:29] <pitti> didrocks: they are autopilot tests, I just don't use the autopilot discovery but the unittest discovery as the former is a bit broken
[08:30] <didrocks> pitti: ah, so it's easy, just ship those autopilot files like for http://packages.ubuntu.com/raring/all/unity-autopilot/filelist, and I'll add them to the daily release configuration
[08:31] <didrocks> no need for wrapper or whatever, I'll add the name of the top test to run
[08:31] <pitti> didrocks: ah, I can just put the files into the "autopilot-gtk" package?
[08:32] <pitti> didrocks: and with above configuration, the tests will run in merge proposals?
[08:32] <didrocks> pitti: no, the upstream merger AFAIK doesn't run them by default, but it's a question for mmrazik I guess
[08:32] <didrocks> pitti: I'm only handling the "land to distro" part (from trunk)
[08:32] <Laney> Sweetshark: Hey, are you aware that autopkgtests started being considered for proposed->release migration? Seems libreoffice's hasn't been succeeding (due to lack of space on the test machines?) - anything that can be fixed?
[08:33] <pitti> didrocks: ah, thanks; I'm currently more interested in the upstream test side
[08:33] <didrocks> pitti: you can ship them to autopilot-gtk if you want, as end user of it won't really care to have those extra files I guess :)
[08:33] <pitti> right
[08:33] <Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html shows (modulo the bug that it shows up as 'RUNNING' when it's not) that it impacts quite a lot of important packages
[08:34] <Laney> s/important/low level/?
[08:42] <seb128> Laney, is that what blocked gcc-4.8 in proposed?
[08:43] <Laney> Well, the RUNNING bug does that anyway
[08:43] <seb128> :-/
[08:43] <Laney> but if that weren't there it would be blocked by LO's testsuite failing, AFAIK
[08:43] <Laney> glib too
[08:43] <seb128> that sucks
[08:43] <seb128> autopkgtest for pango1.0 1.32.5-5ubuntu1: RUNNING
[08:43] <seb128> autopkgtest for ubiquity 2.15.7: RUNNING
[08:43] <seb128> shrug
[08:43] <Laney> those ones pass
[08:43] <seb128> it means anything failing test can block the world?
[08:44] <Laney> that's the intention
[08:44] <seb128> where do you see that they pass?
[08:44] <Laney> there wasn't really an incentive to have your autopkgtests passing up until now
[08:44] <Laney> but they'll have to be fixed
[08:44] <seb128> shrug
[08:44] <Laney> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/
[08:44] <seb128> it's putting the insensitive on the wrong person :p
[08:44] <Laney> how's that?
[08:45] <seb128> ubiquity having buggy test might block glib
[08:45]  * xnox thought whenever britney asks for results it's set to "running" even if it is about to run.
[08:45] <seb128> it puts the insensitive on the glib maintainers to fix ubiquity
[08:45] <seb128> where it should be the ubiquity guys that should fix it :p
[08:45] <xnox> seb128: and not having a working installer will screw everyone ;-)
[08:45] <Laney> I suppose you look at the test and see if it was your upload that broke it or not
[08:45] <Laney> then come to an accommodation with whoever
[08:45] <seb128> xnox, well, broken test != broken program
[08:46] <Laney> xnox: it's been RUNNING all weekend; see #-release chatter saturday morning
[08:46] <Laney> it's a bug
[08:46] <xnox> Laney: since we are triggering tests of rdeps, how do you know if 2.15.7 passed initially, or the repeated rdep triggered run passed?
[08:46] <xnox> Laney: ah, i see.
[08:55] <Laney> The bootstrapping problem is that so many tests just sit there failing currently which is what's happening with libreoffice
[08:55] <Laney> so we need initial effort to fix them to make the system work
[08:57] <seb128> Laney, does it mean we will have saucy mostly stalling until we fix those?
[08:58] <Laney> we can force stuff meanwhile
[08:58] <seb128> that would be good
[08:58] <seb128> shrug
[08:58] <seb128> why do I keep getting prompted about calendar auth dialogs
[09:30] <Sweetshark> Laney: LibreOffice autopkgtests cant run because the images of are too small. It needs a 12GB image IIRC. Up until now, they were not critical as we where running them during the build, but we disabled them there (again for discspace *sigh*), we should have the autopkgtest resized indeed.
[09:30] <Laney> Maybe make them succeed as a kind of no-op in that situation?
[09:43] <seb128> pitti, hey, it seems that you synced the new gucharmap ... it's depwaiting on unicode-data which is in universe, do you plan to file a MIR for that?
[09:47] <pitti> seb128: oh thanks, I didn't notice; it's not even on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[09:47] <pitti> seb128: yes, I'll file a MIR
[09:48] <seb128> pitti, danke
[09:48] <seb128> pitti, it's on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html ... well the package is listed outdated there
[09:48] <seb128> which lead me to check why
[09:48] <seb128> weird that it's not on component-mismatches though
[09:49] <Laney> it is on V
[09:49] <Laney> err, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
[09:49] <seb128> bah
[09:49] <seb128> too many pages
[09:49] <seb128> we need a whiteboard :/
[09:50] <Laney> Don't think that one emails though, for some reason
[09:50] <czajkowski> seb128: whiteboards are amazing!
[09:50] <czajkowski> seb128: just ordered two of them! was tempted to buy whiteboard paint  :)
[09:52] <seb128> czajkowski, haha
[09:53] <pitti> seb128: bug 1194070
[09:53] <ubot2> Launchpad bug 1194070 in unicode-data (Ubuntu) "[MIR] unicode-data" [Undecided,New] https://launchpad.net/bugs/1194070
[09:53] <seb128> pitti, danke!
[09:53] <czajkowski> seb128: all I dis last week was lock myself into rooms and write on walls. very handy
[10:00] <sil2100> seb128: do you know who would be the best person to poke about a failing armhf unit test for gnome-control-center-signon ?
[10:00] <seb128> sil2100, kenvandine
[10:02] <sil2100> Ah, so only him! Too bad ;)
[10:02] <sil2100> seb128: thanks
[10:02] <seb128> sil2100, do you have a link to the error?
[10:03] <seb128> sil2100, you can try pinging mardy as well
[10:03] <sil2100> seb128: yes, but it doesn't say much because of "See ./test-suite.log"
[10:03] <sil2100> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4741417
[10:04] <seb128> sil2100, let me have a try on a porter box
[10:04] <sil2100> seb128: thanks!
[10:23] <mlankhorst> seb128: afaict x1.14 is ready at this point for the transition, even fglrx works now (for as much as fglrx ever could be considered working)
[10:23] <seb128> mlankhorst, do you have the patched unity in the same ppa?
[10:24] <mlankhorst> yeah, still needs to build for amd64
[10:24] <seb128> mlankhorst, can you make a call for testing on ubuntu-devel@ with instructions to enable the ppa etc, once everything is built?
[10:24] <mlankhorst> already working on it
[10:25] <seb128> mlankhorst, great, thanks
[10:52] <seb128> sil2100, http://paste.ubuntu.com/5795142/
[10:52] <seb128> sil2100, that's what the tests hit on the builder
[10:52] <seb128> seems to be a armhf being slow/timeout
[10:55] <sil2100> seb128: thanks! I'll try unblocking that by increasing the timeout value and ask ken to fix it once he's up
[10:58] <sil2100> seb128: what about "Error sending message: Operation not permitted" ? Doesn't look as a timeout issue
[11:05] <seb128> sil2100, I think it's a side effect of the previous timeout, yes
[11:05] <seb128> sil2100, try with an increased timeout
[11:12] <tseliot> didrocks: hi, can you review and approve my fglrx-pxpress package in saucy (in NEW) please?
[11:13] <tseliot> it's very small and simple
[11:13] <didrocks> tseliot: not right now, can be delayed for some time :)
[11:13] <didrocks> tseliot: hem, last time you told that, there were a bunch of fixes :p
[11:13] <tseliot> didrocks: well, the package is based on the one you approved, so it shouldn't really be a big deal
[11:14] <didrocks> tseliot: I'll review it in a couple of hours, want to finish a complex packaging review first
[11:14] <tseliot> didrocks: sure, thanks
[11:14] <didrocks> yw :)
[12:42] <jbicha> dobey: you maintain USC these days right? could you look at bug 1163886? esp. comment 29
[12:42] <ubot2> Launchpad bug 1163886 in software-center (Ubuntu) "software-center crashed with signal 5 with the GNOME3 PPA on 13.04" [High,Confirmed] https://launchpad.net/bugs/1163886
[13:08] <jbicha> Laney: yes that looks fine for xmonad
[13:08] <seb128> jbicha, hey, do you have a vcs for the webkit work? I think we could push to the desktop team ppa and I can upload to a ppa with arm support
[13:08] <jbicha> I ran an apt-file search; Cinnamon is not affected, cairo-dock was already fixed, which only leaves xmonad
[13:10] <jbicha> seb128: can I re-use https://code.launchpad.net/~ubuntu-desktop/webkit/ubuntu ?
[13:10] <seb128> jbicha, sure
[13:11] <seb128> jbicha, btw were you going to look at the accountsservice update (I was going to have a look)
[13:16] <jbicha> seb128: no, I think accountsservice is over my head
[13:16] <seb128> ok, I'm going to do that one then
[13:18] <jbicha> building webkit took a ridiculous number of retries on amd64 this last time (maybe 20!)
[13:18] <jbicha> I see that there's ifeq ($(DEB_HOST_ARCH_BITS),32) LDFLAGS += -Wl,--no-keep-memory
[13:18] <seb128> what error did you hit?
[13:19] <jbicha> which we had modified to ifeq ($(DEB_HOST_ARCH_BITS),32) LDFLAGS += -Wl,--no-keep-memory -Wl,--reduce-memory-overheads
[13:19] <seb128> right
[13:19] <seb128> that's from https://launchpad.net/ubuntu/+source/webkit/1.7.90-0ubuntu1
[13:19] <jbicha> I didn't have a problem really with i386 so maybe we should use --no-keep-memory for all arches?
[13:19] <seb128> I think the option makes the build slower
[13:20] <seb128> we had to add it because we were hitting the 32bit address space limit
[13:20] <seb128> there is no reason to slow down the build on amd64 afaik
[13:20] <seb128> 64bit don't hit that limitation
[13:21] <jbicha> uh I don't think I kept a build log, but it looked like it kept timing out
[13:22] <seb128> ok, let's see what it makes in the desktop team ppa
[13:22] <seb128> I guess we don't need a source build there
[13:22] <seb128> can you just ppa copy the binaries if they are ready for there?
[13:23] <seb128> I will do a source upload to another ppa which includes armhf to test that arch
[13:23] <jbicha> yes, I can do that now
[13:23] <seb128> thanks
[13:24] <desrt> hey seb
[13:25] <desrt> oh wait.  if forgot how this irc stuff works
[13:25] <desrt> seb128: hey!
[13:25] <jbicha> I pushed my webkit packaging to that branch, I dropped the Disable jit on armhf too since I wasn't sure whether we still needed that
[13:25] <seb128> desrt, hey
[13:25] <seb128> desrt, how are you?
[13:26] <seb128> jbicha, ok, thanks
[13:26] <desrt> seb128: good :)
[13:26] <desrt> seb128: i did a new round of the extensions patch for accountsservice after failing to notice that stef reviewed it ages ago
[13:26] <desrt> after being poked by pete, who needs it ASAP
[13:26] <seb128> desrt, ok
[13:27] <desrt> it depends on a somewhat large patchset in glib that also landed over the weekend
[13:27] <desrt> so i'm wondering if we can somehow get the new glib packaged, plus a vendor-patched accountsservice for now, pending further reviews
[13:27] <desrt> (the last set of reviews were all clean-up type stuff... no proposed functionality changes...)
[13:27] <seb128> desrt, newer that 2.37.2 ?
[13:27] <desrt> seb128: it landed over the weekend...
[13:27] <seb128> k
[13:28] <seb128> Laney, ^ can you backport those glib commit for desrt?
[13:28] <desrt> i could probably do a release if it would help
[13:28] <desrt> it's monday, after all :p
[13:28] <seb128> desrt, I can do the accountsservice side (I was going to update to the current version today)
[13:28] <didrocks> desrt: but but, friday releases are the best! :)
[13:32] <attente> dpm, hey
[13:32] <attente> is there a way we can let people know that the new keyboard indicator is available for testing in a ppa?
[13:33] <desrt> seb128: i'm going to hold off on the glib release today
[13:33] <seb128> desrt, ok
[13:33] <desrt> seb128: ebassi just landed the private-registration-API rework that he was doing (facilitated by the recent changes to how private works internally)
[13:34] <seb128> desrt, seems safer to backport your change then (if they are not mixed with other things)
[13:34] <dpm> attente, there are different ways, depending on what you want to achieve: an announcement on the ubuntu-devel mailing list, on the Fridge, on social media? What are you after? Do you want folks to test it for different keyboard layouts? Desktop of phone?
[13:34] <desrt> actually, hold on
[13:35] <desrt> blah
[13:35] <desrt> seb128: i think it's probably safe since it's mostly just API additions, in fact
[13:35] <desrt> seb128: i'm going to do some local testing
[13:36] <desrt> the only thing that concerns me is that some classes in GIO are already using this new API
[13:36] <desrt> but i honestly think i'm just being paranoid
[13:36] <seb128> desrt, ok
[13:36] <desrt> (due to all of the crashes that happened last time we had private-related changes)
[13:36] <seb128> desrt, btw just as fyi, https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1194123
[13:36] <ubot2> Ubuntu bug 1194123 in gtk+3.0 (Ubuntu) "[gcc-linaro wrong-code regression] gcc 4.8.1-2ubuntu1 to 4.8.1-3ubuntu1 breaks gtk on armhf" [High,New]
[13:36] <desrt> neat!
[13:37] <jbicha> attente: have you tested whether ibus works with indicator-keyboard? I couldn't figure out how to get it to work with ibus-pinyin
[13:37] <desrt> so suspected compiler bug, or confirmed compiler bug?
[13:37] <desrt> or 'gcc changed the rules for atomics again, and now we fall on the wrong side of the line' bug?
[13:37] <seb128> desrt, suspected, could be gtk doing something stupid that was working by luck before
[13:37] <attente> jbicha, ibus should work with ibus-pinyin, but that reminds me that i should upload other engines to the ppa as well
[13:37] <seb128> desrt, I just know that this upgrade breaks it and that -O0 workaround it
[13:37] <attente> dpm, this is just for the desktop
[13:38] <desrt> seb128: most curious!
[13:38] <seb128> desrt, I'm trying more builds are the porter box to find what option in -O1 breaks it
[13:38] <seb128> desrt, the css used is a gresources, but extracting it with the command line gives a non corrupted resources
[13:38] <attente> dpm, probably something on the devel mailing list would be appropriate
[13:38] <jbicha> attente: uh could you give me instructions? I added Chinese in text entry settings but nothing happens when I switch to Chinese
[13:38] <seb128> desrt, my first guess was that something broke the resources stuff
[13:38] <desrt> i doubt that resources would have any problems
[13:39] <desrt> i have more suspicions about atomics or something along those lines
[13:39] <seb128> could be...
[13:39]  * desrt kicks off some jhbuildage for testing purposes
[13:39] <attente> jbicha, what version of ibus-pinyin do you have?
[13:39] <dpm> attente, if you send something to ubuntu-devel, make sure to copy ubuntu-translators, as there are lots of folks there that use the indicator and can probably help with the testing
[13:40] <jbicha> attente: 1.4.0-2ubuntu1ppa1 from your ppa and ibus-pinyin-db-android too
[13:40] <seb128> desrt, I tried to reduce the amonth of rebuild needed, but I can only test with a "make clean; make" in gtk/ atm, touching some random .c is not enough ... not sure how to find what object is problematic
[13:40] <attente> jbicha, is ibus-daemon running?
[13:41] <jbicha> attente: no, how should I start it?
[13:41] <attente> jbicha, the issue might've been that if ibus 1.5 was running with the older ibus-pinyin engine, that would cause a crash with ibus
[13:41] <attente> i think you just need to restart the session
[13:42] <attente> (or yes, start ibus-daemon again)
[13:42] <jbicha> well I've logged out several times since then...
[13:42] <attente> hrm. do you have other ibus engines enabled?
[13:43] <didrocks> tseliot:                 mv $xorg_conf $xorg_conf.$now
[13:43] <didrocks> tseliot: now=$(date +"%m%d%Y")
[13:43] <jbicha> ok, starting ibus-daemon manually worked and now I get Chinese (Pinyin) and Chinese (Bopomofo) where before I only had Chinese
[13:44] <tseliot> didrocks: yes?
[13:44] <didrocks> tseliot: if I reinstall the package the same day (or reconfigure it), I'll get into trouble with the mv failing, isn't it?
[13:45] <didrocks> same in postrm
[13:45] <didrocks> mv $xorg_conf $xorg_conf.$now
[13:45] <didrocks> if I remove it the same day, things will go badly :)
[13:45] <didrocks> (I would just rm the config in that case btw)
[13:45] <tseliot> didrocks: in the postrm?
[13:46] <didrocks> postinst as well, if you configure twice the package the same day, you will have the script failing
[13:46] <tseliot> didrocks: and I can use "mv -f"
[13:46] <didrocks> tseliot: yeah, that would work as well
[13:46] <attente> jbicha, just speculating, but maybe the bopomofo engine is causing it to crash since it was built against ibus 1.4
[13:47] <tseliot> didrocks: ok, please reject it and let me reupload
[13:47] <didrocks> tseliot: empty debian/docs btw :)
[13:47] <didrocks> tseliot: otherwise, everything looks good :)
[13:47] <didrocks> tseliot: rejected
[13:49] <jbicha> attente: the cool part is that after logging out and logging back, indicator-keyboard won't start (I guess because ibus-daemon isn't running and it's needed)
[13:50] <attente> jbicha, :(
[13:51] <attente> jbicha, can you run /usr/lib/indicator-keyboard/indicator-keyboard-service --force manually?
[13:51] <tseliot> didrocks: ok, reuploaded and here's the diff: http://paste.ubuntu.com/5795532/
[13:52] <didrocks> tseliot: good for me, thanks! universe or main?
[13:52] <tseliot> didrocks: universe should be fine for now, thanks
[13:53] <jbicha> (indicator-keyboard-service:11152): IBUS-CRITICAL **: ibus_bus_call_sync: assertion 'ibus_bus_is_connected (bus)' failed Segmentation fault (core dumped)
[13:53] <jbicha> (if ibus-daemon isn't running)
[13:53] <didrocks> tseliot: NEWed then :)
[13:53] <tseliot> didrocks: thanks a lot!
[13:53] <didrocks> yw!
[14:04] <Laney> desrt: so, doing a release?
[14:04] <desrt> hah
[14:04] <desrt> already seeing troubles
[14:04] <desrt> the private changes add emission of a new your_widget_name_get_private() function as part of G_DEFINE_TYPE
[14:04] <desrt> which is handy
[14:04] <desrt> problem is, a lot of people already wrote their own _get_private() functions
[14:05] <desrt> so now you get the same function twice and the build breaks
[14:10] <Laney> har de har
[14:11] <jbicha> attente: I reported bug 1194138
[14:11] <ubot2> Launchpad bug 1194138 in Indicator keyboard "ibus-daemon doesn't autostart" [Undecided,New] https://launchpad.net/bugs/1194138
[14:11] <Laney> jbicha: xmonad> ok, I'll fix that - can you check for other instances?
[14:13] <Laney> also, would that work for < 3.8 or do I need to add a versioned dependency?
[14:13] <jbicha> Laney: yes I ran apt-file search, Cinnamon was fine and cairo-dock was already fixed
[14:15] <jbicha> you shouldn't need that since RequiredComponents has been around for a while
[14:16] <attente> jbicha, thanks
[14:17] <desrt> Laney: it's clear that i'm not doing a release with the private changes in it
[14:17] <desrt> trying not to figure out how to work around that
[14:30] <jbicha> seb128: we need to ask for more disk space in the desktop ppa; webkit is huge
[14:30] <seb128> because of the -dbg?
[14:32] <jbicha> I wonder what's wrong here?
[14:32] <jbicha> libwebkit2gtk-3.0-25-dbg_2.0.3-1ubuntu1~build1_amd64.deb (1.2 GiB)
[14:32] <jbicha> libwebkit2gtk-3.0-25-dbg_2.0.3-1ubuntu1~build1_i386.deb (2.0 MiB)
[14:45] <dobey> jbicha: looking at the code, the claims that commenting out that one line fixes it make no sense to me.
[14:48] <sil2100> jibel: hi!
[14:49] <sil2100> jibel: related to my merge request - I checked the usermod call, and if the user is a member of the group already, usermod does not fail but just succeeds with 0
[14:49] <sil2100> jibel: should I still do that check for membership?
[14:49] <desrt> Laney: how much later are you around? :)
[14:50] <Laney> desrt: maybe 2 hours
[14:50] <Laney> well, 2:10
[14:50] <Laney> ish
[14:50] <desrt> k
[14:50] <desrt> i might have a tarball by then
[14:50] <Laney> packaging a glib release takes a while though ...
[14:50] <desrt> but otherwise we can just do this tomorrow
[14:51] <desrt> seb128: are you okay holding off on the accountsservice upload?
[14:51] <seb128> desrt, I was going to update to the current upstream version, we can add the patches later in the week
[14:51] <desrt> k
[14:51] <desrt> sorry for the noise :/.
[14:52] <seb128> no worry
[14:54] <Laney> btw, what creates the XDG runtime dir? logind?
[14:54] <sil2100> kenvandine, seb128: eh, sadly bumping the timeout did not help
[14:55] <seb128> Laney, libpam-systemd I think
[14:55] <kenvandine> yeah
[14:55] <kenvandine> sil2100, seb128 is trying again
[14:55] <sil2100> I guess something bigger is wrong, since 2x the timeout value is daaamn
[14:55] <Laney> seb128: ah yeah, I guess that
[14:55] <Laney> how does the env var get set? I was seeing it set in schroot but the directory wasn't created
[14:56] <jibel> sil2100, you should at least verify that group autopilot and user ubuntu exist IMO
[14:56] <Laney> context is running the glib installed tests
[14:57] <seb128> Laney, I though it was through pam as well, but I guess pam is not used in that shcroot context
[14:57] <seb128> Laney, or does it get the env from your user?
[14:57] <Laney> it could be passed through
[14:58] <Laney> no, seems not
[14:58] <seb128> Laney, http://codesearch.debian.net/search?prev=&q=XDG_RUNTIME_DIR&skip=0 suggests that logind shoul create the dir
[14:58] <seb128> Laney, is logind running in that context?
[14:59] <seb128> systemd_44-11/src/login/logind-user.c:317
[14:59] <seb128>         log_debug("New user %s logged in.", u->name);
[14:59] <seb128>         /* Make XDG_RUNTIME_DIR */
[14:59] <seb128>         r = user_mkdir_runtime_path(u);
[14:59] <Laney> no
[14:59] <seb128> Laney, the glib tests do
[14:59] <seb128>  * Copyright (C) 2010 Red Hat, Inc.
[14:59] <seb128>  *
[14:59] <seb128>  * This work is provided "as is"; redistribution and modification
[14:59] <seb128>  * in whole or in part, in any medium, physical or electronic is
[15:00] <seb128>  * permitted without restriction.
[15:00] <seb128>  *
[15:00] <seb128>  * This work is distributed in the hope that it will be useful,
[15:00] <seb128>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
[15:00] <seb128>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[15:00] <seb128>  *
[15:00] <Laney> uh oh
[15:00] <seb128>  * In no event shall the authors or contributors be liable for any
[15:00] <seb128>  * direct, indirect, incidental, special, exemplary, or consequential
[15:00] <seb128>  * damages (including, but not limited to, procurement of substitute
[15:00] <seb128>  * goods or services; loss of use, data, or profits; or business
[15:00] <seb128>  * interruption) however caused and on any theory of liability, whether
[15:00] <seb128>  * in contract, strict liability, or tort (including negligence or
[15:00] <seb128>  * otherwise) arising in any way out of the use of this software, even
[15:00] <seb128>  * if advised of the possibility of such damage.
[15:00] <sil2100> Oh no, license spam!
[15:00] <seb128>  *
[15:00] <seb128>  * Author: Matthias Clasen
[15:00] <seb128>  */
[15:00] <seb128> #define GLIB_DISABLE_DEPRECATION_WARNINGS
[15:00] <seb128> #include "glib.h"
[15:00] <sil2100> o_O
[15:02] <seb128> did the spamming stop?
[15:02] <Laney> yes
[15:03] <seb128> (sorry about that, firefox decided to copy the file rather than the line I wanted)
[15:03] <seb128> Laney, I wanted to say
[15:03] <seb128> glib's test seem to do
[15:03] <seb128>   xdg = g_strdup (g_getenv ("XDG_RUNTIME_DIR"));
[15:03] <seb128>   if (!xdg)
[15:03] <seb128>     xdg = g_strdup (g_get_user_cache_dir ());
[15:03] <Laney> yeah
[15:03] <Laney> so it should check if the directory exists maybe
[15:03] <seb128> Laney, is the env variable actually set for you?
[15:03] <Laney> it is, that's the problem
[15:03] <seb128> weird
[15:03] <seb128> I wonder what sets it
[15:08] <seb128> sil2100, didrocks: seems like ubuntu-geoip is not on the autolanding list, do you know why?
[15:09] <didrocks> seb128: IIRC cyphermox told at the time it wasn't ready yet
[15:09] <seb128> ok, I will check with him tomorrow (I guess he's off today since that's an holiday in Quebec)
[15:09] <seb128> didrocks, thanks
[15:10] <didrocks> yw
[15:13] <seb128> kenvandine, sil2100: g-c-c-signon built fine on the porter box with the increased timeout...
[15:36] <attente> sil2100, are you able to run unity-gtk-module tests?
[15:37] <sil2100> seb128: hm, let me re-run that
[15:37] <sil2100> attente: let me check - you mean on jenkins?
[15:37] <attente> sil2100, even just locally
[15:38] <attente> i'm running into issues, not really related to autopilot, but related to at-spi
[15:38] <attente> "WARNING **: Couldn't connect to accessibility bus..."
[15:38] <sil2100> attente: let me check, one moment
[15:46] <sil2100> jibel: I just found a moment to input those fixes - what do you think now?
[16:12] <desrt> Laney: glib seems fine now, so i did a release
[16:13] <Laney> desrt: great, will look at it tomorrow morning then
[16:13] <sil2100> attente: which tests are failing for you?
[16:13] <Laney> merci
[16:13] <desrt> thanks
[16:13] <sil2100> And what package versions are you using?
[16:18] <attente> sil2100, they all fail since they can't connect to the accessibility bus for some reason
[16:18] <attente> sil2100, seems to be completely unrelated to autopilot, but not sure why it's happening
[16:19] <sil2100> attente: since here they're running fine
[16:19] <sil2100> attente: although I'm not using daily-build PPA, just the latest saucy bits
[16:19] <attente> sil2100, i had tried it without any ppas installed, but same problem unfortunately :(
[16:20] <sil2100> hmmm
[16:20] <sil2100> attente: could you paste me the whole error message here?
[16:22] <attente> sil2100, http://pastebin.ubuntu.com/5795926/
[16:22] <attente> sil2100, don't worry about it too much, i'
[16:22] <attente> i'll try to figure out what's going on on my end
[16:22] <sil2100> hm, looks like something new, didn't see that before
[16:23] <attente> sil2100, no worries, i was just wondering if it was working for you :)
[16:29] <sil2100> Laney: ping!
[16:30] <Laney> hi
[16:30] <sil2100> Laney: hello! I need some upstart advice
[16:31] <sil2100> Laney: I need an upstart job to start 'after' another job - should I use start on stopped blabla ?
[16:31] <Laney> what do you mean by after?
[16:32] <sil2100> I want to make sure that the other job is finished before I run my job
[16:32] <Laney> finished means?
[16:32] <sil2100> Because it's a setup job that sets up and exits
[16:34] <Laney> sil2100: is it an upstart 'task'?
[16:35] <sil2100> Laney: I'm not really into upstart vocabulary, but it's a something that's just being ran and not running in the background
[16:35] <Laney> http://upstart.ubuntu.com/cookbook/#task
[16:36] <sil2100> I think stopped is the right thing, jibel nodded to that ;)
[16:37] <Laney> Look at the two queue-worker examples there
[16:37] <Laney> The second one might achieve what you want?
[16:45] <olli> seb128, I am upgrading X, jfyi
[17:07]  * didrocks waves good evening
[17:26] <seb128> olli, ok, let us know how it goes ;-)
[17:51] <kenvandine> seb128, i wonder if those failures on armhf is really because it's building on qemu instead of real hardware
[17:52] <kenvandine> we've had that happen before, maybe the stderr being sent to that logfile is keeping us from seeing the real crash
[17:52] <kenvandine> signond seems to trigger those sorts of problems sometimes
[17:53] <kenvandine> seb128, do you know if the armhf builders on the daily-build PPA are virtual or panda?
[18:20] <seb128> kenvandine, I don't know...
[18:22] <kenvandine> seb128, it's driving me insane!
[18:22] <kenvandine> i'll try building in pbuilder for armhf
[18:33] <seb128> kenvandine, can't you just dh_override_auto_test:
[18:34] <seb128>     dh_auto_test
[18:34] <kenvandine> yes
[18:34] <seb128>     cat *.log
[18:34] <seb128> ?
[18:34] <kenvandine> oh
[18:34] <kenvandine> i didn't even think of that :)
[18:34] <seb128> ;-)
[18:34] <kenvandine> i've been cursing automake for an hour :)
[18:34] <seb128> hehe
[18:34] <kenvandine> apparently setting VERBOSE makes it send it to stdout after the build
[18:34] <kenvandine> but i am not seeing that locally
[18:35] <kenvandine> let me see if i can reproduce this failure in pbuilder
[18:35] <kenvandine> i can't reproduce it on real hardware
[18:37] <seb128> yeah, the only issue I got on porter-armhf.canonical.com is the timeout one
[19:04] <Laney> kenvandine: seb128: daily-build is non-virtual
[19:04] <Laney> It's the one that gets copied into distro isn't it?
[19:04] <Laney> Anyway, if it has ppc it's non-virt
[19:04] <seb128> Laney, right; well is there any virtual armhf?
[19:04] <seb128> Laney, kenvandine mentioned qemu builders
[19:05] <seb128> but non-virt don't have armhf at all
[19:05] <seb128> so I was unsure what builders use qemu :p
[19:05] <Laney> There is virtualised qemu armhf as a separate category
[19:05] <seb128> where are those available/used?
[19:06] <Laney> You can ask for it to be enabled for your PPAs
[19:06] <Laney> https://dev.launchpad.net/CommunityARMBuilds
[19:06] <seb128> oh ok
[19:06] <Laney> but yeah, it's quite flaky
[19:06] <seb128> ok, so yeah, daily-build is real panda
[19:06] <Laney> indeed
[19:06] <seb128> Laney, thanks
[19:06] <kenvandine> damn...
[19:06] <Laney> you can see that if you look at the build page
[19:07] <kenvandine> i can't reproduce this on my own hardware :/
[19:07] <seb128> kenvandine, neither could I on the datacenter porter box
[19:07] <kenvandine> and it builds for seb128 on the porter box
[19:07] <kenvandine> so wtf!
[19:09] <Laney> g-c-c-signon?
[19:11] <seb128> yes
[19:11] <Laney> i'll try it on mr. panda here
[19:11] <seb128> Laney, https://launchpadlibrarian.net/143264352/buildlog_ubuntu-saucy-armhf.gnome-control-center-signon_0.1.7~daily13.06.24-0ubuntu1_FAILEDTOBUILD.txt.gz
[19:12] <seb128> that's the build log on the ppa for daily builds
[19:12] <Laney> yes, that's not an entirely useful output
[19:12] <seb128> no...
[19:12] <Laney> what's the test runner?
[19:12] <seb128> kenvandine, will you do the override to display the log file?
[19:12] <Laney> we should be doing builds in verbose mode or whatever ...
[19:13] <Laney> it also does a quiet build
[19:14] <seb128> Laney, kenvandine, others: btw, new webkitgtk in the desktop team ppa, please install and complain it if it breaks anything, if nobody complains it will go to saucy ;-)
[19:15] <Laney> oh cool, will do tomorrow
[19:15] <Laney> did you try it on armhf? https://buildd.debian.org/status/package.php?p=webkitgtk&suite=experimental
[19:15] <kenvandine> Laney, i am trying to disable quiet, didn't seem to work in my local build
[19:16] <kenvandine> Laney, do you have ideas how to do that?
[19:16] <seb128> Laney, yes, I did a ppa copy to a Canonical ppa which has arm builders
[19:16] <seb128> let's see tomorrow
[19:16] <kenvandine> besides adding a cat *.log in debian/rules?
[19:17] <seb128> kenvandine, you are reluctant to try my hack I see :p
[19:17] <kenvandine> yes :)
[19:17] <kenvandine> well mostly tired of the latency of testing hacks
[19:17] <kenvandine> propose merge, get review, wait for merger try cu2d build
[19:17] <kenvandine> over and over again :/
[19:18] <kenvandine> oh... my build failed in pbuilder for armhf!
[19:18] <kenvandine> i reproduced it!
[19:18] <seb128> kenvandine, "congrats"? ;-)
[19:18] <seb128> kenvandine, what's the error?
[19:19] <kenvandine> ** (/tmp/buildd/gnome-control-center-signon-0.1.7~daily13.06.18/tests/.libs/lt-test-accounts-page:16981): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[19:19] <kenvandine> qemu: uncaught target signal 5 (Trace/breakpoint trap) - core dumped
[19:20] <seb128> k, so a sigtrap somewhere
[19:20] <seb128> but qemu involved there...
[19:21] <kenvandine> yeah...
[19:21] <seb128> tedg, stop using xvfb on porter :p
[19:21] <kenvandine> oh interesting
[19:21] <kenvandine> the specific test that crashes has no tests
[19:22] <Laney> "If the variable ‘VERBOSE’ is set, this file is output after the summary."
[19:22] <seb128> tedg, ok, -n <...> let me use it, you can keep abusing the default port there ;-)
[19:26] <kenvandine> Laney, i tried that... it didn't work :/
[19:27] <kenvandine> bingo!
[19:27] <kenvandine> it is a timeout!
[19:28] <tedg> seb128, heh
[19:36] <kenvandine> ok, not a timeout.. but seb128 did missing a place where we are running dbus-test-runner
[19:36] <kenvandine> i found the test that is failing on qemu
[19:36] <kenvandine> but not on real hardware...
[19:39] <Laney> ahaha
[19:39] <Laney> so yeah I reproduced it
[19:39] <Laney> (/build/gnome-control-center-signon-C7q3H3/gnome-control-center-signon-0.1.7~daily13.06.24.1/tests/.libs/lt-test-providers-page:30487): Gtk-W
[19:39] <Laney> ARNING **: Theme parsing error: Raleigh.css:394:140: Cannot animate property 'background-image'
[19:39] <Laney> task-0: /credentials/providerspage/create:
[19:39] <Laney> task-0: Shutting down
[19:40] <Laney> we ought never to have disabled the gtk tests on armhf...
[19:40] <Laney> kenvandine: ^
[19:45] <kenvandine> Laney, exactly
[19:45] <kenvandine> Laney, how did you reproduce it?
[19:45] <Laney> just built on the panda
[19:45] <Laney> in sbuild
[19:45] <kenvandine> passed for me!
[19:45] <kenvandine> not with sbuild
[19:45] <Laney> saucy?
[19:46] <kenvandine> yes
[19:46] <kenvandine> bzr builddeb
[19:46] <Laney> dunno then, should have been broken for you with current gtk
[19:46] <kenvandine> passed for seb128 on the porter box
[19:49] <Laney> well you saw it
[19:49] <Laney> got to go eat
[19:52] <kenvandine> Laney, thx
[20:21] <ChrisKing> Hey all, I'm new contributor here (as of yesterday!) - am having some problems building packages (using jhbuild), wondered if someone here might not mind giving me some pointers?
[21:08] <dobey> ChrisKing: what do you mean "building packages (using jhbuild)" ?
[22:12] <ChrisKing> dobey: I was trying to use jhbuild to easily checkout and build a package from source :)
[22:28] <Laney> kenvandine: I just checked on shedir (porter-armhf) and gtk wasn't fully up-to-date
[22:28] <Laney> after upgrading that the test fails
[22:29] <Laney> The files are there in my home directory if you fancy a peek