IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 24 November 2013 (all times are UTC)
| 00:08 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.) | |
| 00:09 | christophe_y2k has left IRC (christophe_y2k!~christoph@man06-3-78-237-22-85.fbx.proxad.net, Quit: Leaving.) | |
| 00:24 | Parker955_Away is now known as Parker955 | |
| 00:56 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 245 seconds) | |
| 01:18 | gbit has left IRC (gbit!~chatzilla@unaffiliated/gbit, Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018]) | |
| 01:46 | <vagrantc> this seems pretty evil... http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2447
| |
| 01:46 | what versions of the driver does it affect?
| |
| 01:47 | it just blindly kills the dri for nouveau on i386?
| |
| 01:48 | is it fixed in any newer versions of nouveau?
| |
| 02:30 | clepto has joined IRC (clepto!~chadlepto@unaffiliated/chadlepto) | |
| 02:33 | ChadLepto has left IRC (ChadLepto!~chadlepto@unaffiliated/chadlepto, Ping timeout: 246 seconds) | |
| 02:36 | clepto is now known as ChadLepto | |
| 03:04 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Read error: Operation timed out) | |
| 03:21 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
| 04:25 | <vagrantc> heh.
| |
| 04:26 | heh... this ltsp build picked an amusing randomly generated directory name.
| |
| 04:26 | I: NOTICE: Log filtering will replace 'build/ltsp-DAFunk/ltsp-5.4.6' with '«PKGBUILDDIR»'
| |
| 04:26 | 5.4.6 is DAFunk release.
| |
| 04:30 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 04:37 | * alkisg waves to vagrantc | |
| 04:38 | <alkisg> "01:48 is it fixed in any newer versions of nouveau?" => no idea, but DRI doesn't work on thin clients anyway, does it?
| |
| 04:41 | <vagrantc> no idea, just seemed like a painful hack :(
| |
| 04:42 | <alkisg> True, but I didn't find any alternatives :(
| |
| 04:42 | <vagrantc> i've tagged 5.4.6, and am doing some very last test builds.
| |
| 04:42 | <alkisg> vagrantc: after the epoptes release, me and Phantomas are thinking of starting to implement http://wiki.ltsp.org/wiki/Dev:Ltspd
| |
| 04:42 | Any thoughts/objections on its design?
| |
| 04:43 | * vagrantc takes a look | |
| 04:43 | <alkisg> Client-side, we can use wget, nc, or socat. wget and socat can support SSL, if ever needed. We currently picked wget, it's also available in the initramfs busybox, although without SSL support there.
| |
| 04:44 | Server-side, we can implement it with inetd (no SSL), socat as a daemon, or python.
| |
| 04:44 | <vagrantc> alkisg: I don't think i'm going to apply it this upload, but was wondering what you thought of: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701647
| |
| 04:45 | i haven't done many LTSP setups with DNS available...
| |
| 04:47 | <alkisg> "This seems to be caused by $resolv not beeing writable." ?
| |
| 04:48 | <vagrantc> yeah, there's nothing in the moving around of it that would cause any issue.
| |
| 04:48 | as /run should already be mounted, and everything should be mounted writeable
| |
| 04:49 | <alkisg> /etc/network/interfaces is debian-specific, so I don't think we should upload that, if there are cross-distro alternatives....
| |
| 04:50 | I think you should ask him why $resolv isn't writable
| |
| 04:50 | <vagrantc> i don't think that's the crux of what's broken
| |
| 04:51 | but i don't really know
| |
| 04:51 | i.e. maybe they wrote a fix despite a poor diagnosis
| |
| 04:51 | <alkisg> Maybe his /etc/resolv.conf isn't actually a symlink to /run/resolvconf/resolv.conf
| |
| 04:52 | <vagrantc> even if it wasn't, it should still be writeable in /etc
| |
| 04:52 | <alkisg> He couldn't be using bind-mounts, could he?
| |
| 04:54 | <vagrantc> might be
| |
| 04:54 | sure hope not.
| |
| 04:54 | alkisg: your ltspd sounds good to me
| |
| 04:55 | alkisg: although input sanitization from the data sent by the client will be fairly important.
| |
| 04:55 | <alkisg> So, about ltspd server-side implementation, inetd does have a few good things like preventing DoS attacks etc, but it doesn't have any encryption support,
| |
| 04:56 | <vagrantc> i like config.d dirs
| |
| 04:56 | <alkisg> and we can do in python whatever we can do in a daemon socat.... so we selected python
| |
| 04:57 | Between simple nc-style connections and wget-like connections, we selected wget because it's preinstalled in most chroots, while socat (needed for SSL) isn't
| |
| 04:57 | And, if the python daemon is listening on http/https, we might reuse it to offer a GUI for editing the .conf files
| |
| 04:57 | I.e. a tiny web server with authentication etc
| |
| 04:58 | <vagrantc> which .conf files? the config.d snippets? other arbitrary things?
| |
| 04:58 | <alkisg> Everything under /etc/ltsp/config.d
| |
| 04:58 | <vagrantc> implementing the conditionals in the config parsing is interesting...
| |
| 04:59 | <alkisg> The daemon will always be running (it will replace ldminfod as well), and it will re-read its configuration on sighup
| |
| 04:59 | (or with inotify, if phantomas finds it light+easy)
| |
| 05:00 | <vagrantc> whoah... the cat << EOF stuff is... intteresting :)
| |
| 05:00 | <alkisg> vagrantc: are the names mentioned in the wiki page, and the config file syntax, acceptable?
| |
| 05:00 | The idea is that since the client trusts the server, and there's ssl and everything... we can blindly source everything the server sends to us
| |
| 05:01 | (currently x="$(command)" in lts.conf is executed even thought it's untrusted, unencrypted etc, so it's definately a step up, security-wise...)
| |
| 05:03 | <vagrantc> i didn't know arbitrary commands worked via lts.conf...
| |
| 05:03 | alkisg: a little bit of thought about naming conventions... i.e. ltspd is really visually similar to ltspfsd
| |
| 05:04 | * alkisg is open to any suggestions, not being a native speaker and all... | |
| 05:05 | <alkisg> We'll have `service ltspd start` etc of course, and we might even be able to use it for client authentication in the future,
| |
| 05:05 | something like the "join domain" of windows clients...
| |
| 05:06 | A completely different thought would be to have an ltsp user and use ssh for everything instead of daemons
| |
| 05:07 | There's also a patch for reverse sshfs around, so that would allow for replacing ltspfs with sshfs,
| |
| 05:07 | but I don't know if you guys would consider using an ltsp user acceptable...
| |
| 05:09 | The client would generate a unique (per client) ssh key for the ltsp user ssh login while still in the initramfs, it would "join the domain" on init-ltsp.d, and would keep that connection up and running with an ssh socket for all the duration while the client was booted
| |
| 05:09 | That would allow for secure commands both ways, and hopefully sshfs both ways
| |
| 05:09 | That's how I would implement it if I ever forked ltsp and didn't care about what others think :P
| |
| 05:11 | (of course the ltsp user would have a program of our own as a login shell)
| |
| 05:11 | nx* do the same thing, afaik...
| |
| 05:13 | <vagrantc> i've noted that as one of the messier things nx does...
| |
| 05:14 | <alkisg> I know, that's why I'm not going ahead and implementing it that way, even though I think it's really a superior approach :D
| |
| 05:15 | <vagrantc> not that we don't do a lot messier things to work around it
| |
| 05:15 | <alkisg> It's even easier for WAN-side implementations of LTSP because only one (secure) port is used, other than the root filesystem
| |
| 05:17 | vagrantc: so, waiting for your suggestions... should we name it ltspd, and use a python simplehttpserver etc as described in the wiki page?
| |
| 05:18 | And, is the config file syntax acceptable?
| |
| 05:19 | <vagrantc> alkisg: does that sort of a config syntax exist already?
| |
| 05:20 | <alkisg> Yes, it's the "standard" .ini file format, as implemented by the python configparser
| |
| 05:20 | <vagrantc> alkisg: the "[foo] var=value" format exists ... but "[foo > 12] var=value" ?
| |
| 05:20 | the conditionals too?
| |
| 05:20 | <alkisg> The [headers] can be anything, the parser doesn't mind,
| |
| 05:21 | where to put the conditionals is a choice we have to make on our own,
| |
| 05:21 | <vagrantc> sure.
| |
| 05:21 | <alkisg> either e.g. in the [header], or in a APPLY_WHEN="conditional statement" directive
| |
| 05:21 | And when that directive is missing, we can assume either "always", or "never, it's only to be included by other sections"
| |
| 05:22 | I suggested to put it in the header just to resemble the old lts.conf a bit...
| |
| 05:23 | <vagrantc> fuzzy matching in the headers?
| |
| 05:23 | <alkisg> We can probably also support [mac] and [ip] headers via regex matching, if we want that
| |
| 05:23 | <vagrantc> i.e. [mac = 00:11:22:*] ?
| |
| 05:23 | <alkisg> mac =~
| |
| 05:24 | Some languages use that instead of "similar to"
| |
| 05:24 | We can assume that to mean "starts with"
| |
| 05:24 | [mac =~ 00:11:22: ]
| |
| 05:25 | <vagrantc> mac = <regex> ?
| |
| 05:25 | anyways
| |
| 05:25 | <alkisg> If we want to, sure
| |
| 05:25 | <vagrantc> anyways, the name, i guess ltspd makes sense.
| |
| 05:25 | or ltsp-configd ?
| |
| 05:25 | i guess there's already ltsp-config
| |
| 05:26 | <alkisg> It will also send information to the client, like the available languages etc,
| |
| 05:26 | and in the future it might be used for "domain joining"
| |
| 05:26 | <vagrantc> also, replacing ldminfod with it ... which i guess also includes certain configurations
| |
| 05:26 | <alkisg> So I think I prefer it without the -config part
| |
| 05:26 | <vagrantc> i guess we could send configuration information in variables (i.e. languages, sessions, etc)
| |
| 05:27 | <alkisg> Right, and current server load etc
| |
| 05:27 | Whatever info the client might need
| |
| 05:27 | <vagrantc> at whatever arbitrary phase
| |
| 05:27 | i.e. login time, boot time ...
| |
| 05:28 | <alkisg> initramfs, init, login, logout, shutdown, any other phase needed?
| |
| 05:28 | (the shutdown phase is only to notify the server, the client doesn't need any replies there)
| |
| 05:29 | <vagrantc> alkisg: structurally, do you want the different phases to have a different configuration space? i.e. /etc/ltsp/ltspd/boot.d login.d logout.d , etc
| |
| 05:29 | <alkisg> Maybe... let's think about it
| |
| 05:30 | Some thing like HOSTNAME only make sense in the first phases
| |
| 05:30 | <vagrantc> might make nominal differences in parsing time...
| |
| 05:30 | <alkisg> Some things like server load, available sessions should be re-read upon login
| |
| 05:30 | The daemon will cache all settings in RAM anyway, in some internal structure
| |
| 05:31 | <vagrantc> so it won't re-read the settings?
| |
| 05:31 | <alkisg> It's just about how the user perceives the configuration, not about the implementation
| |
| 05:31 | <vagrantc> sure
| |
| 05:31 | <alkisg> Only on SIGHUP or with inotify
| |
| 05:31 | It won't reread them per client request
| |
| 05:32 | <vagrantc> keeps it fast-ish
| |
| 05:33 | <alkisg> I think separating the configuration too much will make it harder for the users
| |
| 05:33 | To define HOSTNAME and LDM_USERNAME for a single client, he shouldn't need to edit 2 configuration files
| |
| 05:33 | So I lean towards a single /etc/ltsp/config.d approach...
| |
| 05:33 | <vagrantc> sure
| |
| 05:34 | so they just drop a bunch of files in there...
| |
| 05:35 | <alkisg> Packages or users, with 00-xxx naming, yup
| |
| 05:36 | We'll start without SSL support for now, and we can add it in the future without changing the code base much
| |
| 05:36 | Are you OK with the client sourcing whatever the server sends to it?
| |
| 05:37 | Or do we need SSL before that?
| |
| 05:39 | <vagrantc> so we already execute arbitrary code... the filesystem is already insecure (if moderately complicated to compromise) ... dhcp is pretty much insecure...
| |
| 05:39 | <alkisg> OK so let's start simple and work it up later on
| |
| 05:39 | * vagrantc pulls out hair | |
| 05:39 | <vagrantc> what have i been doing all this time?! :)
| |
| 05:39 | <alkisg> Hehe :D
| |
| 05:40 | I think we can easily manage this: the initramfs communications to be insecure, and everything from init-ltsp.d and on to be completely secure, with ssl or ssh
| |
| 05:40 | <vagrantc> actually, with properly implemented secure boot (i.e. the admin can update the keys that sign stuff), we could actually see secure network booting in the near future
| |
| 05:40 | <alkisg> That should prevent the client to be hacked _after_ the initramfs....
| |
| 05:41 | With server spoofing etc
| |
| 05:41 | If the sysadmin somehow puts the kernel and initramfs locally, he can then have a completely secure boot
| |
| 05:42 | <vagrantc> i think iPXE also supports ssl, so you could just use a local iPXE
| |
| 05:43 | even without secure boot
| |
| 05:43 | <alkisg> Ah, we can even serve the kernel and initramfs from ltspd, very nice
| |
| 05:44 | Another plus for using https instead of socat :)
| |
| 05:44 | * vagrantc nods | |
| 05:45 | <alkisg> The "login" phase might actually be separated in 3 phases...
| |
| 05:46 | 1) ldm is ready, what are the available servers, languages etc?
| |
| 05:46 | 2) the user is about to login, what is the server load etc?
| |
| 05:46 | 3) the user has authenticated, do you have any user-specific settings?
| |
| 05:46 | (so we can have [ user = xxx ] sections too)
| |
| 05:47 | [ user = alkisg ] LDM_SESSION=gnome-fallback
| |
| 05:48 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 05:49 | <vagrantc> alkisg: so it would also read from ~/.config/ltspd or something?
| |
| 05:50 | <alkisg> Do we want it to? What use cases are there? How will that configuration file be written?
| |
| 05:50 | It'd be best if ltspd ran as "nobody", not as "root"...
| |
| 05:51 | So it might not have access to /home/username/.config
| |
| 05:51 | <vagrantc> yeah, in general that's a good idea, although currently, at least in theory, we support ~/.dmrc
| |
| 05:51 | alkisg: you were more talking about forced sessions and the like?
| |
| 05:51 | <alkisg> That's ldm via the ssh socket, not ltspd
| |
| 05:52 | <vagrantc> i.e. like what we have via lts.conf now
| |
| 05:52 | <alkisg> I meant that the sysadmin could specify the default session per username, instead of per mac
| |
| 05:52 | <vagrantc> right
| |
| 05:52 | <alkisg> It wouldn't be specified by the user; but by the sysadmin
| |
| 05:52 | The user can override it with .dmrc as it does now, unless the sysadmin uses LDM_FORCESESSION
| |
| 05:54 | * alkisg thinks that ltspd shouldn't ever access $HOME, only ldm/libpam_sshauth/ssh should do that... | |
| 05:54 | * vagrantc nods | |
| 05:54 | <alkisg> Although, if we need it, ltspd can run as an ltsp user, and have access to /var/run/ltsp on the server
| |
| 05:55 | vagrantc: did debian also start offering /run/user/* run time directories?
| |
| 05:56 | 14.04 does that, I didn't read about the rationale/time of implementation etc though
| |
| 05:56 | <vagrantc> such as /run/user/$USER ?
| |
| 05:56 | <alkisg> Yes
| |
| 05:56 | pulse etc go there now
| |
| 05:56 | <vagrantc> don't see anything on jessie or wheezy
| |
| 05:56 | <alkisg> It's a good thing; it doesn't need /home/username file system to support sockets, so it's easier for sshfs or samba HOMEs
| |
| 05:57 | Probably even for nfs homs
| |
| 05:57 | homes
| |
| 05:57 | <vagrantc> yeah, run-time user-specific stuff
| |
| 05:57 | doesn't really belong in $HOME
| |
| 05:58 | <alkisg> I see mentions of that dir for fedora too, I hope it becomes cross-distro eventually
| |
| 05:59 | <vagrantc> meh. forgot to include acpi-support-base in recommends on this last package.
| |
| 05:59 | knew i was forgetting somethin
| |
| 06:00 | * alkisg wonders if logind is the driving force behind /run/user/<uid>... vagrantc, does jessie use logind yet? | |
| 06:01 | <vagrantc> alkisg: debian is in the midst of painful discussions about what to do regarding all that mess.
| |
| 06:03 | * alkisg hopes that debian will prefer systemd, even if it's brutally enforced by fedora, and even if it won't work with *bsd, so that everyone ends up using the same init system in the far future... even if it means that bsd will have to support cgroups for that :P | |
| 06:05 | <alkisg> Ubuntu isn't involved in the upstream development enough (kernel, dbus, udev, logind, whatever) to justify supporting its own init system
| |
| 06:06 | If the upstream developers adopted it (as some once had), ok, but since they aren't...
| |
| 06:07 | * vagrantc has yet to see what's so broken about the old init systems | |
| 06:07 | <vagrantc> but that's typical me :)
| |
| 06:07 | <alkisg> Parallel booting, and event-based starting of daemons
| |
| 06:07 | * alkisg doesn't care about those either | |
| 06:08 | * vagrantc hears that the sky is falling | |
| 06:09 | <alkisg> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
| |
| 06:09 | There is a single base directory relative to which user-specific runtime files and other file objects should be placed. This directory is defined by the environment variable $XDG_RUNTIME_DIR.
| |
| 06:09 | Lennart Poettering :p
| |
| 06:09 | <vagrantc> that's actually something i find useful :)
| |
| 06:10 | <alkisg> Yeah, I like this guy's ideas. Not so much the way he enforces stuff, but at least the things he does eventually work
| |
| 06:11 | <vagrantc> i'm not sure i agree in general... too many things are just reimplemented for no apparent reason and take forever to get it back to a working state
| |
| 06:11 | speaking of ltsp6
| |
| 06:12 | wheee.
| |
| 06:12 | <alkisg> pulse => ok. parallelism+event driven booting, plymouth etc => ok, but it should only become widespread _after_ they got it working.... :
| |
| 06:13 | And I think that's what they're doing, RHEL is only now switching to systemd afaik, while fedora is the playground... the problem is in ubuntu, it adopts things too quickly, before they're stable enough for production use
| |
| 06:13 | <vagrantc> and debian, well, debian doesn't move very fast :)
| |
| 06:14 | <alkisg> That's why it's ideal for schools :)
| |
| 06:15 | When I get a few months with a light schedule, I'll start preparing a live jessie .iso for schools here
| |
| 06:16 | <vagrantc> ok, i want to give a quick go at implementing /opt/ltsp/images/i386.img over NFS
| |
| 06:16 | alkisg: now that's a moving target
| |
| 06:16 | <alkisg> Cool, it should be easy
| |
| 06:16 | Nah, when I get those months jessie will be mostly stable :)
| |
| 06:17 | <vagrantc> freeze is about a year from now
| |
| 06:17 | * alkisg hopes to finish his phd by then | |
| 06:18 | <alkisg> !local-boot
| |
| 06:18 | <ltsp> local-boot: If you want LTSP fat clients on a low-speed network, you can put i386.img on e.g. C:\Boot\LTSP\i386.img and use this command line in pxelinux.cfg: APPEND ro initrd=ltsp/i386/initrd.img init=/sbin/init-ltsp root=/dev/sda1 rootflags=ro loop=/Boot/LTSP/i386.img; IPAPPEND 3
| |
| 06:19 | <alkisg> !nbd-boot
| |
| 06:19 | <ltsp> Error: "nbd-boot" is not a valid command.
| |
| 06:19 | <vagrantc> huh.
| |
| 06:19 | where's loop= implemented?
| |
| 06:19 | <alkisg> vagrantc: if debian supports the "loop" parameter, you might be able to use it for what you're trying now
| |
| 06:20 | In the initramfs, let me check the exact file...
| |
| 06:20 | (outside of ltsp)
| |
| 06:21 | In scripts/local... does nfs call that?
| |
| 06:22 | <vagrantc> i don't see any mention of loop in scripts/local
| |
| 06:22 | <alkisg> In jessie? It was added a bit recently
| |
| 06:22 | <vagrantc> but there is some support with root=/dev/loop0
| |
| 06:22 | <alkisg> http://paste.ubuntu.com/6467322/
| |
| 06:23 | lines about after 100
| |
| 06:23 | <vagrantc> not in jessie
| |
| 06:24 | <alkisg> Meh, ubuntu-isms... but ok they're nice to have
| |
| 06:24 | http://sources.debian.net/src/initramfs-tools/0.115/scripts/local
| |
| 06:24 | It's not there
| |
| 06:24 | <vagrantc> nor in initramfs-tools git
| |
| 06:24 | <alkisg> So ok re-implement it in ltsp
| |
| 06:25 | You might want to use the same syntax... loop=xxx
| |
| 06:25 | <vagrantc> initramfs-tools | 0.103ubuntu2 | trusty | source, all
| |
| 06:25 | initramfs-tools | 0.115 | sid | source, all
| |
| 06:25 | i think there might be more generic syntax
| |
| 06:26 | <alkisg> boot=nfs root=/dev/nfs loop=i386.img (and dhcp ROOTPATH=/opt/ltsp/images)
| |
| 06:27 | (or nfsroot)
| |
| 06:29 | * alkisg reads http://live.debian.net/manpages/2.x/en/html/live-boot.7.html | |
| 06:29 | <vagrantc> it's a live-boot extension?
| |
| 06:31 | <alkisg> I don't know, but live-boot has a lot of things that we currently implement in ltsp
| |
| 06:31 | So it would be nice to at least use the same names
| |
| 06:31 | For example, see "toram" and "todisk" in that page
| |
| 06:31 | You've implemented toram in ltsp already ;)
| |
| 06:31 | <vagrantc> i know
| |
| 06:32 | though poorly
| |
| 06:34 | it's where i got the idea, figured it shouldn't be too hard.
| |
| 06:34 | <alkisg> httpfs2?!! /me googles...
| |
| 06:34 | <vagrantc> well, also sort of got the idea from tcos
| |
| 06:35 | <alkisg> Haha, we can support that with ltspd, as an alternative to nfs/nbd :P
| |
| 06:35 | <vagrantc> i suspect it's not well maintained ... no updates to debian since before oldstable
| |
| 06:35 | then you wouldn't even have to wget the files, it would just serve different configuration files :)
| |
| 06:36 | which is an interesting idea, honestly.
| |
| 06:36 | <alkisg> No, it serves a single big file
| |
| 06:36 | Not a hierarchy
| |
| 06:36 | <vagrantc> oh
| |
| 06:37 | <alkisg> Not all if it is downloaded of course, just the needed chunks of it
| |
| 06:39 | https://github.com/smgoller/rangehttpserver ==> extends the python's simplehttpserver to support the http range command, so yup httpfs2 is possible :P
| |
| 06:42 | vagrantc: when can I start committing stuff about ltspd? i.e. when will you upload ltsp? in a couple of days?
| |
| 06:42 | <vagrantc> alkisg: a couple of hours ago
| |
| 06:42 | <alkisg> :)
| |
| 06:42 | And ldm too?
| |
| 06:43 | <vagrantc> no, haven't touched ldm or ltspfs yet
| |
| 06:43 | <alkisg> Meh. LDM translation commits still happen after I deleted ldm.pot. I'll disable them until the next upload. Should I also revert ldm.pot?
| |
| 06:44 | <vagrantc> why not just put translations on a separate branch, and then merge them periodically
| |
| 06:44 | <alkisg> ltsp-trunk is fine, it doesn't need that
| |
| 06:45 | And, why are we using intltool on ldm but not on ltsp?
| |
| 06:45 | <vagrantc> because ltsp is simpler, and the approach we used for ltsp didn't work with ldm
| |
| 06:46 | <alkisg> So once we remove ldm, we can stop using intltool?
| |
| 06:46 | <vagrantc> there was something different about pulling translations from the c stuff, or something notably different
| |
| 06:46 | <alkisg> Then I don't think it's worth the trouble to change our current workflow...
| |
| 06:46 | <vagrantc> i guess
| |
| 06:47 | <alkisg> Updating the sources to that other translations branch and merging them and importing the translations to the main branch sounds like more work than just disabling/enabling translation commits..
| |
| 06:48 | <vagrantc> suppose so
| |
| 06:48 | just wish we could tell launchpad "please commit them right now, thanks."
| |
| 06:49 | * alkisg wishes launchpad wouldn't insert the "X-Launchpad-Export-Date: 2013-11-23 04:30+0000\n" lines when intltool is used | |
| 06:49 | <alkisg> That would make things automatic, like they are in ltsp-trunk
| |
| 06:50 | <vagrantc> yeah, it should at least be smart enough to figure out the only difference was what it added.
| |
| 06:51 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Operation timed out) | |
| 06:59 | <alkisg> make[2]: Entering directory `/home/Public/Linux/Sources/ltsp/ldm-trunk/po'
| |
| 06:59 | rm -f *.pox ldm.pot *.old.po cat-id-tbl.tmp
| |
| 07:00 | If we make intltool commit an unchanged ldm.pot, and not delete it afterwards, problem solved..
| |
| 07:02 | In po/rc.d/Makefile:
| |
| 07:02 | distclean: clean
| |
| 07:02 | clean:
| |
| 07:02 | - rm *.mo *~
| |
| 07:02 | If we had that in po/Makefile too, I think it would work
| |
| 07:07 | Who knows about intltool? Maybe he can do that change, cause I'm a bit lost there...
| |
| 07:12 | <vagrantc> i seem to recall it requiring removing the .pot in order to get it to update when things changed.
| |
| 07:19 | <alkisg> It shouldn't have to, the -update tools work fine when there are changes vs when there are not
| |
| 07:20 | vagrantc: who did our intltool configuration?
| |
| 07:35 | vagrantc: read my latest comment in https://answers.launchpad.net/launchpad/+question/220460
| |
| 07:35 | debuild -b -tc generates a different .pot than the one we had in trunk
| |
| 07:36 | Source lines changes etc
| |
| 07:36 | Now, I tried using an updated ldm.pot, and intltool didn't change it!
| |
| 07:36 | So maybe this whole time, the problem was that our ldm.pot was outdated...
| |
| 07:37 | I'll try to commit an updated ldm.pot and see if it solves the launchpad issue
| |
| 07:41 | <vagrantc> ok, with a little hackery, i got the loop mounts working
| |
| 07:41 | over NFS
| |
| 07:44 | <alkisg> vagrantc: intltool now with my freshly committed ldm.pot, doesn't update it on build
| |
| 07:44 | <vagrantc> huh.
| |
| 07:44 | <alkisg> So I'll reenable translations, I think that launchpad won't be doing daily commits until we change the source code
| |
| 07:44 | So, everything was fine, and our only problem was that ldm.pot was outdated
| |
| 07:45 | <vagrantc> so, how can we automate ldm.pot getting updated?
| |
| 07:45 | <alkisg> We can do that if we tell intltool to not delete it after build
| |
| 07:46 | Then launchpad will automatically commit it when there are actual changes
| |
| 07:46 | I don't know how to tell intltool to do that though....
| |
| 07:46 | <vagrantc> can we work around it... i.e. put the old one back?
| |
| 07:47 | <alkisg> Sure, we can manually run the command that intltool runs and regenerate the correct one
| |
| 07:48 | But it's a lame hack, we should just fix our intltool makefile
| |
| 07:48 | <vagrantc> so, it wasn't elegant, but i had to trick initramfs-tools/scripts/nfs by creating /opt/ltsp/images/sbin/init-ltsp
| |
| 07:48 | speaking of hacks
| |
| 07:48 | <alkisg> It should be a 1-line change... I'll try it today
| |
| 07:49 | vagrantc: why did you have to do that? It errors out directly after mounting root, if init isn't there?
| |
| 07:49 | <vagrantc> alkisg: the NFS script checks for $init being present
| |
| 07:50 | which is a reasonable check to make sure you've mounted the right thing... usually.
| |
| 07:50 | <alkisg> vagrantc: what do you use for rootmnt ?
| |
| 07:51 | <vagrantc> alkisg: what do you mean exactly?
| |
| 07:51 | alkisg: there's no built-in support for loop=
| |
| 07:51 | <alkisg> I think that you put it in the wrong place
| |
| 07:52 | If you put it in nfs-premount, then you won't need the hack
| |
| 07:52 | Ouch sorry
| |
| 07:52 | It would need to be in nfs-postmount :P
| |
| 07:52 | <vagrantc> nfs-premount is before NFS is mounted
| |
| 07:52 | nfs-bottom
| |
| 07:53 | which is after the $init check
| |
| 07:53 | <alkisg> RIght, they don't give a hook for such things as "loop" inbetween,
| |
| 07:53 | <vagrantc> indeed.
| |
| 07:53 | <alkisg> so I think you have a good case for a bug report...
| |
| 07:53 | (wishlist, of course)
| |
| 07:53 | <vagrantc> yeah, i've been reasonably suuccessful getting patches into initramfs-tools
| |
| 07:54 | and even though i've heard mention of switching to dracut many times over, i don't see it happening soon.
| |
| 07:55 | <alkisg> I think it should be possible for ltsp to have not code at initramfs whatsoever, and only do the cow thing for /run from init-ltsp.d
| |
| 07:55 | <vagrantc> yes, but not with the loop mount stuff
| |
| 07:55 | <alkisg> /run, /home, /etc etc
| |
| 07:55 | The loop mount should be implemented in initramfs-tools
| |
| 07:56 | <vagrantc> indeed.
| |
| 07:56 | <alkisg> It's not specific to ltsp
| |
| 07:57 | <vagrantc> alkisg: so i wonder where the loop mounting support you're using comes from?
| |
| 07:57 | <alkisg> I think it's ubuntu specific, maybe initially developed for casper (livecd)
| |
| 07:58 | And they decided that it should go to initramfs-tools for all installations, instead of only casper for the live cd... it's just an idea though, I didn't verify that
| |
| 07:58 | * alkisg does apt-get source initramfs-tools | |
| 07:59 | <alkisg> initramfs-tools (0.98.8ubuntu1) natty; urgency=low
| |
| 07:59 | - Allow the mounting of a root filesystem as a loop device on top of a
| |
| 07:59 | host filesystem, used for Wubi installs.
| |
| 07:59 | So it was wubi, not casper
| |
| 08:00 | wubi needs it, casper needs it, debian-live needs it... meh maks just get it to initramfs-tools... :D
| |
| 08:01 | <vagrantc> i'll see what i can do...
| |
| 08:02 | <alkisg> I once read about some ...package? I don't remember, which supported multiple path specifications in the same kernel parameter
| |
| 08:02 | iscsi? aoe? I don't remember,
| |
| 08:03 | so it went something like root=/dev/sda1,loop=xxx
| |
| 08:03 | <vagrantc> oh, wow.
| |
| 08:03 | <alkisg> I.e. many instructions on how to effectively mount root
| |
| 08:03 | <vagrantc> well, with /opt/ltsp/images/sbin/init-ltsp and a loop script in nfs-bottom, it works pretty simply.
| |
| 08:04 | <alkisg> That would be the ideal... no need for multiple parameters, one is enough, and that way it also makes clear in which turn the commands need to be executed
| |
| 08:05 | The nfs/local/ltsp scripts then would be just plugins to implement one part of that command sequence
| |
| 08:05 | <vagrantc> i'm surprised LTSP figured out the rootserver though
| |
| 08:06 | i think initramfs-tools generally wanted to re-use and maintain compatibility with existing kernel parameters, though.
| |
| 08:07 | <alkisg> And people went on and invented new ones :) nbdroot, encryption, raid, aoe, iscsi...
| |
| 08:07 | <vagrantc> yup
| |
| 08:08 | this is pretty slick, though
| |
| 08:08 | <alkisg> vagrantc: do some speed testing :)
| |
| 08:09 | <vagrantc> it *seems* faster, what more do you want? :)
| |
| 08:10 | <alkisg> Hehe
| |
| 08:13 | <vagrantc> i did rewrite a lot of the nfs code in initramfs-tools ...
| |
| 08:13 | that whole init problem could very well be my own fault
| |
| 08:16 | i've got a fair number of patches to initramfs-tools for 2006/2007
| |
| 08:24 | i think maks added the init bits ...
| |
| 08:25 | well, git-bzr has some ugly bugs with symlinks, at least.
| |
| 08:25 | anyways, time to sleep.
| |
| 08:26 | <alkisg> Good night vagrantc
| |
| 08:27 | * vagrantc notes that ltsp built on hurd-i386 | |
| 08:28 | <vagrantc> alkisg: phantomas promised to get epoptes working, keep on it! :)
| |
| 08:29 | <alkisg> vagrantc: yeah today is a work day for me and phantomas
| |
| 08:29 | We'll get ldm.pot and epoptes out of the way, and then move on to ltspd
| |
| 08:30 | <vagrantc> i'll hopefully get epoptes, ldm and maybe ltspfs uploaded tomorrow
| |
| 08:33 | i'm tempted to commit the little hack for the loop mounting anyways.
| |
| 08:33 | kind of like the TO_RAM option
| |
| 08:35 | <alkisg> Sure, it sounds nice to have, and it's not available in nfs ubuntu either
| |
| 08:37 | <vagrantc> and i've got a two-liner patch to submit to initramfs-tools ... basically dropping the init check (which happens later anyways)
| |
| 08:48 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 08:53 | gdi2k_ has left IRC (gdi2k_!~gdi2k@120.28.232.172, Ping timeout: 272 seconds) | |
| 09:00 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Read error: Connection reset by peer) | |
| 09:04 | bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com) | |
| 09:06 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@64.69.46.232) | |
| 10:15 | stevecook172001 has joined IRC (stevecook172001!5e032a87@gateway/web/freenode/ip.94.3.42.135) | |
| 10:18 | stevecook172001 has left IRC (stevecook172001!5e032a87@gateway/web/freenode/ip.94.3.42.135, Client Quit) | |
| 10:19 | stevecook172001 has joined IRC (stevecook172001!5e032a87@gateway/web/freenode/ip.94.3.42.135) | |
| 10:20 | <stevecook172001> I currently have an Ubuntu 12.04 ltsp server running on gnome3 with fat clients.
| |
| 10:20 | The clients get their internet connection from a separate wireless network.
| |
| 10:21 | It all works really well (particularly with streaming video, which is why I went with fat clients instead of thin ones
| |
| 10:21 | apart from one irritating thing. When the fat clients boot up, they are not connected to the wireless network although the wireless network is visible in the drop down list on the top desktop panel.
| |
| 10:21 | When the correct wireless network is chosen from the list, the first thing that comes up is a request for the root password.
| |
| 10:21 | When this has been filled in, it then asks for the password for the wireless network.
| |
| 10:22 | After this is filled in, the wireless network connects and full internet access is then available.
| |
| 10:22 | What I am needing to know is how I can force this wireless internet connection to be enabled automatically on the fat clients at boot-up.
| |
| 10:22 | Any advice gratefully received.
| |
| 10:24 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
| 10:24 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
| 10:25 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 10:31 | <alkisg> stevecook172001: on a fat client, use network manager to create a system connection for your wireless network
| |
| 10:31 | system == [x] apply to all users
| |
| 10:31 | Then copy /etc/NetworkManager/system-connections/<your connection> to your chroot
| |
| 10:31 | But omit the mac address, so that it applies to all clients
| |
| 10:32 | Alternatively, use /etc/network/interfaces, google for how to set up a wifi connection over that
| |
| 10:34 | <stevecook172001> Brilliant, thanks so much for the advice.
| |
| 10:47 | <alkisg> vagrantc, for when you're online, here's a stupid hack for debian/rules that does prevent ldm.pot from being deleted, until someone that knows Makefiles can do it properly:
| |
| 10:47 | stevecook172001 has left IRC (stevecook172001!5e032a87@gateway/web/freenode/ip.94.3.42.135, Quit: Page closed) | |
| 10:47 | <alkisg> # Hack to prevent ldm.pot from being deleted, until a proper solution is found
| |
| 10:47 | dh_auto_configure
| |
| 10:47 | sed 's/$(GETTEXT_PACKAGE).pot \*.old.po/*.old.po/' -i po/Makefile*
| |
| 10:47 | That goes under override_dh_auto_configure:
| |
| 10:48 | I tried creating a po/Makefile.am to override that, but it didn't work, possibly because of the --force flags we're using
| |
| 10:58 | test case: a debuild -b -tc, shouldn't delete po/ldm.pot
| |
| 10:58 | sbalneav, stgraber, if you have any better ways... it'll save us from all the stupid launchpad translations commits ^
| |
| 11:37 | gdi2k_ has left IRC (gdi2k_!~gdi2k@64.69.46.232, Ping timeout: 246 seconds) | |
| 11:56 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@120.28.232.172) | |
| 12:14 | christophe_y2k has joined IRC (christophe_y2k!~christoph@man06-3-78-237-22-85.fbx.proxad.net) | |
| 12:34 | <alkisg> Ugh, no, that won't work, I don't think launchpad will use the debian/ directory... it needs to go to the Makefiles
| |
| 13:15 | hs366 has joined IRC (hs366!~hs366@94.254.45.76) | |
| 13:28 | xet7 has left IRC (xet7!~xet7@a88-112-147-81.elisa-laajakaista.fi, Quit: Lähdössä) | |
| 13:33 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 14:44 | Fenuks has joined IRC (Fenuks!~Fenuks@212.164.166.235) | |
| 15:04 | gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com) | |
| 15:07 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 15:33 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 246 seconds) | |
| 15:45 | hs366 has left IRC (hs366!~hs366@94.254.45.76, Quit: Leaving) | |
| 16:00 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 16:33 | gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Remote host closed the connection) | |
| 16:37 | gbaman_ has joined IRC (gbaman_!~gbaman@host81-130-48-226.in-addr.btopenworld.com) | |
| 16:38 | Fenuks has left IRC (Fenuks!~Fenuks@212.164.166.235, Ping timeout: 272 seconds) | |
| 16:54 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
| 17:04 | <vagrantc> Phantomas: how's epoptes coming?
| |
| 17:05 | <Phantomas> vagrantc: Hey, I think I fixed it, now need to test it :)
| |
| 17:05 | <vagrantc> i've got a test environment ready to go... :)
| |
| 17:05 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 272 seconds) | |
| 17:06 | <Phantomas> good, let me do the basic tests though first :D
| |
| 17:07 | <vagrantc> ok
| |
| 17:14 | gbaman_ has left IRC (gbaman_!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Remote host closed the connection) | |
| 17:17 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 17:24 | lmds_ has left IRC (lmds_!~lmds@213.41.240.245, Read error: Connection reset by peer) | |
| 17:28 | <Phantomas> vagrantc: btw Is there a case in which a regular user (not root) home dir would not have a .config directory?
| |
| 17:30 | <vagrantc> Phantomas: newly created homedir?
| |
| 17:30 | Phantomas: it shouldn't assume the directory is present, but if it needs it, it should create it
| |
| 17:30 | <Phantomas> i wonder if it's ok to create it when it's missing
| |
| 17:30 | ok
| |
| 17:30 | <vagrantc> but you might not necessarily have a writeable home ...
| |
| 17:30 | so it would be best to be able to work without it
| |
| 17:31 | Phantomas: are you saving per-user configuration for epoptes?
| |
| 17:31 | <Phantomas> Yes.
| |
| 17:32 | UI preferences, epoptes groups and an executed commands history
| |
| 17:33 | <vagrantc> ah, this is for the epoptes daemon, not for the epoptes-client stuff.
| |
| 17:34 | <Phantomas> these settings are for the epoptes gui. epoptes daemon doesn't need to store anything on any homedir
| |
| 17:34 | but the gui and the daemon use the same config module
| |
| 17:35 | <vagrantc> ah, ok.
| |
| 17:49 | stgraber: hopefully this next upload will be syncable for ubuntu
| |
| 17:49 | stgraber: of ldm
| |
| 17:52 | <Phantomas> vagrantc: pushed epoptes :)
| |
| 17:56 | <vagrantc> Phantomas: cool.
| |
| 17:56 | huh. there's been an NMU of ldm that never was announced to the list, and some bug traffic never made it there
| |
| 18:24 | gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com) | |
| 18:43 | christophe_y2k has left IRC (christophe_y2k!~christoph@man06-3-78-237-22-85.fbx.proxad.net, Quit: Leaving.) | |
| 18:43 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 18:43 | * alkisg waves | |
| 18:45 | * vagrantc waves | |
| 18:46 | markit has joined IRC (markit!~marco@88-149-177-66.v4.ngi.it) | |
| 18:47 | <markit> alkisg: don't know if is something that can be fixed, but if a fat client has i.e. Libreoffice open and a document not yet saved, and in epoptes you issue a "close session", kde disappears and you have libo alone asking if you want to save.
| |
| 18:49 | <alkisg> markit: open /usr/share/epoptes-client/endsession, see the command there that we're using for KDE, google it, and if you find something better, file a bug report with a patch :)
| |
| 18:49 | <markit> alkisg: lol, I dubt, but thanks :)
| |
| 18:51 | <alkisg> vagrantc: so to sum up the current status of the translations commits bug, we should manually upload ldm.pot whenever there are changes in the .c source code (we'll also know that because launchpad will start again doing daily commits)
| |
| 19:06 | <vagrantc> i just realized i haven't tested fatclients at all...
| |
| 19:06 | alkisg: what a lovely notice...
| |
| 19:07 | <alkisg> Hehe
| |
| 19:07 | <vagrantc> alkisg: any changes, or changes that affect the translations
| |
| 19:07 | <alkisg> Changes that affect translations, but I think that changes in line numbers also affect them
| |
| 19:07 | Any change in which ldm.pot is changed when intltool is ran
| |
| 19:08 | <vagrantc> ouch
| |
| 19:08 | wonder if we can have some sort of check in the revision control system that warns when that happens
| |
| 19:09 | <alkisg> I think we can have a bzr hook that even pushes ldm.pot when there are changes that affect it...
| |
| 19:09 | But I wouldn't worry too much about it, how much are we going to change the .c code until we ditch ldm?
| |
| 19:11 | <vagrantc> no idea, but it's really messy when it starts happening
| |
| 19:11 | it definitely slows my workflow down uploading a new version
| |
| 19:13 | gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Remote host closed the connection) | |
| 19:13 | <alkisg> There was a new reply to my question, https://answers.launchpad.net/launchpad/+question/220460, but it's not helpful...
| |
| 19:13 | gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com) | |
| 19:13 | <vagrantc> as least they tried
| |
| 19:20 | epoptes looks worth tagging.
| |
| 19:24 | alkisg: you made the ethtool support a suggests rather than a recommends? seems worth having by default ... or is it too buggy?
| |
| 19:26 | <alkisg> vagrantc: ethtool is there to fix some bugs about WOL
| |
| 19:27 | That part doesn't really belong to epoptes-client, that's why I left it a "suggests"
| |
| 19:27 | The relevant code is at epoptes-client.if-up
| |
| 19:28 | <vagrantc> alkisg: which files contain the version strings?
| |
| 19:29 | <Phantomas> vagrantc: it's taken from the changelog
| |
| 19:29 | (by setup.py)
| |
| 19:31 | <vagrantc> it looks like epoptes/__init__.py and and epoptes-client/epoptes-client bot have the version hard-coded ... ?
| |
| 19:31 | <alkisg> Phantomas: you should commit something like this: http://bazaar.launchpad.net/~epoptes/epoptes/trunk/revision/327
| |
| 19:31 | ...and vagrantc the does the debian release, like this: http://bazaar.launchpad.net/~epoptes/epoptes/trunk/revision/328
| |
| 19:32 | <vagrantc> Phantomas: yeah, you should do the honors of tagging
| |
| 19:32 | <alkisg> (327 shows the files that have the version numbers)
| |
| 19:33 | vagrantc: should we look at anything from the qa reports?
| |
| 19:33 | http://packages.qa.debian.org/e/epoptes.html => 1 warning from lintian etc
| |
| 19:33 | <vagrantc> probably a good idea.
| |
| 19:33 | <alkisg> The xvnc4viewer dependency doesn't seem worth removing, it's still the best default
| |
| 19:34 | The standards were updated afaik,
| |
| 19:35 | And the /root/.rnd issue is actually and openssl issue, we ignored that in the past too
| |
| 19:35 | About the warning, should we add a .lintian-overrides?
| |
| 19:36 | * vagrantc pastes a more up-to-date lintian output | |
| 19:38 | <vagrantc> alkisg: http://paste.debian.net/67547/
| |
| 19:38 | nothing major, really.
| |
| 19:39 | alkisg: W: epoptes-client: init.d-script-does-not-source-init-functions etc/init.d/epoptes-client
| |
| 19:39 | would be good to fix
| |
| 19:40 | <alkisg> vagrantc: that script is only there to trigger an event for *old* ltsp thin clients, it just calls the if-up script because until a couple of years ago, they didn't receive an if-up event
| |
| 19:40 | <vagrantc> ah.
| |
| 19:40 | could remove it entirely, then?
| |
| 19:41 | <alkisg> We're still supporting 10.04 and squeeze...
| |
| 19:42 | <vagrantc> wow
| |
| 19:42 | <alkisg> vagrantc: does this make lintian happy? http://paste.debian.net/67551/
| |
| 19:43 | <Phantomas> vagrantc: We should wait for launchpad to export the latest PO files to the branch, in order to have updated translations. Then I'll commit the new version numbers. OK?
| |
| 19:43 | <alkisg> epoptes-client doesn't use any init functions, so it's silly to source it for nothing, before exec'ing another program...
| |
| 19:43 | <vagrantc> Phantomas: how long will that be?
| |
| 19:43 | <alkisg> Phantomas: that might take many hours, will vagrantc still be available then?
| |
| 19:44 | <Phantomas> I don't think I can make a manual export... Should we proceed without that 1 string? :)
| |
| 19:44 | <vagrantc> might be good to tidy up a few things
| |
| 19:44 | * vagrantc wishes there was a button for launchpad translations to say "get em!" | |
| 19:45 | <vagrantc> that would solve all these problems
| |
| 19:45 | <alkisg> Phantomas: do we have 1 new, untranslated string?
| |
| 19:45 | <Phantomas> alkisg: translated to rosetta not exported to our branch
| |
| 19:45 | translated for some languages of course
| |
| 19:45 | <alkisg> Ah. Hmm...
| |
| 19:46 | <vagrantc> alkisg: it's not sourcing it for nothing, it's enabling a hook of some kind...
| |
| 19:46 | <alkisg> vagrantc: the output functions are only valid if the caller script... calls them
| |
| 19:46 | epoptes-client isn't an initscript, it runs from if-up.d, so it's not using the init functions
| |
| 19:46 | <vagrantc> alkisg: apparently there's some systemd hook tthat it helps redirect
| |
| 19:46 | <Phantomas> alkisg: maybe i could manually download the POs from rosetta and push them manually to trunk...
| |
| 19:47 | but even on that one launchpad takes some time to send you the download links
| |
| 19:47 | <alkisg> I don't think it's worth the trouble, and the possible launchpad side effects...
| |
| 19:47 | vagrantc: systemd in 10.04 and in squeeze?
| |
| 19:47 | <vagrantc> alkisg: then i think we leave it alone, rather than implement a workaround.
| |
| 19:48 | alkisg: leave the warning there, and wait for a bug report about it
| |
| 19:48 | alkisg: or set up an override...
| |
| 19:49 | <alkisg> OK let's leave it there, when 14.04 and jessie are released we'll stop supporting squeeze and 10.04 so we'll just remove that initscript..
| |
| 19:51 | <Phantomas> According to bzr log, launchpad exports the translations every day at 04:00 - 06:00 UTC, so we won't see a commit soon. I'm commiting the new version numbers, if you agree.
| |
| 19:59 | <vagrantc> can always make a point release later, we're bound to find other issues.
| |
| 19:59 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 246 seconds) | |
| 20:00 | <vagrantc> alkisg: ah, and it mentions what versions are affected
| |
| 20:00 | good.
| |
| 20:01 | alkisg: alternately, could just put a Breaks: ltsp-client-core << 5.3
| |
| 20:01 | alkisg: and only ship the init script with backports...
| |
| 20:02 | <alkisg> Is it worth the trouble, to have patches for backports for such a minor thing?
| |
| 20:02 | Also, what about other distros?
| |
| 20:02 | opensuse and fedora are using epoptes, I don't know what happens there wrt compatibility...
| |
| 20:04 | <vagrantc> alkisg: well, they're probably not using debian/epoptes-client.init, in any case :)
| |
| 20:04 | <alkisg> I think opensuse copied that...
| |
| 20:04 | <vagrantc> alkisg: i'm fine with leaving it, and not bothering with a lintian override
| |
| 20:04 | <alkisg> But it would be a copy, ok
| |
| 20:05 | Yup let's leave it I don't think it's worth the trouble to handle it when it's schedule for future removal
| |
| 20:05 | <vagrantc> and waiting for someone who cares enough to ask for it's removal
| |
| 20:06 | squeeze support officially will end in May, and 10.04 is questionably supported at this point.
| |
| 20:07 | alkisg: i'll review standards-version
| |
| 20:08 | <alkisg> Nice, ty
| |
| 20:16 | vagrantc: when you're done testing, ping Phantomas to commit the new upstream version... or should he do it now?
| |
| 20:16 | Ah ok he already did
| |
| 20:19 | gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Remote host closed the connection) | |
| 20:19 | <Phantomas> Oh, my bad, should I uncommit?
| |
| 20:22 | <vagrantc> Phantomas: no, if we really need to, we can commit a point release
| |
| 20:22 | it's not like we're going to run out of version numbers any time soon
| |
| 20:34 | gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com) | |
| 20:34 | <Phantomas> vagrantc: Here are the extracted commit messages from bzr log since 0.5.6 http://pastebin.com/r6Mx90hD
| |
| 20:35 | in case you don't already have them
| |
| 20:35 | <vagrantc> Phantomas: i just pull them from bzr
| |
| 20:36 | <Phantomas> yep, that's what i did too :)
| |
| 20:36 | just took off the useless launchpad automatic translation ones
| |
| 20:39 | <vagrantc> sure
| |
| 20:39 | i'll try to summarize those for debian/changelog
| |
| 20:43 | <Phantomas> The only feature is the zooming bar, and support for logout/shutdown/reboot in Mate
| |
| 20:43 | the rest are bug fixes
| |
| 20:45 | <vagrantc> sure.
| |
| 20:52 | i forgot how cool epoptes was... haven't actually used it much, even though i think it would be useful at freegeek
| |
| 20:54 | Phantomas, alkisg : how important is it that epoptes-client and epoptes match between a server and client?
| |
| 20:54 | <alkisg> vagrantc: we have a hardcoded, internal, version checking
| |
| 20:55 | <vagrantc> alkisg: so it just refuses to work with version mismatch?
| |
| 20:55 | <Phantomas> it won't include the non-matching client
| |
| 20:55 | <alkisg> Yup, the epoptes UI notifies the user that he should update some of his clients
| |
| 20:55 | It pops a window once, not for each and every client
| |
| 20:57 | <markit> alkisg: will you update the "roadmap" on the site? i.e. I'm looking for the "troubleshooting and test lan perfomance" improvements
| |
| 20:58 | <alkisg> Phantomas has a prototype for that, I think he's programmed it for the next version
| |
| 20:58 | <vagrantc> alkisg: rather than a pop-up, maybe displaying the clients with old versions with a different icon in an "outdated epoptes versions" section?
| |
| 20:59 | alkisg: it seems like a pop-up could easily get forgotten
| |
| 20:59 | <alkisg> vagrantc: epoptes tells the older clients to abort the connection, as it probably cannot handle them
| |
| 20:59 | The pop up, pops up every time the epoptes UI is restarted
| |
| 20:59 | Just once for all clients, but every time it runs the epoptes UI
| |
| 21:06 | <vagrantc> Phantomas: did you push a new tag?
| |
| 21:06 | i'm getting a tag conflict
| |
| 21:07 | <Phantomas> vagrantc: Yea, i mistakenly tagged the previous revision, and moved the tag..
| |
| 21:08 | <alkisg> bzr push --overwrite ftw!
| |
| 21:09 | * Phantomas runs | |
| 21:10 | <vagrantc> overwriting history is evil. :P
| |
| 21:12 | <Phantomas> I don't think I could remove the tag from 412 without overwriting :-\
| |
| 21:12 | <vagrantc> alkisg: Support xtightvncviewer as an alternative to xvnc4viewer, but that's not reflected in the depends
| |
| 21:12 | <alkisg> vagrantc: if one pushes --overwrite, and the other person uncommits, he can then pull the changes without overwriting history
| |
| 21:13 | We support xtightvncviewer if it's installed, but we don't suggest its use
| |
| 21:13 | <vagrantc> which i guess is covered by ... | vnc-viewer
| |
| 21:14 | <alkisg> Yup, we support "any" vncviewer that has a compatible command line, if people install it and (for the unknown ones) declare it in the epoptes configuration
| |
| 21:32 | mgariepy has left IRC (mgariepy!mgariepy@ubuntu/member/mgariepy, Ping timeout: 264 seconds) | |
| 21:32 | <vagrantc> alkisg: it seems like LSB headers should be used to fix http://bazaar.launchpad.net/~epoptes/epoptes/trunk/revision/340
| |
| 21:32 | https://bugs.launchpad.net/epoptes/+bug/1054665
| |
| 21:32 | at least on debian
| |
| 21:32 | the start numbers are essentially ignored
| |
| 21:33 | and that also affects both initscripts, if it affects anything at all...
| |
| 21:34 | * alkisg hasn't ever seen a likewise installation, he wouldn't know what headers to put there... | |
| 21:35 | gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Remote host closed the connection) | |
| 21:35 | * vagrantc neither | |
| 21:35 | <alkisg> It's very strange that we'd have to "require-start" things that we're not using at all... we can reasonably assume that the epoptes group exists, if it doesn't, it's a bug in the other packages, not in epoptes...
| |
| 21:35 | <vagrantc> there's also Should-Start annd whatnot
| |
| 21:36 | there might even be a generic service name or something
| |
| 21:36 | but i'd say let's put that off for another day
| |
| 21:36 | <alkisg> Yeah I don't like having to google about the likewise service name :P
| |
| 21:37 | I'm not even sure if system groups should be in such user DBs anyway
| |
| 21:38 | <vagrantc> /w 4
| |
| 21:38 | <alkisg> Ah, they changed the socket group to SOCKET_GROUP=net_remoteview
| |
| 21:39 | <vagrantc> alkisg: i'm almost tempted to back out that change and get followup from the bug reporter.
| |
| 21:41 | * vagrantc will be back in a few hours | |
| 21:42 | <vagrantc> alkisg, Phantomas: would you be opposed to leaving that fix out?
| |
| 21:42 | <alkisg> vagrantc: I was reading the 2 bug reports about it,
| |
| 21:42 | one is for samba, and the other for likewise,
| |
| 21:43 | ...do you think that it will have no effect on debian?
| |
| 21:43 | <vagrantc> alkisg: i'm 85% certain it will do nothing.
| |
| 21:43 | <alkisg> Will it make things worse somehow? If not, why not leave it there for ubuntu users? The PPA is the same...
| |
| 21:43 | <vagrantc> so it definitely changes things on ubuntu?
| |
| 21:43 | <alkisg> Yes, it did solve both bug reports
| |
| 21:45 | mgariepy has joined IRC (mgariepy!mgariepy@ubuntu/member/mgariepy) | |
| 21:45 | * alkisg is reading https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot ... | |
| 21:50 | <vagrantc> alkisg: keep me posted. i guess i can upload as-is if i don't hear better.
| |
| 21:50 | gdi2k__ has joined IRC (gdi2k__!~gdi2k@120.28.253.229) | |
| 21:50 | <alkisg> vagrantc: I don't mind if you exclude it though
| |
| 21:51 | I'm reading some related bug reports from debian
| |
| 21:51 | What I want to find out is, if the numbering is still applied with inserv, between services with similar dependencies...
| |
| 21:51 | So if I have 20-a and 80-b with no dependencies at all, I would expect 20 to start earlier
| |
| 21:52 | That's what ubuntu is doing afaik, it first starts all upstart jobs with dependencies and everything, and then it uses the numbering
| |
| 21:52 | ...for the rest of the non-upstart services
| |
| 21:54 | gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com) | |
| 21:54 | gdi2k_ has left IRC (gdi2k_!~gdi2k@120.28.232.172, Ping timeout: 245 seconds) | |
| 21:57 | gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Remote host closed the connection) | |
| 21:58 | <alkisg> Samba provides "smbd", no generic name like "user_lookups" as mentioned in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478674 ...
| |
| 21:59 | So we'd have to list all name services there for a dependency-based booting, if numbering doesn't cut it
| |
| 22:00 | And we couldn't ignore it on debian + fix it with an upstart job in ubuntu, because we'd need to list all the name services there too
| |
| 22:00 | Well, if you decide not to include it, we can remove it from the upstream debian/ dir, and tell the affected users to either file their bug reports in the other packages, or to call update-rc.d manually
| |
| 22:07 | gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com) | |
| 22:23 | markit has left IRC (markit!~marco@88-149-177-66.v4.ngi.it, ) | |
| 22:25 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 22:26 | gdi2k__ has left IRC (gdi2k__!~gdi2k@120.28.253.229, Quit: Leaving) | |
| 22:28 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 23:07 | gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Remote host closed the connection) | |
| 23:38 | gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com) | |
| 23:45 | gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Ping timeout: 248 seconds) | |