[06:03] <hikiko> hi
[07:16] <didrocks> good morning!
[08:56] <seb128> good morning desktopers
[08:56] <willcooke> morning seb128
[08:56] <seb128> hey willcooke
[08:57] <willcooke> seb128, just reading Barry's email
[08:57] <seb128> k
[08:57] <willcooke> feels like 16.10 is the right time to me
[08:58] <willcooke> LTS is more likely to be used in places where SMB printing is used
[08:58] <seb128> well, printing is fine
[08:58] <seb128> the current issue is that we are talking about smb drives browsing
[08:58] <seb128> and smb disk mounts
[08:59] <seb128> like being able to connect to that corporate z: and open some word files from it
[08:59] <willcooke> oh.  When did it change from being about printing to file shares?? /me rereads the whole thread
[08:59] <willcooke> in which case I think we 100% need SMB support out of the box
[09:00] <willcooke> the pop-up is "ok", but that change is for 16.10 IMO
[09:00] <seb128> I'm unsure you can "pop-up"
[09:00] <seb128> nautilus lists nearby servers
[09:00] <seb128> you can't do that job if the smb backend is not installed
[09:01] <willcooke> humm.  I've a feeling in 12.04(???) that when you used nautilus and clicked on "Windows networks" is would prompt
[09:01] <willcooke> I don't think that prompt actually worked, but I think it did prompt
[09:03] <willcooke> meh
[09:03] <willcooke> either way
[09:03] <willcooke> I've read the thread now
[09:03] <Laney> yo
[09:03] <willcooke> I vote to keep it and work on porting next cycle
[09:03] <willcooke> morning Laney
[09:04] <seb128> hey Laney
[09:06] <seb128> Laney, how are you?
[09:08] <Laney> hey willcooke seb128
[09:08] <Laney> I'm alright
[09:09] <Laney> no prize on the pub quiz /o\ but we did get the bonus question
[09:09] <Laney> what about you?
[09:14] <seb128> I'm good thanks :-)
[09:15] <seb128> though it's one of those days where I already have a stack of emails/IRCs nags to start the day
[09:15] <seb128> which is a bit annoying, but oh well
[09:16] <Laney> all useful things right?
[09:16] <seb128> of course :p
[09:16] <Laney> making the world a better place!
[09:53] <didrocks> hey seb128, Laney, willcooke
[09:53] <willcooke> what up didrocks
[09:53] <seb128> hey didrocks! ça va ?
[09:53] <didrocks> seb128: I think willcooke is referencing the "please install samba" prompt
[09:54] <didrocks> (having fixed it multiple times brings back "old good times" memories btw ;))
[09:54] <seb128> that is/was when trying to share something in nautilus no?
[09:56] <didrocks> hum, not at a client as well?
[09:56] <didrocks> I don't remember, too long ao…
[09:56] <didrocks> ago*
[09:56] <seb128> same here ;-)
[09:56] <didrocks> seb128: ça va sinon :) and you ?
[09:56] <seb128> ça va bien !
[10:02] <alexarnaud> hello world!
[10:08] <seb128> hey alexarnaud
[10:36] <hikiko> hey desktopers
[10:37] <willcooke> morning hikiko
[10:37] <hikiko> hi willcooke :)
[11:18] <davmor2> jibel, mvo, seb128, willcooke: I hope you are all sitting down 14.04.4 → 16.04 got passed step 2 not to see if it completes or chokes on something else \o/
[11:18] <willcooke> :)
[11:18] <willcooke> progress
[11:20] <mvo> davmor2: yay
[11:41] <seb128> davmor2, \o/
[11:42] <davmor2> Yeap dies somewhere else now so badly it takes out tty I assume that isn't a good thing :(  So now I need to transfer over my base image and try again /me thanks god for vms
[11:49] <desrt> morning, peeps
[11:49] <seb128> good morning desrt
[12:16] <desrt> quiet morning -)
[12:16] <desrt> what's up, seb?
[12:28] <GunnarHj> seb128: Hi Sebastien, would the proposed changes to u-c-c at https://launchpad.net/~gunnarhj/+archive/ubuntu/im-config-gnome/+packages be a problem somehow?
[12:32] <seb128> GunnarHj, I don't know, I'm going to have a look in the afternoon
[12:33] <seb128> desrt, sorry I didn't see you message, fighting with nautilus and gtk behaviour changes, I start wondering if we should go back to 3.18...
[12:33] <Laney> HAHA
[12:34] <GunnarHj> seb128: Ok, let's talk later on. (It's only about a variable name change throughout the package.)
[12:36] <ximion> Laney: I asked around, apparently nobody supports separating .desktop files, binaries and metainfo and still have the result show up in a software center
[12:37] <ximion> asked hughsie and he said he doesn't do that because it would complicate Fedora's metadata generator and massively hurt performance
[12:37] <ximion> so, while "the others do it" is not an argument, it is an interesting data point on whether we should fix packages or adjust the generator
[12:37] <Laney> hey ximion
[12:38] <Laney> I don't really mind if someone is going to fix the packages :)
[12:38] <seb128> Laney, :p
[12:38] <ximion> Laney: :D
[12:39] <ogra_> just use snappy, it makes everything so much easier (ask Sweet5hark1 *g* )
[12:39] <ximion> well, not showing up in the SCs seems to be a strong incentive for people to do the work ^^
[12:39] <seb128> Laney, ximion, do we have datas on the number of packages we are speaking about?
[12:39] <Laney> nope
[12:39] <seb128> ogra_, people hosting those are going to like having so much space used and no data shared between archs ;-)
[12:39] <ximion> seb128: not yet, that's one of the things we need to do, but I would be very surprised if it's more than 20 packages
[12:40] <ogra_> seb128, diskspace is cheap :P
[12:40] <ogra_> (somewhere)
[12:40] <Laney> ximion: it does need to become an error though at least
[12:40] <Laney> then we get to re-process everything, woohoo
[12:41] <seb128> ximion, we have at least 3 in the default installations that I hit this week, I wouldn't be surprised if it's not trivial
[12:41] <ximion> Laney: jup, meaning we need to read the Exec line in the .desktop file and check if the binary is there - if not, emit an error-type tag stating that
[12:41] <seb128> debian likes to split things in common
[12:42] <ximion> seb128: yes, and -common does make sense, but separating the .desktop file and relying on TryExec is IMHO a really bad practice (while technically possible, though) - separating the metainfo file from the .desktop file is also evil (since that one should be in the same pkg that gets installed to satisfy the component)
[12:43] <seb128> ximion, right, I'm not arguing against that, just saying that it was not documented and quite some maintainers put the desktop in -common since it's arch independant
[12:43] <seb128> ogra_, you should host a business is server storage ;-)
[12:44] <ogra_> seb128, now that you say that ...
[12:44] <andyrock> hey all
[12:45] <seb128> :-)
[12:45] <seb128> hey andyrock
[12:45] <seb128> ok, enough poking at nautilus, it's nice outside and I need to move a bit
[12:46] <ximion> seb128: at least for .desktop files without TryExec, that's a definitive error - I need to check if lintian tests for that already
[12:46] <seb128> going for some exercice, bbiab
[12:46] <seb128> ximion, right
[12:46] <seb128> bbl
[12:46] <ximion> for everything else, this change would need to be communicated properly
[12:47] <ximion> integrating AppStream's issue hints with Debian's PTS would be ideal (nobody is working on that yet, though)
[12:47] <Laney> we are also trying to release with this in a short number of weeks :)
[12:48] <ximion> Laney: the previous app-install-data generator also didn't do all that stuff...
[12:48] <ximion> so I wonder how that worked before :P
[12:48] <ximion> or maybe it was just run on a complete Contents file once
[12:49] <ximion> or someone did manually fix things up
[12:49] <Laney> laney@nightingale> head -2 menu-data/evince-common:evince.desktop                                                                                                ~/temp/app-install-data-ubuntu-15.10
[12:49] <Laney> [Desktop Entry]
[12:49] <Laney> X-AppInstall-Package=evince
[12:50] <ximion> interesting...
[12:51] <Laney> don't know where the code is for this though
[12:52] <ximion> Laney: somewhere at Debian's Git, I read it ages ago...
[12:52] <ximion> it operated on the Contents file though
[12:52] <ximion> could send you a link when I'm home, I think I bookmarked it
[12:53] <Laney> nod
[12:53] <Laney> this particular problem has to use Contents
[12:53] <ximion> Laney: btw, you definitely want to switch to the new appstream-generator for later Ubuntu releases when it's done - it massively outperforms the Python thing
[12:54] <ximion> it uses libarchive to extract the .deb files and does some useful caching, and it time it's twice as fast compared to the Python code (but it doesn't do icon processing or screenshot downloading yet)
[12:55] <ximion> downside will be that installing it will be harder (C and D code needs to be compiled...)
[12:55] <ximion> another thing that increases performance is that we can use LMDB in a threaded environment (as opposed to a multiprocess-environment in Python), so we only need to open the cache once
[12:56] <ximion> makes quite a difference ^^
[12:57] <Laney> ximion: you know you could avoid Contents by building that yourself
[12:57] <Laney> just an idea ;-)
[12:59] <ximion> Laney: I was thinking about that ^^
[12:59] <ximion> would help Ubuntu, since in Debian the contents file is up-to-data, usually
[13:00] <ximion> but would also not be bad for Debian, since it would *guarantee* that Contents and package-content match
[13:00] <ximion> (something which we just have to assume at time...)
[13:16] <Laney> ximion: yeah
[13:17] <ximion> Laney: Python just wasn't the ideal choice ^^ - not sure if D is (yet), but I got stuck after trying it - parallelization works really well :)
[13:18] <ximion> big work item will be implementing a proper YAML writer in C
[13:18] <ximion> libyaml is
[13:18] <ximion> not very nice ^^
[13:18] <ximion> (outputting XML already works)
[13:19] <Laney> python is nice for having lots of libraries already available
[13:19] <ximion> that indeed! And handling YAML data is much more natural in Python
[13:20] <ximion> it's also easy to learn or people are already familiar with it, and you can just write the logic and don't need to care much about memory safety (as in C)
[13:21] <ximion> but multiprocessing with Python turned out to be really bad, I understand now why the dak developers are always cursing it
[13:23] <ximion> Laney: btw, sorry for not being very active the past weeks - too much work
[13:23] <ximion> (I am now replying from work, waiting for some computation to finish...)
[13:25] <Laney> ximion: no worries, I think I only have one PR outstanding atm
[13:26] <ximion> the read-canonical-gettext-files-for-desktops thing
[13:26] <ximion> *desktop-files
[13:28] <Laney> ah yeah sorry 2 then
[13:28] <Laney> absolute paths one too
[13:28] <Laney> but I need to fix that if you say that looking in Contents first is good enough to get it merged
[13:30] <ximion> Laney: for absolute paths: first check if the file has an extension we support (there's a function for that), if we don't do that already. Then check the .contents file
[13:30] <ximion> that's the uncontroversial part
[13:31] <ximion> I'm not yet sure about the "check dependencies explicitly as well" approach
[13:31] <Laney> It's needed to avoid breaking for any new split
[13:31] <Laney> but probably won't be used that much after the contents check
[13:32] <Laney> oh wow, appstream.ubuntu.com is down because of a kernel panic
[13:32] <Laney> [1642642.764107] Buffer I/O error on device vdc, logical block 7
[13:32] <Laney> [1642642.765654] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[13:33] <ximion> oO
[13:33] <ximion> what did it do to trigger that?
[13:34] <Laney> who knows
[13:34] <Laney> all is never well The Cloud
[13:34] <Laney> in^
[13:36] <Laney> it is back
[13:36] <ximion> the cloud is the "even if things fail, if you have a lot of them failure doesn't matter much and isn't worth time to investigate because some instance will always keep running when one breaks down" approach
[13:38] <Laney> here it is have some commands to make VMs on demand but sometimes those VMs will break mysteriously
[13:42] <ximion> usually I would blame btrfs or OverlayFS and be right with it 60% of the time :P
[14:38] <desrt> attente, larsu: https://wiki.gnome.org/Hackfests/GTK2016
[15:00] <attente> "Threat to global stability" ¬_¬
[15:05] <desrt> :D
[15:25] <larsu> desrt: I don't think I'll come :/
[16:00] <desrt> aw :(
[16:11] <davmor2> cyphermox, willcooke: we still have slightly MASSIVE issues with upgrades, I'm currently looking at a black screen on my laptop that does nothing.
[16:12] <ogra_> "slightly MASSIVE" heh
[16:12] <ogra_> davmor2, stop using the black on black theme !
[16:12] <davmor2> ogra_: if only it were that
[16:13] <davmor2> The fact I can't get a tty is the thing I'm finding most concerning
[16:14] <ogra_> wiggle the cable
[16:14] <ogra_> :P
[16:17] <davmor2> cyphermox, willcooke: the nice thing now though is at least I know it's not just a kvm thing so can enjoy testing this from there again :)
[16:17] <willcooke> davmor2, ha
[16:18] <davmor2> flocculant: ^ just a heads up that upgrades are a bit fixed and a lot broken
[16:18] <flocculant> davmor2: ha ha thanks :)
[16:18] <willcooke> davmor2, so the initial problems are now fixed, but this is something new?
[16:19] <cyphermox> well, the "True" distro still does not exist so that's at least one issue on upgrade using the CD
[16:20] <davmor2> willcooke, cyphermox: or the original upgrade issue that I saw.  This basically gets so far through the install kicks you out of the session and leaves you in session with no display as in really no display
[16:21] <cyphermox> davmor2: I haven't seen that yet
[16:24] <davmor2> cyphermox: I see it on both kvm and hardware with uefi + secureboot I'm using -cpu host which is i7 on kvm and it is an i7 in the hardware too
[16:24] <cyphermox> I don't know, I can only deal with one thing at a time
[16:24] <cyphermox> for now I'm fixing the sources.list (or trying to, at leat)
[16:25] <cyphermox> *least
[16:26] <davmor2> cyphermox: being as I have no tty's I'm thinking enable open ssh and see if I can at least ssh into the kvm/laptop to get around that issue to atleast be able to run apport
[16:31] <cyphermox> if you have to tty and stuff like that, I'd be very suspicious of systemd in general
[16:31] <cyphermox> (that was me trying to shift the blame to pitti, yes) ;)
[17:09] <davmor2> cyphermox, willcooke: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1555237  -redir and install openssh-server to the rescue :)
[17:10] <willcooke> thanks davmor2
[17:10] <willcooke> trying here in a vm
[17:15] <Texou> hi
[17:15] <Texou> hi didrocks
[17:16] <alexarnaud> didrocks: hello! How when you installed a package to define relacatable profile ?
[17:16] <cyphermox> davmor2: compiz crashes maybe? https://launchpadlibrarian.net/247279143/CurrentDmesg.txt.txt
[17:16] <cyphermox> Texou: hey!
[17:17] <Texou> hey cyphermox  :)
[17:17] <willcooke> cyphermox, yeah, just seen that as well
[17:17] <davmor2> cyphermox: that's what I said to willcooke but then why is there no tty
[17:17] <willcooke> hikiko, looks like compiz is seg faulting in the upgrade ^
[17:17] <willcooke> Trevinho, ^
[17:17] <willcooke>   726.661272] compiz[1908]: segfault at 18 ip 00007f8ba143d26e sp 00007ffddce03f70 error 4 in libglib-2.0.so.0.4002.0 (deleted)[7f8ba13bc000+106000]
[17:17] <cyphermox> well, if compiz explodes it will kill off the session, and then lightdm may want to try to restart
[17:18] <didrocks> alexarnaud: well, you have the example in the compiz package itself with the Unity profile
[17:18] <davmor2> cyphermox: I'm wondering if x goes and that in turn kills compiz which in turn takes out the system
[17:18] <didrocks> (isn't what you are working from day one? :))
[17:18] <cyphermox> davmor2: so, normally you'd be right it should get back to lightdm, which would be happy again, but it looks like it's crashing badly enough to try to get in failsafe-x, which also for some reason starts compiz?
[17:19] <davmor2> I blame ogra_ snappy should of fixed this :D
[17:19] <cyphermox> at least that's my reading of dmesg there
[17:20] <ogra_> davmor2, except that these desktoppers are lazy and havent ported their desktop to snappy yet ... not my fault at all !
[17:20] <willcooke> :p
[17:20] <ogra_> :)
[17:20] <davmor2> cyphermox: could be
[17:21] <davmor2> ogra_: hey don't try squirming out if it, I put the blame squarely on your shoulders :P
[17:22] <Trevinho> Oh, crash? What, when, why?
[17:22] <davmor2> Trevinho: upgrade from 14.04.4 + updates to 16.04
[17:22] <Trevinho> davmor2: mh, nice one...
[17:22] <Trevinho> davmor2: do you have any stacktrace for that?
[17:22] <willcooke> it might be a red herring Trevinho
[17:23] <davmor2> Trevinho: no crash as such whole system is taken out bug is https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1555237
[17:25] <Trevinho> Well, I guess that still compiz crashes for some reason, thus the rest stops... And isn't anything on /var/crash about that?
[17:26] <willcooke> davmor2, are you upgrading from the UK mirrors or the main ones?
[17:27] <davmor2> willcooke: I assume uk as that is default
[17:46] <Trevinho> seb128: can you have a look at https://code.launchpad.net/~3v1n0/gtk/unity-maximized-headerbar-buttons-hide/+merge/288552 ?
[17:47] <seb128> Trevinho, did we decide to go for an unity/ubuntu hack rather than a gtksetting?
[17:48] <Trevinho> seb128: well, that's what we said yesteday (go for the easiest way,as it would cause changing the u-s-d as well), no?
[17:48] <seb128> attente, unsure how busy you are on g-s bugs but I can't figure out https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1554164 , it looks like it should be simple but I don't understand where it's wrong, maybe you could have a look?
[17:49] <seb128> Trevinho, you discussed it with desrt, I didn't follow too closely sorry
[17:49] <seb128> but that wfm
[17:49] <attente> seb128: sure
[17:49] <seb128> attente, thanks
[17:50] <attente> seb128: how did you produce that?
[17:50] <Trevinho> seb128: based on that I'd also rework the message-dialog-restore-traditional-look-on-unity.patch to use the new atom instead of XDG_CURRENT_DESKTOP ? (desrt didn't like that)
[17:50] <seb128> attente, have an update available
[17:50] <seb128> or some updates
[17:50] <seb128> Trevinho, wfm
[17:51] <desrt> Trevinho: that is more tricky
[17:51] <Trevinho> seb128: actually, we can't since... it's on _init...
[17:51] <seb128> attente, install https://launchpad.net/ubuntu/+source/language-selector/0.158/+build/9296660/+files/language-selector-common_0.158_all.deb https://launchpad.net/ubuntu/+source/language-selector/0.158/+build/9296660/+files/language-selector-gnome_0.158_all.deb
[17:51] <seb128> attente, if you are uptodate
[17:51] <Trevinho> so, we can safely keep in that way
[17:51] <attente> seb128: you did that via the --localfilename option?
[17:51] <desrt> Trevinho: some deep detail in gtk implementation like how dropshadows are handled is a bit different than issues of higher level UI layout
[17:51] <desrt> Trevinho: i'd leave it alone, ya
[17:52] <seb128> attente, no, I just start gnome-software, it fetches updates available and their changelogs
[17:52] <Trevinho> ok
[18:01] <attente> seb128: you installed those packages on an up-to-date system, launched g-s then switched to the Updates tab and clicked the refresh button? can't seem to reproduce with that sequence of steps :(
[18:01] <seb128> attente, no
[18:02] <seb128> attente, my system is not update
[18:02] <seb128> but those invalid reads seem to happen when get_changelog is called
[18:02] <seb128> I guess for that to happen you need updates to be available with changelog fetching to be done
[18:02] <seb128> I was suggesting one way to create that situation
[18:03] <seb128> unsure what code you are using though?
[18:03] <seb128> robert did some changes in https://git.gnome.org/browse/gnome-software/log/?h=wip/rancell/apt
[18:03] <seb128> if you are on trunk you might want to change
[18:03] <seb128> 	uri = g_strdup_printf ("http://changelogs.ubuntu.com/changelogs/binary/%s/%s/%s/changelog", source_prefix, source, update_version);
[18:03] <attente> seb128: you're running from robert's branch or the distro packaged version?
[18:03] <seb128> to have s/source/binary_source/
[18:04] <seb128> attente, doesn't matter
[18:04] <seb128> well I'm on robert's trunk version atm
[18:04] <seb128> and current_version is garbage if I tried to print it in get_changelog
[18:04] <seb128> so I guess the issue is not fixed
[18:11] <seb128> attente, if it's not easy to trigger for it forget about it, or wait a bit for xenial updates to be available
[18:12] <GunnarHj> seb128: Do you have time to take a look at the u-c-c change I mentioned? Asking you because you added the problematic line:
[18:12] <GunnarHj> g_setenv ("XDG_CURRENT_DESKTOP", "Unity", TRUE);
[18:12] <GunnarHj> The issue I ran into is that language-selector-gnome uses XDG_CURRENT_DESKTOP to control the behavior (wrt im-config configuration) depending on the desktop, and when language-selector-gnome is started from u-c-c in GNOME Flashback, it does the wrong thing.
[18:12] <seb128> GunnarHj, sorry, day was crazy ... did I add that line?
[18:13] <seb128> what's the issue with that?
[18:13] <GunnarHj> seb128: I think so. (According to the changelog.)
[18:13] <GunnarHj> seb128: It hijacks the XDG_CURRENT_DESKTOP variable for u-c-c internal purposes.
[18:13] <seb128> well, u-c-c is an unity thing
[18:14] <seb128> don't use it if you don't have an unity type session
[18:14] <GunnarHj> seb128: Well, currently it's used by GNOME Flashback.
[18:15] <GunnarHj> seb128: The think is that we don't want the same behavior on GNOME Flashback as in Unity.
[18:15] <seb128> why not?
[18:17] <GunnarHj> seb128: It's a little complicated. Actually a workaround, so the ibus variables are not set for users who don't need them.
[18:18] <attente> seb128: yeah, the xenial version is quite a bit different from the apt branch, and looking at robert's changes, it's possible that it'll be fixed once he does another upload
[18:18] <GunnarHj> seb128: Changing the variable name to something else solves the problem.
[18:18] <hikiko> willcooke, i was at the pool, i ll test this when i go home
[18:18] <seb128> attente, well, if I apply that on top of trunk http://paste.ubuntu.com/15336283/
[18:19] <hikiko> (the segfault)
[18:19] <willcooke> hikiko, thx.  Not sure what's going on there yet.  Still upgrading my VM to see if I can get any more idea
[18:19] <seb128> attente, I get e.g
[18:19] <seb128> version: X�«�«0
[18:19] <seb128> version: 0.157
[18:19] <willcooke> hikiko, might be a symptom rather than a cause
[18:19] <seb128> attente, sometimes it's fine, but it still gets corrupted
[18:20] <seb128> attente, the first chunk is a hack to not be disturbed by info about all other things I didn't have updated
[18:24] <seb128> GunnarHj, I don't have a good answer/idea aobut your issues, it feels like the problem described in the changelog when the line was added would still apply today if we reverted the change
[18:26] <GunnarHj> seb128: I'm not suggesting we revert the change, actually. XDG_CURRENT_DESKTOP seems to used within unity to control things like if it shall provide links to Ubuntu docs or GNOME docs. My suggestion is to keep the hardcoded "Unity", but use another variable name for the purpose (throughout the whole u-c-c).
[18:27] <seb128> attente, it might be that the issue is with re-entrance and that this function needs to be called several time in // so requires more updates to be available to hit the bug
[18:27] <seb128> GunnarHj, you have a patch to do that?
[18:28] <GunnarHj> seb128: Yes. https://launchpad.net/~gunnarhj/+archive/ubuntu/im-config-gnome/+packages
[18:28] <seb128> GunnarHj, that change feels wrong
[18:29] <seb128> XDG_CURRENT_DESKTOP is a standard thing
[18:29] <seb128> GunnarHj, I guess you could try to summarize the issue on an email to the desktop list and see if you get any traction there
[18:31] <attente> seb128: yeah... tbh i'm really not sure. if you can reproduce it reliably, can you at least figure out which string is being invalidly accessed by trying each one in the g_strdup_printf invidiually?
[18:31] <GunnarHj> seb128: Is it standard to change it within a application to something else but the originally set value? Why is XDG_CURRENT_DESKTOP the right variable to use for controlling the u-c-c behavior internally?
[18:32] <attente> it seems like source and binary_source should be safe because of the guard, but maybe there's some other weird threading issues happening here
[18:32] <seb128> attente, in the current trunk code current_version has the issue for sure
[18:32] <mdeslaur> seb128: fyi, I'm stealing your graphite2 merge
[18:32] <seb128> mdeslaur, thanks
[18:33] <seb128> mdeslaur, is there a security fix in there?
[18:33] <mdeslaur> yeah, 1.3.6 fixes a zillion cves
[18:33] <seb128> GunnarHj, XDG_CURRENT_DESKTOP is what tells you in what desktop you are, so it's what we query to check if we are in unity and have unity specific behaviour, it's done in gedit/nautilus/etc as well
[18:33] <seb128> mdeslaur, good!
[18:34] <attente> seb128: but current_version isn't used in the g_strdup_printf() call
[18:35] <attente> or did you mean update_version?
[18:36] <seb128> attente, http://paste.ubuntu.com/15336283/
[18:36] <seb128> attente, the valgrind might not be matching what I describe
[18:37] <seb128> I took it on xenial some days ago
[18:37] <seb128> attente, that diff prints a corrupted "version" with trunk
[18:37] <GunnarHj> seb128: Right, and when I'm in GNOME Flashback, the original XDG_CURRENT_DESKTOP is "GNOME-Flashback:Unity", but an app (in this case language-selector-gnome), which is started from u-c-c, is told that it is on "Unity" only.
[18:38] <seb128> GunnarHj, right, as said I don't have a good reply to that
[18:38] <seb128> I understand the issue but I don't know how to fix it
[18:43] <muktupavels> seb128, GunnarHj: how about checking current value of XDG_CURRENT_DESKTOP before changing it? Change it only if does not include GNOME-Flashback?
[18:44] <seb128> muktupavels, GunnarHj, I guess we could read the value and add Unity to the list if it's not there
[18:44] <seb128> muktupavels, good thinking :-)
[18:45] <GunnarHj> muktupavels, seb128: Sure, that would serve the same purpose from my POV.
[18:47] <GunnarHj> muktupavels, seb128: Before I go back to the drawing board, would that be an acceptable change?
[18:48] <seb128> GunnarHj, I think so
[18:49] <GunnarHj> seb128: Ok, then I'll make a new patch based on that. Hopefully you don't change your mind later. ;)
[18:50] <seb128> thanks
[18:50] <seb128> well, the patch should be trivial if you change the "set XDG_CURRENT_DESKTOP to unity" to be "get the variable, add unity if it's not in the list"
[18:50] <seb128> and that should get your case to work as well right?
[18:51] <GunnarHj> seb128: Yes, that's my understanding.
[18:54] <seb128> great
[18:54] <seb128> GunnarHj, thanks for working on that!
[18:54] <muktupavels> why it is needed in first place? Maybe it can be as simple as checking if that variable is set and if not then set it to Unity?
[18:55] <seb128> that might work as well
[18:55] <seb128> the changelog mention the env ubiquity
[18:55] <seb128> unsure if XDG_CURRENT_DESKTOP is set there and to what
[18:56] <seb128> but I guess it's not
[18:57] <muktupavels> how is ubiquity started? maybe correct thing is to make sure that it is set for that session? Setting it from ucc feels like workaround/hack...
[19:00] <GunnarHj> muktupavels, seb128: But to be safe, it's just as simple to check if the variable includes "GNOME-Flashback", and if not set it to "Unity".
[19:01] <GunnarHj> muktupavels: Agree that it feels like a workaround in the first place. Just trying to solve a tiny problem. ;)
[19:17] <willcooke> davmor2, new wheeze.  Potentially related.... started upgrade, came back to it a few times to see how it was getting on.  This time I can't unlock the lockscreen to see whats going on
[19:21] <willcooke> enter password, black screen, then back to the lock screen again
[19:25]  * flocculant shall carry on studiously ignoring upgrades then :p
[19:26] <willcooke> :)
[19:43] <davmor2> willcooke: yeap same kinda thing
[19:44] <davmor2> willcooke: infact I think that is the exact symptoms I had before the init-mod-utils bug
[19:44] <davmor2> willcooke: it's good fun though right :)
[19:44] <willcooke> ohhh yes
[19:44] <willcooke> fun
[19:45] <davmor2> willcooke: is that shuggin fashin shuggin fashin dick dastardly I hear muttering under your breath?
[19:45] <willcooke> :D:D
[19:54] <willcooke> davmor2, is this normal:
[19:54] <willcooke> Configuring libssl1.0.0:amd64
[19:54] <willcooke> blah blah blah
[19:54] <willcooke> ou can choose this option to avoid being prompted;
[19:54] <willcooke> instead, all necessary restarts will be done for you
[19:54] <willcooke> automatically so you can avoid being asked questions on each
[19:54] <willcooke> library upgrade.
[19:54] <willcooke> Restart services during package upgrades without asking?
[19:55] <willcooke> .
[19:55] <willcooke> Basically I had to expand the terminal section and say "y"
[19:55] <willcooke> Not that out of the ordinary, but I don't think I've had to type anything in to that terminal to complete an upgrade befor
[19:55] <willcooke> e
[19:59] <davmor2> willcooke: I thought it was meant to throw up a popup for those kind of requests
[19:59] <willcooke> humm
[20:00] <davmor2> willcooke: it at least does for things like config changes
[20:02] <GunnarHj> seb128: Still there?
[20:08] <seb128> GunnarHj, not really but around the computer, just ask I might reply if it's easy
[20:11] <willcooke> ahhh
[20:11] <willcooke> davmor2,
[20:11] <willcooke> from your apttermlog.txt
[20:11] <willcooke> you got as far as the prompt I was talking about up there ^^^^
[20:11] <willcooke> and that's why yours stopped
[20:11] <willcooke> https://launchpadlibrarian.net/247279149/VarLogDistupgradeApttermlog.txt
[20:11] <willcooke> have a look there ^
[20:12] <willcooke> but....
[20:12] <willcooke> I got past that
[20:12] <willcooke> and mine stopped here:
[20:12] <willcooke> Setting up bash-completion (1:2.1-4.2ubuntu1) ...
[20:12] <willcooke> Setting up liblocale-gettext-perl (1.07-1build1) ...
[20:12] <willcooke> and at some point before that, not much before that mind, my shell stopped working
[20:12] <willcooke> cyphermox, fyi ^
[20:12] <willcooke> I will comment on the bug
[20:13] <davmor2> willcooke: I'm actually beginning to wonder if it isn't the code that is meant to block the system sleeping that is causing it
[20:13] <davmor2> willcooke: hence me hitting it one place and you another
[20:14] <willcooke> I think that if you'd answered yes to that you would have carried on to where I got to
[20:16] <davmor2> willcooke: for the question you should get a debconf popup like this https://zxtech.files.wordpress.com/2014/12/debconf-on-sara_066.png
[20:16] <GunnarHj> seb128: Well, I jumped at conclusions. Not changing it in case of "GNOME-Flashback" would solve my problem, but also create a new bigger one: The original g-c-c code would be applied wherever the XDG_CURRENT_DESKTOP value is tested against "Unity". So I'm back at my original idea with using some other variable name. (An alternative, if you for some reason don't want that, is to test XDG_CURRENT_DESKTOP both against "Unity" and "
[20:16] <GunnarHj> GNOME-Flashback:Unity" all over the place. But that would be more code...
[20:18] <davmor2> willcooke: definitely not a happy place to be though right
[20:21] <muktupavels> GunnarHj, 'The original g-c-c code would be applied wherever the XDG_CURRENT_DESKTOP value is tested against "Unity".' - why/how that is problem?
[20:21] <davmor2> willcooke: I think if you reboot you are able to access tty but still get no gui too
[20:21] <willcooke> rebooting now
[20:21] <willcooke> it's dead Jim
[20:22] <willcooke> ah, there we go
[20:22] <willcooke> oh wow
[20:22] <willcooke> now it really is dead
[20:22] <willcooke> yay
[20:22] <davmor2> willcooke: and that is why I marked it critical
[20:22] <willcooke> kernel panic
[20:23] <davmor2> willcooke: oh I never had that
[20:23] <GunnarHj> muktupavels: The original g-c-c options are simply different, and probably not what the GNOME Flashback people want.
[20:23] <davmor2> willcooke: but either way really not a happy place
[20:23] <willcooke> davmor2, my guess is that if you could have answered Y to that prompt, you'd now have a kernel panic
[20:23] <davmor2> willcooke: possibly
[20:24] <GunnarHj> muktupavels: They are probably just a leftover from the time when u-c-c was forked from g-c-c.
[20:24] <muktupavels> GunnarHj, gcc? or did you mean ucc?
[20:24] <davmor2> willcooke: oh and to add no pressure final beta is when most people upgrade right
[20:25] <GunnarHj> muktupavels: I think I wrote what I meant...
[20:25] <GunnarHj> muktupavels: u-c-c is a fork from g-c-c.
[20:26] <GunnarHj> muktupavels: u-c-c includes quite some code which is not actually used.
[20:26] <muktupavels> Can you give link that is applied but should not?
[20:26] <cyphermox> willcooke: what did you mean by your shell stopped working?
[20:26] <cyphermox> ugh, made bad coffee somehow, brb
[20:33] <GunnarHj> muktupavels: Most it is about reference to applicable docs: Ubuntu help or GNOME help. This file includes a few such spots, where XDG_CURRENT_DESKTOP is tested against (the hardcoded) string "Unity": http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/unity-control-center/wily/view/head:/shell/control-center.c
[20:35] <muktupavels> GunnarHj, that must be fixed... Add ucc to affects in this bug - https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1554878
[20:36] <willcooke> cyphermox, U7 session just locked up.  First of all the upgrader window went grey and unresponsive but I was still seeing new log entries via ssh
[20:36] <willcooke> cyphermox, then the whole desktop stopped responding.  SSH was still alive.
[20:36] <willcooke> cyphermox, then I ctrl-c'd out of the log and sudo reboot
[20:37] <willcooke> and then the whole thing just locked up.
[20:37] <willcooke> and now it is dead.
[20:37] <willcooke> :(
[20:37] <willcooke> Attached my log here:  https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1555237
[20:38] <GunnarHj> muktupavels: Well, one option is to keep using XDG_CURRENT_DESKTOP, and thus add u-c-c to that bug. Another option is to use some other variable name for the purpose, as I first suggested. (But seb128 didn't like that...)
[20:38] <muktupavels> GunnarHj, while I dont know original reason why that was added, it looks like it was added for cases when it was not set at all. So right thing might be to set it to Unity when XDG_CURRENT_DESKTOP is NULL or fix ubiquity scripts to export XDG_CURRENT_DESKTOP=Unity.
[20:39] <willcooke> morning robert_ancell
[20:39] <robert_ancell> willcooke, hi
[20:39] <GunnarHj> muktupavels: But that wouldn't help, considering how the variable is queried at a lot of places.
[20:40] <sarnold> willcooke: btw, if you inteded to attach logs on the kernel panic, they don't appear to have made it to the bug
[20:41] <willcooke> sarnold, it's in a VM, can I get logs out of it?  Dont know how
[20:41] <muktupavels> GunnarHj, g_strcmp0 (XDG_CURRENT_DESKTOP, Some Desktop) is incorrect and must be fixed in all known places.
[20:42] <sarnold> willcooke: depends upon how dead it is, I guess .. perhaps a different kernel via grub, or init=/bin/sh or something similar if it's only partially dead..
[20:43] <muktupavels> GunnarHj, first thing is to make sure that this variable is not changed. If session was started with GNOME-Flashback:Unity then it should not change.
[20:43] <sarnold> willcooke: if it's too dead for that, then perhaps some qemu-img messing around to try to gte to the files directly. (assuming it even logged its own death, that's getting harder and harder to capture..)
[20:44] <muktupavels> GunnarHj, if (g_getenv("XDG_CURRENT_DESKTOP") == NULL) g_setenv ("XDG_CURRENT_DESKTOP", "Unity", TRUE); should be correct patch/fix even if it does not directly fix problem.
[20:45] <GunnarHj> muktupavels: Should we split on ":" all over the place, to be able to test against "Unity", or what?
[20:46] <muktupavels> GunnarHj, that would be right thing.
[20:46] <GunnarHj> muktupavels: Or using strncmp()
[20:46] <GunnarHj> muktupavels: (last 5 characters)
[20:47] <willcooke> sarnold, cheers.  Managed to get in to a desktop with an old kernel, no networking though (yet)
[20:47] <sarnold> willcooke: heh, at least it's a start..
[20:47] <willcooke> :)
[20:49] <muktupavels> GunnarHj, it could be also set to - GNOME-Flashback:Unity:My-Desktop...
[20:50] <GunnarHj> muktupavels: Do you mean according to the new spec?
[20:51] <davmor2> willcooke: fire up the live cd that should give you access to the logs if all else fails
[20:51] <willcooke> I've got logged in, but no logs
[20:52] <davmor2> willcooke: sigh
[20:52] <muktupavels> GunnarHj, yes!?
[20:52] <davmor2> willcooke: it's too late to care anymore I'm calling it a night and I'll see what I can get tomorrow on hardware with a really ethernet port and stuff :)
[20:53] <willcooke> ditto I think
[20:53] <davmor2> -ly
[20:53] <willcooke> cheers davmor2
[20:53] <muktupavels> GunnarHj, https://bugzilla.gnome.org/show_bug.cgi?id=763364
[20:55] <muktupavels> GunnarHj, if such API would be added then it would be as simple as if (g_in_desktop("Unity")) or if (g_in_desktop("Unity") && !g_in_desktop("GNOME-Flashback"))
[20:57] <GunnarHj> muktupavels: Basically I understand what you are saying. However, in the case of u-c-c changing it like that all over would be quite some extra code for no sensible reason. I can't think of a situation when some desktop would like to use u-c-c and not refer to Ubuntu help. So I keep thinking that the root issue in case of u-c-c is that XDG_CURRENT_DESKTOP is used unnecessarily. Hmm.. Maybe robert_ancell can show some light on it
[20:57] <GunnarHj> ...
[20:57] <GunnarHj> robert_ancell: Hi Robert!
[20:57] <robert_ancell> GunnarHj, hi
[20:58] <GunnarHj> robert_ancell: Do you know why the XDG_CURRENT_DESKTOP is used in u-c-c to choose the code for references to Ubuntu help rather than GNOME help etc.?
[20:59] <robert_ancell> GunnarHj, we treat Unity as the exception (checked via XDG_CURRENT_DESKTOP) and revert to upstream behaviour in all other cases
[20:59] <robert_ancell> Seems the fairest for upstream
[20:59] <muktupavels> GunnarHj, whell ucc is for unity so it might make sense to remove checks and assume that it is run on Unity desktop...
[20:59] <robert_ancell> muktupavels, that API would be super helpful
[21:00] <robert_ancell> muktupavels, actually, good point. It is *only* for Unity, so it doesn't really need to check
[21:00] <GunnarHj> robert_ancell: But is u-c-c actually used on other desktops?
[21:00] <robert_ancell> perhaps that is a hangover from the split from g-c-c?
[21:00] <GunnarHj> robert_ancell: That's my theory too.
[21:00] <muktupavels> robert_ancell, then drop comment in that bug? looks like glib developers is not quite interested in adding such API.
[21:01] <robert_ancell> GunnarHj, it might be, but they would be derivatives would be Ubuntu based and so the Ubuntu docs are the most appropriate
[21:02] <GunnarHj> robert_ancell: Right. GNOME Flashback is one such example, and that's why I'm here bothering a lot of people. ;)
[21:03] <GunnarHj> robert_ancell: The problem is that u-c-c currently *sets* XDG_CURRENT_DESKTOP to "Unity", which in case of GNOME Flashback results in an incorrect variable value. My idea, for a simple change to solve the conflict, is to just use some other variable name instead of XDG_CURRENT_DESKTOP.
[21:04] <muktupavels> GunnarHj, some other variable will not work. You need Unity to get panels loaded...
[21:05] <GunnarHj> muktupavels: I mean changing the variable name all over u-c-c. As I suggested at ttps://launchpad.net/~gunnarhj/+archive/ubuntu/im-config-gnome/+packages
[21:06] <robert_ancell> GunnarHj, u-c-c sets XDG_CURRENT_DESKTOP?
[21:06] <GunnarHj> robert_ancell: Yes, unfortunately.
[21:06] <robert_ancell> it should only be set by LightDM...
[21:06] <willcooke> night all
[21:07] <robert_ancell> GunnarHj, is there a bug for that?
[21:07] <muktupavels> GunnarHj, does ucc has custom code that reads desktop files? or do you plan to patch glib? panels have desktop files that have ShowOnlyIn=Unity (most likely, did not check). So you can change watever you want - panels will not get loaded...
[21:08] <GunnarHj> robert_ancell: No bug yet...
[21:08] <robert_ancell> GunnarHj, 'cause that's wrong and should  be fixed
[21:08] <muktupavels> robert_ancell, is ubiquity started by lightdm?
[21:08] <robert_ancell> muktupavels, I'm not sure
[21:09] <muktupavels> if I understand corecly then it was added because ucc was not loading panels there...
[21:10] <GunnarHj> muktupavels: Not sure what you mean now. XDG_CURRENT_DESKTOP is set to its proper value elsewhere, so I don't see what the problem with the .desktops files would be.
[21:10] <robert_ancell> muktupavels, in other desktops other than Unity?
[21:13] <muktupavels> robert_ancell, seb128 probably can explain better. I think that ubiquity does not set XDG_CURRENT_DESKTOP at all, but it should set it to Unity.
[21:13] <muktupavels> So when ucc is used in ubiquity panels are not loaded because they include OnlySHowIn=Unity
[21:14] <muktupavels> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/unity-control-center/wily/view/head:/panels/appearance/unity-appearance-panel.desktop.in.in
[21:17] <muktupavels> GunnarHj, check .desktop files for ucc panels. They are only shown if desktop is Unity. Missing XDG_CURRENT_DESKTOP means that no panel will be loaded.
[21:18] <GunnarHj> muktupavels: Right, *missing* value would result in that, I forgot about the assumed ubiquity issue... Sorry.
[21:21] <GunnarHj> muktupavels: Hmm.. I have an idea: 1. Set XDG_CURRENT_DESKTOP to "Unity" if empty. 2. Introduce a new boolean environment variable IS_UNITY which for now can be used for the tests all over the place.
[21:24] <GunnarHj> muktupavels: (I mean that u-c-c should set that variable for internal use only.)
[21:24] <muktupavels> GunnarHj, ucc should not set it at all... but setting it only if empty/not set should be better then setting it always. I would not use env, introduce function to check it and use it.
[21:26] <GunnarHj> muktupavels: The purpose with such a boolean variable would be to split on ":" once, instead of doing it in 25 or so places in the source code.
[21:29] <GunnarHj> muktupavels: Aha, you said function *instead of* an env. variable. Got it.
[21:29] <muktupavels> GunnarHj, http://paste.ubuntu.com/15337448/
[21:30] <GunnarHj> muktupavels: Right, something like that.
[21:33] <muktupavels> GunnarHj, if it will be used only to check for Unity then result probably could be stored in static so next time it is called it already returns previous result.
[21:34] <GunnarHj> muktupavels: But there are multiple files which need to use it...
[21:35] <GunnarHj> muktupavels: I'll make an attempt. I'm not really a C coder, so it will be a 'challenge'. ;)
[22:16] <robert_ancell> GunnarHj,  muktupavels, a load of those XDG_CURRENT_DESKTOP checks in u-c-c are pointless - I've filed some MPs to remove them
[22:32] <GunnarHj> Excellent, robert_ancell! That's what I thought. Where is that MP?
[22:35] <GunnarHj> robert_ancell: Never mind, I found them.
[23:19] <GunnarHj> robert_ancell: I see that muktupavels added a u-c-c task to bug #1554878. Just for my understanding, before we go on and fix the remaining XDG_CURRENT_DESKTOP tests: Is u-c-c at all in use on non-Unity desktops? Isn't it a Unity only fork from g-c-c? If it is, I suppose that the most logical measure would be to drop the "else" code snippets, and stop testing for XDG_CURRENT_DESKTOP completely.