[01:14] hi, does anyone know a good code snippet manager on ubuntu ? [03:12] RAOF, what makes Vala code unreviewable for SRUs? [03:13] robert_ancell: The only thing I see is the generated C code, and relatively small changes to the vala code make drastic changes to the C. [03:13] RAOF, also, prepare for some serious convincing [03:13] RAOF, Don't you just ignore the .c code? [03:13] Do you even ship the vala code? [03:14] RAOF, yes [03:14] It's possible that I didn't notice that because the pages and pages of C. [03:14] yeah, autotools is stupid and likes to ship the .c [03:15] I did try a hack that mterry came up with to stop it doing that, but it's a bit dodgu [03:15] Also, I was predisposed to reject it, as “rewrite feature X to prevent slowness caused by feature X” starts from a position of ‘that's probably not SRUable’ :) [03:16] ah, unity-greeter doesn't ship the .c files. I'll copy that for new versions [03:16] Yeah, please do so. [03:16] RAOF, the slowness is critical (i.e. it easily becomes unusable after more than a page or using high res colour pages) [03:16] RAOF, so the only real option is to disable the autosave or use the new version [03:17] Given it's not a critical app and it's so broken I opted for the latter [03:17] Deleting the file on clean exit doesn't resolve that? [03:17] RAOF, no, it already does that [03:17] Ok. [03:19] So now you get to convince me that "all new shiny autosave code" is more appropriate than "disabling autosave" :) [03:20] Well, it can't be worse than broken autosaving code? [03:21] * robert_ancell can't wait until we don't have to do SRU's anymore [03:22] RAOF, the main reason I want the new autosave code is it will be a better experience for users [03:22] And as the upstream, I'm happy to weather any problems that may arise from that [03:23] Of course it can be worse than no autosaving code! It can *crash* :) [03:24] The SANE drivers crash all the time, much more often than simple-scan. Which is why the autosave code is there [03:24] What does the autosave do, anyway? I've never hit it (nor the problem, obviously) [03:24] Ah, SANE. [03:24] errors.ubuntu.com shows all the SANE errors [03:24] Such a terrible name. [03:24] The API isn't bad, it's just the awful implementations [03:24] I found a char[7] code that reads from the *network* and doesn't have any bounds checking in a HP driver [03:25] ...! [03:26] it was getting "HTTP/1." before it crashes. Probably some proxy or something in the middle. It was expecting "n\r\n" where n is an integer [03:27] RAOF, so, what's it going to be? How many beers will this cost? [03:27] Let me have another look at the diff... [03:34] bbl [03:34] I particularly like the way Vala leaks the details of your development directory structure :) [03:41] robert_ancell: That's a sizeable chunk of code :/ [04:21] RAOF, the autosaving? [04:21] Good morning [04:33] Trevinho, all those u-g branches are good to land - feel free to push whenever you want [04:33] I thought I'd got u-g setup with Jenkins, but apparently not [04:33] robert_ancell: Yeah, the autosaving. [04:34] RAOF, the delta or the module? [04:35] robert_ancell: ah, cool... thanks for the reviews... [04:35] robert_ancell: I was waiting for jenkins as well, but if it's not the case, should I proceed with manual merge? [04:36] robert_ancell: The delta. Well, and the module :) [04:37] Trevinho, yes, go for manual [04:37] robert_ancell: ok, perfect [04:43] Trevinho, are you looking after u-g now? [04:44] robert_ancell: ehm, what you mean? [04:44] Trevinho, I wondered if bregma had assigned it to you or you were just fixing the dialogs :) [04:45] robert_ancell: oh, no.. I did that by myself [04:45] robert_ancell: I think andyrock will work on the locker side [04:45] ok, cool [04:45] screensaver I mean [04:46] I just saw your initial work and I put some efforts in improving it to match unity.. [04:49] Trevinho, much appreciated! I wasn't sure if I could get all those features in there [04:50] robert_ancell: me neither :) but I wanted to give a try, and see if everything was feasible without much time... and it was :) [04:55] bye all === duflu_ is now known as duflu [09:00] good morning desktopers! [09:02] oh,pitti is piloting [09:02] rroooooooarrrrrr! [09:02] ;-) [09:02] 52 -> 32 so far:) [09:03] pitti, I unsubscriber sponsors from https://code.launchpad.net/~timchen119/gnome-settings-daemon/gnome-settings-daemon.precise.lp1055874/+merge/194661 yesterday, but it still needs reviewing ... if you feel bored (not sure how well you know that part of the gsd code) [09:03] seb128: he's exceeding mac2 at the moment, but still accelerating to mac3 :) [09:03] (I subscribed sponsors because I started having a look/it seemed a desktopish one) [09:03] hey btw! [09:03] didrocks, good morning, and no I was not drinking, I was doing exercice, and by the time I was back seems like you left to drink :p [09:04] seb128: ahah! ;) [09:04] didrocks, what's the bug btw? [09:04] if you go to the g-c-c shorcuts panel [09:04] you can't assign alt (alone) to anything anymore [09:04] like "to show the HUD" [09:05] howdy [09:05] didrocks, I can... [09:05] didrocks, well, it writes "mod2+alt L" but that works (e.g "alt" opens the HUD) [09:06] interesting, latest trusty, right? [09:06] didrocks, for desktop components, yes [09:06] "disabled" here… [09:06] Laney: hey! mind trying assigning alt to a shorcut in g-c-c? [09:06] Laney, good morning ;-) [09:06] haha [09:08] it goes to "disabled" [09:10] I think you can't have modifiers alone [09:10] isn't that known? [09:10] Laney, you can, we have a GTK patch for that case [09:10] like a known bug [09:10] and it's working for me [09:10] seems to be the case here [09:10] but didrocks has the same issue than you [09:10] unless it got lost in T? [09:10] wfm [09:11] hmm [09:11] but I'm running GTK 3.10 pre packages atm [09:13] want to share those? [09:13] can check if it gets fixed [09:15] Laney, well ... I've only a local build and it's i386, so don't bother, I'm downgrading GTK to see if that's fixed [09:15] Laney, https://code.launchpad.net/~ubuntu-desktop/gtk/ubuntugtk310 has the current version if you want to build it yourself [09:15] ok [09:15] Laney, https://code.launchpad.net/~larsu/gtk/3.10/+merge/194619 has some review comments/the list of bugs that need to be fixed before we upload to the ppa for more testing [09:17] Laney, should jenkins automatically pick up the autopkgtests? (in gjs) [09:17] Laney, didrocks: wfm with gtk from trusty, so that's not this one either [09:18] darkxst: in theory, but it doesn't always work [09:18] darkxst: oh, that stuff might be down atm? [09:19] there's QA lab maintenance [09:19] well gjs was in -proposed for more than a week, surely it should have picked it up then? [09:20] mmm [09:20] jibel: ^^^ is there a problem with adt job creation? [09:23] Laney: -ENODATACENTER [09:23] pitti: See darkxst's previous line [09:23] was around before that was true [09:24] darkxst: ah, was that the first version to introduce an autopkgtest? [09:24] yeah [09:24] ubuntu1 was [09:24] there's a known bug that the first upload isn't being tested [09:24] first upload to introduce a test ,that is [09:25] unrelated: looks like indicator-application libdbusmenu ubuntu-download manager are saucy > trusty [09:28] bah, something made my xorg unhappy [09:28] Laney, saucy > trusty, yeah, that's thanks to trusty autolanding not happening anymore for over a week and being blocked on a touch image to be green [09:28] I was pondering doing a pocket copy of those SRUs [09:28] mmm [09:29] but didrocks is going to be unhappy if I do that (or we need to merge the SRU changelog back in trunk which is a pain to do) [09:29] seb128: I don't think that you blocked on touch image to be green [09:29] are* [09:30] didrocks, I asked on -ci-eng on monday and somebody told me that there was no landing of things that are not helping the image to be back to green [09:30] seb128: that's not what I wrote on the email [09:30] but monday is not a week [09:30] didrocks, can we do a landing of indicator's stack today then? [09:30] seb128: is the CI engine back? [09:31] dunno [09:31] I didn't see any email [09:31] didrocks, well, my "a week" is based on how long my u-s-s landing ask has been sitting without change in the landing ask table [09:32] seb128: yeah, blocked first on autopilot 1.4 [09:32] seb128: you can thanks the QA team [09:32] and then the CI went down [09:32] didrocks: no, CI isn't back [09:32] not fair to blame on other things like "we are blocking for a green image" [09:32] didrocks, I'm not blaming anyone, but it feels like we are stucked atm to land stuff from the indicator stack in trusty [09:33] seb128: right [09:33] nothing we can do about it [09:33] and clearly not blocked on a green image [09:33] could copy the packages [09:33] is there any urgency to do that? [09:33] is it blocking anything? [09:33] are you going to merge back with the current info? [09:33] exact* [09:33] (knowing that the commit numbers don't match) [09:34] it's blocking high e-u-c-ranked segfaults fix to land [09:34] if you can answer to "yes" for all of this, I'm fine [09:34] no [09:34] I'm not going to bother merging thing back, I'm just going to let those segfaults in and wait, no big deal [09:34] ok then, no need for that discussion in the end :) [09:34] I just never though we would see a day with SRUs either to get it than uploads to unstable series [09:35] well, it's very frustrating to let know high visibility segfault in because our processes are so tedious [09:35] we should maybe revisit the rule to block to unstable series in those circumstances [09:35] but yeah, sorry for the ranting [09:35] oh come on [09:35] don't start… [09:35] sigh [09:35] ok, back to the meeting that is delayed because of that discussion [09:36] Laney, hm, first trace of gjs in britney's logs are yesterday, nothing before that day. Has 1.38.1-0ubuntu1 been ever published? [09:36] jibel: in proposed, didn't migrate to release [09:36] because of ppc ftbfs [09:36] Laney, ok [09:45] seb128: ev suggests that you talk with him directly about the CI shutdown [09:46] didrocks, I've no problem with the CI shutdown, it's maintenance and needed, I've a problem with the fact that we can't pocket copy good fixes from saucy-proposed to trusty (at least without having to then do manual merging of changelog hackery) [09:47] Those fixes are in trunk [09:47] seb128: you can ignore if you do the landing yourself the changelog, remember? [09:47] You should be able to just override the changelog check [09:48] Laney, right, but we can't land trunk because of the CI (and because there are changes to use upstart for indicator that probably need a bit more thinking/testing for landing) [09:48] Laney: you can [09:48] seb128: I just mean that the copy shouldn't create any work if the fixes are already in trunk [09:48] because they're not going to be lost [09:49] Laney, well, last time I did that I got sil2100 and cyphermox pinging me a few hours later to get the changelog of the copy merged back in trunk [09:49] which is not the end of the world, but it's annoying still [09:50] right, suggesting we could be more relaxed about that [09:50] again, you can ignore the destination if you handle the landing [09:50] but seems nobody reads [09:50] anyway, continuing doing work, all the MP would have been done by the time we discussed it === tvoss is now known as tvoss|test [09:50] it's quite hard to have discussions about this if people are touchy === tvoss|test is now known as tvoss [09:51] Laney, yeah :/ [09:51] didrocks, let's forgot about it and wait for the CI to be back (I don't want to have to handle the next landing of the indicator stack since there is an upstart-job transition in there that I didn't follow) [09:51] ok, fine :) [09:52] ok, let's move on [09:52] didrocks, sorry about the discussion [09:52] seb128: no worry, we'll be better tomorrow with the CI back (I hope :)) [09:53] seb128: we are trying to still spin images without results to dogfood if something horrible broke [09:53] FYI [09:53] (which totally destroyed ogra_'s week-end FYI ;)) [09:53] Constructively, it'd make it easy for manual uploads (from the point of view of cu2d) if all uploaders could set some flag saying 'please overwrite this archive upload' [09:53] which the vanguard / whatever they're called doesn't need to care about [09:53] didrocks, not that much though, i shared the pain with rsalveti [09:53] just happens at the next normal run [09:54] Laney: you think the override should be in the upload? [09:54] it means that the next commit can revert your fix [09:54] ogra_: pairing pain [09:54] :) [09:54] Not necessarily [09:54] :) [09:54] larsu, seb128 hi [09:54] seb128: so diwic started implementing https://wiki.ubuntu.com/Sound#Handling_unknown_audio_jack_devices [09:54] Laney: ok, in CI "new world", this will be accessible by all core dev in the system FYI [09:55] do you think g-s-d is the best place to have this? (a new plugin?) [09:55] larsu, at least implementation planning [09:55] diwic, hey [09:55] to tell "please ignore v" [09:55] diwic: heh, ya [09:55] yeah [09:55] like the hinting in britney [09:55] that's what I'm asking for [09:55] seb128: we were thinking indicator-sound first, bt that can't have a gtk dep anymore [09:55] so I can do an upload, handle it in trunk, and then flag cu2d to ignroe that [09:55] ignore the manual upload [09:55] Laney: yeah, that's planned in the UI [09:55] so the pipe is unblocked as it were [09:55] nice [09:56] oh poop, webkitgtk migrated [09:56] without an arm64 build [09:57] seb128, what larsu said, do you think gnome-settings-daemon would be a good place for a "What did you plugin?"-dialog ? [09:57] Laney, it's a new package, it never built on that arch [09:57] yes but it makes binaries on arm64 outdated [09:57] the old webkit1 ones [09:57] seb128, and I've been asked to this for our pre-installs, which still ship with 12.04, so an SRU back to 12.04 will probably be necessary [09:58] didrocks, btw found back the "can't land stuff that don't help the image to be green", that was from ogra [09:58] nov. 08 14:28:45 though the current word is, only stuff that improves the image to go gree on the dashboard is allowed to enter [09:58] bad bad ogra_ :) [09:58] that's why I thought it would be stopped [09:58] in my email, it was: [09:58] Laney, ok, dunno about that :/ [09:58] well, it's probably a misunderstanding on my part [09:58] Laney, did we have webkitgtk ever building on arm64? [09:58] yes [09:58] Here is what I think we should do: [09:58] 1. ubuntu-ui-toolkit should their backward compatibility issue and shipping that (I heard this is already under work) [09:58] 2. balloons is going to coordinate the core apps team side (ubuntu-weather-app, ubuntu-terminal, ubuntu-rssreader, ubuntu-filemanager, calendar-app) [09:58] but now it's more complicated [09:58] 3. bfiller is going to get his team fixing notes-app and mediaplayer-app. webbrowser-app will be fixed in image 15. [09:58] Please until then, refrain from merging/releasing anything that can impact those component test results. We need to ensure we are progressing quickly. [09:59] I don't think the indicators is going to impact ubuntu-ui-toolkit, not those apps [09:59] nor* [09:59] sorry ! [09:59] the current series looks like it'll fix it though, so I guess we should take that [09:59] ogra_: don't make the seb angry! :) [09:59] didrocks, it was what i understood from the meeting ... [09:59] means taking a dev series which isn't the best, checking in #debian-gnome if it's going to be stable [09:59] Laney, define "current serie", please tell me it's not the GNOME 3.12 one [09:59] & test building [09:59] (though that was before CI went down) [09:59] ogra_: I think the written down part will help more ^ [09:59] k [09:59] didrocks, ogra_: ok, thanks for clarification [10:00] FYI 1 and 3 are done [10:00] so, only 2 [10:00] (and I don't think apart from the toolkit, anything will impact 2) [10:01] diwic, larsu: sorry, lot of discussions happening here atm, a bit difficult to keep track ... let me think [10:01] seb128, no worries [10:02] diwic, larsu: ideally any new code would be though with ubuntu-touch in mind, and g-s-d is not going to be available there ... [10:02] diwic, larsu: could we get the logic/detection in the indicator and have a separate UI or would that be too complex? [10:03] seb128, we don't want it on ubuntu touch for the foreseeable future [10:04] seb128, all phones can successfully distinguish between headphones and headsets AFAIK [10:04] diwic, why not? (keep in mind that touch is going to be our desktop after the coming LTS, we for sure don't want to regress that feature under unity8?) [10:05] diwic, touch->unity8 if that helps btw [10:06] seb128: would that mean that indicator-sound would need to show qml dialogs? [10:06] diwic, e.g the goal is to make sure new features are made with unity8 sessions in mind, which means either have the choice of the frontend or make easy to replace the GTK bits by Qt ones [10:06] hm, fair point. [10:06] larsu, ^ under unity8 it would make sense [10:06] no? [10:07] larsu, that's not something we need to focus on for the LTS [10:07] seb128, I've never even heard of unity8 sessions...seems I have some catching up to do [10:07] but if we write new code I would rather to have most of it re-usable [10:07] rather than having to throw it away and rewrite for unity8 in one cycle [10:07] diwic, larsu: does that make sense? [10:08] I agree, but not as long as we need to have it running on the current desktop [10:08] which is what I focussed on when thinking about this [10:08] right [10:08] we could have indicator-sound have the logic an hit a name up on the bus that activates an executable which shows the dialog [10:08] well my point is that it would be nice to do it in a way where the device detection would be in the backend [10:08] slightly cringeworthy... [10:09] I think most of the code here is actually dialog layout. [10:09] seb128: I don't think there's that much detection [10:09] ok [10:09] sure, there'll have to be something talking to pulseaudio too, I guess [10:09] it'll be more or less like "pulse, what kind of device is this? Ah, a shitty one. Show a dialog please" [10:09] how much work is that stuff? [10:09] diwic: correct me if I'm wrong^^ [10:10] I would almost recommend doing it in the indicator with a Qt dialog [10:10] though I would prefer a GTK UI for unity7/the LTS [10:10] larsu, I think that anything that's not GUI wise can be directly in pulseaudio. [10:10] I'd be fine with having a separate executable though [10:11] larsu, so if the dialog is in a separate executable, maybe PA can fire that dialog rather than the indicator? [10:11] diwic: can it? I'm not too familiar with what you can do on pulse events [10:12] Laney, do you suggest taking the webkit matching GNOME 3.12? how sure are we that they are not going to make change that imply apps porting? [10:12] seb128: That's what I asked & pochu pinged kov about [10:13] Otherwise try to backport the arm64 porting patches which sounds hairy [10:13] larsu, well, PA modules can fire executables. I just wonder if that executable will have the right environment set etc for doing GUI stuff. [10:14] larsu, but PA does talk to X11 at least. Maybe that is enough to do GUI stuff as well? [10:14] Laney, another of those fun situations :/ [10:14] yeah [10:14] hopefully we get the right answer [10:15] diwic, larsu: that dialog seems little enough code that it should be easy to redo a qt version next cycle if needed, so do whatever is easier (might be less work to do 2 frontends that to over-engineer it) [10:15] diwic: should be if it starts anything from inside the session. Is it smart enough to only start the executable when that type of device shows up? [10:15] larsu, seb128 and then we try to do as much logic as possible in PA, leaving only the dialog layout to the executable [10:16] +1 [10:16] diwic: I wouldn't like a solution where pulse always starts that binary and the binary would need to find out whether to show the dialog or not. Seems wasteful on machines with proper audio hardware [10:16] diwic: yeah, that sounds good to me. (To be honest, that's my favorite solution so far) [10:16] larsu, no; I'll write the PA module so that it only fires the dialog if the dialog should actually be shown [10:16] diwic: awesome! [10:17] seb128: I totally agree. It's a window with five buttons and a checkbox [10:17] seems like a plan then [10:17] larsu, diwic: thanks ;-) [10:18] larsu, seb128 and the dialog result would be communicated back by... [10:18] diwic: couldn't the app just use pulse's api to switch device type? [10:18] larsu, sure, but then the dialog needs to connect to PA, which makes it more code in that app === Sweetsha1k is now known as Sweetshark [10:20] larsu, I'm thinking maybe one could just communicate back through reading the exit code from the executable [10:20] diwic: right. I can't think of another clean solution though [10:23] seb128: btw, I think webkitgtk & webp need promoting to main [10:23] larsu, or reading stdout/stderr perhaps [10:23] Laney, oh, right, new source ... I'm on it [10:23] ty [10:24] diwic: I recommend against doing that. Is it really that much hassle to connect to pulse? [10:24] diwic: ad-hoc results on stdout sounds like a debugging nightmare down the line to me [10:26] larsu, it is a bit of hassle, but overcomable. Could you elaborate on why you think using stdout is bad? Are you afraid something else will output there too? [10:34] diwic: it sounds less robust to me, because now the pulse module must keep state about that application (to wait for it to return; and handle error cases) [10:34] ideally, it would just do this over dbus [10:35] that would also fix the case of me unplugging and replugging the cable while the dialog is up [10:35] so that we don't show two dialogs [10:36] (I mean using dbus would solve this) [10:36] Laney, did you look at merging epiphany-browser (just asking because you did webkit), if not don't worry about it, I started the other day (before noticing it needed the new webkit) [10:36] larsu, hmm, that's an interesting corner case. In that case the PA module should kill the dialog, in my scenario [10:37] diwic: in mine, it would simply activate the same name again on the bus, but since the dialog is already running and owning the name, nothing would happen [10:37] seb128: nope, not yet [10:37] diwic: I just feel like having state inside the pulse module and this weird interaction between the two might get cumbersome [10:37] Laney, ok, I'm going to do that one then [10:38] diwic: in all fairness, you don't have to do it my way. I'm just thinking out loud :) [10:38] larsu, you'll need to have some state inside the pulse module anyway - because you have the "remember my choice" checkbox, which is an interesting twist [10:38] diwic: can't that be a dconf key? [10:39] ah wait, pulse doesn't do dconf I guess? [10:39] but it must have some way to store configuration, no? [10:40] larsu, sure, it stores configuration [10:41] diwic: can that be set by the public API? (i.e., could the dialog set it?) [10:42] larsu, might require a protocol extension unfortunately - but I might have to do that anyway for sound settings [10:44] diwic: it occurs to me, if we're separating the logic from the ui anyway, we might as well do it in indicator-sound [10:44] diwic: it already has a gsettings schema. The dialog could just write into that [10:45] problem solved [10:45] the code for the dialog executable could even live inside the same source package [10:50] larsu, I'm thinking that maybe I should start writing the backend logic and then, in a first iteration, have PA fire up a zenity dialog. In next iteration, replace the zenity dialog with something that looks more like mpt's design. Upstream might even like the zenity version and accept it [10:53] diwic: sounds good to me :) [10:54] oh cool, gnome-online-accounts is already split in experimental [10:54] fatal++ [10:54] larsu, seb128 ok, thanks for the chat. Seems like we come up with a different solution every time we talk about it :-) [11:16] mvo, hey, how are you? === gatox is now known as gatox_brb [11:31] xnox: feel free to mangle imagemagick [11:31] for webp [11:32] Laney, ok, so epiphany-browser depwait on arm64 due to webkit not building here ... do you think we should block migration on that? (or should we just delete the old arm64 epiphany-browser binary so it can migrate?) [11:33] Give me a bit to test build this current webkit [11:35] ok [11:36] btw I test built gtk and it hung in the testsuite, was giving errors about unavailable schemas too [11:37] probably should look at that list of issues before raising things ;-) [11:39] Laney: \o/ [11:40] Laney, the schemas errors didn't fail the build here and I didn't get the hung [11:41] Laney: in which test? I thought I had gotten them all... [11:42] let me see if it saved a log [11:42] Laney: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1117481/comments/3 ... and we moved webp into main =/ [11:42] Launchpad bug 1117481 in imagemagick (Ubuntu) "Imagemagick lacks support for webp" [Undecided,Opinion] [11:42] haha [11:43] xnox, hopefully we can move webkitgtk to universe once we have our own bindings... [11:45] Laney: then again https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=imagemagick is not exactly stellar =) [11:45] seb128: while webp is in main, I'd take the opportunity. [11:45] mmm, I don't find many CVEs === gatox_brb is now known as gatox [11:46] chrisccoulson, hey, is there any way you could use your magical powers to see if https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1200272 is known upstream? I didn't find it in their bugzilla but I've a feeling bugzilla is not the place to check for that [11:46] Launchpad bug 1200272 in firefox (Ubuntu) "firefox crashed with SIGSEGV" [Medium,Confirmed] [11:47] don't have a log for gtk, will need to rebuild [11:56] larsu: http://people.canonical.com/~laney/weird-things/gtk+3.0_3.10.2-0ubuntu1~local0_amd64.build [11:56] large file, don't open it in your browser [11:57] too late :D [11:57] heh [11:58] Laney, what's weird in it? [11:58] nothing [11:59] I can't remember why I called that directory weird-things [11:59] there was probably a good reason at the time [11:59] heh [11:59] ah, settings schemas again [11:59] oh yeah, they are kerrrrrrrrrrrazy [11:59] I'm guessing my patch simply doesn't install them right [12:00] I'll will have a more detailed look after lunch === MacSlow is now known as MacSlow|lunch [12:00] larsu, Laney: debian workaround it in debian/rules if we want to copy that [12:00] they do [12:00] # So that gsettings can find the (uninstalled) gtk schemas [12:00] pre-build:: [12:00] mkdir -p debian/build/glib-2.0/schemas/ [12:00] cp gtk/org.gtk.* debian/build/glib-2.0/schemas/ [12:00] glib-compile-schemas debian/build/glib-2.0/schemas/ [12:00] # So that gsettings can find the (uninstalled) gtk schemas [12:00] export XDG_DATA_DIRS=/usr/share:$(CURDIR)/debian/build [12:00] oh yeah, it's not a merge, right [12:01] seb128: ah thanks. I've tried fixing it in the build system: https://bugzilla.gnome.org/show_bug.cgi?id=711715 [12:01]