[05:50] <hikiko> hello
[08:21] <larsu> good morning!
[08:24] <pitti> larsu: hey Lars!
[08:24] <pitti> hello hikiko, too!
[08:24] <pitti> pretty lonely here with folks travelling..
[08:25] <larsu> indeed. Morgen pitti!
[08:43] <alexarnaud> Good morning all
[08:43] <alexarnaud> hikiko: Hi
[08:54] <willcooke> morning gang
[08:54] <larsu> hi alexarnaud and willcooke!
[09:01] <ksamak> hoy all
[09:10] <Laney> hey!
[09:10] <Laney> sorry for being late
[09:10] <larsu> g'day Laney!
[09:10] <Laney> got a friend over to paint in our living room
[09:11] <Laney> had to show her where all the stuff is
[09:11] <Laney> hey larsu
[09:12] <larsu> what's she painting?
[09:13] <Laney> starting with the skirting
[09:13] <Laney> then window frames
[09:13] <Laney> then walls
[09:13] <Laney> then if that goes really well, part of the outside wall!
[09:13] <Laney> basically we/I could have done it, but we didn't over 15 months or however long we have been here now
[09:13] <Laney> and she was looking for jobs to do
[09:14] <Laney> seemed fair
[09:14] <larsu> cool :)
[09:14] <alexarnaud> Laney: it's a good deal yeah
[09:38] <pitti> hey Laney!
[09:38] <Laney> hi there pitti!
[09:38] <Laney> what's up?
[09:39] <Laney> are you having a good sprint?
[09:39] <pitti> Laney: guess what -- handholding LXC workers and making adt-run more robust against more errors :)
[09:39] <pitti> Laney: I do, yes! (but in the afternoon/night)
[09:39] <pitti> the three guys kept me full-time busy with questions, MPs, setup, etcl
[09:40] <pitti> but they all managed to set up the infra in juju-local, and start hacking on it
[09:40] <Laney> great
[09:41] <Laney> I thought that it was going to cover errors, CI train and other related bits too
[09:41] <Laney> seems not?
[09:41] <pitti> Laney: not this sprint, this is for p-m
[09:41] <pitti> Laney: we'll have 3 more sprints for the other pieces of infra
[09:42] <pitti> Laney: today we want to look into a web/SSO based test retry button
[09:42] <Laney> nice!
[09:43] <Laney> I guess that will be the first dynamic piece on the server
[09:44] <pitti> yeah, scary
[09:44] <pitti> so far everythign is nice and read-only
[09:44] <pitti> Laney: btw, do you know why http://autopkgtest.ubuntu.com/packages/g/glib2.0/xenial/s390x/ is so flappy?
[09:45] <pitti> Laney: is that a matter of running against more triggers in -proposed, or just a flaky test and I'll retry until it sticks?
[09:45] <Laney> pitti: I didn't really look yet
[09:45] <Laney> is it always the same failure?
[09:46] <pitti> Laney: I'm still trying to find the failure; it's not "FAIL:", it's not "ERROR:", goddammit world, agree to some common string to search for
[09:46] <pitti> it's not "not ok" either
[09:47] <Laney> pitti: "killed by signal"
[09:48] <pitti> GLib-GIO:ERROR:/build/glib2.0-dQLvhN/glib2.0-2.47.4/./gio/tests/gdbus-proxy.c:826:fail_test: code should not be reached
[09:48] <pitti> # GLib-GIO:ERROR:/build/glib2.0-dQLvhN/glib2.0-2.47.4/./gio/tests/gdbus-proxy.c:826:fail_test: code should not be reached
[09:48] <pitti> cleaning up pid 6856
[09:48] <pitti> Test glib/gdbus-proxy.test failed: Child process killed by signal 6
[09:48] <pitti> I think that's the one
[09:48] <Laney> oh man, gdbus tests
[09:49] <pitti> failure in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/g/glib2.0/20160119_151405@/log.gz looks different
[09:49] <pitti> (/usr/lib/glib2.0/installed-tests/glib/gdbus-threading:6884): GLib-GIO-ERROR **: connection had too many refs
[09:49] <pitti> cleaning up pid 6886
[09:49] <pitti> Test glib/gdbus-threading.test failed: Child process killed by signal 5
[09:49] <Laney> still gdbus though
[09:49] <Laney> so at least the same area
[09:49] <pitti> same on the next failure
[09:49] <Laney> I think we know someone who speaks dbus quite well
[09:49]  * Laney looks west
[09:50] <Laney> could try to get it in an accessible instance
[09:50] <pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/g/glib2.0/20160118_105206@/log.gz is pcre, but I think that was due to pinning
[09:50] <Laney> pcre broke every arch
[09:50] <Laney> and is fixed
[09:50] <pitti> Laney: can you ssh ubuntu@10.100.0.12 ?
[09:51] <pitti> Laney: I mean firewall-wise (I didn't import your key yet)
[09:51] <Laney> pitti: yeah
[09:51] <Laney> I know the password :)
[09:51]  * Laney h4x0r
[09:51] <pitti> Laney: ah, ok -- I just did ssh-import-id lp:laney
[09:51] <Laney> I've stolen this before to test stuff
[09:52] <pitti> "12345, the same combination that I use on my luggage!"
[09:52] <pitti> Laney: so I guess I'll just retry some more, and if I get bored I force it?
[09:52] <pitti> not really libselinux' fault anyway
[09:53] <Laney> well... I'm going to upload a new upstream release to experimental today
[09:53] <Laney> and sync that later or tomorrow
[09:53] <pitti> but nice, glib2.0 is the last s390x specific regression, I managed to fix all the other ones
[09:54] <pitti> all other regrssions happen on all arches
[09:58] <Laney> adt-xenial-rva0ksiq  RUNNING  10.0.3.231  -     -       NO
[09:58] <Laney> ubuntu@aupkg01:~$ lxc-console -n adt-xenial-rva0ksiq
[09:58] <Laney> adt-xenial-rva0ksiq is not running
[09:58] <Laney> thanks lxc!
[09:59] <pitti> Laney: is that s390x?
[09:59] <pitti> ah yeah, that
[09:59] <pitti> $ sudo lxc-attach -n adt-xenial-rva0ksiq systemctl  status
[09:59] <pitti> Laney: ^ that clearly works
[10:00] <pitti> Laney: but I've never used lxc-console
[10:01] <Laney> pitti: ah right
[10:01] <Laney> lxc-start-ephemeral printed out that command for me to use
[10:01] <Laney> oh right, sudo, /me fails
[10:06] <pitti> ah, I finally know how to fix these eternal armhf hangs
[10:06]  * Laney runs one of the tests in a loop
[10:06] <pitti> Laney: hah! lucky day! http://autopkgtest.ubuntu.com/packages/g/glib2.0/xenial/s390x/
[10:07] <pitti> http://autopkgtest.ubuntu.com/packages/g/glib2.0/ -> IMPECCABLE!
[10:07] <Laney> perfect package, no problems here
[10:07]  * Laney coughs
[10:07] <Laney> GLib-GIO:ERROR:/build/glib2.0-dQLvhN/glib2.0-2.47.4/./gio/tests/gdbus-proxy.c:826:fail_test: code should not be reached
[10:07] <Laney> # GLib-GIO:ERROR:/build/glib2.0-dQLvhN/glib2.0-2.47.4/./gio/tests/gdbus-proxy.c:826:fail_test: code should not be reached
[10:07] <Laney> woot
[10:08]  * Laney saves this state for a certain ARL
[10:08] <pitti> ARL?
[10:08] <pitti> oh, ARL!
[10:08]  * pitti hugs desrt
[10:14] <Laney> larsu: heeeeeeeeeeeey larsu
[10:15] <Laney> gtk css help required
[10:16] <Laney> larsu: I was looking at webkit scrollbars (see devhelp on xenial for example)
[10:16] <Laney> as far as I can tell it is drawing them itself instead of using gtk's ones
[10:16] <Laney> https://sources.debian.net/src/webkit2gtk/2.10.4+dfsg1-1/Source/WebCore/platform/gtk/ScrollbarThemeGtk.cpp/ <- this is the file in question
[10:17] <Laney> but there is some bug with drawing the background, it gets glitchy after you scroll
[10:18] <Laney> https://paste.ubuntu.com/14581466/ adding those two rules makes it look somewhat normal (probably acceptable)
[10:18] <Laney> wondering if you can help suggest the right way to do it
[10:45] <andyrock> monring
[10:45] <andyrock> *morning
[10:45] <willcooke> hey andyrock
[11:03] <larsu> Laney: hm no clue. Let me check
[11:03] <larsu> does it work with Adwaita?
[11:05] <Laney> umm didn't actuallyt ry
[11:06] <larsu> it does
[11:06] <Laney> yeah sort of
[11:06] <larsu> sort of? Works fine for me
[11:06] <Laney> they are obviously still custom scrollbars there though
[11:06] <larsu> ah, true
[11:06] <larsu> maybe they just don't draw them in that case, but let ebkit handle them?
[11:07] <Laney> yeah but still themed
[11:07] <Laney> so I guess we can find out which rules are needed and put those in
[11:08] <larsu> hm but I can't find anything :/
[11:11] <larsu> Laney: they're not doing anything webkit specific, but setting backgrounds (like your patch)
[11:17] <larsu> your patch makes it work for webkit windows, but breaks the style of other windows
[11:17] <Laney> I know, it applies to too much
[11:18] <Laney> just wanted to see if it was fixable by styling at all
[11:18] <Laney> I also don't know why you have to have the .scrollbar.slider rule since the same thing is in the theme already
[11:18] <Laney> but there's no slider without it
[11:19] <larsu> I see it without it
[11:19] <larsu> or I misunderstand what I mean :)
[11:21] <Laney> weird, I need both rules
[11:25] <Laney> larsu: do you think you could look at this please? if you have time
[11:25] <larsu> yep, already doing it :)
[11:25] <Laney> I have a load of stuff ready to move to webkit2
[11:25] <Laney> and kick the shitty old one out
[11:25] <larsu> \o/
[11:26] <Laney> thanks!
[11:26] <Laney> keep bumping into mcatanzaro on bugs too
[11:26] <Laney> seems he is also doing this for fedora
[11:26] <larsu> hehe
[11:44] <Sweet5hark> libreoffice 5.1.0~rc2 finished building locally. now lets see about libreoffice-l10n
[12:06] <larsu> Laney: could you try it out please? https://code.launchpad.net/~larsu/ubuntu-themes/webkit-scrollbar
[12:09] <Laney> okay!
[12:21] <Laney> larsu: is it less rounded than the regular scrollbars?
[12:22] <Laney> otherwise it looks good to me
[12:22] <Sweet5hark> question: how do you get gcc to commit an internal compiler error?
[12:22] <Sweet5hark> (gcc6 that is)
[12:23] <Sweet5hark> answer: LibreOffice, based on technology breaking your toolchain since 1985 ...
[12:27] <larsu> Laney: no change in the roundedness
[12:27] <larsu> but appears like it to me as well
[12:28] <Laney> might be because they are wider
[12:28] <Laney> so look more square
[12:29] <larsu> I wonder why
[12:29] <larsu> should be the same as expanded overlay scrollbars
[12:31] <larsu> Laney: ah, webkit seems to calculate slider width slightly differently. Good enough to keep like this?
[12:36] <Laney> larsu: yeah if it's not fixable in the theme
[12:58] <Laney> jdstrand: hi, would it be possible for someone to get to bug #1475021 quite soon please?
[12:58] <ubot5> bug 1475021 in gcab (Ubuntu) "[MIR] gcab" [High,Triaged] https://launchpad.net/bugs/1475021
[12:58] <Laney> we have appstream-glib in depwait for some time on this
[13:00]  * Laney back soon
[13:21] <willcooke> https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1534085
[13:21] <ubot5> Launchpad bug 1534085 in unity-control-center (Ubuntu) "System Settings legal text contains a 404 link and some inaccurate wording about online searches" [High,Fix released]
[13:21] <willcooke> \o/
[13:21] <willcooke> thanks Laney
[14:08] <Laney> willcooke: woot
[14:16] <desrt> Laney, pitti: good morning
[14:16] <desrt> everyone else, good morning as well :)
[14:18] <Laney> hi desrt!!!!
[14:18] <desrt> Laney: what's going on here?
[14:18] <Laney> EVERYTHING (not much) is BROKEN (sometimes doesn't work)
[14:19] <Laney> some gdbus tests seem not very good on s390x
[14:19] <desrt> i noticed that assert is tied to a timeout...
[14:19] <desrt> i don't suppose the test machine is super-slow...
[14:20] <Laney> i think that it is the opposite
[14:20] <Laney> do you have VPN?
[14:20] <desrt> yes
[14:21] <Laney> ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no ubuntu@10.100.0.12
[14:21]  * desrt clicks a couple of buttons and lets NM do the work
[14:22] <Laney> then screen -r
[14:22] <desrt> does ubuntu@ have a password? :)
[14:22] <Laney> I imported your key
[14:22] <Laney> allegedly
[14:22] <desrt> okay.
[14:22] <Laney> but you could try to guess the password
[14:23] <desrt> i'm in
[14:23] <desrt> my yubikey seems to have trouble resuming from suspend...
[14:23] <Laney> screen window 0 and 1 show the two which have failed on the real instances lately
[14:23] <Laney> and FYI you are inside an lxc container there
[14:24] <jdstrand> Laney: re 1475021 - I'll talk to tyhicks about it
[14:24] <Laney> thanks jdstrand, we'd like to get the ground prepared for uploading gnome-software quite soon
[14:24] <Laney> so that the universe can explode with enough time for us to glue it back together
[14:24] <larsu> morning desrt!
[14:24] <larsu> how goes?
[14:25] <desrt> good
[14:25] <desrt> wishing i had glasses
[14:25] <larsu> come to Berlin. Took them 1 day
[14:25] <desrt> i went to a place here.  they did the test and sent me away.
[14:25] <Laney> i showed rosie the picture of larsu with specs
[14:25] <Laney> she approved
[14:25] <jdstrand> Laney: ack
[14:25] <larsu> Laney: :)
[14:25] <Laney> "they look like mine"
[14:25] <larsu> Laney: say hi to her!
[14:26] <Laney> will do!
[14:27]  * Laney wonders how/what the ubucon people are doing
[14:27] <Laney> guess it's still kind of early there
[14:28] <jdstrand> Laney: question for you-- just otoh, can you think of a reason why dlna wouldn't work on xenial in rhythmbox any more when it has the same upstream version as wily (and the Ubuntu delta didn't have any relevant changes), grilo is the same as wily and grilo-plugins only has one irrelevant change over wily?
[14:29] <jdstrand> (it the dleyna code in grilo that handles this afaik)
[14:30] <desrt> Laney: how do i get other screens into the container?
[14:30] <Laney> jdstrand: hmm, nope, I tried this out a couple of weeks ago
[14:30] <jdstrand> Laney: the dlna server just doesn't show up any more (but daap still does)
[14:30] <Laney> desrt: ctrl-a, <n>
[14:30] <desrt> i know the screen part :p
[14:30] <jdstrand> Laney: it worked for you a couple of weeks ago?
[14:30] <desrt> i'm missing the 'not in the container' part
[14:30] <Laney> oh right, SSH to its IP
[14:31] <Laney> thought you might be a tmuxer or something
[14:31] <Laney> jdstrand: well I could be confused about the difference between dlna and daap to be honest
[14:31] <Laney> I shared my library between two rhythmboxen
[14:31] <jdstrand> I see
=== ChrisTownsend1 is now known as ChrisTownsend
[14:31] <jdstrand> I think rhythmbox exports as daap, iirc
[14:32] <jdstrand> exports/shares, whatever the terminology is
[14:32] <Laney> does it work with another client?
[14:32] <jdstrand> well, yes, wily rhythmbox :)
[14:32] <jdstrand> the minidlna server didn't change
[14:32] <tjaalton> codec search seems broken on xenial
[14:32] <jdstrand> I only upgraded to wily
[14:33] <jdstrand> I have both forked-daapd and minidlna exporting at home
[14:33] <jdstrand> and rhythmbox used to see both on wily. on xenial, it only sees daapd
[14:33] <jdstrand> tjaalton: it doesn't even see the server at all
[14:34] <jdstrand> (and it can play all the files from daapd)
[14:34] <jdstrand> so I don't think it is codec related
[14:34] <Laney> ok, I'll try to look
[14:34] <Laney> is there a bug that you can assign to me?
[14:34] <tjaalton> this was just an observation on my local machine with totem trying to play bbb :)
[14:34] <tjaalton> fresh install, can't find codecs to install
[14:34] <jdstrand> Laney: minidlna is really easy to setup. apt-get it, then adjust the config file for a dir of music
[14:35] <tjaalton> though I guess it's due to the software manager migration
[14:35] <jdstrand> Laney: I can. I'll work up a reproducer too. thanks
[14:36] <Laney> thanks!
[14:36] <Laney> I just want to be assigned something so I have less chance of forgetting :)
[14:39] <desrt> uhh
[14:39] <desrt> gdbus-proxy is failing on my machine this morning
[14:39] <desrt> dispite discheck having worked only two days ago
[14:39] <desrt> that's neat.
[14:40] <Laney> tjaalton: looks like something happened to break sessioninstaller
[14:44] <tjaalton> yeah
[14:44] <tjaalton> just saw the trace
[14:58] <desrt> okay.  back to not failing.  great.
[14:58]  * desrt made a mistake
[15:05] <Laney> tjaalton: https://paste.debian.net/366793/ ?
[15:08] <tjaalton> Laney: hang on
[15:09]  * Laney grips tight
[15:09] <desrt> Laney: gdb on this machine seems to be ... not great
[15:09] <Laney> oh?
[15:10] <desrt> even with debug symbols installed there are fairly big gaps in the backtraces
[15:11] <tjaalton> Laney: nope :/
[15:12] <Laney> tjaalton: did you kill the daemon?
[15:12] <Laney> it fixed it for me
[15:12] <tjaalton> ah
[15:12] <Laney> xnox: is gdb on s390x supposed to be working properly?
[15:12] <tjaalton> Laney: correct, works
[15:13] <xnox> Laney, yes....
[15:13] <xnox> Laney, do you have bugs =)
[15:13] <Laney> meet desrt
[15:13] <Laney> tjaalton: cool!
[15:13] <Laney> I'll upload that then, thanks for reporting
[15:13] <Laney> just kicked a stair and now my toe is bleeding
[15:14] <Laney> probably should have kept the nail shorter :/
[15:14]  * Laney goes to clean that up
[15:14] <desrt> xnox: hi.  seeing weird backtraces on a x390 machine :)
[15:14] <xnox> desrt, x390 ssl cert? or s390x machine?
[15:14] <desrt> uh.  the other one :)
[15:14] <desrt> isn't the ssl thing x509? :)
[15:15] <tjaalton> Laney: thanks :)
[15:23] <pitti> Laney: ok, I think I should have finally stopped the worker log spam, sorry
[15:23] <Laney> pitti: pinning fun I assume
[15:24] <pitti> Laney: that, and unclear to me why it happened; but I built a new wily base image, it only happened for wily ..
[15:24] <Laney> :/
[15:24] <pitti> Laney: and then I screwed up a fix from this morning which was supposed to fix the s390 tmpfails
[15:24] <pitti> (which didn't show in local testing)
[15:24] <pitti> but should be all good now
[15:24] <pitti> well, I still need to fix the eternal armhf hangs, but at least I now know how
[15:25] <pitti> (and what happens)
[15:25] <pitti> i. e. I can't fix the hung containers, but at least have adt-run ignore them insted of waiting forever
[15:29] <desrt> Laney: cannot reproduce on a fresh build >:|
[15:29] <desrt> Laney: can you tell me a bit more about the setup here?  these are installed tests running against a new library version, or what?
[15:31] <Laney> desrt: build/install versions should be the same
[15:34] <Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/g/glib2.0/20160120_091557@/log.gz
[15:35] <Laney> they are both 2.47.4-1 there
[15:35] <desrt> nod.
[15:50] <andyrock> if i do
[15:50] <andyrock> g_signal_emit (...., g_strdup(...))
[15:51] <andyrock> I'm supposed to g_free the string in the callback right?
[15:52] <andyrock> desrt: ^^^
[15:52] <desrt> uh
[15:52] <desrt> don't do that :)
[15:52] <andyrock> or it's automatic?
[15:52] <desrt> g_signal_emit will fire the signal directly in place
[15:53] <desrt> so as long as the string in question will survive until g_signal_emit() returns, you don't need to dup it
[15:53] <andyrock> so I can free after g_signal_emit
[15:53] <andyrock> right?
[15:53] <desrt> in fact, depending on the signal, it may also dup the string for itself (and free it)
[15:53] <desrt> yes.  definitely.
[15:54] <desrt> but maybe you don't need to dup it at all, is what i'm saying...
[15:55] <desrt> but in any case: absolutely do not g_strdup() something you pass to g_signal_emit() and free() inside a handler.  that is absolutely broken.
[15:55] <desrt> and not just 'in theory' -- there is no guarantee that the string passed to the handler will have the same pointer value as the string passed to g_signal_emit() -- only that it will have the same value (as a string)
[15:55] <andyrock> ok thanks! :)
[16:31] <qengho> If I'm merging a package from Debian, and I quote the patches that will remain in the package, should I also reference the Debian bugs with "closes: #nnnn"? That seems weird.
[16:32] <Laney> You don't have to, but it's nice to have them referred to somewhere
[16:32] <Laney> the patch header is fine for that
[16:35] <qengho> Thx
=== rickspencer3_ is now known as rickspencer3
[17:13] <desrt> Laney: got a working theory
[17:14] <desrt> it's a stretch, though
[17:17] <qengho> dpm: Hi. Some translations team didn't respond to join requests. I advised a would-be contributor to message admins individually, wait, and then open a Question against Launchpad. Was that right?
[17:18] <dpm> qengho, it used to be, but nowadays no one really looks at those questions. The best thing might be to send an e-mail to ubuntu-translators@ubuntu(dot)com
[17:19] <Laney> desrt: real bug or test bug?
[17:20] <desrt> test bug
[17:20] <desrt> like usual
[17:20] <desrt> still investigating...
[17:20] <Laney> fun
[17:21] <Laney> no need to waste all day on it if you have better things to be doing
[17:35] <desrt> Laney: actually, i've binned that first theory and am now tending toward 'actual bug'
[17:36] <desrt> the proxy does a sequence of things in order to get the service to start up... first it tries to StartServiceByName... and if that fails then it does GetNameOwner in order to figure out if it already exists
[17:37] <desrt> the problem is that maybe for some random reason (like a well-placed exec()) the service might pop into existence in between those two and the process may receive a NameOwnerChanged
[17:37] <desrt> in both cases, gdbus will try to GetAll properties on the service... which it seems to be doing twice
[17:37] <desrt> that much, at least, is a bug in the proxy
[17:38] <desrt> so ya... one of those this-timing-issue-would-never-happen-in-the-real-world issues
[17:38] <desrt> but it's a legit issue
[17:40] <Laney> and I guess the test is making a new proxy async then execing the service
[17:41] <desrt> the weird thing is that it should result in the async call finishing twice, as far as i can tell
[17:41] <desrt> and instead, it's finishing zero times
[17:41] <desrt> very odd
[17:42]  * desrt curses the gigantic ugly asyncinit state machine in here
[17:44] <desrt> hilariously, this could just be an entirely unrelated bug because it also happens in the case where the test runs properly
[17:44]  * desrt sighs
[17:58]  * Laney hugs desrt 
[17:58] <Laney> it's going to be okay
[17:58]  * Laney goes off to roast a chicken
=== lifeless_ is now known as lifeless
[18:13] <Mirv> is there a bug for "lightdm doesn't show user background anymore and theme seems a bit resetted (domain name has grey background and date is black font etc)"
[18:13] <Mirv> I have had it before 14.04 out of the blue and it happened again. I can't figure out how I fixed it last time, but I remember it was not straight-forward.
[18:13] <Mirv> like uninstalling / resetting config files for lightdm + unity-greeter not enough
=== xnox_ is now known as xnox
=== Tex is now known as Texou
[18:32] <Mirv> I meant, before on 14.04 and now again on 14.04. well, I'll eventually have time to find out the fix and at least document that somewhere.
[19:01] <willcooke> night night all
=== ochosi_ is now known as ochosi
=== Guest6639 is now known as fredp
=== fredp is now known as Guest83051
[22:12] <attente> robert_ancell: hey, which branches of gnome-software should i be looking at?
[22:12] <robert_ancell> attente, wip/rancell/ubuntu-reviews-3-18
[22:13] <attente> ubuntu-ratings?
[22:13] <robert_ancell> attente, that's been merged into ubuntu-reviews
[22:14] <attente> robert_ancell: ok
[22:14] <attente> robert_ancell: i can't see ubuntu-ratings on the remote though
[22:15] <robert_ancell> attente, https://git.gnome.org/browse/gnome-software?h=wip%2Francell%2Freviews-3-18
[22:15] <robert_ancell> I'll delete the other branches