[02:15] <robert_ancell> jbicha, ping
[02:15] <jbicha> robert_ancell: hi
[02:15] <robert_ancell> jbicha, you can reproduce bug 1672424 right? It's working fine for me here on both xenial and zesty..
[02:16] <jbicha> what test file did you use?
[02:16] <robert_ancell> jbicha, switcheroo-control as per the bug instructions
[02:16] <jbicha> do you have the gnome3 staging ppa enabled?
[02:16] <robert_ancell> jbicha, no
[02:16] <jbicha> hmm
[02:17] <robert_ancell> indeed
[02:19] <jbicha> yes, I can still reproduce it on Ubuntu (Unity) 16.04
[02:19] <jbicha> this time, I right-clicked on it in Nautilus and chose to open it with Ubuntu Software
[02:20] <robert_ancell> jbicha, what version of g-s?
[02:20] <robert_ancell> I tried with Nautilus - still wokrs
[02:21] <robert_ancell> I'm using the .a34b091 version here
[02:21] <jbicha> yes, that's the same version I'm using
[02:22] <robert_ancell> amd64?
[02:22] <jbicha> yes
[02:22] <robert_ancell> bare metal or VM?
[02:22] <jbicha> VirtualBox
[02:22] <robert_ancell> I'm using QEMU, but I can't see how that would make a difference...
[02:23] <jbicha> but I can reproduce it in zesty too
[02:23] <robert_ancell> 3.22.6-0ubuntu2?
[02:24] <jbicha> we're up to 3.22.7 now
[02:24] <jbicha> and I'm using the PK-enabled version from that ubuntu-desktop PPA
[02:28] <jbicha> the latest comment on bug 1581713 asks for the ability to use gnome-software without snap
[02:28] <jbicha> that's sort of possible in zesty except that I have gnome-software depend on g-s-plugin-snap instead of just recommends
[02:32] <robert_ancell> jbicha, yeah, uninstalling the plugin seems an appropriate solution.
[02:33] <robert_ancell> Though it's just a side effect of not being able to do this properly. Still waiting on the support from the snapd side
[02:33] <jbicha> except we don't have a supported way of uninstalling that plugin
[02:35] <robert_ancell> i.e. graphically?
[02:35] <robert_ancell> or in older releases?
[02:36] <jbicha> you can't do it in zesty because I made it a hard-depends; you can't do it in earlier releases because it's included in the same binary pkg as gnome-software
[02:38] <robert_ancell> Given the request is "I want to disable snaps because they're harder to install than .debs" I think the real solution is to fix the snap installing issues..
[02:40] <jbicha> oh never mind, I guess they could just uninstall 'snapd' which is only a recommends
[02:40] <jbicha> jhbuild run gnome-software --local-filename=switcheroo-control_1.1-0ubuntu0~zesty1_amd64.deb
[02:41] <jbicha> fails too with gnome-software 3.22.7 without our patches
[02:42] <robert_ancell> oh yeah, snapd is optional
[02:43] <jbicha> Gs  failed to convert to GsApp: no application was created for /home/jeremy/Downloads/switcheroo-control_1.1-0ubuntu0~zesty1_amd64.deb
[02:45] <jbicha> (it seems a bit extreme to switch to Debian testing because of that one snapd issue!)
[02:48] <robert_ancell> RAGE QUIT!
[02:49] <robert_ancell> Seems the trend is to change the error message every release :)
[02:49]  * robert_ancell wishes he'd bought a faster SSD. Updates take ages...
[02:59] <robert_ancell> Still works on zesty with all updates... :(
[02:59]  * robert_ancell reboots
[03:02] <robert_ancell> still works
[05:21] <hikiko> hi
[06:32] <Guest63440> Morning hikiko!
[06:32] <hikiko> morning Guest63440
[06:38] <RAOF> Oops.
[08:58] <willcooke> morning all
[09:00] <didrocks> hey willcooke
[09:00] <davmor2> Morning all
[09:01] <didrocks> happy monday davmor2
[09:01] <Laney> AHHHHHHHHHHHHHHHHHHHHHHH
[09:01] <didrocks> oh, a Laney
[09:01] <didrocks> UK's really united… in time :)
[09:04] <Laney> 3~/sb e
[09:04] <Laney> argh
[09:04] <Laney> hey didrocks!
[09:04] <Laney> how's it going?
[09:09] <didrocks> good good! busy week-end even if didn't do much in the end :)
[09:09] <didrocks> how was yours?
[09:09] <didrocks> (btw, played unlocked at the game cafe, really really cool game: https://boardgamegeek.com/boardgame/213460/unlock)
[09:09] <didrocks> unfortunately can't replay a scenario once done
[09:10] <didrocks> (card-based escape room game)
[09:10] <seb128> hey willcooke Laney davmor2, how is u.k today? had a good w.e?
[09:12] <davmor2> seb128, didrocks: Doing well thanks miserable weather, but I finished my Millenium Falcon Model, Now I just need to figure out where the hell I'm going to put it
[09:13] <didrocks> haha, it's the hardest part :)
[09:15] <Laney> didrocks: nice, not heard of that one
[09:15] <Laney> hey seb128!
[09:15] <Laney> was quite good, exploring in wales
[09:15] <Laney> rained every day but that's expected :P
[09:16] <davmor2> didrocks: have you seen the size of it
[09:16] <didrocks> davmor2: ah no, how big is it?
[09:31] <davmor2> didrocks: https://photos.google.com/photo/AF1QipPfwDJuQqMUxGKYJoMK5uJaFQRVhRKYnEngcUXB can you see that
[09:33] <davmor2> didrocks: to give you and Idea the cushion in the background is 40cm Squared
[09:35] <Sweet5hark> moin
[09:38] <didrocks> hey Sweet5hark
[09:38] <didrocks> davmor2: I don't have access to it
[09:39] <davmor2> didrocks: https://photos.google.com/photo/AF1QipPfwDJuQqMUxGKYJoMK5uJaFQRVhRKYnEngcUXB try that
[09:39] <didrocks> davmor2: nope
[09:39] <davmor2> https://goo.gl/photos/ULpqxMp8Wo7QcvYY9
[09:39] <davmor2> sorry paste fail
[09:39] <didrocks> better :)
[09:39] <didrocks> ahah, quite massive then!
[09:41] <seb128> hey Sweet5hark
[09:42] <davmor2> didrocks: I think the round is 70cm and with the blades it is 82cm
[09:42] <willcooke> seb128, could you take a look at this one pls:  https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1661371
[09:44] <Sweet5hark> didrocks, seb128: bonjours!
[09:47] <Sweet5hark> mondays lament: After backing up the bundled windows, setting up ubuntu, customizing everything and moving my workflow to the new machine and being really happy about it ...
[09:48] <Sweet5hark> ... yesterday I played my first youtube video on it. Turns out the right internals speakder doesnt work.
[09:48]  * Sweet5hark is so angry at Lenovo for letting such an obvious fail pass QA on a 1000+ EUR machine.
[09:49]  * Sweet5hark is even more angry at himself for not having tested sound on delivery before setting anything up.
[09:53] <seb128> willcooke, sure, I had it in my triaged bug emails box, going to have a look today or tomorrow
[09:57] <willcooke> perfect, thanks seb128
[09:58]  * Laney emerges from emails
[10:06] <flexiondotorg> Morning desktopers
[11:10] <chrisccoulson> ricotz, all the bits are in place for building firefox with our rust toolchain now, but we're blocked on https://bugzilla.mozilla.org/show_bug.cgi?id=1347483 (the build fails because it hits the network)
[12:01] <Sweet5hark> oh, lol: a redhat employee pimping my performance hacks on GNU make to upstream (again): http://lists.gnu.org/archive/html/bug-make/2017-03/msg00038.html
[12:31] <seb128> Sweet5hark, be careful or you might end up maintaining gnumake :-)
[12:46] <Sweet5hark> seb128: you mean maintaining an ancient widely used codebase with way too few developers? Would be an entirely new experience to me then ...
[12:58] <Sweet5hark> Laney: FWIW, preventing premature promotion of libreoffice-l10n with the last upload worked. It worked jsut a bit ... too well too.
[13:00] <Laney> boop
[13:00] <Laney> you mean it broke libreoffice somehow?
[13:02] <Sweet5hark> Laney: nah, not really broke it. Just means that we need one extra build of -l10n this time around although it is not strictly needed. see: https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?id=485e71dffdaf408d17b51a8118d9bda303b914e3
[13:03] <Laney> Sweet5hark: ah right, do you know about source:Upstream-Version?
[13:07] <Sweet5hark> Laney: hmm. both source:Upstream-Version and binary:Version might bite you in one scenario or the other, wouldnt they? Murphy says likely the one that hurts you will come to pass anyway.
[13:08] <Sweet5hark> Laney: I mean chances of upstream or packaging incompatibilities are roughly the same between libreoffice and libreoffice-l10n.
[13:09] <Laney> I thought you wanted to express 'should be the same upstream version'
[13:09] <Laney> keeping binary versions in sync across different package is a nightmare (so >= is better there)
[13:15] <Sweet5hark> Laney: for the most part, -l10n being a separate package is artificial anyway: I mean, they are even maintained in the same repo and generated from the same source. Being able to update libreoffice without libreoffice-l10n is just a minor sideeffect, but IMHO we should not depend on that anyway: just take it as a freebie that pays back some of the pain we get for splittng these in the first place.
[13:16] <Sweet5hark> Laney: but yeah: (= ${binary:Version}) had no benefits at all here, so good to kill it.
[13:21] <Laney> Sweet5hark: meh, it still requires a libreoffice upload to match every l10n one
[13:21]  * Laney lunch
[13:30] <Sweet5hark> Laney: so: 1/ changes in libreoffice-l10n without one in libreoffice have never happened. 2/ incompatible changes on the same upstream version of LibreOffice DO happen: e.g. dis-/enable a feature with configure-flags and suddenly you have too much/too little in the -l10n (and possibly, given the funky "Help-Id" mapping of translated text in libreoffice-l10n: broken l10n even for stuff that both
[13:30] <Sweet5hark> versions had).
[13:34] <Sweet5hark> Laney: building l10n separately isnt an supported upstream scenario. Compatibility of -l10n when e.g. config-flags change isnt a promise that upstream ever made. IOW: we should be thankful if even "(>= ${binary:Version})" works. ;)
[13:39] <Sweet5hark> (The l10n strings arent mapped to content between the two via something sane and stable like unique strings. Rather ints that are generated during the build. We should be thankful libreoffice and libreoffice-l10n agree on the generated ids so much: that was never an expectation when that code was originally written.)
[14:53] <Laney> Sweet5hark: Right, so this whole approach is fragile and prone to random breakage. Got you.
[14:58] <Laney> :)
[14:59] <Sweet5hark> Laney: aye. Its a bit "We are doomed anyway". To be properly fixed, that would need to happen upstream, but that is a lot of work with zero enduser visible benefit, so as long as what we do now works, Id rather spend the time on other things ...
[15:02] <Sweet5hark> e.g. we discussed moving to gettext for l10n upstream (because ~everyone else is, and then we would only have the troubles everyone else has). in addition to a lot of work, while it would make things more robust, it would also roughly double l10n file sizes: so enthusiasm was ... limited.
[15:18] <Sweet5hark> is it ok to reuse bug 1673790 for the -0ubuntu2 upload?
[15:20] <jbicha> Sweet5hark: yes, could you add that bug number to your debian/changelog so it will get closed automatically when it makes it into zesty?
[15:25] <Sweet5hark> jbicha: hmm, already uploaded the changes w/o a launchpad bug id (debian bug id is in there though). Would it be ok for me to close the lp bug manually this time? Otherwise I'd have to redo the whole source package dance ...
[15:26] <Sweet5hark> jbicha: see https://bugs.launchpad.net/debian/+source/libreoffice/+bug/1673790/comments/3
[15:29] <jbicha> Sweet5hark: since we already have the original tarballs in zesty, a .debdiff would be a lot easier for you I think
[15:30] <jbicha> just send a diff of the debian/ directory since what's already in zesty-proposed
[15:30] <davmor2> willcooke: did your branch for slides still not make it in?
[15:32] <Laney> davmor2: https://code.launchpad.net/~willcooke/ubiquity-slideshow-ubuntu/ubiquity-slideshow-ubuntu-zesty/+merge/319962
[15:32] <davmor2> Laney: meh
[15:33] <jbicha> Sweet5hark: actually now that I think about it some more, your way is fine; building LO and Firefox's sources for uploading take a very long time
[15:34] <davmor2> Laney: any way to get that moving it would be nice to have before Thursday if possible you know with it being final beta and all that ;)
[15:34] <Laney> Yes, get a reviewer to review it and then, if approved, to upload it. :)
[15:35] <Laney> (#ubuntu-installer)
[15:38] <jbicha> Sweet5hark: I would have used (<< 1.5.3.1-0ubuntu2~) for the breaks/replaces to better match the existing replaces but your way should be fine too
[16:53] <Sweet5hark> jbicha: yep, it would only be a difference for 1:5.3.1-0ubuntu1+foo versions (IOW <=1:5.3.1-0ubuntu1 assumes there wont be a 1:5.3.1-0ubuntu1+x version with the bug, while <<1:5.3.1-0ubuntu2~ assumes those might exist).
[16:53] <Sweet5hark> jbicha: and thanks for not insisting on a debdiff -- my jenkins machinery doesnt autogenerate one, so Id have to manually create one ...
[17:21] <Laney> back in a bit
[17:32] <Sweet5hark> jbicha: thanks for sponsoring. FWIW, I might ask for a yakkety SRU too: usually I waited for an CVE to bump versions, but for yakkety none came about, so its still stuck at 5.2.2. Id bump to 5.2.6 and add the backport of the SDK fix.
[17:33] <jbicha> sounds good
[17:36] <Sweet5hark> jbicha: eh, forget about backporting the SDK patch. yakkety isnt broken apparently as rene broke it after I branched off.