[02:19] <jbicha> robert_ancell: can you look into syncing appstream-glib?
[02:19] <robert_ancell> jbicha, sure
[05:41] <pitti> Good morning
[05:46] <didrocks> bonjour pitti !
[05:47] <pitti> bonjour didrocks, ça va ?
[05:47] <didrocks> pitti: très bien, et toi ? :)
[05:47] <pitti> ça va -- apparently I caught a cold :(
[05:47] <didrocks> oh :(
[05:48] <didrocks> is it cold in germany or just stayed at the wrong place ?
[05:48] <pitti> it's nice summer weather, apparently the latter
[07:03] <ochosi> seb128, Laney: morning you two! quick question: who is maintaining the headerbar patches? i have a suggestion (if you plan to keep the patches around for 16.10 and onwards)
[07:07] <seb128> hey ochosi! unsure what patches you are talking about? the ones to not use headbar under unity? there is no dedicated maintainer, whoever update a package deals with refreshing the changes
[07:12] <seb128> oh, and good morning desktopers ;-)
[07:16] <darkxst> hey seb128
[07:16] <seb128> hey darkxst, how are you? it has been a while we didn't see you on IRC (at least on european hours)
[07:16] <darkxst> seb128, I am good, been up in the mountains with no internet ;(
[07:17] <seb128> ah, well it's good to cut from technology sometime ;-)
[07:18] <darkxst> in theory, but been dealing with windows crap at work ;(
[07:18] <seb128> :-/
[07:18] <darkxst> there is a desktop team position going atm?
[07:23] <seb128> talk to willcooke when he's online, there were 2, one is taken and the other one has a potential lead but I'm unsure how they moved with it, I think it's not a done deal yet so you might be able to apply still if interested
[07:24] <darkxst> seb128, ok will do
[07:24] <darkxst> I am interested, finish up here in the mountains late September, but could leave earlier
[07:25] <seb128> good ;-)
[07:25] <seb128> I don't think the "when you can start" is an issue
[07:26] <darkxst> no! its probably a more, when the snow all melts issue ;)
[07:30] <ochosi> seb128: yeah, those patches
[07:30] <darkxst> at which point I wont have any more work here
[07:31] <ochosi> seb128: basically at the moment those headerbars still look like headerbars, maybe we can improve the patch so they look like toolbars
[07:33] <seb128> that would be nice
[07:33] <seb128> I think Trevinho looked a bit at that previous cycle and tweaked the theme
[07:33] <seb128> but we might be able to do better
[07:34] <seb128> coffee, brb
[08:02] <Laney> hi there!
[08:04] <willcooke> morning all
[08:04] <davmor2> Morning all
[08:09] <Laney> hi willcooke & davmor2 & darkxst & ochosi
[08:09] <Laney> darkxst: you picked a bad time to disappear
[08:09] <Laney> ochosi: do you mean changing style classes or something else?
[08:11] <seb128> hey u.k
[08:11] <seb128> how are you today?
[08:11] <Laney> hi seb128!!!
[08:11] <ochosi> seb128, Laney: it's not just the theme, you could e.g. simply set the toolbar class on each patched headerbar and to the worst add a single line to the theme/s to take that into account
[08:12] <davmor2> seb128: good thanks how's france
[08:12] <ochosi> Laney: yeah, exactly, didn't read yours before posting mine :)
[08:12] <seb128> davmor2, good :-)
[08:12] <ochosi> Laney: all other avenues are too much work
[08:12] <Laney> ochosi: ya, some of them do that already but possibly not consistently
[08:14] <ochosi> oh i see
[08:14] <ochosi> do you guys even plan to keep those patches around?
[08:14] <ochosi> i remember switching to headerbars was an open topic practically every cycle
[08:14] <Laney> don't even go there
[08:16] <Laney> seb128: we've had like 6 days of sun now
[08:17] <willcooke> Laney, check out the forecast for the weekend.
[08:17] <Laney> I choose to interpret that as you telling me it's going to continue
[08:17] <Laney> and therefore I don't need to look
[08:17] <Laney> thanks!
[08:17] <willcooke> :)
[08:17] <willcooke> any time
[08:22] <seb128> lol
[08:26] <Laney> Breaks/Replaces are hard
[08:26]  * Laney gently stabs someone with a floppy carrot
[08:40] <willcooke> is LP slow for anyone else today?
[08:43] <davmor2> willcooke: are you insinuating that LP is fast sometimes ;)
[08:45] <seb128> speaking of
[08:45] <seb128> TheMuso, thanks for fixing bug #1613600 ;-)
[09:12] <seb128> lol, seems like that's the one Laney mentioned though :-/
[09:12] <seb128> thanks for fixing it harder!
[09:13] <Laney> heh
[09:13] <Laney> I'm not actually sure right now what breaks if you do B and not R
[09:13] <Laney> would need to meditate on it a bit
[09:13] <seb128> did you hit an actual issue with the update?
[09:13] <seb128> or did you just look at the diff and fixed it on principle that it was wrong?
[09:14] <Laney> I didn't get ubuntu2 yet, so it did break
[09:14] <Laney> but then yes, that
[09:15] <seb128> k
[09:18]  * Laney eyes ximion
[09:18] <Laney> he changed my patch when committing it and broke it
[09:18] <Laney> including the testcase
[09:23] <Trevinho> hey people
[09:23] <Trevinho> sorry I forgot to send the notes for yesterday's meeting before the WE :/
[09:26] <seb128> hey Trevinho! had a good long w.e?
[09:27] <Trevinho> Yeah, barbecue, beach volley and gokarts... So yeah :)
[09:29] <Laney> ahoy Trevinho
[09:29] <Trevinho> hey Laney
[09:29] <Trevinho> hey seb128 too
[09:29]  * Laney wants bbq
[09:30] <Trevinho> seb128: it was NH in France too on monday, right?
[09:30] <seb128> Trevinho, nice ;-)
[09:30]  * davmor2 sets up a big firepit to bbq Laney not sure why he wants to be bbq though
[09:31] <seb128> Trevinho, yes, but I decided to work, want to and swap the day for next week or do (going to spend a week in France, so need to drive there and might take some hours off while there)
[09:31] <Trevinho> ah, yeah... smart move
[09:31] <Trevinho> here 15 aug it's like the summer version of christmas...
[09:32] <Trevinho> With no tree or decorations, but all the rests stays and applies in shorts and in a saside area if possible
[09:34] <Laney> muuuuuuuuch better
[09:49] <willcooke> hmm
[09:50] <willcooke> I just installed a Y daily
[09:50] <willcooke> It installed fine, but then I got a message pop up something about "16.10 has been released after 16.04 do you want to upgrade"
[09:50] <willcooke> is that expected?
[09:52] <seb128> no
[09:52] <seb128> talk to bdmurray when he gets online
[09:53] <seb128> does shotwell has integrated menus for you?
[09:53] <willcooke> I'll try and reproduce it
[09:53] <willcooke> @ shotwell - 1 sec...
[09:53] <meetingology> willcooke: Error: "shotwell" is not a valid command.
[09:53] <seb128> it didn't for me in a VM yesterday with the daily iso
[09:53] <seb128> wonder if that's just another of those racecondition
[09:53]  * seb128 looks at Trevinho
[09:54] <willcooke> I have a global menu for shotwell
[09:54] <seb128> k, thanks
[09:54] <seb128> what I though
[09:54] <Laney> it's s-s-s-ssystemd unit time
[09:54] <seb128> do we still have some unlanded ones that lead to that?
[09:55] <Laney> unity itself
[09:56] <willcooke> hikiko, Trevinho - lowgfxmode in a virtualbox machine working automatically, and it's *awesome*!
[09:58] <Trevinho> willcooke: cool :)
[10:01] <willcooke> Here's a question...
[10:01] <willcooke> Does anyone else find it annoying that clicking to focus a window also passes that click through to the window
[10:02] <willcooke> so if I want to focus a different browser window
[10:02] <willcooke> I click on it
[10:02] <willcooke> and then I might want to ctrl-f to find something
[10:02] <willcooke> but if, when I clicked on that window, I click on a link by accident - then that link would get opened
[10:03] <willcooke> so instead I have to be careful when clicking on a window to make sure I click in free space
[10:03] <willcooke> which I find annoying
[10:03] <Laney> it would be way WAY more annoying if you had to always click twice to do something in an unfocused window IMO
[10:04] <Laney> for example it would ruin dual monitors
[10:04] <willcooke> hm, yeah
[10:04] <willcooke> good point
[11:38] <Sweet5hark> ricotz: hmmm, folks are asking about the fresh ppa for precise, last upload was 5.0.6 there. I assume you did not do any security backports to that though?
[11:56] <ricotz> Sweet5hark, hmm, I see -- and you assume wrong, it includes the backport of latest wily upload 1:5.0.6-0ubuntu1
[11:57] <ricotz> are there really so many request which makes it worth to look into using a gcc-4.8 backport
[12:07] <Sweet5hark> ricotz: wily is EOL too.
[12:11] <ricotz> Sweet5hark, I assume you were referring to "SECURITY UPDATE: Denial of service and possible arbitrary code execution via a crafted RTF file" which is included there
[12:11] <ricotz> but I guess you mean "SECURITY UPDATE: possible arbitrary code execution via out-of-bounds polygon array"?
[12:12] <Sweet5hark> ricotz: I mean no specific issue, just the general 'making sure all sec issues are accounted for'
[12:13] <ricotz> so far I am not doing specific CVE fixes
[12:29] <seb128> Sweet5hark, hey, did you see that the libreoffice update failed to build?
[12:32] <seb128> only built on armhf and powerpc
[12:35] <Sweet5hark> seb128: not yet, looking now thx
[12:35] <seb128> yw
[12:35] <seb128> the log doesn't seem very informative
[12:37] <Sweet5hark> Session terminated, terminating shell.../«PKGBUILDDIR»/solenv/gbuild/CppunitTest.mk:99: recipe for target '/«PKGBUILDDIR»/workdir/CppunitTest/desktop_lib.test' failed
[12:38] <Sweet5hark> "Session terminated, terminating shell" is not something GNU make says. seems like the builder session is killed by some watchdog or something?
[12:39] <Sweet5hark> FWIW, the sd_exports_test is exactly the one I tested here locally and it had no issue running some 10 times in a row.
[12:39] <Sweet5hark> ^^ seb128
[12:39] <seb128> which was the one hanging on the builders?
[12:39] <seb128> still seems to be an issue :-/
[12:44] <Sweet5hark> "Build killed with signal TERM after 150 minutes of inactivity" <- ah yes, it was some watchdog.
[12:45] <seb128> so the issue is a test hanging
[12:45] <seb128> but not everytime?
[12:48] <Sweet5hark> seb128: well, it hangs on the buildds _sometimes_ but not so far on a local build. all the buildds seem to hang at the same position, but running the test 10 times here locally it doesnt hang at all.
[12:49] <Sweet5hark> seb128: I'd suggest to just disable that particular test for now.
[12:49] <seb128> it's going to be fun to debug ... maybe try to see if a buildd admin can give you a shell access to hanging build?
[12:49] <seb128> getting at least a bt should be useful
[12:51] <seb128> well, maybe first try that ^ and if that doesn't work out then disable it?
[12:58] <Sweet5hark> seb128: well, we are on FF date, right? and at this point I dont think the test is showing any major libreoffice functionality. at least not if the rest of the tests succeed.
[13:00] <Sweet5hark> This test is mostly testing for some specific customer fixes in exports to not regression again. I doubt they do if they pass on another machine.
[13:01] <seb128> Sweet5hark, k, you are the maintainer, whatever you decide ;-)
[13:01] <seb128> Sweet5hark, btw you should ask the DMB again for upload rights
[13:01] <Sweet5hark> I would still go for disabling and then look at the details later (e.g. add some tombstone output and then see which of these hang for real)
[13:01] <seb128> k, wfm
[13:01] <Sweet5hark> seb128: DMB yes.
[13:24] <flexiondotorg> Laney, Will upload ubuntu-mate-artwork 16.10.6 later this afternoon. This add GTK 3.20 support.
[13:24] <flexiondotorg> Just testing a final build in PPA.
[13:27] <Sweet5hark> seb128: looking again at the output from the buildd again, I think its not actually LibreOffice or the test failing/looping
[13:27] <Sweet5hark> seb128: because the watchdog kill the process and then make says:
[13:28] <Sweet5hark> seb128: make[1]: *** wait: No child processes.  Stop.
[13:28] <seb128> Sweet5hark, do you know what command is that test spawning?
[13:30] <Laney> flexiondotorg: Nice one
[13:31] <Sweet5hark> seb128: that is the next curious thing: there is the "[CUT] sd_exports_test" which make puts out right before it should spawn the test, but I dont see the command spawning the test itself.
[13:31] <Laney> Sweet5hark: You can ask in #webops internal for a process list when it's hanging if that helps
[13:32] <seb128> let's do a build retry and ask them later?
[13:34] <Sweet5hark> seb128: and make says confused things when killed: "no childs", but also "deleting intermediate file" and "recipe failed". IOW my bet is on GNU make losing its marbles. Or more specifically: GNU makes children finishing successfully, but GNU make somehow not noticing and waiting forever for them to finish.
[13:35] <Sweet5hark> hrmrhm, but the GNU make in yakkety is ... old.
[13:35] <seb128> I'm retrying some build
[13:36] <seb128> let's ask #webops for the ps output if those hang
[13:36] <Sweet5hark> seb128: aye
[13:36] <Sweet5hark> Laney, seb128: thanks
[13:36] <seb128> doesn't block us from working on a new upload that disable this test as well
[13:36]  * Sweet5hark goes to #webops
[13:36] <Laney> probably going to be a while before it hangs no?
[13:36] <seb128> well, wait a bit, need some hours before being there :p
[13:37] <Laney> set alarm for 10pm :P
[13:37] <Sweet5hark> seb128: patched package with disabled test already (source) build here locally, will sign and upload in a bit.
[13:38] <seb128> well, 150min timeout and the build took like 6 hours
[13:38] <seb128> so check around 7pm
[13:38] <Laney> you could get a silo and build it in there
[13:38] <seb128> for the hang?
[13:38] <seb128> would that be easier to debug?
[13:38] <Laney> either one actually, I was thinking the workaround
[13:38] <Laney> then you can copy that straight in tomorrow
[13:39] <seb128> doesn't make much difference I guess
[13:39] <Laney> few hours
[13:39] <Laney> if it's ready...
[13:39] <Laney> up to you
[13:39] <seb128> I mean why not just uploading to the archive?
[13:39] <seb128> what do we win using a silo?
[13:40] <Laney> oh right, well you can keep doing stuff to the broken build then if you want
[13:40] <Laney> or copy/upload that one to a ppa
[13:40] <Laney> there is more than one way to do it
[13:42] <seb128> right, well let's see what that upload is doing
[13:42] <Laney> as you wish
[13:46] <Sweet5hark> urgs, bad news.
[13:47] <Sweet5hark> seb128, Laney: I see that while the broken libreoffice source build didnt even end up in -proposed (it hardly could), the libreoffice-l10n build happily completed and was promoted right from -proposed to yakkety proper ...
[13:47] <seb128> urg
[13:48] <seb128> seems like you are missing some cross packages relations there
[13:51] <Sweet5hark> seb128: well, strictly speaking a libreoffice-l10n package hardly depends on anything. the problem is not having a 5.2 libreoffice-l10n package, its not having the libreoffice 5.1 one anymore ...
[13:52] <seb128> well if l10n n+1 should be installed with libreoffice n you might want to have the packaging to state that was with a Conflits or such
[13:53] <Sweet5hark> seb128: yeah :/
[13:55]  * Sweet5hark wonders what the contigency plan is, if the pstree from webops is a GNU make process without children.
[13:56] <Sweet5hark> debugging "GNU make gets confused after the first 20 thousand targets or so" isnt something that will be quickly debuggable.
[13:56] <seb128> well, if that's one bit that you skip that's going to be ok
[13:56] <seb128> let's wait for that build to hand and see what we get
[13:57] <ricotz> was there a gnu make update within the last 2 weeks?
[13:57] <seb128> make didn't change since march
[13:57] <seb128> so not likely it
[13:57] <ricotz> since 5.2.0 build fine on yakkety before gcc6
[13:57] <seb128> it's doko's fault for sure ;-)
[13:57] <Sweet5hark> seb128: my fear is, that if this is GNU make running out of jobs or something it will just get struck a few spawns later ...
[13:57] <Trevinho> tedg: hey, I was about to land the systemd branch, but it seems there's still an issue
[13:57] <Trevinho> tedg: unity-services : Depends: indicator-common but it is not installable
[13:57] <Trevinho> who should provide that?
[13:58] <seb128> Sweet5hark, let's see
[13:58] <Trevinho> tedg: maybe https://requests.ci-train.ubuntu.com/#/ticket/1710 ?
[13:58] <tedg> Trevinho: It'll be libindicator, but we need to land that silo, unfortunately we need to land the UAL ABI one first. Then I can land that.
[13:58] <Trevinho> tedg: so you want me to remove your branch from my silo and land that alltogether?
[13:59] <Sweet5hark> seb128: well, on the other hand: I did see some weird Heisenbug hangs with GNU make earlier in this cycle (e.g. on the ppa builds_. But as Heisenbugs do, they disappeared once I wanted to look at them closer.
[14:00] <tedg> Trevinho: Your choice, I'm good either way. But all publishing to yakkety is blocked right now... so it won't speed you up much :-)
[14:00] <seb128> tedg, why is ual needed first?
[14:00] <tedg> seb128: Because it has a bunch of no-change rebuilds in it for some of the indicators.
[14:00] <seb128> k, that's a convenience, not a reason
[14:01] <seb128> we could land it and rebuild those out of that sil
[14:01] <seb128> o
[14:01] <tedg> seb128: Sure, just trying to play control tower for the landing planes :-)
[14:01] <Sweet5hark> seb128:  the interesting new thing is that it happened on four platforms now.
[14:01] <seb128> Sweet5hark, seems random, I'm curious if some of the 3 archs I retried are going to success
[14:01] <Trevinho> tedg: well, I try to land unity alone first then
[14:02] <Sweet5hark> seb128: I see it coming: of the three rebuilds, two will magically succeed and one will fail :/
[14:02] <Sweet5hark> seb128: hehe, right.
[14:03] <Sweet5hark> seb128: the russian approach to the space race: if it doesnt fly use more power. the russian approach to release engineering: if it doesnt succeed, do more rebuilds.
[14:03] <seb128> :-)
[14:04] <seb128> that also explains why it's warmer here today right?
[14:04] <Sweet5hark> totally
[14:04] <Laney> oh MAN
[14:05] <Laney> thanks gcc (no joke)
[14:05] <Laney> daemon/gkd-main.c: In function ‘on_logind_session_property_get’:
[14:05] <Laney> daemon/gkd-main.c:865:2: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation]
[14:05] <Laney>   if (should_quit);
[14:05] <Laney>   ^~
[14:05] <Laney> daemon/gkd-main.c:866:3: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’
[14:05] <Laney>    cleanup_and_exit (0);
[14:05] <Laney>    ^~~~~~~~~~~~~~~~
[14:06] <seb128> nice!
[14:07] <seb128> did that stop the build?
[14:07] <seb128> or was it just a warning that you happened to catch?
[14:07] <Laney> nein it's not in Werror
[14:07] <seb128> great
[14:07] <Laney> but I did check for the files I changed
[14:08] <seb128> oh, not, :-(
[14:08] <Laney> I guess it makes a lot of false positives
[14:08] <seb128> yeah, still nice
[14:08] <seb128> I wish we had reports of those
[14:08] <seb128> I wonder if somebody wrote a script to grab the current build logs from a list of package/a packageset
[14:08] <seb128> would be handy to grep for similar ones
[14:09] <xnox> there is stuff like that in debian, with the buildd log scanner
[14:09] <xnox> reporting to the new PTS
[14:09] <Laney> happens at build time, right?
[14:09] <Laney> not like "go scan all the existing logs for this new thing"
[14:10] <Sweet5hark> Laney: wait, gnome-keyring has a "goto fail" fail? nice
[14:10] <xnox> scans existing build logs
[14:10] <Laney> that was a laney fail
[14:10] <xnox> it's post-processing thing, as far as i can see.
[14:11] <Laney> remember the link?
[14:11]  * Sweet5hark mumbles something about clang compiler plugins being awesome and having lots of this stuff btw
[14:12] <Laney> go tell that to gnome :P
[14:12]  * qengho hugs clang.
[14:16] <Laney> hmm
[14:16] <Laney> pitti: can you remind me where the thing to brutally kill gnome-keyring lives?
[14:17] <pitti> Laney: in /usr/share/upstart/systemd-session/upstart/systemd-graphical-session.conf
[14:17] <xnox> Laney, i think it's build log scanner -> https://qa.debian.org/bls/packages/n/netcfg.html
[14:17] <pitti> Laney: (in the upstart package);
[14:18] <pitti> Laney: ah, did you see the upstream review of your patch?
[14:18] <Laney> yes, that's exactly what I want to test
[14:18] <pitti> \o/
[14:18] <Laney> thanks!
[14:18]  * Laney dusts off that ancient VM
[14:20] <pitti> Laney: should work in standard yakkety now, no?
[14:20] <Laney> yep
[14:20] <Laney> just dist-upgrading it
[15:06] <ximion> Laney: initial impression on your asgen PR is good :)
[15:06] <ximion> yu can easily fake a set type using an associative array
[15:07] <ximion> (hmm, I wonder if my keyboard is getting broken.... it's swallowing latters every once in a while)
[15:09] <Laney> hey ximion
[15:09] <Laney> like with the same key and value or something?
[15:09] <Laney> or just = true
[15:10] <ximion> Laney: just true
[15:10] <ximion> bool[string]
[15:10] <Sweet5hark> a two-segment flight for 540EUR or the train for 130EUR. hard decision.
[15:10] <Sweet5hark> (not)
[15:11] <ximion> then you can use if ("blah" in set)
[15:11] <Laney> grim
[15:11] <Laney> I found some old posts complaining about the lack of collecctions
[15:12] <jbicha> Sweet5hark: train, right? unless you're in a hurry
[15:13] <ogra_> jbicha, nah, plane because he will get enough bonus miles to buy a new cozy :P
[15:14] <ogra_> s/cozy/tea cozy/
[15:14] <Sweet5hark> jbicha: sure train. possibly I even get an additional 25% discount on the train. and with preboarding and getting to downtown from the airport the flights are even taking almost the same time.
[15:14]  * Laney cries
[15:14] <Laney> I somehow broke the gnome-keyring stuff
[15:14] <ximion> Laney: that's one of the things which would be trivial to implement but super useful in *any* standard library
[15:15] <Laney> hmm
[15:15] <Laney> IDEA
[15:16] <ximion> I could probably implement a Set type and submit a PR to add it to the stanrard lib...
[15:17] <Sweet5hark> ogra_: the miles for a flight HAM-MUC-BRQ wont get me far. maybe a free sandwich at the airport
[15:17] <ximion> (but quite honestly, I have better things to do at time ^^)
[15:17] <Laney> heh
[15:17] <Laney> that's what everybody must have said over the years
[15:17] <ogra_> Sweet5hark, tea cozys arent much more expensive than a sandwich i guess :)
[15:18] <Sweet5hark> ogra_: true.
[15:20] <Laney> ya, my idea was good
[15:20] <ximion> Laney: I bet the issue isn't painful enough for someone to be forced to fix it :P
[15:20] <Laney> ximion: it just means that everyone invents their own collections
[15:20] <Laney> which is a collective sad face
[15:22] <ximion> there are two things D people are bad at: writing standard libraries and writing build tools :P
[15:23] <ximion> the latter is mainly due to not caring about distros and wanting to simplify too much, the former is due to historic legacy
[15:30] <Laney> ah well
[15:30] <Laney> it's workaroundable
[15:32] <seb128> Sweet5hark, lol, ppc64el retry looks like it worked, it's doing dpkg-deb according to the log...
[15:32] <seb128> Sweet5hark, we might end up not needing another upload :p
[15:33] <Sweet5hark> seb128: yay
[15:33] <seb128> would be unlucky, trying to get info on the bug and having not showing up then
[15:33] <Sweet5hark> seb128: we just need a rebuild click bot
[15:34] <Sweet5hark> lets see what the other builds will do
[15:37] <ximion> Laney: reviewed the PR (didn't test it!) and actually found nothing bad in there - LGTM
[15:37] <Laney> ximion: suggest you test :P
[15:37] <Laney> but thanks!
[15:37] <ximion> (I will need to test it with Debian once it has been merged though, to spot any accidential breakage)
[15:38] <Laney> shall I fix the set thing?
[15:38] <ximion> Laney: yes, that's be great
[15:38] <Laney> ok
[15:38] <Sweet5hark> seb128: digging in my memory I think the other time where I saw such a "make looping" thing was actually on the snap build (which is 16.04 baseline after all). However that "disappeared" somehow. I fear there is some Heisenbug that depends on some weird stuff in the env ... after all four platforms broke here at the same time and other times it is reasonably well.
[15:40] <Sweet5hark> seb128: and "make looping" can also be make thinking it needs to restart itself (to reparse new dep files etc.). then again that doesnt match up with make still thinking it has active child jobs here ....
[15:40] <seb128> yeah, let's see what we get
[15:40] <seb128> other builds are still ongoing
[15:40] <ximion> Laney: do you know any (fast) way of checking whether a screenshot exists on screenshots.debian.org?
[15:41] <ximion> I think folding in screenshots into the AppStream data would make some sense
[15:41] <Sweet5hark> yep. /me goes jogging for a round, should be back when there is one hanging ...
[15:41] <seb128> Sweet5hark, enjoy!
[15:43] <Laney> ximion: https://screenshots.debian.net/json/package/coreutils
[15:44] <ximion> oh yeah!
[15:44] <Laney> seems you can get https://screenshots.debian.net/json/package/realpath or https://screenshots.debian.net/json/package/libgio-fam or https://screenshots.debian.net/json/package/libglib2.0-0
[15:44] <ximion> that's even better API than I was hoping for
[15:44] <Laney> many different failure types
[15:45] <ximion> and here goes my excitement...
[15:45] <Laney> it's not that bad
[15:46] <Laney> catch http errors, try the good json path and see if you get anything
[15:46] <Laney> either it's a 404 or "screenshots" doesn't contain what you want
[15:47] <ximion> that's what I will do
[15:47] <Laney> still weirdly inconsistent though
[15:49]  * Laney wah
[15:51] <Laney> using the AA changed the order of the output which breaks the test
[15:51]  * Laney sorts stuff
[15:54] <Laney> better
[15:57] <ximion> Laney: one interesting thing about D AAs is that - while being random - their ordering is much more predictable still than the Python dictionaries are, which look completely shuffled everytime you recreate them
[15:57] <ximion> I wonder how the AAs/dicts are implemented and what's causing this
[15:58] <ximion> (there is no performance difference)
[16:01] <Laney> would be interesting to know
[16:01] <Laney> hashtables are comples beasts
[16:01] <Laney> pushed the change btw
[16:03] <xnox> ximion, yes python uses randomisation, but one can reproduce the order by seeding the initial seed every time.
[16:04] <xnox> or don't rely on the order, and sort things in test-suite.
[16:05]  * xnox really hates gcc6
[16:06] <xnox> well, g++-6
[16:07] <Laney> 666
[16:07] <ximion> Laney: ok - would you fix the remarks I made in the PR? If not, I can do that quickly as well, it's all minor changes
[16:07] <Laney> ye
[16:08] <Laney> in one of those you comment on your own code that I just reindented :P
[16:10] <ximion> :D
[16:10] <ximion> that was probably from when I didn't know D yet
[16:10] <ximion> (the Debian backend is the olderst code in the project)
[16:15] <Laney> ximion: ok, pushed the fixes
[16:15] <Laney> there's some other scope(exit) without the space too
[16:15] <Laney> didn't fix as they aren't part of this set
[16:17] <ximion> ok, I'll look at them
[16:17] <ximion> I'll merge this as soon as the CI is green, and then test it locally and (if that worked) on Debian
[16:17] <Laney> nice
[16:17] <Laney> enjoy the translations
[16:18] <Laney> next up is langpacks :(
[16:18] <Laney> I probably should make an ubuntu backend for this
[16:18] <Laney> if it's possible for this to just copy the debian one and override one function, or something similarly lightweight
[16:18] <Laney> s/copy/inherit from/
[16:20] <ximion> Laney: you should be able to inherit from the Debian backend
[16:20] <ximion> I see no reason why that wouldn't work
[16:20] <Laney> hope so
[16:21] <Laney> although it requires looking in the desktop file
[16:21] <Laney> which is in the core code...
[16:21] <Laney> hmm
[16:23] <ximion> right, that will break the backend limitations
[16:23] <ximion> translations patch merged
[16:24] <Laney> sweet
[16:24] <Laney> enjoy
[16:42] <jbicha> I'm getting bug 1605868 when I try to change settings in software-properties-gtk
[16:44] <Laney> is aptdaemon installed?
[16:46] <ricotz> Laney, seb128, Sweet5hark, libreoffice amd64 is stuck
[16:46] <jbicha> Laney: no but installing it fixed it, should we make that a Depends then?
[16:46] <Sweet5hark> ricotz: yes, as is i386
[16:46] <Laney> Sweet5hark: gogogo #webops
[16:49] <Laney> jbicha: It seems like it depends on python3-aptdaemon.gtk3widgets which is okay, but python3-aptdaemon only Recommends aptdaemon - maybe this is what needs to be upgraded
[16:51] <Sweet5hark> arm64 and s390x still building
[16:53] <jbicha> Laney: ok I'll do that
[16:55] <Laney> jbicha: just a preliminary look, but it seems like if it uses aptd over dbus unconditionally then it should depend on it
[16:56] <Sweet5hark> seb128: the more I look at this the more weird it is. the rule that hangs is this here: http://opengrok.libreoffice.org/xref/core/solenv/gbuild/CppunitTest.mk#98
[16:58] <Sweet5hark> seb128: and the $(call gb_Output_announce ..) is just a glorified $(info ) -- so GNU makes way of "echo". And that is already on stdout. So the rule is already expanded. However, the sd_export_test command that follow is _not_ spawned it seems. at least its not on the output.
[17:14] <willcooke> night all
[17:29] <Sweet5hark> seb128: see discussion on #webops. everything is horrible.
[17:31] <Sweet5hark> seb128: given this is smelling a bit like IPC b0rkage, I wonder if trying to restrict jobs to 1 would help ...
[18:47] <Sweet5hark> k, #webops says aint nobody got time for that, so I spammed multiple ppa builder with various shots into the dark which could circumvent this issue ....
[18:47] <Sweet5hark> and with that good n8 ;)
[21:26] <attente> robert_ancell: hey, i have to head out for a few hours, but there's this commit here from master that i think is meant to replace a lot of the gs-application.c hackery: 995f9967c1e943760bba40b89462b65ea2bea311
[21:26] <robert_ancell> attente, ok, I'll try dropping our stuff then
[21:27] <attente> i'll have to take a closer look to see how to make it work to fix the corresponding bug though
[21:29] <jbicha> robert_ancell: could you look at bug 1613954 ? I'd like to upload some gnome-games today (thurs) that need it
[21:37] <robert_ancell> jbicha, done
[21:40] <jbicha> thank you