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


Channel log from 1 January 2014   (all times are UTC)

00:00
<vagrantc>
so, i should clean up the XS80-x-modes mess i just committed
00:01
and then upload?
00:01
oh, i wanted to fix resolvconf handling
00:01
<alkisg>
Sounds good to me!
00:01
<vagrantc>
alkisg: at least in debian, the resolvconf init script wipes out all our configs generated from init-ltsp.d
00:02
<alkisg>
Ouch
00:02
So we should put it in RM_SYSTEM_SERVICES?
00:02
<vagrantc>
er, rather, it wipes out resolvconf stuff generated in 10-resolv-conf
00:03
and it's been doing that since wheezy at least
00:03
<alkisg>
vagrantc: maybe we need to put our configuration in /etc then instead of /run ?
00:04
<vagrantc>
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701647
00:04* alkisg doesn't know exactly how resolvconf does its things...
00:04
<vagrantc>
yeah, i don't either
00:04
<alkisg>
Maybe when it starts, it deletes everything under /run, but it should always respect /etc/resolvconf...
00:06
<vagrantc>
maybe we drop an /etc/resolvconf/update.d script
00:06
or in /etc/resolvconf/resolv.conf.d/
00:08vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 260 seconds)
00:14stgraber_ is now known as stgraber
00:15* vagrantc waves to stgraber
00:15* stgraber waves back to vagrantc
00:15
<stgraber>
and now time to head to bed (temporarily in Europe, so 1am here already)
00:16
<vagrantc>
welll, apparently writing to /etc/resolvconf/resolv.conf.d/base works
00:17
dunno if that's bad for other reasons
00:17
<alkisg>
And resolvconf then puts it in /run... sounds OK
00:17
<vagrantc>
i think i'm going to commit that.
00:17
unless ubuntu behaves differently?
00:19
<alkisg>
I don't think so
00:19
The manpage mentions "base", and it exists, it's an empty file
00:26
Time for bed here too... happy last 2013 coding and a happy new year :)
00:26alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
00:30gbaman_ has joined IRC (gbaman_!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
00:33gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 245 seconds)
00:52gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113)
01:35lee_ is now known as lee
02:19PhoenixSTF has joined IRC (PhoenixSTF!~rudi@78.29.154.124)
02:21PhoenixSTF has left IRC (PhoenixSTF!~rudi@78.29.154.124, Client Quit)
02:22gbaman_ has left IRC (gbaman_!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
02:35gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, Ping timeout: 272 seconds)
03:12gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
03:14gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Read error: Connection reset by peer)
03:14gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
03:23gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 260 seconds)
04:19gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
04:23gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds)
05:10lnsand has joined IRC (lnsand!~AndChat70@173-16-199-235.client.mchsi.com)
05:18lnsand has left IRC (lnsand!~AndChat70@173-16-199-235.client.mchsi.com, Remote host closed the connection)
05:20gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
05:24gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds)
05:44alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
05:49
<alkisg>
Good morning
05:57
<vagrantc>
heh
05:57
happy new year ...
05:58
alkisg: well, i've rewritten that modeline support patch a bit
06:04
<alkisg>
vagrantc: pastebin?
06:05
<vagrantc>
alkisg: whole script, or diff?
06:05
<alkisg>
Better whole script
06:06
<vagrantc>
alkisg: http://paste.debian.net/73599/
06:06
i think that's the last thing i want to bother to test...
06:07
<alkisg>
Just for the fun of it, env | sed | sort is faster of env | sort | sed
06:08
printf "\"$mode\" " => better always use "%s" in printf
06:09
<vagrantc>
alkisg: urg. removed some of the %s stuff based a previous comment of yours ... but maybe i misunderstood
06:09
alkisg: i tried doing it with only one env loop, but i couldn't get the variables back out again...
06:10
<alkisg>
Yeah I wasn't talking about %s then, I was talking about printf not being needed to read the variables
06:10
<vagrantc>
while seems to make them local in scope
06:10
<alkisg>
That's when the EOF is needed
06:10
If you want the variables value to be remembered, then don't use a subshell (| while), but <<EOF
06:11
read -r mode modeline <<EOF
06:11
$s
06:11
EOF
06:13
<vagrantc>
don't understand how to put the output from "env | sort | sed" to that
06:14
alkisg: i used "env | sed | sort" first, but it stripped out the variable names and only sorted based on the values
06:14
<alkisg>
Ah you're right my bad sorry
06:14
read <<EOF
06:14
$(command)
06:14
EOF
06:14
<vagrantc>
while read -r mode modeline <<EOF
06:15
$(command)
06:15
EOF
06:15
; do ...
06:15
?
06:16
admittedly, i've been fighting minutiae all day, maybe i should just push what i've tested
06:16gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113)
06:17
<alkisg>
Sure, I don't think such small implementation details matter
06:18
while read -r mode modeline ; do
06:18
mode=xx etc
06:18
done <<EOF
06:18
$(env | sort | sed -n '/^X_MODE_[0-9]=/s///p')
06:18
EOF
06:18
Also, the "eval" part isn't needed, you can just define the function
06:20
<vagrantc>
then i could just do a single while loop ... that seems better.
06:20gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
06:23
<alkisg>
vagrantc: here's a new trick I just found out:
06:23
exec 5<&0
06:23
exec <<EOF
06:23
whoami
06:23
sleep 1
06:23
exec 0<&5
06:23
EOF
06:23* vagrantc is terrified
06:23
<alkisg>
That allows us to execute strings instead of using eval, thus avoiding all the weird escaping that eval needs
06:24
So we can have e.g.:
06:24
display_hacks="$display_hacks
06:24
some command | instead of a function"
06:25gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 240 seconds)
06:25* alkisg was looking for something similar since a long time... that would be useful in epoptes too
06:39
<vagrantc>
hrm.
06:40
<alkisg>
Meh it only works with interactive shells, so it's only good for epoptes
07:04gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, Ping timeout: 272 seconds)
07:06
<vagrantc>
almost got this modeline support cleaned up
07:08
or maybe sent it into an infinite loop
07:08* alkisg feels responsible for vagrantc taking so much time with it and thinks he shouldn't have provided so much feedback... it's just wasn't that significant, just silly coding ideas...
07:08
<alkisg>
pastebin?
07:09
<vagrantc>
the code is much better...
07:09
shorter, easier to read...
07:14
alkisg: http://paste.debian.net/73600
07:16
<alkisg>
Yup, you're right, it's easier to read
07:16
if [ -n "$modes" ]
07:17
And 4 spaces indentation :P
07:17
<vagrantc>
alkisg: with $modes it doesn't matter so much if there's a space
07:17
<alkisg>
I mean [] instead of test
07:17
<vagrantc>
the only not-so-easy-to-read is the EOF bits
07:18
<alkisg>
We don't use "if test" so much in the code... either "if []" or plain "test"
07:18
<vagrantc>
alkisg: test -n is ok for short one-liners
07:18
<alkisg>
Sure, but we don't use "if test", just plain "test" there
07:18
<vagrantc>
ah, didn't see that.
07:18
nice catch
07:21* alkisg will stop proposing silly tiny improvements when vagrantc tells him to...
07:21
<alkisg>
Smaller sed: sed -n 's/^X_MODE_[0-9]=//p'
07:21gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
07:22
<vagrantc>
stole that from the HOSTS_* code
07:23
if i'm not careful, i'll upload at precisely midnight (in my timezone)
07:24
<alkisg>
Finally, /me prefers "unset var" instead of "var=", because at the later case "var" shows up in `set`
07:25gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 252 seconds)
07:30* vagrantc conceedss
07:30
<vagrantc>
alkisg: did you re-enable translations?
07:31
<alkisg>
vagrantc: no, I thought you did!
07:31
<vagrantc>
nope
07:31
<alkisg>
Ah
07:31
wait, that's ltsp-trunk, we never disabled them there
07:31
<vagrantc>
heh
07:31
<alkisg>
Only ldm has issues because of intltool
07:31
(so for ltsp6 we'll be fine :P)
07:32
<vagrantc>
alkisg: it was a pretty pointless translation commit
07:32
just updated line numbers in files...
07:33
or, even worse, used the same line numbers, but rearranged the order of the line numbers!
07:33
er, not line numbers, but files
07:33
in comments.
07:34
there was some actual content in at least one of the files, at least.
07:37
<alkisg>
Hrm. And it didn't update ltsp.pot, so it might just do that again...
07:38
<vagrantc>
alkisg: grep -q "root=/dev/nbd." /proc/cmdline || exit 0
07:38
root=/dev/nbd. ???
07:38
<alkisg>
. == any number
07:38
Or better yet, [0-9]...
07:38
<vagrantc>
well, anything
07:38* vagrantc nods
07:38
<alkisg>
It's a bit confusing though, so yeah [0-9] would be better
07:40* alkisg will commit that in a couple of minutes
07:41
<alkisg>
Meh I have /dev/nbd0 hardcoded for root, I should have used 0 there instead
07:41
<vagrantc>
we shouldn't have 0 hard-coded for root either...
07:42
<alkisg>
Sure, so OK i'll leave that for when it's properly rewritten
07:42
Although that script shouldn't even exist, but anyways...
07:42* vagrantc nods
07:43
<alkisg>
!learn alkisg-todo as ltsp-config aoe (for swap too)
07:43
<ltsp>
The operation succeeded.
07:43
<vagrantc>
swap is going to be harder, isn't it? it's not like multiple clients can share that...
07:44
<alkisg>
Same as in nbd
07:44
The real trouble is managing the numbers
07:44* vagrantc nods
07:45
<vagrantc>
alkisg: so, are you going to commit that nbd-disconnect fix, or should i, or... ?
07:45
<alkisg>
The good thing is that aoe knows the client's mac address
07:45
vagrantc: nah just leave it as it is now
07:45
<vagrantc>
ok.
07:45
<alkisg>
Unless you want me to fix it for any root, not just 0
07:46
<vagrantc>
no, that's too much work for short order, although i think it's worth catching the nbd-disconnect now
07:46
would be easy to forget later
07:46
<alkisg>
It does work now
07:46
It just matches any character instead of any digit, nothing significant
07:47
<vagrantc>
sure
07:47
<alkisg>
Fortunately I've discovered the kvm's "-no-shutdown" parameter, that allowed me to see the output of those last commands
07:47
<vagrantc>
nice
07:47
<alkisg>
...and, "console output" in the ltsp-client-core upstart job
07:48
(otherwise echo >&2 shows nothing)
07:48* vagrantc commits it anyways :P
07:48
<alkisg>
:)
07:48
vagrantc: ok at least put /dev/nbd0 there, not [0-9]
07:48
I.e. "we only care about roots that we know about"
07:49
Wait wait
07:49
vagrantc: /dev/nbd[1-9]) => put that 0-9 too
07:49
vagrantc: leave it to me
07:49
We can easily do the "any root" change
07:50
<vagrantc>
forget it, time to release :)
07:50
<alkisg>
OK
07:50
<vagrantc>
eesh, haven't even started on the changelog.
07:50
<alkisg>
Ah you want to do it before 2014 :D
07:51
<vagrantc>
yup
07:53
<alkisg>
vagrantc: http://pastie.org/8591167
07:54
Or http://pastie.org/8591168 in .diff form
07:57
Err for param in $(cat /proc/cmdline) sorry
07:57
<vagrantc>
too late, already tagged and pushed 5.5.0
07:58
alkisg: is nbd swap handled by something else?
07:58
<alkisg>
Nice!!!
07:59
<vagrantc>
upload will likely be late
07:59
<alkisg>
(updated) http://pastie.org/8591174
07:59
I think there's a service that just runs swapoff -a on shutdown
08:03
initscripts: /etc/init.d/umountfs
08:04
Happy new year vagrant :)
08:05* vagrantc thanks alkisg and continues to frantically write a changelog
08:15* vagrantc wonders if the NBD swap thresholds are a bit too high
08:20
<alkisg>
vagrantc: I've had crashes with 1 gb fat clients
08:20
<vagrantc>
512MB ram + 512MB swap for a thin client?
08:21
<alkisg>
Fat clients with 1 GB RAM didn't get NBD swap previously due to low thresholds,
08:21
and when I changed the thresholds and they got NBD_SWAP, then the crashes stopped
08:22
Assuming firefox/libreoffice might need 500 mb ram on a thin client,
08:22
and the rest of the OS might need ~200 MB RAM...
08:22gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
08:22
<vagrantc>
might be right.
08:22
<alkisg>
That's 700 mb without using localapps
08:22
<vagrantc>
it's just hard to even think of that as a thin client
08:23
<alkisg>
It's silly that xorg doesn't take `free` into account when apps tell it to use local pixmaps
08:23
Firefox wants 300 mb in local pixmaps? and I only have 2 mb free? tell firefox "no I can't do that"
08:27gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 272 seconds)
08:33
<vagrantc>
no doubt
08:34
X.org needs to learn how to say no.
08:34
<alkisg>
Actually I think that fixing things like those are even more important than ditching ldm... at some point we need to put some resources into making some upstream projects respect remote desktop solutions more
08:34
<vagrantc>
of course, they'll just move on to wayland or mir or who knows what
08:34* vagrantc nods
08:35
<vagrantc>
sorry, we don't support systems without 2TB of video ram anymore...
08:42* alkisg would like it if we branched ltsp6 now, right after tagging ltsp 5.5
08:43
<alkisg>
...actually just being able to say "ltsp 5.5 is the last version that runs with ldm and isn't developed anymore, it's only getting some backports from ltsp6"
08:47* alkisg publishes the latest versions of ldm, ltspfs and ltsp in the greek schools *proposed* ppa, for *precise* :)
08:52
<alkisg>
vagrantc: schools here have the versions shipped around wheezy, do you think that if one upgrades the server only (and not the chroot) to the latest ldm/ltspfs/ltsp versions, will have issues?
08:52vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi)
08:56
<alkisg>
http://packages.qa.debian.org/l/ltsp.html
08:56
<vagrantc>
don't think there are any incompatibilities
08:57
<alkisg>
I think http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701916 can be closed now, it's committed/released, even if it never were actually reproduced in debian
08:58
<vagrantc>
ok.
09:00
<alkisg>
...so, tomorrow we start ltsp6? :D
09:00
<vagrantc>
seems like it
09:02bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 240 seconds)
09:03bennabiy has joined IRC (bennabiy!~Thunderbi@24.181.55.79)
09:23gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
09:27gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 245 seconds)
09:33* alkisg wonders how easy would it be to backport ltsp5.5 for squeeze/10.04 for use with an aoe root, for schools that want gnome 2, have 64mb ram clients etc
09:35* vagrantc cringes
09:36
<vagrantc>
wheezy with one of the external mate repositories is probably a more sane bet...
09:37
<alkisg>
Why oh why didn't those mate folks invest on gnome-flashback instead... :(
09:40* vagrantc can't keep track of all the variants
09:42
<alkisg>
I think it's possible to have multiple vlade instances that serve different swap files for the same slot, if one defines the mac address that each vblade instance should reply to
09:43
...but the best approach there would be an upstream patch to vblade
09:45
<vagrantc>
right
09:46
well, uploaded ltsp 5.5.0-1 to debian unstable
09:46
<alkisg>
:)
09:47
<vagrantc>
my first upload of the year.
09:48
<alkisg>
vblade is using stdlib instead of glib, I love it
09:49* vagrantc doesn't know which alkisg prefers
09:49
<alkisg>
So... plans for 2014: compressed btrfs with embedded swap partition over aoe with server-side cow support
09:50
<vagrantc>
it's about time!
09:50
<alkisg>
glib is gnome specific and I don't want to invest there as I think qt should be preferred for UI apps and plain libc for non ui apps
09:51
Or at least that's my initial understanding, when I'm ready to write .c code I'll check again :)
09:54
<vmlintu>
sounds interesting.. so nbd is going out?
09:55
<vagrantc>
alkisg: are there other AoE implementations besides vblade?
09:55
alkisg: we could also boot with iPXE and just boot directly from the image
09:55
could also do that with NFS
09:56
<alkisg>
vmlintu: of course not, but if aoe doesn't suffer from ip issues, persistence issues etc etc, why not default to it at some point in the future?
09:57
vagrantc: no idea, but it seems very easy to fork it
09:58
(11:55:47 πμ) vagrantc: alkisg: we could also boot with iPXE and just boot directly from the image => you mean if the cow is server-side?
09:58
How would we do that with NFS?
09:58
<vagrantc>
alkisg: looking at how much extra space nbi.img files take, i'm really thinking we should drop support by default
09:58
<alkisg>
+1000
09:58
They just don't work
09:59
Lets start ltsp6 tomorrow and drop a whole lot of things :D
09:59
<vmlintu>
alkisg: nbd certainly has had its share of problems.. and it would be nice to have fail-over for the image server..
09:59
<alkisg>
nbi, nbd-proxy etc, and anyone that wants them can send working patches
09:59
<vagrantc>
i guess just removing the package dependency will at least cause them not to generate
09:59
<alkisg>
Ah true... wish you could do that for ltsp 5
09:59
5.5
09:59
<vagrantc>
alkisg: but stgraber says nbd-proxy works! :)
10:00
<alkisg>
Oh well
10:00
<vagrantc>
alkisg: i think the code supports the wrappers not being present
10:00
alkisg: for nbi.img
10:00
<alkisg>
I'd say that anyone who wants a proxy, should send a patch for xnbd-proxy instead
10:01
<vagrantc>
or split nbd-proxy into it's own project
10:01
at the very least
10:01
<alkisg>
Sure, but it'll be harder, just using xnbd sounds much easier (and more stable, and extra benefits for local caching, etc etc)
10:01
I'd love to have support for xnbd in ltsp-trunk, but I don't like nbd-proxy
10:02
Also, the reason it was invented was persistence, I think there were several upstream nbd-client commits for persistence... maybe it doesn't even have a reason to exist anymore
10:03
I would like to have at least someone that uses it and sends feedback on why it's still needed... anyways
10:03
<vmlintu>
Have you thought about using the same image to netboot ltsp servers?
10:04
<alkisg>
I think ltsp-pnp made that possible, no?
10:04
Same image not only for ltsp-servers but for ltsp-clients as well :D
10:07
<vmlintu>
I haven't really been using ltsp-pnp, but we are now using the same image for thin and fat clients, ltsp servers and laptops
10:09
<alkisg>
ltsp-pnp was about doing stuff from init-ltsp.d
10:09
I.e. removing services, configuration files etc on boot, not statically on ltsp-build-client
10:09
<vagrantc>
one of the better innovations in recent years
10:12
<vmlintu>
yes, the init-ltsp.d approach is the key to that
10:12
I needed to do some big changes to that to init-ltsp.d parts get laptop boots without network. Would that be something that you'd want in ltsp6?
10:13
<alkisg>
vmlintu: say more about that... what changes?
10:13freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
10:13
<alkisg>
!local-boot
10:13
<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
10:13
<alkisg>
I thought that was all that's needed...
10:14
(oh well, similar, without the pxe kernels part)
10:14* vagrantc wonders where loop= is implemented
10:14
<alkisg>
in initramfs-tools
10:14
<vagrantc>
not in debian's initramfs-tools
10:14
<alkisg>
Really?!! That's ubuntu-ism?!
10:14
<vmlintu>
normally the init-ltsp.d scripts require that network is available during boot time, but when you run local grub + image on harddrive, dhclient and others fail
10:15
when booting without network, that is
10:15
<alkisg>
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468114
10:16
vmlintu: sure, could you file a bug report and send patches there?
10:17
It's actually a good thing that debian doesn't support loop=, it'll be easier to convince maks to support root=<multiple,roots,to,be,executed,sequentially> :D
10:18
Or at least mount=x,y,z to be executed sequentially before root=
10:18
Ah. mount=x mount=y mount=z
10:19
<vmlintu>
alkisg: the "bad" thing about that is that it kind of requires local storage to store some information like hostname and lts.conf etc..
10:19
<alkisg>
vmlintu: I don't think that's bad...
10:20
They could go in kernel parameters, or inside the squashfs image, or even in C:\ltsp\lts.conf :D
10:20
<vmlintu>
Right now I'm using a specially named lvm partition, but the kernel parameter sounds better
10:21
<vagrantc>
alkisg: have fun with ltsp6! :)
10:21
<alkisg>
Ooooh /me checks trunk...
10:22
<vagrantc>
alkisg: there are probably a handful of smallish fixes that might make sense to push first
10:22
<alkisg>
Ah, I thought you created the ltsp5 branch
10:22
Sure, let's do that
10:22
We can start ltsp6 when we're out of ideas that apply to ltsp5
10:22
<vagrantc>
heh
10:23gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
10:23
<vagrantc>
i'd kind of like to split up update-kernels and ltsp-client-core initscript
10:24
or at least add some crude plugin support to both
10:25
<alkisg>
OK, I'll start testing ltsp5.5 on 12.04 to see if any fixes are needed
10:25
<vagrantc>
sounds good!
10:26
<vmlintu>
do you feel like using fat clients as wifi access points?
10:27vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
10:28gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 260 seconds)
10:38alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
10:38mattcen has left IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au, Ping timeout: 272 seconds)
11:19gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113)
11:24gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
11:27gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Read error: Operation timed out)
12:09mattcen has joined IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au)
12:25alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 248 seconds)
12:25gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
12:28alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
12:30gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 265 seconds)
12:45gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
12:57cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
13:05gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
13:05gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
13:24gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, Ping timeout: 260 seconds)
13:53gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113)
14:20PhoenixSTF has joined IRC (PhoenixSTF!~rudi@78.29.154.124)
14:34willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116)
14:56khildin has joined IRC (khildin!~khildin@ip-80-236-219-149.dsl.scarlet.be)
16:14Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
16:16shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-229.se.biz.rr.com, Ping timeout: 252 seconds)
16:17alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
16:21Fenuks has joined IRC (Fenuks!~Fenuks@176.51.127.69)
16:38gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
17:02gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
17:27freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Ping timeout: 240 seconds)
17:28alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
17:29vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
17:41alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
17:41freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
17:42
<alkisg>
vagrantc: I can't install ltsp-client 5.5 on 12.04: http://packages.ubuntu.com/search?keywords=fonts-dejavu-core
17:42
...recommends? :)
17:43
Also, please remove zram-config, it's very bad for ltsp clients
17:43alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Remote host closed the connection)
17:43
<alkisg>
(assuming that we do have nbd swap in ltsp... which is way better)
17:45
<vagrantc>
alkisg: got patches in one of your packaging branches?
17:45
<alkisg>
Meh the package name has changed, it was: ttf-dejavu-core
17:45
So, it can just be one | the other
17:46
<vagrantc>
put the newest named one first
17:46
<alkisg>
No I don't, do you want me to?
17:46
OK
17:46
<vagrantc>
alkisg: it's easier to merge exactly what you're asking for if you do :)
17:46
<alkisg>
Should I put zram-config in suggests?
17:46
<vagrantc>
dunno.
17:47
<alkisg>
It would help installations that for some reason want to avoid nbd swap
17:47
<vagrantc>
alkisg: do these packages work fine in 14.04 ?
17:47
<alkisg>
The zram-config package?
17:47
<vagrantc>
no, the others
17:47
<alkisg>
The dejavu ones? They're just fonts, they renamed a package... yeah I do see dejavu fonts...
17:48alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
17:51
<alkisg>
vagrantc: can we lower the fonts to recommends?
17:51
Ubuntu now defaults to installing recommends in ltsp chroots, so it should be fine
17:52
And, I don't see why I must absolutely have thai fonts in my chroot...
17:52
<vagrantc>
lower all the fonts to recommends ... that makes some sense
17:53
<alkisg>
dejavu wasn't the only package that got renamed, so I'll check all packages now
18:11bennabiy has left IRC (bennabiy!~Thunderbi@24.181.55.79, Ping timeout: 240 seconds)
18:11bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
18:31
<alkisg>
vagrantc: http://bazaar.launchpad.net/~ts.sch.gr/sch-scripts/ltsp-debian-packaging/revision/1189
18:37
<stgraber>
alkisg: we can't do a direct sync from unstable but I'll try to do a merge over the next couple of days
18:37
alkisg: I'll be travelling tomorrow so I'll grab the source packages on my laptop and see if I have some time during my flight for that
18:38
<alkisg>
stgraber: thanks, in the meantime I've built it with a recipe on launchpad and I'll be testing that on 14.04 and also 12.04
18:38
Btw it would be nice to have it autosync from debian, i.e. to completely eliminate the delta...
18:39
(not from unstable of course...)
18:39
stgraber: please also see the link I just posted above ^ where I lower the fonts to recommends, and zram to suggests
18:42
<stgraber>
alkisg: I'll take a look. We're not very far from being syncable with Debian though some bits are going to be hard to handle without the occasional manual merge.
18:42* alkisg has been using the debian packaging for the last 2 years in ubuntu
18:42
<stgraber>
assuming vagrantc applied some of the patches I sent him last time I did the merge, the delta should be pretty small nowadays (some d-i changes and dhcpd)
18:43
<alkisg>
stgraber: if you want, cc me when you have the delta ready, I think it's worth the trouble to get it completely synced
18:43
I.e. to find ways to ship different dhcpd packages or whatever else is needed
18:46
<vagrantc>
depends how ugly it is...
18:46
i mean, we can do all manner of hacks in debian/rules conditionally based on Vendor, but...
18:46
i did merge most of the ubuntu changes, but i forget what all was leftover
18:46
<alkisg>
vagrantc: just simple file overlaying
18:47
Same as we currently do for init-ltsp.d
18:47
<vagrantc>
we'd probably need to use dh_exec to do that sanely.
18:48
<alkisg>
I think stgraber wants to keep the old 192.168.0.1 and .254 server IPs instead of the new 192.168.67.1 one
18:50
<vagrantc>
could probably handle that with sed...
18:50
at build-time
18:50
<alkisg>
btw having `ltsp-config dnsmasq` always create the 192.168.67.1 range makes it pretty simple to tell the users "if you have a 2 nic setup, just declare that static IP, done"
18:50
sch-scripts even do NAT-ting there automatically for fat clients
18:51GEEGEEGEE has left IRC (GEEGEEGEE!~Charles@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net, Ping timeout: 272 seconds)
18:56
<vagrantc>
alkisg: sorry for misspelling your name!
18:57
<alkisg>
No worries I don't like my surname anyways :)
19:00
<stgraber>
alkisg: yeah, I need to figure out an upgrade path...
19:01
<alkisg>
stgraber: I think ltsp6 will be so different that we should declare it needs manual upgrading from ltsp5
19:01
So then it will be a good time to break the upgrade path :)
19:01
<stgraber>
alkisg: sounds reasonable :)
19:10danishman has joined IRC (danishman!~kvirc@62-243-156-218-static.dk.customer.tdc.net)
19:15
<vagrantc>
alkisg: needed to +Suggests: ${vendor:Suggests}
19:15
<alkisg>
Sorry, didn't see that
19:15Fenuks has left IRC (Fenuks!~Fenuks@176.51.127.69, Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/)
19:16
<vagrantc>
no worries
19:21
alkisg: i reworked your patch slightly and committed it.
19:25vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
19:32GEEGEEGEE has joined IRC (GEEGEEGEE!~Charles@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net)
19:51SmallR2003 has joined IRC (SmallR2003!~Robert@c-98-253-173-240.hsd1.il.comcast.net)
19:51rhptyosy has joined IRC (rhptyosy!iamparadox@c-71-206-130-134.hsd1.va.comcast.net)
19:53shawnp0w1rs has joined IRC (shawnp0w1rs!~spowers@151.236.4.166)
19:58|Paradox| has left IRC (|Paradox|!iamparadox@c-71-206-130-134.hsd1.va.comcast.net, *.net *.split)
19:58SmallR2002 has left IRC (SmallR2002!~Robert@c-98-253-173-240.hsd1.il.comcast.net, *.net *.split)
19:58shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, *.net *.split)
20:03book` has left IRC (book`!~book`@li125-242.members.linode.com, Ping timeout: 248 seconds)
20:03monteslu has left IRC (monteslu!~monteslu@ip68-109-175-67.ph.ph.cox.net, Ping timeout: 248 seconds)
20:04elias_a has left IRC (elias_a!elias@hilla.kapsi.fi, Ping timeout: 248 seconds)
20:07ltsp` has joined IRC (ltsp`!bot@75.98.171.129)
20:09book` has left IRC (book`!~book`@li125-242.members.linode.com, *.net *.split)
20:09monteslu has left IRC (monteslu!~monteslu@ip68-109-175-67.ph.ph.cox.net, *.net *.split)
20:09ltsp has left IRC (ltsp!bot@ltsp.org, *.net *.split)
20:09elias_a has left IRC (elias_a!elias@hilla.kapsi.fi, *.net *.split)
20:11elias_a_ has left IRC (elias_a_!elias@hilla.kapsi.fi, Ping timeout: 240 seconds)
20:12elias_a has joined IRC (elias_a!elias@hilla.kapsi.fi)
20:14monteslu has joined IRC (monteslu!~monteslu@ip68-109-175-67.ph.ph.cox.net)
20:29Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 240 seconds)
20:45book`_ has left IRC (book`_!~book`@li125-242.members.linode.com, Ping timeout: 252 seconds)
20:51book` has joined IRC (book`!~book`@li125-242.members.linode.com)
20:53danishman has left IRC (danishman!~kvirc@62-243-156-218-static.dk.customer.tdc.net, Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
21:20book` has left IRC (book`!~book`@li125-242.members.linode.com, Ping timeout: 240 seconds)
21:20book` has joined IRC (book`!~book`@li125-242.members.linode.com)
21:36khildin has left IRC (khildin!~khildin@ip-80-236-219-149.dsl.scarlet.be, Quit: I'm gone, bye bye)
21:58alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Read error: Connection reset by peer)
21:58gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
21:59alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
22:05GEEGEEGEE has left IRC (GEEGEEGEE!~Charles@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net, Ping timeout: 272 seconds)
22:10GEEGEEGEE has joined IRC (GEEGEEGEE!~Charles@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net)
22:39gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
22:43alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
22:43vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 245 seconds)
22:55PhoenixSTF has left IRC (PhoenixSTF!~rudi@78.29.154.124, Quit: Leaving)
23:39gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)