[01:18] <qengho> zaoshanghao
[01:26] <duflu> qengho: Morning?
[06:41] <pitti> robru: is it possible to remove a package from a CI train ticket again?
[06:47] <pitti> tedg: ^ for update-notifier
[06:57] <seb128> good morning desktopers
[07:00] <qengho> 5hi
[07:00] <qengho> hi
[07:00] <pitti> bonjour seb128!
[07:00] <pitti> hey qengho
[07:00] <seb128> salut pitti, ça va bien ?
[07:00] <seb128> hey qengho
[07:09] <pitti> seb128: oui, et toi ?
[07:10] <didrocks> bonjour pitti, qengho, re seb128
[07:10] <pitti> bonjour didrocks !
[07:12] <Trevinho> Morning folks!
[07:13] <Trevinho> Bonjour didrocks, seb128, pitti...
[07:14] <didrocks> hey Trevinho
[07:48] <seb128> hey Trevinho, how are you?
[07:49] <seb128> pitti,  ça va bien (sorry was just eating breakfast)
[07:49] <Trevinho> seb128: hey, allright..
[07:49] <Trevinho> Hi willcooke
[07:49] <seb128> Trevinho, getting a new landing going before the w.e? ;-)
[07:49] <seb128> Trevinho, do you have special plans for the long w.e?
[07:49] <willcooke> morning all
[07:50] <Trevinho> seb128: yeah trying to
[07:50] <seb128> hey willcooke
[07:50] <Trevinho> seb128: yeah going few days to the sea here...
[07:50] <seb128> nice
[07:50] <seb128> hope you have fun there!
[08:02] <Laney> morning!
[08:02] <hikiko> morning all!
[08:02] <willcooke> hi hi
[08:03] <duflu> Afternoon...
[08:04] <seb128> hey Laney hikiko duflu
[08:04] <duflu> Hey seb128
[08:20] <Laney> hi seb128
[08:20] <Laney> forgot to say hi back :(
[08:20] <Laney> good tennis?
[08:24] <seb128> yes, excellent, weather was perfect to play yesterday, not windy, not too warm/cold and I had a good feeling, did some nice serving and points
[08:24] <seb128> how was your evening?
[08:24] <Laney> ARGH
[08:24] <Laney> that beeping is still ongoing
[08:25] <Laney> evening was nice, went to the allotment and constructed some more path
[08:25] <Laney> then pub quizzed it up
[08:25] <seb128> ah, nice
[08:26] <Laney> one of the questions was "what is the name of moe's cat in the simpsons?"
[08:26] <Laney> nobody even knew that he had one
[08:26] <Laney> -> good question
[08:26] <seb128> I didn't know either
[08:27] <Laney> https://simpsonswiki.com/wiki/File:Mr._Snookums.png
[08:27] <seb128> learning every day!
[09:27] <Trevinho> hikiko: hey, can you check my branch this morning?
[09:28] <hikiko> sure Trevinho :)
[09:28] <Trevinho> hikiko: also there was a crash on closing google chrome... I've fixed it, but there are still some warnings I'd like to avoid
[09:28] <Trevinho> since we're trying to get info from an unmapped window with no winndow id
[09:31] <willcooke> desktoppers - please take a few mins to help smoketest the Trusty daily ISO booting on real hardware?
[09:32] <willcooke> davmor2, if you have a gap in your schedule?  ^
[09:32] <qengho> willcooke: Trusty?
[09:33] <Laney> https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
[09:33] <Laney> trusty
[09:33] <Laney> .5 is out soon
[09:34] <qengho> Ah!
[09:36] <davmor2> willcooke: that is next on my schedule now that 16.04.1 and upgrades are tested
[09:36] <hikiko> Trevinho, what's the point of renaming all the variables everytime? it's difficult to see the changes... btw at a first glance, I see some things that might cause problems, eg: I had the addDamage there because in mmon some shadows didn't update
[09:36] <hikiko> I haven't built it yet though
[09:36] <willcooke> thanks davmor2 - writing a USB stick here
[09:37] <hikiko> Trevinho, honestly, why changes like replace an if with foo ? bar : foobar  are necessary? they make the diff larger without adding any real optimisation
[09:37] <hikiko> it's just a matter of preference
[09:38] <hikiko> and why :s/width/Width for example?
[09:38] <davmor2> willcooke: I need to test server proposed too I think for the fix for d-i so I need to test that for sru verfication
[09:39] <Trevinho> hikiko: we've coding style in unity... guides/cppguide.xml
[09:40] <Trevinho> hikiko: adddamage is implicit there
[09:40] <hikiko> I am not sure, I was looking for a bug and this fixed it, I'll check in a while
[09:41] <Trevinho> hikiko: optimizations are in not rebuilding the shadows at every window movement though...
[09:41] <Trevinho> hikiko: now it happens only when the size of the window changes
[09:42] <hikiko> I'll check it with a real-time shadow in a while
[09:43] <hikiko> ok but anyway I think it would be better if you added a comment 7 months ago to rename the vars and the diff had your optimisations only so that it was cleaner anyway, thanks a lot, I am building :)
[09:44] <hikiko> now the diff has all my lines
[09:44] <hikiko> :p
[09:44] <Trevinho> hikiko: I did most of the changes several months ago (as you can see in the commit log), but then as you know other priorites come in, and we had to delay this
[09:45] <hikiko> yeah, i kno, i am not saying about the time anyway, I mean that the diff would be cleaner if we only see the optimisations and not the renames
[09:45] <Trevinho> Now I'm just trying to clean the plate with all the stuff we did and never landed, so we can hopefully SRU them if they work fine and leave unity7 in the best shape we can....
[09:45] <hikiko> because now it has every single line
[09:46] <Trevinho> hikiko: review commit by commit if you want... it should be easier
[09:46] <hikiko> yeah, good idea
[09:46] <Trevinho> hikiko: refactor is here, other commits are changes http://bazaar.launchpad.net/~3v1n0/unity/shadows-on-existing-pixmaps-cleanup/revision/4078
[09:46] <hikiko> thanks
[10:20] <Trevinho> hikiko: I've pushed a fix that was causing a warning when closing chrome...
[10:20] <willcooke> desktoppers (and davmor2) - I've done a test for x86 64 and 32.  Both passed and logged on the ISO tracker.  Moar testing please though
[10:21] <willcooke> ISO tracker here:  http://iso.qa.ubuntu.com/qatracker/milestones/308/builds
[10:21] <Trevinho> hikiko: can you get that revew done in 2 hrs? Since i'd like to do this landing...
[10:22] <seb128> willcooke, is there any point doing more standard intel hwd installs?
[10:22] <seb128> I can do some but I don't have any "interesting" config
[10:23] <seb128> like nvidia ones
[10:25] <hikiko> I am trying Trevinho
[10:25] <Trevinho> thanks
[10:30] <willcooke> seb128, certainly no point in you testing your Inspiron :)
[10:30] <willcooke> hikiko, could you try a live ISO on your NV machine?
[10:30] <seb128> willcooke, lol, I can do inspiron or vm ... :-/
[10:31] <hikiko> willcooke, I can but since I can't use intel and nv at the same time, could you wait a couple of hours to finish Trevinho's review?
[10:31] <hikiko> because I am on intel right now
[10:31] <willcooke> hikiko, of course, np
[10:42]  * Laney screams at D
[10:49] <Trevinho> Laney: instead of screaming... when you want to take a break, can you get ahead in reviewing the distro changes for https://requests.ci-train.ubuntu.com/#/ticket/1698 😝? So we can publish it straight forward once hikiko is done ;-)
[10:50] <hikiko> Trevinho, it seems to work but I am not sure about something I'll ping you in a while
[10:50] <Trevinho> hikiko: there's really no much change in terms of logic...
[10:50] <Trevinho> but sure
[10:52] <hikiko> well, if you want to merge it then I could check and do another mp, there aren't any crashes etc so I guess wont be a prob, just 1 thing I had a comment in PixmapTexture::Ptr
[10:52] <hikiko> Make sure to modify Window::Impl::ComputeShapedShadowQuad in
[10:52] <hikiko> /DecoratedWindow.cpp if you change the factor.
[10:53] <hikiko> but I can't find it, if you don't change both factors it will misfunction, maybe put it back?
[10:54] <hikiko> Trevinho, ^
[10:54] <Trevinho> hikiko: I've defined a const value for that which is shared now
[10:54] <hikiko> ok
[10:54] <hikiko> I didn't find that
[10:54] <Trevinho> hikiko: see SHADOW_BLUR_MARGIN_FACTOR
[10:55] <hikiko> ok
[10:55] <hikiko> found
[10:55] <hikiko> alright
[10:56] <hikiko> Trevinho, merge it since there aren't crashes, I am going to check the livecd and then come back to it, if I see anything I'll do another MP
[10:56] <hikiko> thanks
[10:56] <Trevinho> hikiko: fine... It used to crash before though
[10:56] <Trevinho> (as it was trying to paint an invalid texture, but this is not the case anymore)
[10:56] <hikiko> yes you told me, I never got that crash but I guess I was lucky
[10:57] <Trevinho> hikiko: I saw it with google chome all the times...
[10:57] <hikiko> sounds reasonable to crash if the tex was invalid
[10:57] <hikiko> yeah you told me and I tested it I had sent you a video I think
[10:57] <Trevinho> basically that was because we were setting the frame geo dirty on window that were destroyed, and trying to damage them
[10:57] <Trevinho> this was causing a paint loop... and all the rest.
[10:57] <hikiko> sounds like a bug, I just was lucky :)
[10:58] <hikiko> thanks
[10:58]  * Trevinho yeah this was the trace http://pastebin.ubuntu.com/21126640/
[10:58] <seb128> grrr intel drivers, vt switch and I've no vt prompts (systemd?) and now going back to vt7 my unity dash elements have no textures&co
[10:58] <seb128> ->reboot
[11:05] <hikiko> seb128,
[11:05] <hikiko> wait!
[11:05] <hikiko> i have that too
[11:05] <hikiko> you don't need a reboot
[11:05] <hikiko> just kill Xorg
[11:05] <hikiko> killall Xorg is fine
[11:06] <seb128> does that bring back vts as well?
[11:06] <seb128> but already rebooted
[11:06] <hikiko> yes
[11:06] <seb128> going to try next time
[11:06] <seb128> k, weird
[11:06] <seb128> thanks!
[11:06] <hikiko> welcome :)
[11:06] <seb128> but restarting X or rebooting is not much different
[11:06] <seb128> need to close my session :-/
[11:06] <hikiko> yeah :/
[11:07] <hikiko> I think this happens when xserver receives a signal
[11:07] <hikiko> but I can't recall which one
[11:07] <hikiko> it usually happens to me after dist-upgrade
[11:08] <andyrock> hey all
[11:42] <Trevinho> Laney: available for your lovely publishing hands https://requests.ci-train.ubuntu.com/#/ticket/1698 :-)
[12:31] <hikiko> willcooke: busy?
[12:55] <willcooke> hikiko, back
[12:55] <hikiko> welcome back willcooke
[12:55] <hikiko> there's actually a problem with nouveau
[12:56] <hikiko> I didn't realize that at once
[12:56] <hikiko> I tested the installation process that was ok apart from a small delay and flickering at the beginning
[12:56] <willcooke> hikiko, cool - so a pass from you?
[12:56] <hikiko> and then the desktop
[12:56] <hikiko> was idle
[12:57] <willcooke> hikiko, do you have write access to this?  http://iso.qa.ubuntu.com/qatracker/milestones/308/builds
[12:57] <hikiko> when the system went to sleep mode
[12:57] <hikiko> there was a hang
[12:58] <willcooke> hikiko, actually, this is the right page:  http://iso.qa.ubuntu.com/qatracker/milestones/308/builds/127049/testcases/1303/results
[13:00] <hikiko> willcooke: the bug is in the nouveau driver
[13:00] <hikiko> should I link it?
[13:00] <hikiko> if the system sleeps during the installation process it will fail
[13:00] <willcooke> hikiko, hmm.  It's not a failure in the sense that 14.04.5 is now broken, but yeah, log it and we can follow up with the driver guys
[13:01] <hikiko> I didn't finish the installation because it's not a vm, I stopped before "writing changes to disk"
[13:01] <willcooke> hikiko, you just needed to test a live session
[13:01] <hikiko> willcooke: did that
[13:02] <willcooke> hikiko, cool.  If you can mark it as a test passed then.  And then we can work out how to report to nouveau
[13:06] <dobey> Laney, seb128: can we get https://bugs.launchpad.net/ubuntu/+source/zeitgeist/+bug/1584849 at least into y and maybe SRUed to xenial?
[13:15] <hikiko> oh
[13:15] <hikiko> willcooke:
[13:15] <hikiko> I am sorry
[13:15] <hikiko> I didn't mark it as passed
[13:15] <hikiko> I didn't see the last line
[13:15] <hikiko> can I change it?
[13:15] <hikiko> found ok I changed it
[13:16] <willcooke> thx
[13:18] <seb128> oh come on intel
[13:22] <Laney> dobey: I put it in the sponsor queue, won't have time to look immediately but I have a patch pilot shift coming up if nobody else does it before then
[13:32] <dobey> Laney: ok. just saw you had done previous uploads of zeitgeeist, so thought i should ask you
[13:33] <ximion> Laney: I think I exist to annoy you ^^
[13:34] <ximion> (I just pushed a patch to asgen master which speeds up the generator by 4-6min (depending on how many suites/sections one processes), but that patch will almost certainly clash with your changes)
[13:34] <ximion> but maybe Git can rebase, who knows ^^
[13:36] <Laney> bah
[13:36] <Laney> merge them?
[13:37] <seb128> bah, downgraded back packages to proper xenial for the user session upstart/systemd but I still get indicators missing in the greeter when I try to switch user
[13:37] <Laney> also give me some ideas about why this happens and we can be friends again https://paste.debian.net/785587/
[13:38] <ximion> Laney: eh.... no memory? :P
[13:39] <ximion> for that, the patch I just committed might actually help
[13:39] <ximion> oh, and we can also get rid of that spawnProcess, at the expense of depending on a more recent libarchive
[13:39] <Laney> it can't fork
[13:39] <Laney> but I don't know why
[13:40] <Laney> meh
[13:40] <Laney> let me rebase and then try with the new thing
[13:41] <ximion> it's a bad habit of me that when I find an issue I end up moving all pieces around a lot to make it sane
[13:41] <ximion> (it usually ends up being much better than before - until I find some issue and rework that stuff again)
[13:41] <Laney> I would have preferred you to merge my stuff than make me understand what changed and adapt to it
[13:42] <ximion> Laney: I am actually just waiting for a PR from you, when you think it's ready
[13:42] <willcooke> hmmm.  Fresh install of 16.04.1 on my Inspiron has a slight odd looking font...  http://imgur.com/a/O190P
[13:42] <Laney> just take it without the PR if you know you're going to break it
[13:42] <Laney> I don't mind
[13:43] <ximion1> [15:42] <ximion> Laney: I am actually just waiting for a PR from you, when you think it's ready
[13:43] <willcooke> bah, that screenshot sucks, this is better:  http://imgur.com/a/qUAI2
[13:43] <willcooke> seb128, did you see this on your Inspiron? ^
[13:43] <Laney> 27/07 14:42:25 <Laney> just take it without the PR if you know you're going to break it
[13:44] <Laney> 27/07 14:42:26 <Laney> I don't mind
[13:44] <willcooke> seb128, sorry, this:  http://imgur.com/a/qUAl2
[13:45] <seb128> willcooke, I didn't notice but I don't have a good eye for details and tend to overlook those, let me boot it to see how it's there
[13:45] <ximion1> I didn't know I would break it
[13:46] <ximion1> fortunately there's no functional break, you probably just need to add overrides
[13:46] <willcooke> seb128, bah, ignore.  Reboot and it's fine now
[13:46] <seb128> willcooke, can you try to go the switch user and see if the greeter has all its indicators?
[13:46] <seb128> willcooke, like lock screen and use the session indicator to "switch user" or open a guest and close it
[13:47] <willcooke> seb128, Heisenbug
[13:47] <Laney> ximion1: I mean "hmm, these changes touch that code - I'll just grab the commits and then make my refactoring"
[13:47] <Laney> you can ask me if that's a good idea if you want, I'm always online in the day
[13:47] <Laney> anyway
[13:47] <Laney> doesn't look that bad at first glance
[13:48] <bregma> hey desktoppers, I'm looking for additional testers for a unity8-desktop-session landing in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-007
[13:48] <Laney> thanks for the optimisations!
[13:49] <willcooke> bregma, just reinstalled my test machine to test u8 things! :)
[13:49] <bregma> initial testing surfaced some incompatible apps, so more testing is better
[13:49] <willcooke> bregma, I'm investigating reports that apps stopped running again
[13:49] <willcooke> bregma, is that the same thing?
[13:49] <seb128> willcooke, heisenbug? you mean indicators work for you?
[13:49] <willcooke> bregma, oh wait - I'm testing 16.04
[13:49] <bregma> willcooke, not unless they already installed that silo
[13:50] <willcooke> seb128, that font bug has vanished as soon as I started to look at it
[13:50] <seb128> k
[13:50] <seb128> willcooke, can you still try the indicators one? ;-)
[13:50] <willcooke> bregma, lemme do these 16.04 ones and I'll loop back
[13:50] <willcooke> seb128, testing now
[13:50] <seb128> thanks
[13:50] <bregma> willcooke, sure
[13:52] <willcooke> seb128, all indicators missing except a11y.
[13:52] <seb128> shrug
[13:52] <seb128> willcooke, thanks
[13:52] <seb128> "great"
[13:53] <willcooke> seb128, also super-L in guest session seems to spawn a new session leaving the old ones running
[13:53] <willcooke> realted?
[13:53] <willcooke> related
[13:53] <seb128> urg
[13:53] <seb128> no
[13:58] <ximion1> Laney: it really isn't - if you want, I could even fix it up for you
[13:58] <Laney> ximion1: just pushed
[13:58] <ximion1> (should take less than 3min)
[13:58] <Laney> going to test it, then you can have a PR
[13:58] <ximion1> hehe ^^
[13:58] <ximion1> great!
[13:58] <Laney> then I work on Translation support
[13:59] <Laney> hope it's okay to rely on http://archive.ubuntu.com/ubuntu/dists/yakkety/main/i18n/Index
[14:00] <Laney> debian doesn't have this
[14:01] <Laney> although it is in InRelease
[14:01] <ximion1> ...yet
[14:01] <Laney> probably should just use that
[14:03] <Laney> why does git pull require an email address to be set?
[14:03]  * Laney slaps
[14:03] <Laney> oh right, it'is trying to do a merge
[14:03] <ximion1> pull can mean Git needs to do a merge, which it needs the mail address for...
[14:03] <Laney> I forgot I did some hax on the box directly
[14:04] <ximion1> btw, as long as it doesn't break Debian, any code in the backend is fine :)
[14:04] <Laney> I want this remote stuff to work for Debian too as far as possible
[14:05] <Laney> hopefully this abstract class thing means that I can put the langpack support in an ubuntu backend which inherits from the debian one
[14:05] <ximion1> sitter on KDE Neon is looking at the remote stuff too
[14:06] <ximion1> I wonder if it makes sense to implement a cache manager which handles this transparently for all backends
[14:31]  * Laney adds a timeout and then runs
[14:31] <Laney> timeout retry
[14:40] <bregma> I'm trying to track down the cause of something we see in Libertine: <Fly__> For terminal and firefox I get an error when it starting : "an error occured while loading or saving configuration information for terminator. Some of your configuration settings my not work properly". When I click "details" it says "Failed to activation configuration. The name org.gnome.GConf was not provided by any service files"
[14:40] <bregma> would anyone here have a suggestion as to why we see that and how to cure it?
[14:57] <seb128> bug #1521116 should be an easy one for andyrock right? ;-)
[14:58] <Laney> bregma: Sounds like gconf isn't installed in there
[14:58] <Laney> ximion: these unittest blocks
[14:58] <seb128> just got annoyed again by this one and looked to see if it was already reported, seems I did that in novembre :p
[14:58] <Laney> is there an easy way to mock something?
[14:58] <Laney> I want to provide sample Release files to test against
[14:59] <seb128> Laney, were you going to look at the landing Trevinho pingeg you about?
[15:00] <Laney> later, I have a tab for it
[15:00] <Laney> you can if you want though
[15:00] <seb128> no it's fine ;-)
[15:01] <seb128> just checking because I went over the backlog
[15:01] <seb128> if it's going to be handled it's fine
[15:01] <seb128> I guess we don't need to have Trevinho around after landing
[15:01] <seb128> worth thing we block it in proposed until monday
[15:02] <Trevinho> As you prefer
[15:02] <Laney> it's blocked either way because of freeze
[15:03]  * ricotz grabs Sweet5hark's 5.1.5rc2 package
[15:03] <Trevinho> andyrock can handle that in case if you help him landing something if needed
[15:04] <ximion> Laney: you could generate it at test-time, or place it in the test/samples directory
[15:04] <seb128> oh, right, alpha
[15:04] <seb128> I tend to forget about those since we stopped doing them
[15:05] <seb128> doing->participating in
[15:05] <Laney> ximion: the hard bit seems to be mocking a function?
[15:05] <Laney> I don't want to call the real download thing
[15:05] <Laney> -debian/00_remove_obsolete_plugins_in_unity_session_v1.py
[15:05] <Laney> +debian/00_remove_obsolete_plugins_in_unity_session_v2.py
[15:05] <Laney> haha
[15:06]  * Laney stares at the 00
[15:06] <seb128> lol
[15:06] <ximion> Laney: hmm.... http://stackoverflow.com/questions/4800122/what-mock-object-libraries-are-there-available-for-d
[15:07] <ximion> DMocks-revived is pretty dead again ^^
[15:08] <Laney> yeah
[15:08] <Laney> was wondering if that unittest {} stuff had something for this
[15:10] <ximion> I am sure something exists for Vibe, since they will simply have to mock network operations in a web framework
[15:11] <ximion> unittest blocks on their own are pretty dumb :P https://wiki.dlang.org/Unittest
[15:11] <ximion> Laney: btw, instead of just asserting here, you probably want a contract instead: https://github.com/iainlane/appstream-generator/blob/master/source/utils.d#L332
[15:12] <ximion> https://dlang.org/spec/contracts.html#pre_post_contracts
[15:12] <Laney>  /me blinks
[15:12] <Laney>                             /me
[15:18] <Laney> ximion: that page says that assert is already a contract
[15:20] <ximion> jup
[15:20] <tedg> seb128: Laney: Could I please add uploading this patch to ZG to one of your TODO lists? bug 1584849
[15:20] <Laney> dobey already asked earlier
[15:20] <ximion> but since this is input-validation, you could but it into an in {} block, if you want
[15:21] <tedg> Ah, awesome.
[15:21] <Laney> ximion: what's the advantage for simple asserts?
[15:22] <Laney> as far as I can tell both will be ignored in release builds
[15:22] <ximion> (IMHO the real useful feature is the invariant block for classes, but I didn't feel the need to use it yet ^^)
[15:22] <Laney> like I'd use in {} if doing more complicated precondition checks
[15:22] <Laney> but assert is going to be skipped anyway...
[15:22] <Laney> that's how it seems to me anyway
[15:22] <ximion> in this case, the advantage would only be syntactical
[15:23] <ximion> and the documentation generator would show this constraint on the input value in the docs
[15:23] <seb128> tedg, hey, what L_aney said
[15:23] <Laney> ok
[15:23] <Laney> I'll do it if you want
[15:23] <Laney> you go do it in the places where you haven't :P
[15:23] <seb128> tedg, how are you?
[15:24] <seb128> tedg, btw since you are around, I'm curious but what's the status of snapping inkscape? I think you had it mostly working?
[15:24] <tedg> seb128: Doing good, I dropped update-notifier and unity from the silo.
[15:24] <seb128> good
[15:24] <pitti> hey tedg, good morning
[15:24] <tedg> seb128: Yes, but they haven't fixed the desktop bug yet :-(
[15:24] <pitti> tedg: ah, you figured out how to do that?
[15:24] <tedg> pitti: Yeah, looking at the hud build now.
[15:25] <Laney> ximion: actually I can add an out {} there that the file exists
[15:25] <tedg> Might be easier to drop hud and just put it in a dual silo.
[15:26] <pitti> tedg: oh, I thought unity was needed for all the indicators to even work
[15:26] <tedg> pitti: Yes, but Trevinho wanted to land it in a different silo
[15:26] <pitti> ok
[15:26] <robru> pitti: yes it is
[15:27] <Trevinho> tedg: actually... I didn't include your branch in the landing I've ready... So feel free to readd it to your silo
[15:29] <pitti> Trevinho, tedg: did you find out what caused this mysterious depwait on a newer compiz? ted's systemd branch didn't change that build dep
[15:31] <Laney> ximion1: pushed it (and fix your connection!)
[15:31] <tedg> pitti: Was that only on vivid? /me deleted it so can't check
[15:32] <pitti> tedg: no, on all releases
[15:32] <pitti> tedg: anyway, certainly simpler to land everything else first, and then another silo for the special kids
[15:33] <tedg> Yeah
[15:37] <seb128> tedg, what desktop bug?
[15:37] <tedg> seb128: ?
 seb128: Yes, but they haven't fixed the desktop bug yet :-(
[15:37] <seb128> sorry was lagging behind
[15:37] <tedg> seb128: Oh, sorry, let me find it.
[15:37] <seb128> discussing on snappy channel from other issues
[15:38] <seb128> tedg, was that the relocation?
[15:38] <tedg> seb128: https://bugs.launchpad.net/snapcraft/+bug/1588359
[15:38] <seb128> you could snap from your branch which includes the fix :p
[15:38] <seb128> ah
[15:38] <tedg> seb128: The being able to use desktop files with merged translations
[15:38] <seb128> come on
[15:38] <seb128> it's easy enough to workaround to get going
[15:38] <seb128> just manually cp the one from the build to setup/gui
[15:38] <seb128> and do another build
[15:38] <seb128> or copy to the prime and snapcraft snap prime
[15:39] <tedg> You can't do it in snapcraft, but yes.
[15:39] <seb128> well, you can copy the generated version in the vcs
[15:39] <seb128> in setup/gui
[15:40] <tedg> Yes, also thinking you could do a CMake target: "make snap" that would do it.
[15:41] <tedg> Would be nice to also not have to have all the snapcraft stuff in the root dir.
[15:42] <seb128> tedg, d_idrocks (I think?) wrote recently somewhere that you can have it in a subdir, you just need to have the corresponding relative path for the source
[15:42] <seb128> I didn't test that though
[15:42] <seb128> tedg, also you can use .snapcraft.yaml
[15:44] <tedg> Might be easier to use the . file, as I'm not sure LP will build in a subdir.
[15:45] <seb128> right
[15:45] <seb128> tedg, in any case let me know if I can help with something, would be cool to have inskcape in the store ;-)
[15:46] <tedg> Yeah, we could put something provisional there, but was hoping to have it upstream first. Which would require using the proper desktop file.
[15:46] <ximion1> Laney: is it merge-ready?
[15:47] <ximion1> sorry for the connection, seems to be a bad day for my provider or the wifi connection
[15:48] <Laney> ximion1: still running, didn't crash yet
[15:48] <seb128> tedg, would upstream be opposed to have a .desktop checkout in setup/gui until the bug is fixed? sure that would need to be refreshed when translations change but I guess that doesn't happen so often for the Name/Comments, inkscape is there for a while and those don't move a lot
[15:48] <Laney> you might as well review
[15:48] <Laney> have a PR
[15:49]  * ximion1 doesn't see a PR yet
[15:50]  * ximion1 doesn't see the new commit either :P
[15:53] <Laney> look harder!
[15:56] <ximion1> a Github-internal "squash to one commit" feature would be very cool now ^^
[15:56] <tedg> seb128: Probably not a huge issue, but more I something I thought was going to be fixed soon as everyone basically needs it...
[15:57] <tedg> seb128: Anyway, I merged the 0.92.x branch. Let's see if it still snaps :-)
[15:57] <seb128> tedg, it probably would if the snappy team was not locked down in sprint for 15days every month :p
[16:01] <tedg> seb128: Yeah, I'd recommend not looking at the snappy critical bug list :-)
[16:02] <ximion1> Laney: looks good! (I have a few minor nitpicks, but that's something I can quickly fix when things are merged)
[16:02] <Laney> cool
[16:02] <ximion1> I'll merge it as soon as you report no-failure from your side :)
[16:02] <Laney> my first dlang code
[16:02] <ximion1> \o/
[16:03] <ximion1> btw, a thing that is starting to be a bit annyoing in D is decorator bloat - a few hours ago, I annotated a function @safe override pure immutable @nogc
[16:03] <Laney> bahaha
[16:03] <Laney> @itsreallygoodok
[16:03] <meetingology> Laney: Error: "itsreallygoodok" is not a valid command.
[16:03]  * Laney slaps meetingology 
[16:04] <ximion1> :-D
[16:04] <ximion1> those decorators are really neat for web-development (you can have @path("/foobar"), reminds me of Python)
[16:05] <ximion1> but at least @safe should be the default
[16:06] <Laney> 2016-07-27 16:05:37 - INFO: Writing metadata for yakkety/universe [armhf]
[16:06] <Laney> std.process.ProcessException@../../../../src/libphobos/src/std/process.d(417): Failed to spawn new process (Cannot allocate memory)
[16:06] <ximion1> Laney: run it again ^^
[16:07] <ximion1> if it's a memory issue, it will use less memory on the second run
[16:07] <ximion1> Laney: could you get a libarchive backport without big problems?
[16:08] <Laney> it does work when run again
[16:08] <Laney> is libarchive a transition?
[16:10] <ximion1> Laney: no
[16:10] <Laney> should be easy then
[16:11] <ximion1> okay, then I can get rid of this not-so-failsafe code
[16:11] <ximion1> (will need libarchive >= 3.2 then)
[16:11] <Laney> cool
[16:11] <Laney> I'll just re-run now, can clean when that appears
[16:26] <seb128> attente, hey, can I bother you a sec about the snappy xdg-open thing
[16:26] <attente> seb128: sure
[16:26] <seb128> did you look at getting it working from a GNOME app?
[16:26] <seb128> it works if I xdg-open URL
[16:27] <seb128> but I guess we need a .desktop and a mimetype handle for the gtk side to work?
[16:27] <seb128> handler
[16:27] <seb128> I'm going to have a look to that, just wanted to check before starting in case you already did some work
[16:27] <attente> yeah, i think you're right. desrt would know more about that though
[16:28] <seb128> that's fine, I know what is needed
[16:28] <seb128> just checking so I don't dup work
[16:28] <attente> thanks seb128
[16:28] <seb128> attente, thanks!
[16:32] <seb128> willcooke, do you have a fresh 16.04.1 from those test installs?
[16:32] <willcooke> seb128, yes!
[16:33] <seb128> willcooke, could you try bug #1605802 when you have some free slot?
[16:33] <seb128> downloading chrome .deb and double click and see if it installs
[16:33]  * Trevinho leaves for a while... might be back later... or... see you monday!
[16:33] <willcooke> have a good break Trevinho
[16:33] <willcooke> seb128, sure
[16:33] <seb128> Trevinho, have a nice w.e!
[16:33] <Trevinho> thanks
[16:33] <seb128> willcooke, thanks
[16:36] <willcooke> seb128, tested and works
[16:36] <seb128> k
[16:36] <seb128> thanks
[16:37] <seb128> good to see it's not a regression
[16:37] <seb128> or not happening for everyone
[16:37] <seb128> on that note time for making dinner
[16:37] <seb128> have a nice evening desktopers!
[16:39] <ximion1> Laney: all good?
[16:39] <Laney> ximion1: it's going to take some hours to finish
[16:40] <willcooke> cheers seb128
[16:40] <Laney> bye seb128
[16:41] <Laney> happy dinner!
[16:42] <ximion1> oh, so it's a full run then
[16:42] <ximion1> did you preserve the contents cache?
[16:42] <ximion1> (and run it with eatmydata, that also speeds things up, as always)
[16:44] <Laney> I made a new machine for this
[16:44] <Laney> firewall was only fixed in a different env
[16:44] <Laney> it just saved amd64/universe without crashing
[17:03] <Laney> night!
[17:15] <willcooke> night Laney
[17:37] <ximion1> Laney: neat!
[17:38] <ximion1> I got rid of the xz/gzip calls meanwhile, so we don't spawn any external process anymore now \o/ (except for maybe gdk-pixbuf (does it still do that?), but that is avoided as much as possible)
[17:41] <ximion1> good night! :)
[20:40] <tedg> seb128: Here is a build, but it doesn't have menus :-/  Have to look into it more. https://code.launchpad.net/~ted/+snap/inkscape/+build/1909
[21:03] <seb128> tedg, no menu or no exported ones?
[21:03] <seb128> tedg, is that normal that it builds only for amd64 (my laptop is i386 still ... need to change that but I would have expected launchpad to build for different archs)
[21:04] <tedg> seb128: No menus, in line or exported.
[21:04] <seb128> weird
[21:04] <tedg> seb128: Oh, I only built for amd64 while testing.
[21:04] <seb128> I though launchpad would do the same as ppa
[21:04] <tedg> seb128: I can build others, just was saving build time.
[21:04] <seb128> default build for all supported archs
[21:04] <tedg> seb128: It did, I unchecked them :-)
[21:05] <seb128> if you build for i386 I can have a look to see if there is a gotcha I'm familiar with
[21:05] <tedg> Will do
[21:05] <seb128> thanks
[21:05] <seb128> hey robert_ancell!
[21:05] <robert_ancell> seb128, yo, still up?
[21:05] <tedg> seb128: https://launchpad.net/~ted/+snap/inkscape/+build/1913
[21:06] <seb128> robert_ancell, yeah, was at tennis and decided to hack a bit after that and try to catch up with you after the sprint
[21:06] <seb128> tedg, thanks
[22:09] <seb128> tedg, works for me including nicely integrated menus, but I tried with devmode ... do you use strict?
[22:10] <seb128> hum, no, that has menus as well
[22:11] <seb128> calling it a day but let's talk about that tomorrow, night there!