[04:52] <hikiko> hi
[05:40] <happyaron> pitti: hey, wonders how's the n-m SRU?
[06:52] <pitti> Bonjour tout le monde !
[06:54] <flocculant> morning pitti
[06:55] <happyaron> morning pitti
[06:56] <pitti> hey happyaron and flocculant, how are you?
[06:56] <happyaron> good, except oem guys bugging me about the n-m sru, :-/
[06:57] <flocculant> just good here :p
[07:01] <pitti> happyaron: releasing
[07:03] <happyaron> great
[07:03] <happyaron> ty pitti!
[08:02] <willcooke> o/
[08:02] <TheMuso> Hey willcooke.
[08:02] <Laney> moin
[08:04] <alexarnaud> Hey willcooke, TheMuso :) !
[08:05] <alexarnaud> TheMuso: Did you receive my IRC message about EFI and accessiblity?
[08:06] <ricotz> hi, please keep webkitgtk/yakkety in proposed https://bugs.launchpad.net/ubuntu/+source/webkitgtk/+bug/1588209
[08:11] <seb128> good morning desktopers!
[08:16] <Laney> ricotz: add the tag block-proposed
[08:16] <Laney> hi seb128!
[08:16] <alexarnaud> seb128: good morning seb :) !
[08:17] <ricotz> Laney, ok
[08:19] <Laney> ricotz: your report also lacks details on how it is broken, and a debian report would be good too
[08:22] <seb128> hey Laney alexarnaud ricotz
[08:28] <TheMuso> alexarnaud: I did, thought you were still online when I responded... Let me dig it out of my history.
[08:28] <TheMuso> alexarnaud: I think Windows does have an option to let you boot into the UEFI settings on next boot, but from there you will need sighted help, unless of course your UEFI vendor has implemented some kind of accessibility, but that is very very unlikely.
[08:28] <Laney> seb128: how's it going?
[08:28] <Laney> hey TheMuso, what a rare treat
[08:29] <seb128> Laney, good! but not having a working internet at home sucks, one more day and it should be fixed though!
[08:29]  * Laney eyes component-mismatches
[08:29] <Laney> looks like u-a-l -> libertine is going to be a problem
[08:29] <TheMuso> Hey Laney.
[08:29] <seb128> Laney, libical went it yesterday ;-)
[08:29] <Laney> seb128: are you on that 4g stick?
[08:29] <alexarnaud> TheMuso: do you know some vendor with accessible EFI?
[08:29] <Laney> indeed, thanks for helping!
[08:29] <seb128> Laney, see #ubuntu-release backlog from yesterday
[08:29]  * Laney found https://bugs.launchpad.net/ubuntu/+source/libertine/+bug/1588050
[08:29] <Laney> ah yeah
[08:30] <Laney> britneyyyyyyyyyyy
[08:30] <seb128> Laney, no, I didn't take the stick because at first they were supposed to get it fixed in ~1.5 days, but when they came they decided they needed the new cable, I'm working from my parents place meanwhile which is ok for a few days
[08:31] <seb128> just makes me be online a bit later in the morning :p
[08:36] <ricotz> seb128, hey
[08:36] <ricotz> Laney, added the content of libwebkit2gtk-4.0-37.install as example
[08:37] <ricotz> or does dpkg gain a feature to cope with that if the files are exactly same?
[08:38] <ricotz> (here the content of /usr/share/locale/*)
[08:38] <seb128> ricotz, dpkg deals fine with files that are identical between archs iirc
[08:40] <Laney> ricotz: do you get an actual error?
[08:40] <Laney> it's always been able to cope with identical files
[08:40] <ricotz> which requires that the amd64 and i386 builder would create binary-identical mo-files here
[08:41] <Laney> please actually try installing and then paste the output you get if there's an error
[08:41] <ricotz> Laney, I didnt dare to let apt upgrade since it was to obvious to me
[08:41] <Laney> use a chroot
[08:42] <ricotz> will do
[08:43] <seb128> ricotz, I think mo are identical between arches
[08:43] <seb128> but worth checking
[08:44] <didrocks> oh people here, hello guys
[08:45] <seb128> hey didrocks
[08:45] <alexarnaud> Hello didrocks :) !
[08:46] <didrocks> hey seb128, alexarnaud!
[08:55] <andyrock> hey all
[08:55] <andyrock> willcooke: can you run the trell script? :)
[08:58] <TheMuso> alexarnaud: No.
[08:59] <willcooke> andyrock, done
[08:59] <TheMuso> alexarnaud: Or at least not that I know of.
[09:17] <ricotz> Laney, seb128, false alarm, seems fine after testing
[09:18] <Laney> indeed
[09:20] <ricotz> of course it still uselessly increases the download size ;)
[09:21] <mvo> does anyone know if tseliot will be around today?
[09:33] <seb128> Laney, coming?
[09:33] <Laney> WHAT
[09:52] <andyrock> desrt: http://paste.ubuntu.com/16917101/
[09:52] <andyrock> something like that would be ok?
[10:27] <Laney> going to hide away for a bit to work on theme
[10:27] <Laney> telegram to summon me if you want owt
[10:27] <seb128> Laney, good luck!
[12:44] <desrt> andyrock: you're gonna wanna return FALSE from the timeout callback to stop it from running again
[12:45] <desrt> also: handling the unref/free of the child and info structs on two separate paths is bad form.  do that in one place, please.  either nest the entire "working" body inside a block if or use a goto
[12:45] <mhall119> Hey guys, the Software app doesn't show icons or screenshots for snap apps in the store, are we doing something wrong?
[12:46] <desrt> andyrock: three separate paths, in fact...  merge those.
[12:53] <willcooke> mhall119, https://bugs.launchpad.net/bugs/1588266
[12:54] <willcooke> argh, session issues brb
[12:55] <mhall119> thanks, I hadn't gotten that far through the email thread to see it :)
[13:03] <mhall119> seb128: for the translations problem, could we symlink or bind-mount the in-snap files into the system-directory location that gettext tries to read, and then have the apparmor profile allow access to that?
[13:03] <mhall119> Is there a way to namespace separate them so they can't mess with other app's files
[13:04] <mhall119> or, perhaps just patch gettext itself
[13:05] <jdstrand> someone mentioned this is fixed in click. would be interesting to understand what is happening there. that said, click doesn't support unmodified debs like snapcraft does so don't know how helpful it would be
[13:06] <desrt> the bind mount idea is not great
[13:06] <desrt> it only works if the thing that needs its translation is also installed on the system, and with the same version
[13:06] <desrt> if the snap has an older (or newer) gtk version, for example, some of the strings will be different
[13:08] <desrt> ie: since we're not in a filesystem namespace, you'd end up replacing the "outside" version with the version from the snap, and they might not be the same
[13:09] <desrt> patching gettext (glibc) to be more flexible about this stuff might be the way to go here
[13:11] <seb128> mhall119, I guess we could, but gettext files are only an example of resources having the issue, you get the same trying to load .ui files or custom images you ship or whatever
[13:13] <mhall119> ack
[13:13] <desrt> unless i've fundamentally misunderstood snap, it is not possible for the snap to put files in /usr that do not then appear outside of the snap to the rest of the system
[13:14] <desrt> including replacing system versions of those files that may already have existed...
[13:15] <desrt> if they could do that, then we may as well save ourselves the trouble and put all of the resources in the usual place in /usr -- but then we'd basically be back to dpkg plus confinement
[13:45] <pitti> hey desrt, how are you?
[13:46] <desrt> i'm okay, except that google is currently annoying me lots.
[13:46] <desrt> how are you? :)
[13:46] <pitti> desrt: would it be possible for you to do another (probably the last) release of https://github.com/desrt/systemd-shim/, for the benefit of Debian?
[13:46] <pitti> desrt: quite fine, thanks
[13:46] <desrt> sure.
[13:46] <desrt> i'll try to do that later today.
[13:46] <pitti> getting too many infra issues and pings from folks to really get anything done, but *shrug* :)
[13:46] <desrt> if i remember how =)
[13:46] <pitti> desrt: we could also move to just doing git tags and let github build the tarballs
[13:47] <pitti> desrt: I removed systemd-shim from yakkety yesterday :)
[13:47] <desrt> sweet!
[13:47] <pitti> but I'd like to clean up the package for sid
[13:47] <desrt> cgmanager gone too?
[13:47] <pitti> desrt: not yet, still an rdepends for a few things
[13:47] <pitti> cgmanger binary went to universe, though
[13:48] <desrt> "we couldn't destroy it, so we had to send it into outer space"
[13:48] <pitti> desrt: I recently managed to get init/systemd etc. out of Essential: (thus frmo build chroots), and initscripts out of the default install \o/
[13:48] <pitti> fewer init systems
[13:48] <pitti> desrt: ROTFL
[13:48]  * desrt is waiting for all the sysv back-compat stuff to disappear... LSB be damned
[13:48] <pitti> desrt: we had that for two days
[13:48] <pitti> in images.linuxcontainers.org images
[13:48] <pitti> no sysv-rc, no insserv, etc.
[13:49] <desrt> ya.  all that stuff.
[13:49] <pitti> it breaks all packages which only have an init.d script
[13:49] <desrt> well ya... that's kinda the point, though :)
[13:49] <pitti> but well, containers boot and everything, so one of these days..
[13:49] <desrt> everyone should get on with providing unit files already
[13:50] <desrt> if package maintainers want to ship /etc/init.d/junk for the devuan haters, then they can... as long as i have a way to permanently divert that to /dev/null
[13:51] <desrt> glad to hear that you're making progress here, in any case :D :D
[13:51] <pitti> desrt: at least it made me fix invoke-rc.d for packaages that *do* have a system unit
[13:51] <pitti> systemd
[13:52] <pitti> desrt: these were also broken, but now not any more
[13:52] <pitti> so, this was an useful exercise
[14:00] <Trevinho> hey Laney....
[14:00] <Trevinho> once britney did the job in https://requests.ci-train.ubuntu.com/#/ticket/1481 can you ack the packaging changes?
[15:09] <mvo> seb128: who should I talk to about the nvidia driver?
[15:10] <pitti> mvo: tseliot normally
[15:11] <alexarnaud> Trevinho: Hello :) ! When do you plan to release the 0.9.12.3 versions of Compiz ?
[15:11] <alexarnaud> It is a condition for Debian to accept Compiz because it seems you've fixed the lintian errors.
[15:13] <mvo> pitti: do you have any idea if he is on vac or just not around today? I have a snap releated fix I would like to run by him
[15:13] <pitti> mvo: I don't know, sorry
[15:14] <alexarnaud> FYI the RFS request on Debian about Compiz : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816652
[15:16] <seb128> mvo, what pitti said
[15:17] <seb128> dunno either if he's on vac
[15:18] <mvo> thanks
[16:14] <Trevinho> alexarnaud: hey... I will do it on landing complete
[16:15] <seb128> alexarnaud, whoever is packaging for Debian can probably patch any fix they need
[16:16] <seb128> requesting a package to be lintian clean to go in the archive is ridiculous
[16:18] <alexarnaud> Trevinho: OK but I'm very disappointed, I don't understand, what is the landing complete?
[16:19] <alexarnaud> seb128:  I don't know exactly what the problem exactly is but it seems better to fix lintian issues before to release package as I understand.
[16:19] <Trevinho> alexarnaud: in few days hopefully. It has to go through the distro approval, then I can do that
[16:20] <Trevinho> seb128: can you please publish this https://requests.ci-train.ubuntu.com/#/ticket/1481 or should I ask Laney?
[16:20] <seb128> alexarnaud, sure, in an ideal world all bugs would be fixed, but let's be realistic they don't need to block on that
[16:20] <alexarnaud> Trevinho: Good news to heard that. Do you know if it is possible to be notified by Launchpad of a new release of a package?
[16:20] <seb128> Trevinho, I can do it
[16:22] <seb128> Trevinho, done
[16:22] <alexarnaud> seb128: Do you think you can help us to have Compiz into Debian? At Hypra we have no legitimacy to discuss about that. We are very new in packaging and we wouldn't create conflicts.
[16:22] <Trevinho> seb128: thanks
[16:23] <seb128> alexarnaud, sorry but no, too much to do
[16:24] <alexarnaud> seb128: OK, we'll wait the new upstream release before to re-open the discussion.
[16:24]  * qengho afk 2h, dentist and govt-id check.
[16:24] <alexarnaud> All the works on compatibility have been done few month ago :).
[16:29] <muktupavels> Trevinho, alexarnaud: Can compiz release wait few days until I release Metacity 3.20 and finish compiz branch to add support for new Metacity? Otherwise when mitya57 will upload new Metacity in debian compiz will need rebuild to disable metacity theme support in gtk-window-decorator.
[16:33] <Trevinho> muktupavels: in fact this was my plan... But I don't want either to make people wait too much. However, would metacity 3.20 support break build in Xenial?
[16:33] <Trevinho> muktupavels: as I'd like to do a release Xenial compatible..
[16:35] <muktupavels> Trevinho: https://code.launchpad.net/~albertsmuktupavels/compiz/gwd-support-metacity-3-20/+merge/296257
[16:35] <muktupavels> I dont plan to remove support for older metacity versions, it still should work with metacity 3.16+
[16:35] <muktupavels> but it is not finished
[16:41] <Trevinho> muktupavels: yeah it was under my radar
[16:55] <mitya57> muktupavels, Trevinho: I can't upload new metacity to Ubuntu anyway because it needs new GTK+…
[16:55] <mitya57> And if I upload it to Debian, it won't get autosynced because the package has a delta.
[17:00] <Laney> Trevinho: was hiding away, sorry
[17:00] <Laney> the list is shrinking though
[17:01] <Laney> popovers, separators, other things look good now
[17:01] <Laney> night!
[17:04] <seb128> Laney, night
[17:04] <willcooke> I'm off too
[17:04] <willcooke> night all
[17:14] <Trevinho> seb128: you said you published https://requests.ci-train.ubuntu.com/#/ticket/1481 right, as I can't see the publishing status
[17:15] <seb128> Trevinho, https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/15/console
[17:15] <seb128> 2016-06-02 16:22:49,747 ERROR Needs review: https://code.launchpad.net/~azzar1/unity/whitelist-repated-keys/+merge/296053
[17:15] <Trevinho> seb128: ah, ok... sorry, the ui didn't show things...
[17:15] <seb128> Trevinho, seems like you are trying to make me publish not approved code
[17:16] <Trevinho> seb128: yeah, sorry.. I forgot to approve that
[17:16] <Trevinho> seb128: it's done now
[17:17] <Trevinho> seb128: all approved now, so if you can re-ack it...
[17:17] <Trevinho> weird that I didn't get any notification from the ci-train bot
[17:18] <seb128> Trevinho, done
[17:18] <Trevinho> ta
[18:40] <mhall119> is there a url scheme that will open an app's page in Gnome Software?
[18:41] <mhall119> IIRC, we had one for USC
[19:00] <mhall119> I found appstream: but none of the things I try have worked
[19:54] <Laney> mhall119: gnome-software --details=org.gnome.Cheese.desktop
[20:03] <mhall119> Laney: I'm looking for a URL
[20:03] <mhall119> something that can be put on a website and, when clicked in the browser, will open Gnome Software to that app
[20:24] <qengho> mhall119: is it not "apt:$packagenamecsv" still?
[20:24] <qengho> mhall119: If not, that's bad. URLs are permanent.
[20:24] <mhall119> qengho: no, update-manager grabs apt: URLs
[20:25] <qengho> mhall119: Oh, then probably not. URLs are not app-specific, usually. Anything could handle.
[20:25] <qengho> No help. Sorry.
[20:27] <attente> mhall119: this seems to be broken right now for two reasons: if apturl is installed, then it takes precedence. and if it isn't, gnome-software isn't handling them correctly for some reason
[20:28] <mhall119> actually `xdg-open appstream:org.gnome.Cheese.desktop` works
[20:29] <mhall119> so it sometimes works
[20:30] <attente> mhall119: that didn't work for me: gvfs-open: appstream:org.gnome.Cheese.desktop: error opening location: The specified location is not supported
[20:30] <mhall119> hmmmm, odd
[21:21] <a1fa> andyrock: +1
[21:21] <a1fa> just got your notification
[21:22] <a1fa> how bad was it?
[21:24] <andyrock> a1fa: sorry what? :)
[21:24] <a1fa> oh the show desktop bug
[21:26] <a1fa> i run into a new one.. firefox, chrome, gnome terminal < :), etc, disappear behind the top bar when you maximize them
[21:27] <a1fa> so firefox tabs would be hidden by the top bar
[21:27] <a1fa> and gnome terminal menu would be hidden, but controls would expose themselves so you can unmaximize
[21:27] <a1fa> =) rockin' besides pidgin sucking
[23:03]  * desrt learns something interesting about wireless keyboards: this do not like USB3
[23:05] <desrt> plugging a receiver directly in to a busy USB3 hub: massive amounts of lag and dropped/repeated keystrokes
[23:05] <desrt> add a short USB A-A extension to move the receiver a little bit away from the hub: works great
[23:05] <desrt> turns out USB3 throws off a lot of noise in the 2.4GHz range...
[23:08] <TheMuso> And we want to use this interface for connecting everything including the kitchen sink... :)
[23:08] <TheMuso> Thats just messy.
[23:09] <desrt> imho, the fault lies with someone who creates a wireless keyboard based on 2,4ghz and tries to sell it in the year 2016
[23:09] <TheMuso> Thats a good point.
[23:09] <TheMuso> Even now 5Ghz wireless is still not a thing at the lwo end of gear.
[23:09] <desrt> and this is not a low end keyboard.... not by far
[23:10] <TheMuso> Yeah, amazing...
[23:10] <TheMuso> But I think it has to do with 2.4ghz being unlicensed or some such... Or am I mixing that up with something else?
[23:11] <desrt> 2.4 is unlicensed in most places
[23:11] <desrt> but also 5, i guess
[23:11] <TheMuso> Ok, wasn't sure about 5.
[23:12] <TheMuso> But they could at least use 5... Until its also crammed full. :p
[23:59] <JanC> desrt: AFAIK BT also uses (or can use) 2.4GHz...?