IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 24 November 2013   (all times are UTC)

00:08Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.)
00:09christophe_y2k has left IRC (christophe_y2k!~christoph@man06-3-78-237-22-85.fbx.proxad.net, Quit: Leaving.)
00:24Parker955_Away is now known as Parker955
00:56alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 245 seconds)
01:18gbit 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:30clepto has joined IRC (clepto!~chadlepto@unaffiliated/chadlepto)
02:33ChadLepto has left IRC (ChadLepto!~chadlepto@unaffiliated/chadlepto, Ping timeout: 246 seconds)
02:36clepto is now known as ChadLepto
03:04freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Read error: Operation timed out)
03:21freedomrun 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:30alkisg 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:48alexqwesa 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:51alexqwesa 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:48vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
08:53gdi2k_ has left IRC (gdi2k_!~gdi2k@120.28.232.172, Ping timeout: 272 seconds)
09:00bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Read error: Connection reset by peer)
09:04bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
09:06gdi2k_ has joined IRC (gdi2k_!~gdi2k@64.69.46.232)
10:15stevecook172001 has joined IRC (stevecook172001!5e032a87@gateway/web/freenode/ip.94.3.42.135)
10:18stevecook172001 has left IRC (stevecook172001!5e032a87@gateway/web/freenode/ip.94.3.42.135, Client Quit)
10:19stevecook172001 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:24bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
10:24freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
10:25alexqwesa 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:47stevecook172001 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:37gdi2k_ has left IRC (gdi2k_!~gdi2k@64.69.46.232, Ping timeout: 246 seconds)
11:56gdi2k_ has joined IRC (gdi2k_!~gdi2k@120.28.232.172)
12:14christophe_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:15hs366 has joined IRC (hs366!~hs366@94.254.45.76)
13:28xet7 has left IRC (xet7!~xet7@a88-112-147-81.elisa-laajakaista.fi, Quit: Lähdössä)
13:33Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
14:44Fenuks has joined IRC (Fenuks!~Fenuks@212.164.166.235)
15:04gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
15:07alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
15:33ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 246 seconds)
15:45hs366 has left IRC (hs366!~hs366@94.254.45.76, Quit: Leaving)
16:00ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
16:33gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Remote host closed the connection)
16:37gbaman_ has joined IRC (gbaman_!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
16:38Fenuks has left IRC (Fenuks!~Fenuks@212.164.166.235, Ping timeout: 272 seconds)
16:54vagrantc 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:05alexqwesa 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:14gbaman_ has left IRC (gbaman_!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Remote host closed the connection)
17:17alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
17:24lmds_ 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:24gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
18:43christophe_y2k has left IRC (christophe_y2k!~christoph@man06-3-78-237-22-85.fbx.proxad.net, Quit: Leaving.)
18:43alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
18:43* alkisg waves
18:45* vagrantc waves
18:46markit 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:13gbaman 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:13gbaman 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:59bobby_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:19gbaman 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:34gbaman 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:32mgariepy 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:35gbaman 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:45mgariepy 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:50gdi2k__ 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:54gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
21:54gdi2k_ has left IRC (gdi2k_!~gdi2k@120.28.232.172, Ping timeout: 245 seconds)
21:57gbaman 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:07gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
22:23markit has left IRC (markit!~marco@88-149-177-66.v4.ngi.it, )
22:25alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
22:26gdi2k__ has left IRC (gdi2k__!~gdi2k@120.28.253.229, Quit: Leaving)
22:28Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
23:07gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Remote host closed the connection)
23:38gbaman has joined IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com)
23:45gbaman has left IRC (gbaman!~gbaman@host81-130-48-226.in-addr.btopenworld.com, Ping timeout: 248 seconds)