[04:35] <alkisg> stgraber: any hints on how to send you the packaging merge request?
[04:37] <stgraber> alkisg: if you branch is based on lp:ubuntu/ltsp you should be able to do it with lp-propose-merge or just give me an URL and I'll have a look
[04:37] <alkisg> Thanks, will do
[04:44] <alkisg> stgraber: if you also have the upstream code merging command handy, it'll save me quite some time... :)
[04:45] <stgraber> alkisg: you'll want to get a .tar.gz from the upstream branch, then use bzr merge-upstream --version 5.x.x 5.x.x.tar.gz
[04:45] <alkisg> Thanks
[04:45] <stgraber> alkisg: IIRC merge-upstream comes from the bzr-builddeb package
[04:46] <alkisg> Ah, /me looks at that too...
=== alkisg1 is now known as alkisg
[07:50] <alkisg> Hmmm the default "set -e" in ltsp-common-functions breaks login too, we obviously need to fix more errors there
[13:34] <alkisg> stgraber: I've started working on packaging here: https://code.launchpad.net/~alkisg/+junk/ltsp - I didn't try to merge upstream etc, I started with a new branch and I'm only doing changes in the debian/ folder, hope it's good enough
[13:41] <stgraber> alkisg: ok. Merging won't quite work then but I'll manually take the changes from it
[13:42] <alkisg> stgraber: it would be much much easier if you had the packaging somewhere seperate from the tree copy, because the tree copy is frequently old
[13:43] <alkisg> Sure my bzr lack of knowledge is to blame too :(
[13:43] <stgraber> alkisg: well, it makes things much more complicated if I need to track down the changes in two places.
[13:43] <stgraber> alkisg: lp:ubuntu/ltsp always matches what's in the archive, which is what I care about
[13:47] <alkisg> Maybe that makes sense for debian packages, where you get a snapshot per ubuntu series and the changes after that are small, but for packages that are maintained in ubuntu it makes things harder, as there's no clean history of the debian/ folder:(
[13:48] <stgraber> bzr log debian/ looks fine here
[13:49] <alkisg> But I can't get it without getting an old trunk tree though. The delta with debian grows, new translations aren't added, etc etc
[13:49] <alkisg> I don't know it doesn't seem right to me
[13:49] <stgraber> ah, yeah, if you want to compare with debian, you'll need to also get lp:debian/sid/ltsp, then you can bzr diff between the two
[13:50] <alkisg> I got vagrantc's packaging tree, he keeps the debian/ folder separate, it looks much cleaner
[13:50] <stgraber> though currently I don't pretend to be anywhere near in sync with Debian so I don't even look as merging would just conflict on every single file
[13:50] <alkisg> I'm trying to minimize that
[13:51] <stgraber> once we're almost in sync again, we'll be able to merge by simply doing "bzr get lp:debian/sid/ltsp" in the lp:ubuntu/ltsp branch, just like you'd for a regular bzr branch
[13:51] <stgraber> the UDD branches are full source branches as we want to have an exact snapshot of what's getting in the archive, we don't want to ever depend on an external .tar.gz that might change
[13:52] <stgraber> the idea being that in the (far?) future, we won't dput anymore, Ubuntu will simply build from the UDD branch when we tag
[13:52] <alkisg> I get the idea, I just don't think it's convenient to maintain an ubuntu-specific packaging in that tree
[13:53] <alkisg> E.g. what if I wanted to be an ubuntu ltsp maintainer, but I didn't want/couldn't have access to UDD branches?
[13:53] <alkisg> (co)maintainer
[13:53] <alkisg> It sounds fine for deltas after debian snapshots, but not for maintaining an ubuntu-specific debian/ folder history
[13:53] <stgraber> Ubuntu doesn't have maintainer we only have uploaders. If you get upload rights for ltsp you'll automatically get upload right to the UDD branch (as it's using the same archive ACL)
[13:54] <stgraber> otherwise, work in a branch and request for it to be merged
[13:54] <alkisg> kk
[13:55] <alkisg> One thing where I'm not sure if it's the right thing to do: ltsp-server.examples: client/localapps/doc/examples/*.desktop
[13:55] <alkisg> Right now these are installed in the client, but that doesn't make much sense, it'd be better if they were installed server-side, right?
[13:56] <stgraber> no, these are the shutdown/reboot localapps entries, they need to be on the client as they are localapps
[13:56] <alkisg> They are .desktop files invoked from the client session which runs on the server,
[13:56] <alkisg> and they use localapps to initiate shutdown... no?
[13:56] <stgraber> I don't think so, /me checks
[13:57] <alkisg> Exec=sh -c 'xprop -root -f LTSP_LOGOUT_ACTION 8s -set LTSP_LOGOUT_ACTION HALT && gnome-session-save --logout'
[13:57] <alkisg> That would be ran on the server...
[13:57] <stgraber> ah right, we have X-LTSP-NoChange set so that they don't get called through ltsp-localapps
[13:57] <alkisg> (and btw we can use the epoptes endsession script which also supports kde, xfce, lxde etc)
[13:58] <stgraber> I guess the reason to have them on the client instead of the server is that we don't want them to show up in non-ltsp sessions
[13:58] <alkisg> If we put them in ltsp-server.examples, the sysadmin still has to put them manually in applications
[13:59] <alkisg> If we put them on the client, they won't show up anywhere anyway
[13:59] <alkisg> (except for fat clients, where they'd confuse people)
[14:01] <stgraber> checking here to confirm they don't magically appear, if they don't, I'd prefer to have them in ltsp-client (or ltsp-client-core)'s examples as if someone wants to enable them, they'd want them as localapps
[14:01] <alkisg> Ah, except if we put them on the client, AND activate localapp menus so that they show up in the menus
[14:01] <stgraber> yeah, I think that was the idea
[14:01] <stgraber> hmm, got go for 5 minutes, be back in a bit
[14:01] <alkisg> Gotcha, I'll notify vagrantc to change his packaging
[14:04] <alkisg> Although they'll still confuse people that use fat clients as they're not needed there, and even people that use thin clients without gnome as they won't work there at all
[14:08] <stgraber> ah, for the gnome use case we can fix it easily at least
[14:08] <stgraber> TryExec=gnome-session-quit
[14:08] <stgraber> and we need to change gnome-session-save to gnome-session-quit (upstream changed the name)
[14:08] <alkisg> I think we should generate those .desktop files from an init-ltsp.d script
[14:08] <stgraber> I'll push that change to trunk
[14:08] <alkisg> Check if it's a fat client or not, if it has gnome installed or not, etc
[14:09] <stgraber> one problem with auto-generating is how to deal with the translations
[14:09] <alkisg> We can copy the file from examples
[14:09] <alkisg> Or symlink it to save a few disk bytes
[14:09] <stgraber> indeed, that'd work. Just check for the fatclient though, for the session type, tryexec will do the trick
[14:10] <alkisg> OK so for the packaging part, I think it's best to put it in examples, not in applications, and later on symlink it from init-ltsp.d, and maybe even use the epoptes endsession logout/reboot etc script
[14:11] <alkisg> That would work in other DEs too so there's no need to check for the DE
[14:42] <alkisg> stgraber: I think I'm done except for debian/rules... I might need some help there, it seems complicated
[14:43] <stgraber> alkisg: ok, IIRC debian/rules is in a completely different dh format, so I'll probably just copy debian's and re-add anything that's missing
[14:44] <alkisg> Sounds good :)
[18:41] <highvoltage> jbicha: btw, how are things with that lightdm sru? is there anything I could test or do to help with that?
[18:55] <jbicha> highvoltage: you can ping Cimi about when the next light-themes update will be
[19:30] <highvoltage> jbicha: ok
=== jbicha_ is now known as jbicha
=== eHyperbyt is now known as Hyperbyte