[04:47] <hikiko> hi
[06:09] <pitti> Good morning
[07:59] <willcooke> pip pip
[08:01] <RAOF> Tally ho!
[08:03] <Laney> COME ON BARBIE LET'S GO PARTY
[08:04] <willcooke> :D
[08:14] <seb128> hey willcooke Laney RAOF
[08:15] <willcooke> morning seb128
[08:19] <pitti> hey Laney!
[08:19] <pitti> bonjour seb128
[08:19] <pitti> hello willcooke
[08:19] <seb128> salut pitti, ça va ?
[08:20] <pitti> seb128: ça va bien, merci ! et toi ?
[08:20] <seb128> pitti, ça va bien aussi merci !
[08:20] <Laney> hi seb128 pitti & willcooke
[08:20] <Laney> how are you all?
[08:21] <seb128> good! you?
[08:21] <Laney> it's september
[08:21] <Laney> back to school
[08:21] <seb128> seems so
[08:21] <seb128> haha
[08:21] <Laney> do they have that in france?
[08:21] <Laney> 6 week summer holiday
[08:26] <seb128> I think it's more than that
[08:26] <Laney> :-o
[08:27] <seb128> it starts like on july 8th
[08:27] <seb128> and resume on septembre 1st
[08:27] <Laney> we should have that
[08:27]  * Laney emails some people to get it arranged
[08:28] <seb128> :-)
[08:28] <seb128> k, need to reboot
[08:28] <seb128> why is intel becoming so crappy :-/
[08:29] <Laney> :(
[08:30] <seb128> better
[08:31] <seb128> that laptop used to work perfectly fine in trusty times :-/
[08:31] <seb128> now on xenial I can't switch to a vt
[08:31] <seb128> they are missing to start with (systemd issue?)
[08:31] <seb128> then when I switch back to my session I get corruption and missing textures
[08:31] <seb128> like launchpad icons are empty
[08:31] <seb128> icons are missing in random gtk uis etc
[08:31] <seb128> ups
[08:31] <seb128> launchpad->unity launcher
[08:33] <Laney> is there an upstream bug?
[08:33] <Laney> if not maybe tjaalt_on  could help you file one
[08:35] <seb128> there is https://bugs.freedesktop.org/show_bug.cgi?id=88584 open since 2015-01 with a stack of users from different distro commenting
[08:35] <seb128> but no upstream traction :-/
[08:37] <seb128> the missing vt prompts is newer though
[08:38] <seb128> so likely another issue but I don't even know where to start to determine if that's systemd or something else
[08:38] <seb128> I guess I could try to switch back to upstart to compare
[08:40] <seb128> that upstream bug has a patch attached since april but that's not getting reviewed ...
[08:40] <seb128> tjaalton, ^ do you know anything you could nudge about getting it reviewed maybe?
[08:47] <tjaalton> seb128: distros are moving away from -intel
[08:47] <seb128> shrug
[08:47] <seb128> that feels like standard answer nowadays
[08:48] <seb128> "the code you are using is being replaced, get the new stuff when you can, meanwhile sucks to be you"
[08:48] <tjaalton> there hasn't been even a snapshot release in almost two years
[08:49] <seb128> :-(
[08:49] <tjaalton> everyone running a random git snapshot instead
[08:49] <seb128> is there still a company who cares about their users?
[08:49] <tjaalton> until recently
[08:49] <tjaalton> they do, just not on -intel
[08:50] <tjaalton> which is a one-man show
[08:50] <seb128> that's ridiculous
[08:50] <tjaalton> not really
[08:50] <tjaalton> they're testing everything on modesetting now
[08:50] <Trevinho> Hello
[08:51] <seb128> right, still reality is most of their linux users are on -intel
[08:51] <tjaalton> for a while
[08:51] <seb128> it's like Apple saying that they stop supporting iphone < 7 next weeks
[08:51] <seb128> see how it would fly with people who just bought a 6
[08:51] <seb128> anyway
[08:52] <seb128> bottom line is that I'm going to be stucked with non working video driver if I understand correctly?
[08:52] <tjaalton> with iphone there are no options
[08:53] <seb128> I wonder if I should buy ati or nvidia for my next laptop
[08:53] <tjaalton> are you on xenial?
[08:53] <seb128> yes
[08:53] <tjaalton> so try modesetting
[08:53] <tjaalton> uninstall intel
[08:53] <seb128> I'm not "trying" anything
[08:53] <tjaalton> easiest way
[08:53] <tjaalton> then don't
[08:53] <seb128> I'm using whatever we ship to our users
[08:53] <tjaalton> 16.04.2 users will get modesetting
[08:54] <seb128> it's not a solution to ship a non working driver by default and tell technical enough users to go install something else and let normal user stucked on buggy software
[08:54] <tjaalton> and newer
[08:54] <seb128> k
[08:54] <seb128> so I'm waiting for that ;-)
[08:54] <tjaalton> sounds like it's not a critical issue then :)
[08:55] <seb128> well it's really annoying
[08:55] <seb128> but it's too easy to do hacks and forget about our users
[08:55] <seb128> I'm not doing that, I'm not hacking my box and claiming it's fixed/not an issue
[08:55] <tjaalton> so is there a lp bug?
[08:56] <seb128> sure
[08:57] <seb128> bug #1573959 for example
[08:57] <tjaalton> how is that related?
[08:57] <tjaalton> I know there are bugs
[08:58] <seb128> related to what?
[08:58] <tjaalton> to ilk screen corruption
[08:58] <seb128> I don't know
[08:58] <seb128> there is a bug but my awesome bar doesn't seem to have it
[09:01] <seb128> tjaalton, https://bugs.launchpad.net/bugs/bugtrackers/freedesktop-bugs/88584
[09:02] <seb128> some of those are probably different issues
[09:02] <seb128> but there is a class of similar user visible problems
[09:04] <tjaalton> it's been like that in every release
[09:04] <tjaalton> just for different set of users
[09:05] <seb128> :-/
[09:05] <seb128> well when I try to vt switch I get those
[09:05] <seb128> Sep  1 11:04:24 localhost kernel: [ 2112.025344] dell_wmi: Unknown WMI event type 0x11: 0xffd1
[09:05] <seb128> Sep  1 11:04:29 localhost kernel: [ 2117.261620] [drm] stuck on render ring
[09:05] <seb128> Sep  1 11:04:29 localhost kernel: [ 2117.268160] [drm] GPU HANG: ecode 5:0:0x87e6fff8, in Xorg [2190], reason: Ring hung, action: reset
[09:05] <tjaalton> that's kernel or mera
[09:06] <tjaalton> mesa
[09:06] <seb128> k, so modesettings is not going to help?
[09:06] <tjaalton> no
[09:06] <seb128> :-/
[09:07] <seb128> seems similar to https://bugs.freedesktop.org/show_bug.cgi?id=94002
[09:08] <tjaalton> you have skylake?
[09:09] <seb128> "Intel® Ironlake Mobile x86/MMX/SSE2"
[09:09] <tjaalton> not that then
[09:10] <seb128> https://bugs.freedesktop.org/show_bug.cgi?id=93311 then
[09:11] <tjaalton> dunno
[09:12] <tjaalton> try latest kernel, and if it goes away start bisecting ;)
[09:12] <seb128> haha
[09:12] <tjaalton> or ignore it
[09:12] <seb128> well, I would like to get some vt back
[09:12] <seb128> and being able to switch session without having to reboot after
[09:13] <tjaalton> you're asking too much ;)
[09:13] <seb128> I'm going to end up being one of those people buying a mac
[09:13] <seb128> or installing win10 and using the ubuntu command line there
[09:13] <seb128> :-(
[09:13] <tjaalton> that's a solid plan
[09:13] <seb128> wtf intel really
[09:14] <seb128> I wonder if nvidia or ati is any better
[09:14] <tjaalton> none of my friends run linux anymore
[09:14] <seb128> :-(
[09:14] <tjaalton> just the way it is
[09:14] <seb128> it's sad
[09:14] <tjaalton> not that the desktop is much better
[09:14] <tjaalton> sorry :)
[09:15] <seb128> no your fault
[09:15] <seb128> tjaalton, thanks and sorry for the ranting
[09:16]  * larsu cheers seb128 up
[09:16] <tjaalton> it's getting better even on the intel side
[09:16] <seb128> anyway let's reboot and try that i915.enable_rc6=0 in case that makes a difference
[09:16] <seb128> hey larsu ;-)
[09:16] <seb128> brb
[09:17] <Trevinho> Laney: hey.... So, i was wondering: is there a way to figure if systemd is running in the session or not?
[09:18] <Trevinho> cause we've some upstart stuff running which I'd like to disable
[09:18] <Trevinho> in that case
[09:18] <Laney> yeeeessssssssss
[09:18] <Laney> let me try to remember what the way we used elsewhere is
[09:18] <Trevinho> as upstart has an env var... I don't see much in systemd
[09:18] <Laney> I think it's [ -d "${XDG_RUNTIME_DIR}/systemd" ]
[09:18] <Laney> pitti: ^?
[09:19] <Trevinho> m
[09:19] <pitti> define "in the session'
[09:19] <pitti> what's easy is "running for current user"
[09:19] <Trevinho> pitti: user session
[09:19] <Trevinho> yeah
[09:19] <pitti> which is by and large a constant "yes"
[09:20] <larsu> [ /bin/true ]
[09:20] <seb128> better
[09:20] <pitti> what Laney said (${XDG_RUNTIME_DIR}/systemd)
[09:20] <Trevinho> of course there would be also a systemd dbus proxy.... which... we use, but
[09:20] <larsu> hi everyone!
[09:20] <seb128> I've vts back
[09:20] <Trevinho> ok thanks
[09:20] <Trevinho> hi larsu
[09:20] <seb128> and no gpu hang on vt switch
[09:20] <Laney> or if you care about whether you are running, then ask systemd over dbus
[09:20] <Laney> hey larsu!
[09:20] <pitti> Trevinho: but "is it being used to bring up the session", we are currently in the middle of that -- it brings up half of the session
[09:20] <larsu> seb128: but... that't not the linux experience™
[09:20] <seb128> tjaalton, i915.enable_rc6=0 ftw :p
[09:20] <pitti> Trevinho: what's the actual concrete question that you want to answer?
[09:21] <Laney> seb128: you hacked your laptop!
[09:21] <tjaalton> seb128: works?
[09:21] <seb128> larsu, you are wrong, it's exactly the linux experience
[09:21] <larsu> haha, indeed
[09:21] <tjaalton> cool
[09:21] <seb128> larsu, get non working crap, need to ressort to command line hacks to get something working
[09:21] <Trevinho> pitti: i want to understand who has run unity... and so behave consequently
[09:21] <larsu> seb128: I only saw what you did after I wrote that ;)
[09:21] <seb128> Laney, yeah :-(
[09:21] <Laney> might as well try that other driver if you're going to do that
[09:21] <pitti> Trevinho: "systemctl --user is-active unity7.service", I'd say (or the equivalent D-Bus call)
[09:22] <Trevinho> since for the lockscreen we're running a different version of the panel service... And I'd love to decide what method to use to start it...
[09:22] <seb128> Laney, except that tjaalton said the driver wouldn't help with gpu hangs that it's kernel
[09:22] <Laney> larsu: how's it going?
[09:22] <Laney> O RLY
[09:23] <larsu> Laney: great! Visiting Faina in Dubai right now :)
[09:23] <larsu> how are you?
[09:23] <seb128> Dubai, fancy!
[09:23] <Laney> feelin' fine
[09:23] <Laney> I can see a lot of chemtrails
[09:23] <larsu> uh oh
[09:23] <Laney> so probably won't be feeling fine for long
[09:23] <larsu> watch out
[09:24] <Laney> reading the documentation for meson too
[09:24]  * Laney misses jussi
[09:24] <Laney> what's dubai like?
[09:24] <larsu> it was quite popular at GUADEC
[09:25] <Laney> ya, seems to be getting some attention
[09:25] <larsu> Laney: I just got here last night and am sitting in a hotel room working
[09:25] <Laney> want to find out how to build a git submodule and then link that into the outer project
[09:25] <larsu> Laney: but then, my laptop and phone both still knew the wifi... yeah, it's ok. Hot. Tall buildings. A tad boring
[09:26] <Laney> might leave this task up to ximion ...
[09:26] <larsu> did he talk to jussi at guadec?
[09:26] <Laney> dunno
[09:26] <Laney> there's a meson file in this project though
[09:26] <larsu> I saw both of them
[09:26] <larsu> but I don't know if together
[09:27] <Laney> you know
[09:27] <Laney> i've never seen them in the same room at the same time
[09:27] <larsu> oh! I've never thought about that
[09:27] <larsu> I've also never seen them type into irc at the same time
[09:27] <Laney> oh man
[09:28] <seb128> jbicha, hey, I fixed versions, it was stucked on an error about diverging branch, did you uncommit/push --overwrite a different version of your most recent commit?
[09:28] <Laney> https://github.com/mesonbuild/meson/wiki/Wrap%20dependency%20system%20manual
[09:28] <seb128> jbicha, I forced it back to the current trunk
[09:28] <Laney> I guess that I should write a meson build file for the other project to make this easy then ...
[09:28] <seb128> jbicha, should work on the next cron
[09:28]  * Laney is being forced to learn too much stuff!
[09:29] <larsu> Laney: by the chemtrails?
[09:30] <Laney> they do look like they spell out "Satoris"
[09:30] <larsu> haha
[09:55] <Trevinho> pitti: there could be still a case where an user disabled systemd in session, and then we want things to work as it used to be in upstart?
[09:57] <Trevinho> like... disabling the xdg_data dirs not to include the systemd upstart or...
[09:57] <Trevinho> I don't know...
[09:58] <pitti> Trevinho: yes, it should work with upstart or just plain gnome-session too, if possible
[09:58] <Trevinho> mhmh...
[09:58] <pitti> Trevinho: oh, is that for deciding whether you send an initctl emit or systemctl start for triggering screensaver or similar?
[09:58] <Trevinho> pitti: ok since I've the situation where I would like to manage things with the proper runnner
[09:58] <Trevinho> pitti: yes, for example..
[09:58] <Trevinho> pitti: or... the unity script
[09:59] <Trevinho> which right now allows to restar unity manually or with upstart...
[09:59] <pitti> Trevinho: if you want a cheaper way, you can check /proc/self/cgroup
[09:59] <Trevinho> in teh case someone started unity manually and wanted to restart it with systemd, the script support starting it... but what should I pick? Upstart or systemd?
[10:00] <pitti> if "unity7.service" appears in the name=systemd line (or really, anywhere in the file), it's managed inside a unit
[10:01] <pitti> Trevinho: in that caes, why would that someone not just run systemctl --user start unity7 ?
[10:01] <Trevinho> mh, not bad... if it's in upstart instead... there's not much other way
[10:01] <Trevinho> pitti: since there are so many people which use the "unity" script to restart... So, in that case I want to use the proper runner
[10:01] <Trevinho> pitti: however I think that parsing the XDG dirs for the systemd is enough at script level, isn't it?
[10:01] <Trevinho> or... that would change eventuall?
[10:01] <Trevinho> y*
[10:02] <pitti> Trevinho: if that's just for the script, then performance doesn't matter, and you can certainly use systemctl --is-active?
[10:02] <pitti> Trevinho: you mean testing for XDG_RUNTIME_DIR/systemd? that's pretty much a constant yes, so that won't tell you much
[10:02] <pitti> (since vivid)
[10:03] <Trevinho> pitti: mh ok... So if that is there, then we're sure that the user has enabled systemd in session... and thus we consider it the primary choice... right?
[10:03] <pitti> Trevinho: so I'd say, start it with systemd if "systemctl --user is-enabled unity7.service", otherwise the old way
[10:03] <Trevinho> (since unity has support for it)
[10:03] <pitti> err, wait, we might not explicitly enable it but pull it in via ubuntu-session.service
[10:03] <Trevinho> yeah, that's the thing :-)
[10:03] <pitti> Trevinho: can you even stop unity7? I thought you wanted to make it a Requires=, not just a Wants=
[10:03] <Trevinho> but, well having the xdg dir is enough
[10:03] <pitti> then, if you stop unity, your entire session will stop
[10:04] <pitti> (so maybe a Wants= is better after all, if you want to support restarting; and I think it's usually sufficient too)
[10:04] <Trevinho> pitti: that's not happening on crash, right?
[10:04] <Trevinho> pitti: yeah, right now it's a requires btw
[10:04] <pitti> Trevinho: what is "right now"?
[10:04] <Trevinho> restarting has to be suported, yeah...
[10:04] <pitti> it's not unit-ified in yakkety, and in our staging git it's a wants
[10:04] <Trevinho> right now.. means what's I'm landing :)
[10:04] <pitti> a
[10:04] <pitti> "ah"
[10:05] <pitti> Trevinho: so yes, I'd say make it a wants, then you can stop and restart it
[10:05] <pitti> gnome-session, terminals etc. will continue to run
[10:05] <pitti> and Restart=on-failure will make it auto-restart on a crash
[10:05] <Trevinho> I mean, it's fine if it would crash the session on manual crash, but I want it to restart too
[10:05] <pitti> (while still allowing you to stop it cleanly)
[10:06] <Trevinho> yeah, I think that's better... people uses to restart unity sometimes... So I'd prefer not to kill the session in that case
[10:06] <pitti> agreed
[10:07] <Trevinho> although... it would be nice to crash in case this happens during lockscreen :-)
[10:07] <Trevinho> but... not sure I can achieve that
[10:07] <pitti> Trevinho: pretty much the only thing that should be "required" IMHO is gnome-session.service
[10:08] <Trevinho> I mean when unity-screen-locked.target is active, it would be nice that if unity gets killed, the whole session crashes
[10:08] <pitti> Trevinho: I'm not entirely sure what you mean, but if you mean "kill the session if unity crashes while being locked" -> units can have an OnFailure= action which could check the state and do stuff
[10:08] <pitti> Trevinho: ah, that can be done
[10:08] <Trevinho> maybe that needs some more units
[10:09] <pitti> Trevinho: unity-screen-locked.target Requires=unity7.service, and make graphical-session.target go down if unity-screen-locked.target stops (need to think about how this looks like)
[10:10] <Trevinho> pitti: ah, good.... I'm understanding how to do the first two parts, less in how to make graphical session go down
[10:11] <pitti> yeah, the latter is a bit tricky
[10:12] <pitti> Trevinho: I think what we can do is to make unity-screen-locked.target Requires=Requires=unity7.service and OnFailure=unity-crash.service which Conflicts=graphical-session.target
[10:12] <pitti> Trevinho: but this needs some experimentatino first, maybe let's land this in a separate step
[10:13] <Trevinho> pitti: yeah, sure
[10:13] <Trevinho> unity-screen-locked.target Requires=Requires=unity7.service can still be done now thoug, right? There's no problem with this
[10:13] <pitti> except the obvious duplicate Requires= :)
[10:13] <Trevinho> sure
[10:14] <pitti> Trevinho: yes, I think that's semantically correct by itself
[10:14] <pitti> if the screen lock is implemented in unity7
[10:14] <Trevinho> also wondering if the panel-service in locked mode is a requirements or a wants
[10:14] <Trevinho> pitti: yeah, it is..
[10:15] <Trevinho> or.......... well, sometimes it fallback to gnome screensaver, but this won't affect this side of things
[10:56] <Sweet5hark1> hmmm, I wonder  "libreoffice-core" has "Breaks: libreoffice-gnome (<< ${binary:Version})" (but no Conflicts: ) and libreoffice-gnome has "Depends: libreoffice-core (= ${binary-Version)". the upgrade failed with "errors encountered while processing libreoffice-gnome", however a follow-up "apt-get upgrade" complains about the relations mentions above, however "apt-get upgrade -f" is fine and upgrades libreoffice-gnome just fine.
[10:59] <ricotz> Sweet5hark1, there are some things missing on libreoffice-gnome
[11:04] <Sweet5hark1> term.log just has "will deconfig libreoffice-gnome, would be broken by libreoffice-core", which isnt a problem per se. Id assume adding a "Conflicts: libreoffice-core (<= 1:5.2.0-0ubuntu2)" would help (as would having a C/R: libreoffice-gtk (<= 1:5.2.0-0ubuntu2) instead of << -- but Im still not entirely clear what goes wrong here.
[11:13]  * Sweet5hark1 grumbles something about libreoffice-core just doing a "break" instead of a C/R with earlier versions of any binary falling out of the libreoffice is just a maintainer circlejerk. there is absolutely no point in ever allowing binaries from different builds on the same system.
[11:57] <ricotz> Sweet5hark1, mumbling around is not asking
[11:59] <ricotz> Sweet5hark1, in case you want to ignore more suggestions https://paste.debian.net/plain/800852
[12:06] <Sweet5hark1> ricotz: im not aware I ignored that, but maybe sending patches by mail is preferable as things get lost on IRC anyway?
[12:07] <Sweet5hark1> ricotz: also that patch it pretty useless without context (no line count for patching a 3000? line control file) ...
[12:08] <ricotz> Sweet5hark1, haven't sent your this, but I guess I was pretty clear regarding the packagekit stuff
[12:08] <ricotz> in control.in at libreoffice-gnome
[12:09] <ricotz> I can't provide you a properly authored patch with a packaging repo
[12:14] <Sweet5hark1> ricotz: yeah so is the nature of merge conflicts.
[12:15] <jbicha> seb128: yes, I had a typo in a commit so I rewrote history (for versions) :(
[12:15] <seb128> jbicha, k, well that's what make it stop working ... to know for next time, the auto-updater doesn't use --force so it was hitting an error
[12:15] <ricotz> Sweet5hark1, I didn't argued about the merge conflict
[12:16] <seb128> what made it*
[12:16] <seb128> it's fixed now
[12:54] <desrt> good morning, team!
[13:03] <seb128> hey desrt!
[14:01] <qengho> Ugh. Updating w->y yesterday was a mistake.
[14:04] <desrt> lol.
[14:04] <desrt> at least you're not travelling :)
[14:07] <seb128> that's not a supported upgrade path
[14:07] <seb128> you should go through xenial
[14:08] <seb128> what error did you get?
[14:08] <seb128> happyaron, hey, is there any news from those nm/nma updates?
[14:08] <desrt> that's the nice thing about debian: there are never any upgrades :D
[14:08] <seb128> lol
[14:13] <willcooke> seb128, report from happyaron this morning was that sponsorship should be up today
[14:14] <qengho> I meant x->y. Sorry. tetex-doc and tetex-math-extra, apt and apt-utils file collisions. libboost-dev depending on nonexistant virtual pkg. libaccount and ubuntu-system-settings-online-accounts some problems. some libmedia conflict.
[14:14] <qengho> Others that scrolled off top of buffer.
[14:15] <seb128> urg
[14:15] <seb128> did you report those bugs?
[14:15] <seb128> willcooke, k, thanks
[14:15] <seb128> qengho, willcooke, and what's the status of the new api keys?
[14:15] <qengho> At the apt failure, I didn't trust state.
[14:16] <qengho> seb128: I'll see what I can reproduce from /var/log/apt/
[14:16] <seb128> k
[14:16] <seb128> bah, intel bug is back, can't see any text, brb
[14:18] <seb128> tjaalton, where do I find that new intel driver replacement?
[14:19] <tjaalton> seb128: what do you mean? it's built with the server
[14:19] <seb128> should I just uninstall intel then?
[14:19] <seb128> to try it
[14:19] <tjaalton> just uninstall intel and it'll get used
[14:19] <seb128> k
[14:19] <seb128> thanks
[14:20] <tjaalton> in yakkety the server is patched to not load intel except very old gpus
[14:20] <tjaalton> +on
[14:21] <seb128> I'm on xenial
[14:21] <tjaalton> right, just saying
[14:32] <mhall119> willcooke: I just added you to the call, but we're meeting with Saviq and kgunn on https://hangouts.google.com/hangouts/_/canonical.com/michael-hall?
[14:32] <willcooke> mhall119, erm. k.  One moment, I'm in the middle of some stuff
[15:39] <happyaron> seb128: please have a look at xenial branch of nma for SRU when you have time, :)
[15:40] <seb128> happyaron, k, yakkety as well? (that needs to be updated first before a SRU)
[15:40] <happyaron> yakkety is already uploaded
[15:41] <happyaron> gotta merge 1.2.4 very soon, though
[15:44] <seb128> hum
[15:44] <seb128> let me look to git
[15:44] <seb128> I though we would go directly for 1.2.4
[15:45] <happyaron> ok, then would be next morning
[15:46] <seb128> do you think we should not go for the new version directly for some reason?
[15:46] <seb128> it's only some more segfault fixes
[15:46] <seb128> no other changes
[15:47] <happyaron> no, just meant 1.2.4 can be done quicker for xenial
[15:49] <seb128> I'm asking because you updated git to SRU the previous version
[15:49] <seb128> so maybe you prefer that to going to the current one for some reason?
[15:52] <happyaron> just because it's tested, but I agree 1.2.4 is safe
[15:52] <happyaron> so updating to it now (looks easy enough
[16:08] <happyaron> seb128: mind to check again? both x- and y- this time, :)
[16:11] <seb128> happyaron, looks good, going to review a bit more before uploading ... can you update the bug tomorrow to link to some of the segfaults in should fix? like a few e.u.c urls maybe as testcase, also need to update the version referenced in the description
[16:11] <seb128> no need to do that today, it's already late for you
[16:11] <seb128> the SRU team is probably not going to review that today anyway
[16:11] <happyaron> ok
[16:12] <seb128> thanks
[16:17] <seb128> happyaron, would be nice to reference some of the bugs in the changelog as well
[16:58] <mhall119> is the ubiquity slideshow broken in the 16.10 images?
[16:59] <mhall119> I'm installing in a virtualmachine and it's not showing anything
[17:09] <Laney> indeed
[17:09] <Laney> it looks like it broke with the new webkit2gtk
[17:09] <Laney> which jbicha synced, so hopefully he can look
[17:10] <jbicha> hmm? I lost power from tropical storm hermine
[17:10] <Laney> slideshow in ubiquity is broken with new webkit
[17:11] <Laney> you can test it by installing ubiquity and moving the start_slideshow() Gtk.main() block up below self.live_installer_show() in gtk_ui.py and then running 'ubiquity gtk_ui'
[17:11] <Laney> got to go, see you later
[17:15] <seb128> happyaron, uploaded to yakkety after tweaking the changelog to include some bugs references
[17:30] <willcooke> thanks seb128 happyaron
[17:30] <willcooke> off now, night all
[17:49] <xnox> seb128, sil2100, robru - any idea why ubuntu-touch depends on particular python-gnupg?
[17:50] <xnox> known gnupg 2.1 breaks?
[17:50] <robru> i have no idea
[18:13] <sil2100> xnox: not sure, possibly anyway it's no longer valid
[19:20] <chrisccoulson> ricotz, any idea what's going on with https://launchpadlibrarian.net/281964460/buildlog_ubuntu-yakkety-amd64.firefox_50.0~a2~hg20160831r332986-0ubuntu1~umd1_BUILDING.txt.gz ?
[19:29] <ricotz> chrisccoulson, I would assume the "he" translation contains an invalid string?
[19:32] <ricotz> chrisccoulson, I would assume the "he" translation contains an invalid string?
[20:34] <jbicha> desrt: GTK 3.22 is the start of the last stable 3.x series?
[20:34] <jbicha> I wish we had known that a few weeks ago, might have done GTK 3.22 for yakkety
[20:51] <desrt> I doubt it?
[21:07] <xnox> desrt, was the proposed numbering scheme approved?
[21:10] <xnox> sil2100, i don't think python-gnupg is at all at fault here. At the moment in yakkety chroot "apt install ubuntu-touch" fails on amd64
[22:30] <sil2100> xnox: I have a fix for that already
[22:31] <sil2100> xnox: no worries
[22:31] <sil2100> Let me give you the silo number
[22:31] <xnox> ah
[22:31] <sil2100> xnox: don't worry about touch images, I keep looking at the failures when I have a moment
[22:31] <sil2100> xnox: https://requests.ci-train.ubuntu.com/#/ticket/1895 <- the address-book-app change here
[22:32] <sil2100> xnox: I already told slangasek I'm working on it so that no one duplicates work
[22:32] <xnox> sil2100, not concerned about touch, or touch images per-se.
[22:32] <sil2100> Will land tomorrowish :)
[22:32] <xnox> proposed-migration, globally cares about # of uninstallable packages
[22:32] <xnox> and at the moment that count goes up because of ubuntu-touch-meta/amd64
[22:32] <xnox> which is bad =(
[22:33] <xnox> one shall not have meta's uninstallable is a rule of thumb =)
[22:33] <sil2100> hah, indeed! ;)
[22:33] <xnox> sil2100, right, i'll enable that silo tomorrow, and will check if things are better with it.
[22:33] <sil2100> Will get that releases asap, wanted to give a quick spin of the packages before I land this
[22:34] <sil2100> Thanks! I checked in a yakkety-amd64 chroot and it helped
[22:34] <xnox> i don't think that is enough to resolve  bug #1619468 however
[22:34] <xnox> but we shall see.
[22:34] <sil2100> Of course, I was testing it for touch image builds per se
[22:34] <sil2100> And in livecd-rootfs when installing ubuntu-touch for amd64/i386 we install additional hints
[22:35] <sil2100> So that the deps are satisfied (don't ask why, I didn't make it so)
[22:35] <sil2100> But yeah, let's look into that in more detail tomorrow :)