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


Channel log from 3 June 2012   (all times are UTC)

00:08F-GT has joined IRC (F-GT!~phantom@ppp121-44-97-140.lns20.syd6.internode.on.net)
00:21uskerine has left IRC (uskerine!~uske@80.30.244.131, )
01:36vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
01:40Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas, Ping timeout: 248 seconds)
01:53Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
02:43andygraybeal has joined IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net)
02:47Parker955_Away is now known as Parker955
02:52Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
03:04andygraybeal has left IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net, Ping timeout: 246 seconds)
03:56sha has left IRC (sha!~sha@d151092.adsl.hansenet.de, Read error: Connection reset by peer)
04:00sha has joined IRC (sha!~sha@g231161112.adsl.alicedsl.de)
04:00andygraybeal has joined IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net)
04:10adrianorg_ has left IRC (adrianorg_!~adrianorg@189.58.224.221.dynamic.adsl.gvt.net.br, Ping timeout: 240 seconds)
04:28andygraybeal has left IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net, Ping timeout: 246 seconds)
05:21Parker955 is now known as Parker955_Away
05:43Parker955_Away is now known as Parker955
05:50Parker955 is now known as Parker955_Away
05:57alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
06:01komunista has joined IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk)
06:54bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
07:12
<Hyperbyte>
Okay. I officially hate, and will never ever use again, the dreaded, cursed, haunted thing that's called "NetworkManager"
07:14
<alkisg>
Haha
07:14
What did it do to you again?
07:14
<elias_a>
Hyperbyte: What is the problem this time?
07:21
<Hyperbyte>
In the middle of the night
07:21
Out of nowhere
07:21
It decided to give eth2 (an unused nic) the IP address of eth0
07:21
Thus routing all eth0 traffic through eth2
07:22
Small detail - this is on the network server at the radio station, where eth0 is the NIC interface connecting to all servers...
07:22
So the servers could still access eachother, but clients couldn't access server... and servers couldn't access internet
07:22
<alkisg>
Did someone click on that connection from the nm-applet? You should put the mac address in that connection to restrict it to eth0...
07:23
<Hyperbyte>
alkisg, this is Fedora.
07:23
<alkisg>
No nm-applet there?
07:23
<Hyperbyte>
This is our network server we're talking about.
07:23
All critical equipment is locked down in our broadcasting backbone room...
07:23
The network server doesn't even have a mouse and keyboard attached.
07:24
Let alone a GUI.
07:24
<alkisg>
So no nx or vnc supported?
07:24
<Hyperbyte>
There is no GUI.
07:24
<alkisg>
And how did you configure the connection with nm? From /etc/NetworkManager/system-connections, manually writing a file there?
07:25
<Hyperbyte>
Jun 2 21:16:39 buster avahi-daemon[734]: Joining mDNS multicast group on interface eth2.IPv4 with address 192.168.20.1.
07:25
That's where it went wrong.
07:26
<alkisg>
That's avahi, not network-manager
07:26
<Hyperbyte>
Wait you're right.
07:26
But why is avahi meddling in this?
07:26
<alkisg>
Is your network connection managed by network-manager?
07:27
<Hyperbyte>
Wait, this is interesting
07:27
Moment..
07:28
http://razor.middelkoop.cc/~dj/networkmanager.txt
07:28
<alkisg>
Hyperbyte: paste the output of nm-tool
07:29
<Hyperbyte>
Looks like the device behind eth2 went down for a bit (which happens, due to the nature of the device)...
07:29
And it went down with 192.168.22.1, and decided to come back with 192.168.20.1
07:29
<alkisg>
(10:22:52 πμ) alkisg: You should put the mac address in that connection to restrict it to eth0...
07:29
<Hyperbyte>
http://fpaste.org/ijtA/
07:30
<alkisg>
I.e. it's a misconfiguration of your system connections probably
07:30
<Hyperbyte>
The mac address is configured in the standard Fedora configuration files... network-manager should've adopted it.
07:30
<alkisg>
Hyperbyte: when you create a connection, you specify for which NICs it should be available
07:31
I don't know what fedora puts in its configuration files, but NM's system connections can work with multiple NICs
07:32
<Hyperbyte>
alkisg, it might have to do with Fedora's implementation of NetworkManager.
07:32
Fedora has always had custom network configuration scripts, like /etc/network/interfaces on Ubuntu
07:32
<alkisg>
Hyperbyte: here's my /etc/NetworkManager/system-connections/eth0,10.160.31.10: http://paste.ubuntu.com/1020877/
07:32
<Hyperbyte>
When Fedora moved to NetworkManager, it decided to keep the custom configuration scripts, and create a module which on-the-fly parses the scripts to NetworkManager
07:33
<alkisg>
Since I don't have a MAC entry there, if I had an eth2, and it was connected, it would use that
07:33
If I wanted to restrict it to eth0, I should have put its mac section in the nm configuration
07:33
<Hyperbyte>
Right - but Fedora doesn't have that config. So I have no idea what is actually loaded in NetworkManager.
07:34
All I know right now is that I'm gonna get rid of avahi, and then get rid of NetworkManager
07:34
<alkisg>
OK, sounds like a misconfiguration to me, and you should search for how to specify a MAC for each of your connections
07:34
<Hyperbyte>
alkisg, I am specifying that
07:35
<alkisg>
Hyperbyte: obviously not for NM
07:35
<Hyperbyte>
http://fpaste.org/8iNB/
07:35
That's my /etc/sysconfig/network-scripts/ifcfg-eth2
07:35
<alkisg>
Hyperbyte: it's possible that it's a fedora bug, but the restriction obviously doesn't reach nm
07:35
Or it's possible that you're missing some directive in that file
07:35
<Hyperbyte>
Maybe.
07:36
Hrm
07:36
There's no mac address configured for eth0
07:36
There is one for eth2, but not eth0
07:36
Maybe that's why it picks eth0
07:36
It says so in the log actually...
07:36
It says 'eth2 link up' and then Auto-activating connection 'System eth0'.
07:38
That's -nuts-
07:38
"Hrm, eth2 has just come up. You know what, rather than take the config which is specific for eth2, with the exact mac address of the device that has just come up, I'll take the config for eth0"
07:39
Somehow this doesn't change my strong dislike of NetworkManager.
07:42
Whatever.
07:42
<alkisg>
I'd blame the fedora integration, since in Ubuntu there's a mac section in the UI exactly for that
07:42
<Hyperbyte>
alkisg, no UI... made the config by hand, forgot mac for eth0
07:42
Still I don't feel it should make everything eth0 just for that... especially since it doesn't happen on boot, but if eth2 goes down and then back up, it suddenly gives it eth0 config
07:42
<alkisg>
Ah, ok, then a sysadmin error :P
07:42
<Hyperbyte>
But I don't feel like discussing it further now - problems solved, yay!
07:43
So gooooooooood morning alkisg and elias_a!
07:43
<alkisg>
Gooooood morning Hyperbyte :)
07:43
<Hyperbyte>
Why are you guys up so early on a sunday? :P
07:43
<alkisg>
Early? it's 10:43, I usually get up 4 hours before that... :D
07:44
<Hyperbyte>
What!
07:44
How many hours do you generally sleep at night, on average?
07:44
<alkisg>
5-6
07:44
<Hyperbyte>
...
07:44
Wow.
07:44
<alkisg>
Maybe 5
07:44
<Hyperbyte>
You lucky bastard... you live about 2-3 hours long than me every day.
07:44
*longer
07:45
<alkisg>
Haha and 4 hours longer than my wife, but she's going to live 20 years longer than me in return :P
07:45
Age also affects how much sleep each person needs, don't worry your days will expand as you grow older (yet mysteriously seem smaller)
07:46
<Hyperbyte>
Great peptalk.
07:46
<alkisg>
Anyway /me dives into sch-scripts again.. :(
07:47
<Hyperbyte>
Hey no sad faces!
07:47
<knipwim>
alkisg: while you're still here
07:47
https://bugs.launchpad.net/ltsp/+bug/697387
07:47
<alkisg>
Hey knipwim
07:47
<knipwim>
o yes, good morning guys :)
07:48
<Hyperbyte>
Hey Wim!
07:48
<alkisg>
knipwim: In the past I had tried remote logging successfully, but when I commented on that but I couldn't configure syslog to log in the ltsp server, dunno why...
07:49
s/but/bug/
07:50
<knipwim>
at least the SYSLOG var should go methinks
07:51
<alkisg>
Sure, the points in the bug report are valid even if I was too stupid to setup remote logging :)
07:51
if [ "$SYSLOG" != "localhost" ]; ...
07:52
Err host
07:53
Also the "touch" part isn't necessary now that we no longer support bind_mounts
07:54
And I think someone has mentioned or filed a bug about TCP vs UDP logging
07:55
<Hyperbyte>
Awwe... don't worry about a few bugs guys, LTSP is still the coolest piece of software since... well... software!
07:55
<alkisg>
Hehe
07:55
<Hyperbyte>
;-)00
07:56
<alkisg>
knipwim: and I also agree with Xavier in the bug report, since remote logging wasn't working so far anyway, and the server needs to be specially prepared to accept the logs, we should leave it to disabled by default
07:56
So, we should enable it only if SYSLOG_HOST is defined in lts.conf with e.g. SYSLOG_HOST=server
07:56
if [ -n "$SYSLOG_HOST" ]...
07:58
<knipwim>
hmm, wouldn't that cause a lot of breakage
07:58
for all systems that do have remote logging, but not explicitely defined
07:58
<alkisg>
All non ubuntu systems? See comment #3
07:59
I don't know if in other systems /etc/rsyslog.d/ltsp.conf actually overrides the defaults
07:59
In Ubuntu, it doesn't (or didn't last time I checked)
08:01
<knipwim>
Gentoo uses sysklogd
08:02
<alkisg>
And for all the other users of distros where ltsp.conf is actually in effect, it causes unnecessary network delays _unless_ they have setup remote logging in their server
08:03
I think saving that bandwidth (and possibly security issues because of the logs showing up on the network) is more important than keeping compatibility in this case
08:04
<knipwim>
also the possibility of installing ltsp client on an existing install
08:06
<alkisg>
We can just note in lts.conf manpage that "from ltsp 5.4.0 and on, SYSLOG_HOST is unset by default, and you need to set it to e.g. "server" in order to get remote logging to work. Of course you need to configure your server as well. And btw remote logging didn't work for ubuntu and possibly debian users in the past" :)
08:08uskerine has joined IRC (uskerine!~uske@80.30.244.131)
08:38
<knipwim>
and pushed
08:39
will do the lts.conf.xml as well, making use of my new xxe :)
08:39
<alkisg>
Hehe :)
08:39
Nic!
08:39
e
08:40
<uskerine>
i have setup two LTSP servers
08:40
how can i make sure there is one active and the other one backup?
08:40
should is shutdown tftp dnsmasq and nbd?
08:41
<alkisg>
Just dnsmasq
08:41
Hyperbyte: can you tell me again about the new dconf defaults/mandatory settings?
08:42
<uskerine>
this is an easy one (and a bit offtopic), how can i prevent dnsmasq starting at boot time in ubuntu ?
08:42
<alkisg>
/etc/default/dnsmasq
08:43
<uskerine>
and, as i commented out #port 0, is dnsmasq not required for regular name resolution?
08:43
<alkisg>
port 0 disables dns
08:43
If you uncomment it, you enable dns
08:43
*if you comment it, you enable dns
08:44
Normally ltsp doesn't involve dns resolution, it's up to you if you want that or not
08:44
<uskerine>
i had the 127.0.0.1 name resolution issue, vagrantc suggested to comment it out and everything worked fine
08:47
is ltsp-cluster recommended for two-server LTSP installation?
08:47
<alkisg>
So you solved your dns problem by "installing" a dns server. You could have solved it "normally" instead, i.e. from resolvconf.
08:47
<uskerine>
will it make my life more simple or more complex?
08:48* alkisg can't comment on ltsp-cluster as he never even seen it. But I believe it's for more complex installations.
08:48
<uskerine>
ok
08:48
thks
08:50
well i stop dnsmasq and resolution still works
08:50
so i will try that way (disabling dnsmasq in the backup server, it will be enabled only when the server is actually used as backup)
08:57cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Remote host closed the connection)
08:59
<alkisg>
Heeey why are we bothering writing man pages? help2man generates a man page by just running ltsp-tool --help internally!!!
09:08Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
09:11
<alkisg>
Filed https://bugs.launchpad.net/ltsp/+bug/1008053 about it
09:26rkwesk_ has joined IRC (rkwesk_!~rkwesk@adsluser1289.att.sch.gr)
09:27
<rkwesk_>
hello anyone
09:28
<Hyperbyte>
o, hi!
09:29
<rkwesk_>
hi. i have a situation with dns-nameservers in /etc/interfaces
09:29
<Hyperbyte>
!ask
09:29
<ltsp`>
Hyperbyte: ask: Don't ask to ask a question, simply ask it, and if someone knows the answer, they'll respond. Please hang around for at least 15 minutes after asking a question, as not everybody constantly monitors the channel.
09:29
<rkwesk_>
yes, ok
09:30
<alkisg>
And mention your distro/version as well
09:31
<rkwesk_>
i use ltsp with ubuntu 12.04 but with ts.sch.gr's version. I am in Greece
09:32
<Hyperbyte>
Go on... :)
09:32
<rkwesk_>
i set a static ip for server in /etc/network/interfaces including the gateway and dns-nameservers lines
09:32
<alkisg>
rkwesk_: are you trying out the ltsp-pnp method?
09:33
<rkwesk_>
sometimes this works but more often than not the resovconfig doesn't set the dns
09:34
alkis, i now am using the version you put at the end of May
09:34
<alkisg>
rkwesk_: it's recommented to use network-manager to manage your interfaces, ip, dns etc
09:34
So please revert /etc/network/interfaces back to the way it was, and create a system connection from network manager
09:34
Ubuntu introduced a "local resolver" hack and they haven't polished out some bugs yet
09:35
<rkwesk_>
a bad hack that does work 4 me is to rewrite the head file in /etc/resolvconfig
09:35
<alkisg>
But it works if you're using network manager
09:35
/etc/resolvconf is autogenerated, you shouldn't touch it
09:35
<rkwesk_>
ok i have had bad luck in past but will try nm again now
09:35
<alkisg>
For more info see here: http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/
09:36
But basically you just need to revert to network manager
09:36
<rkwesk_>
thank you
09:36
<alkisg>
You can do it with resolvconf too, it's just not recommented, it's best if all greek schools use the same settings for easier troubleshooting
09:36
You're welcome, ping me if you hit any problems with it
09:37
Remember to check [x] Allow all users to use this connection and [x] Connect automatically from network manager
09:38
<rkwesk_>
another point, if i may is it would be good if there was an iso for 12.04 using fallback by default without having so much other software baggage
09:38
<alkisg>
rkwesk_: sch-scripts will install and use gnome-fallback-session by default
09:39
So if you wait until the end of June, you'll get a much easier installation and a full guide in the ts.sch.gr wiki
09:39
<rkwesk_>
ok
09:39
<alkisg>
You can still install ltsp-pnp now, but you'll have to do some things manually
09:40
<rkwesk_>
it is better if we r all on same page
09:40
<alkisg>
Right. Those few that prefer unity will still be able to select it though, by just modifying 1 line in lts.conf.
09:41
Btw about your original problem, from the page I linked above: I use static IP configuration, where should I put my DNS configuration?
09:41
The DNS configuration for a static interface should go as “dns-nameservers”, “dns-search” and “dns-domain” entries added to the interface in /etc/network/interfaces"
09:41
<rkwesk_>
i meant in the sense that other issues like what we be visible to clients and what to hide may be affected by the software installed
09:41
<alkisg>
(...but it's still recommented to use nm)
09:42
<rkwesk_>
yes, ok i will try again with nm
09:42
<alkisg>
True, the wiki and sch-scripts will propose a default installation method. But if someone wants to divert, he's allowed to do so.
09:43
*diverge
09:43
<rkwesk_>
as i will put same install in several schools and leave less experienced sysadmins to it it would be better to follow default
09:46
<alkisg>
rkwesk_: we'll be having an installation seminar in athens at june 22th, if you want you could come to the 4th lykeio of alimos and attend it
09:46
<rkwesk_>
yes, ok i will come
09:47
<alkisg>
About 70-80 teachers will come and some will bring their servers before the seminar to have them installed and get them at the end of the seminar
09:47
<rkwesk_>
i will let hellug know
09:49
<alkisg>
rkwesk_: dide-d-ath.att.sch.gr/ubuntu.pdf - but the date was changed due to the elections, we moved it to 21th and 22th.
09:50
It requires a (free) reservation but we can make an exception for you :)
09:50
<rkwesk_>
thank you :))
09:50
<alkisg>
Other teachers can contact their councelor at the mail in the pdf
09:51
<rkwesk_>
tftp is another topic i want to mention
09:52
in order to put windows in the mix isn't there the remapping thing that dnsmasq doesn't do?
09:54
<alkisg>
What remapping?
09:54
And what windows have to do with tftp in the first place?
09:55
<rkwesk_>
i may have the term wrong. i found on internet that changing forward slash to backward slash is the issue
09:55
<alkisg>
What would you use tftp from windows for?
09:55
<rkwesk_>
if some want to serve up windows as well as linux
09:56
<alkisg>
The image isn't served with TFTP, you probably have a misconception somewhere
09:56
That's only for the kernel, and this is loaded before Windows starts, from the BIOS
09:56
<rkwesk_>
i never use windows but when i go 2 a school some want 2 use windows also
09:57
<alkisg>
If you wanted to serve windows, you'd still wouldn't be using Windows when you downloaded their "kernel"
09:57
It's the PXE stage, before Windows runs.
09:57
<rkwesk_>
ok. i'll go back and try 2 get my facts straight
09:58
<alkisg>
We're preparing 2 solutions for windows users, one based on windows 2008 server in a VM + ltsp + xfreerdp, for thin clients,
09:58
and another with a non-server windows VM + ltsp fat clients + virtualbox
09:58
But not for this September, maybe for the next one
09:59
<rkwesk_>
the discussion mentioned that tftpd-hpa will do this remapping that dnsmasq wouldn't (I think)
10:00
<alkisg>
rkwesk_: netbooted windows clients don't use tftp to access their disk
10:01
<rkwesk_>
ok i will try 2 dig deeper 2 see what was actually being discussed
10:02
i prefer dnsmasq
10:20rkwesk_ has left IRC (rkwesk_!~rkwesk@adsluser1289.att.sch.gr, Quit: Leaving)
10:28andygraybeal has joined IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net)
10:33
<knipwim>
alkisg: i like the help2man idea
10:33
<alkisg>
knipwim: I did a bit of testing and it seems pretty nice, we don't even need to add --version to our scripts, it has a command line switch that we can use while building the package
10:34
<knipwim>
can it be included in autogen.sh? which reads the release.conf?
10:34
at least, that's what i thought was the most practical
10:34
<alkisg>
Sounds like a good idea
10:34
<knipwim>
but don't know a lot about automake
10:35* alkisg neither... I leave the packaging stuff to vagrantc :)
10:35
<alkisg>
It even supports a --help-option=STRING option, and we can pass --extra-help there for ltsp-build-client
10:36
<knipwim>
i saw
10:36
<alkisg>
So other than deleting the existing man pages and modifying autogen.sh, we shouldn't need any more upstream changes
10:37
<knipwim>
perhaps adding some SEE ALSO sections to the --help outputs
10:37
or some other beautifications
10:37
<alkisg>
Copyright etc, yeah
10:49Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71)
10:53vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 246 seconds)
11:04staffencasa has joined IRC (staffencasa!~staffenca@128.193.8.220)
11:06vmlintu has joined IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi)
11:13richard has joined IRC (richard!~rkwesk@adsluser1289.att.sch.gr)
11:14richard is now known as Guest96570
11:15
<Guest96570>
hello again i am back to continue tftp discussion re remapping
11:15
<alkisg>
Hi Richard, what link are you reading?
11:16
<Guest96570>
sorry about id
11:16Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas, Ping timeout: 260 seconds)
11:16
<alkisg>
Type "/nick rkwesk"
11:16
<Guest96570>
the link was http://www.funtoo.org/wiki/PXE_network_boot_server
11:16Guest96570 is now known as rkwesk
11:17
<rkwesk>
the line was "DNSMasq actually provides a tftp server if you want to use it, however I recommend the use of tftp-hpa as it allows remapping in the event you ever intend to boot a Windows environment over your network."
11:18
it may simply not interest our schools. i don't know
11:18
it was indeed about changing slashes
11:19
<alkisg>
rkwesk: do you want to install windows over the network or run windows over the network?
11:20
<rkwesk>
i just wanted 2 explore what a school might want
11:20
if it just involves installing then probably few schools would want it
11:21
<alkisg>
Netbooting windows is much, much harder than netbooting linux
11:22
You'd need to specially prepare an image with aoe or iscsi drivers and it'll only work for a single client
11:22
<rkwesk>
it doesn't surprise me :))
11:22
<alkisg>
And tftp is not involved there
11:23
What you could do is create an installation server, there are many tutorials about that, and even packages that you could use
11:23
<rkwesk>
so in short remapping is not an issue 4 most
11:23
<alkisg>
But schools wouldn't really care about that, they'd care more about a cloning solution or a VM/xfreerdp+linux based solution to run windows on top of linux
11:23
Because then a single image can be used in all clients
11:24
<rkwesk>
yes, ok.
11:25andygraybeal has left IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net, Ping timeout: 246 seconds)
11:25
<alkisg>
Yes remapping shouldn't be an issue for any greek school. And if it was, it could just install tftpd-hpa and keep dnsmasq for the proxydhcp mode.
11:25
<rkwesk>
thank you 4 sorting this point 4 me.
11:25
<alkisg>
np
11:27staffencasa has left IRC (staffencasa!~staffenca@128.193.8.220, Ping timeout: 244 seconds)
11:28Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
11:31rkwesk has left IRC (rkwesk!~rkwesk@adsluser1289.att.sch.gr, Quit: Leaving)
11:37Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Quit: "Achievement is not the end, its the beginning of new journey !!!")
11:45
<alkisg>
knipwim: So far I got help2man to automatically extract those man page sections from the program output:
11:45
NAME, SYNOPSIS, DESCRIPTION, OPTIONS, ENVIRONMENT, FILES, EXAMPLES, REPORTING BUGS, COPYRIGHT.
11:45
Didn't manage yet to make it extract: other, AUTHOR, SEE ALSO.
11:47
Ah ok with AUTHOR
11:54
<knipwim>
cool
11:56
you're extracting those from ltsp-tool, or with the help of an include file?
11:56
<alkisg>
From ltsp-tool
11:59
<knipwim>
well, SEE ALSO doesn't have to be included i think
12:00
<alkisg>
I'll file a bug in help2man though if I can't get it to work
12:01
The SEE ALSO section will still be included as normal text, it just won't be a special section
12:01
(bold letters etc)
12:02
At some point I'd like us to have translatable "usage" texts
12:02
We do already for ltsp-build-client, so it shouldn't be much of a change
12:02
And help2man will then automatically create localized man pages
12:04
<knipwim>
i almost can't believe this hasn't been done sooner
12:05
<alkisg>
Shows how much most devs care about documentation :P
12:08
Ah it appears that help2man can only produce the GNU-related "info" output in the "SEE ALSO" section. So we can use --opt-include=$ltsp-tool.inc if we want, or omit SEE ALSO.
12:25litlebuda has joined IRC (litlebuda!~litlebuda@204.0.166.178.rev.vodafone.pt)
12:36bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 244 seconds)
12:40adrianorg_ has joined IRC (adrianorg_!~adrianorg@189.58.224.221.dynamic.adsl.gvt.net.br)
13:13Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71)
13:29cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
13:56Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas, Ping timeout: 248 seconds)
14:09ricotz has joined IRC (ricotz!~rico@p5B2ACE33.dip.t-dialin.net)
14:09ricotz has joined IRC (ricotz!~rico@unaffiliated/ricotz)
14:14Phantomas has joined IRC (Phantomas!~Phantomas@unaffiliated/phantomas)
14:17komunista has left IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk, Ping timeout: 245 seconds)
14:33komunista has joined IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk)
14:50litlebuda has left IRC (litlebuda!~litlebuda@204.0.166.178.rev.vodafone.pt, Remote host closed the connection)
15:08Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
15:49vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
15:49vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
16:17
<knipwim>
hey vagrantc !
16:18
alkisg and i were entertaining the idea of removing BASE and TFTPDIRS from the commandline options of all ltsp-tools
16:19
and put those in common.conf
16:20
certainly TFTPDIRS can be moved there; these are system specific
16:20
<vagrantc>
that would basically mean you can only have it once?
16:20
i.e. you couldn't experiment with another BASE dir ... but that's prretty niche
16:20
<knipwim>
yeah, i was wondering about that option for BASE as well
16:20
<vagrantc>
well, you could, but not on the fly ... supporting multiple BASE dirs probably doesn't work well anyways...
16:21
since all the various tools would need to consistantly have the option passed on the commandline ...
16:21
sounds reasonable...
16:21
<knipwim>
yes, and passed onwards, for example from ltsp-update-image to ltsp-config
16:21
<vagrantc>
(putting BASE and TFTPDIRS in common.conf)
16:22
<knipwim>
which is not happening now
16:22
<vagrantc>
if we made it possible to specify an alternate config dir, that would make it easier to consistantly support multiple BASE dirs ...
16:23
<knipwim>
or just change the value in common
16:24
<vagrantc>
sure, but supporting multiple common.conf's would require specifying another config dir
16:24
but i don't think it's worth the trouble, really.
16:24
<knipwim>
or move more from $arch to $name, for instance /opt/ltsp/i386-test or /opt/ltsp/my-test-env
16:25
<vagrantc>
right, typically that's enough to make it work well.
16:26
<knipwim>
btw, have you seen alkisg's next briliant idea? about the help2man?
16:37
<vagrantc>
not yet...
16:37* vagrantc looks
16:39
<vagrantc>
i've thought about that in the past ... i even took a stab at it once ... we'll have to make sure out --help output is formatted in a way that help2man expects.
16:39
but generating the manpage are build time would allow things like distro-specific plugin options being documented
16:39
which is cool
16:53
<alkisg>
(07:20:10 μμ) vagrantc: that would basically mean you can only have it once? ==> if common.conf has BASE=${BASE:-/opt/ltsp}, then one can override it with BASE=xx ltsp-update-image params
16:54
But then the .conf syntax is a bit weird
16:54F-GT has left IRC (F-GT!~phantom@ppp121-44-97-140.lns20.syd6.internode.on.net, Ping timeout: 260 seconds)
16:58
<uskerine>
i asked yesterday and i think alkisg answered, but i can not find it, how do i disable the dnsmasq service so in an environment with two servers the backup will not enter into the game unless the service is manually started?
16:58
<alkisg>
/etc/default/dnsmasq
16:58
vagrantc: does it make sense to have both 64bit and 32bit kernels in the same chroot? (about ifcpu64...)
16:59
<uskerine>
thks
17:00
<vagrantc>
alkisg: i have some use-cases for that, yes.
17:01
<alkisg>
vagrantc: yesterday I though that ifcpu64 could show diffeferent menu items based on the client CPU, but it can't, it can only jump to different labels,
17:01
<vagrantc>
alkisg: booting 64-bit machines from a 32 bit chroot, where i want the proper memory handling of a genuine 64-bit kernel, but don't want to maintain a separate userland.
17:01
<alkisg>
so we can either use it in a "master" /var/lib/tftpboot/pxelinux.cfg/default, which chains to 2 different ltsp menus, or in a menu item, "boot kernel version xxx", where it selects between a few kernels to boot
17:01
And I'm thinking what of those best suits us
17:02
vagrantc: is booting 32bit chroots with 64bit kernels debian-specific? E.g. can I do that in Ubuntu? The kernels here don't even have different package names...
17:05
<vagrantc>
alkisg: i don't know what ubuntu supports, i'm guessing there's no technical reason it couldn't be done, although as you point out, the filenames are identical, so it probably makes it difficult.
17:06
alkisg: you could probably use multi-arch to install the amd64 kernel in the i386 userland.
17:06* alkisg is suprised that an 64bit kernel can work with 32bit libs though
17:06
<vagrantc>
alkisg: so theres generic:amd64, generic:i386, generic-pae:i386 ?
17:06
<alkisg>
Right
17:07
And lowlatency and virtual, for both arches
17:07
<vagrantc>
so generic:amd64 and generic-pae:i386 could co-exist ... but that's not the most useful use-case.
17:09
<alkisg>
vagrantc: I'd even have to change my sources to install the 64bit kernel, and that might cause havoc with my system
17:10
OK let's view it from another perspective. Multiple chroots, one for amd64 and one for i386. How useful is to use ifcpu64 on that?
17:10
<vagrantc>
it should still treat "i386" as the native/preferred arch, unless multiarch isn't working properly.
17:10
alkisg: that seems *really* useful.
17:10* alkisg hasn't read about multiarch yet
17:11
<alkisg>
In the previous case we were talking about, ifcpu64 would be used after the user selects a menu
17:12
In this case, ifcpu64 would be the default, and it would select between 2 different ltsp/<arch>/pxelinux.cfg/default menus
17:13Phantomas1 has joined IRC (Phantomas1!~Phantomas@unaffiliated/phantomas)
17:13Phantomas has left IRC (Phantomas!~Phantomas@unaffiliated/phantomas, Disconnected by services)
17:13Phantomas1 is now known as Phantomas
17:14
<alkisg>
For the first case again, I believe we only want ifcpu64 for the first ltsp entry, not for the "other/older kernels" submenu, right?
17:15
If the user wants to go in there, we should allow him to choose e.g. the 486 kernel even if he has a 64bit cpu and the 64bit kernel is available
17:16
And, for the second case to work, we'll need absolute tftp paths in ltsp/i386/pxelinux.cfg/default
17:16
<vagrantc>
alkisg: that seems reasonable, though i could see allowing autodetection even in the submenus.
17:16
<alkisg>
Let's not make it too complicated though... :-/
17:16
<vagrantc>
alkisg: yeah, that's what i was thinking
17:17
alkisg: so it seems like autodetection should go something like: if amd64 and amd64 chroot, boot amd64 chroot, if amd64 and i386 chroot only, boot i386 chroot with amd64 ...
17:17
<alkisg>
With that scheme we can still make it with only 2 files,ltsp and ltsp-old. And for the second case, a master TFTP/pxelinux.cfg/default is needed as well, and a bit of change in how we detect the lts.conf path (we'd take it from the cmdline instead of dhcp)
17:18
<vagrantc>
if no amd64 kernel in i386, boot pae kernel, fallback to nonpae kernel in i386 chroot
17:21
<alkisg>
Master ifcpu64 call: check for chroots named amd64 / i386. Nothing -pae related there.
17:21
<vagrantc>
though now that we're talking about multiple chroots, it sounds like we're talking about pxemenus and not in-chroot pxelinux configuration
17:21
<alkisg>
Secondary ifcpu64 call, only in the i386 chroot: check for pae or i386 kernel.
17:21
The master one will be generated by ltsp-update-kernels, the secondary ones by update-kernels.
17:22
<vagrantc>
alkisg: you're chaining ifcpu64 calls?
17:22
<alkisg>
Right, we need 2 of them to make both cases work
17:22
The first one is to select the chroot to boot
17:22
It's executed without a menu. It selects a chroot and loads vesamenu.c32 with the path to the chroot configuration file, /ltsp/<arch>/pxelinux.cfg/default
17:22Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving)
17:23
<vagrantc>
alkisg: with the secondary call (the i386 chroot call) i still want to be able to boot an amd64 kernel with an i386 chroot
17:23
<alkisg>
Right, but what name would you check for?
17:23Parker955_Away is now known as Parker955
17:23
<vagrantc>
kernel name? -amd64 :P
17:24
it's easy on debian, ubuntu makes it hard :P
17:24
(admittedly it's probably a lot simpler to have a -generic kernel on all arches)
17:25
<alkisg>
OK, so debian would have "ifcpu64 amd64 -- 686 -- 486", and ubuntu would have "ifcpu64 generic-pae -- generic-pae -- generic" - of course only if those exist
17:25
...or something, dunno what else could be done with multiarch given the ubuntu kernel names
17:26
<vagrantc>
alkisg: that seems like the best you can do
17:26
<alkisg>
Now, if the user wants to have different chroots like "nvidia-clients-i386" and "ati-clients-amd64", I don't see how we can help him :P
17:26
He'd have to specify them in dhcp
17:27
<vagrantc>
alkisg: actually, though, on debian the -686 kernels do not necessarily support pae.
17:27
alkisg: -686-pae supports pae, -686 does not.
17:27
<alkisg>
Then you'd check for both of them and put them in the "pae" placeholder
17:27
<vagrantc>
alkisg: so it'd be more like amd64 -- 686-pae|686-bigmem -- 486|686
17:28
<alkisg>
...ifcpu64 supports | ?
17:28
The choice would be done from update-kernels, no?
17:28
<vagrantc>
no, just trying to map the potentials to kernel names
17:28
<alkisg>
OK, so update-kernels would only put 686-pae there if both it and plain 686 were installed
17:29
In other words, we need 3 lists
17:29
<vagrantc>
alkisg: it basically depends on if you're using squeeze or wheezy ... 686-bigmem -> 686-pae and 686 -> 486
17:29
<alkisg>
LIST_KERNELS_AMD64, LIST_KERNELS_PAE, LIST_KERNELS_I386
17:29
<vagrantc>
there is no wheezy equivalent to plain 686
17:30
yup, so: LIST_KERNELS_AMD64="-amd64" LIST_KERNELS_PAE="686-pae 686-bigmem" LIST_KERNELS_I386="486 686"
17:31
<alkisg>
For Ubuntu: LIST_KERNELS_64="lowlatency-pae lowlatency virtual-pae virtual generic-pae generic", LIST_KERNELS_PAE="lowlatency-pae lowlatency virtual-pae virtual generic-pae generic", LIST_KERNELS_I386="lowlatency virtual generic"
17:31
<vagrantc>
if the preference is listed that way
17:31
i.e. first one gains preference
17:31
<alkisg>
Right, ok we'll see if we need to list the rest of them or if they're implied
17:32
<vagrantc>
oh, right, i'd need to add the -pae as alternates for amd64, in case there was no amd64 kernel.
17:32
<alkisg>
And the 486/686 ones too
17:32
With the opposite order there
17:32
<vagrantc>
yup, so: LIST_KERNELS_AMD64="amd64 686-pae 686-bigmem" LIST_KERNELS_PAE="686-pae 686-bigmem" LIST_KERNELS_I386="486 686"
17:33
<alkisg>
IST_KERNELS_AMD64="amd64 686-pae 686-bigmem 686 486"
17:33
LIST_KERNELS_PAE="686-pae 686-bigmem 686 486"
17:33
<vagrantc>
alkisg: shouldn't we just append each list?
17:33
<alkisg>
The order is not the same, 686 is preferred in amd64 cpus
17:34
<vagrantc>
since AMD64 could run anything in PAE, and PAE could run anything in I386
17:34
eesh.
17:34
<alkisg>
If you appended the lists, you'd get LIST_KERNELS_AMD64="amd64 686-pae 686-bigmem 486 686" instead of LIST_KERNELS_AMD64="amd64 686-pae 686-bigmem 686 486" - last 2 swapped
17:35
<vagrantc>
and in order to support PAE, you need to support amd64.
17:35
alkisg: i'm ok with that level of wrongness.
17:35
<alkisg>
It doesn't matter much; it's just 3 lines in a configuration file
17:36
Whatever, both work for me, I don't even need pxemenus now with ltsp-pnp, just to prefer the non-pae kernel if it's installed, and cleanup.d already does that :P
17:37Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
17:37komunista has left IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk, Quit: Leaving.)
17:37
<alkisg>
I think that the problem with writing the whole path in ltsp/i386/pxelinux.cfg/ltsp can be amended with ltsp-update-kernels sed'ing through the files while copying them
17:38
...as the chroot currently doesn't not need to know its name, we'd best keep it that way unless we have to
17:38
<vagrantc>
right.
17:40
<alkisg>
About the master TFTP/pxelinux.cfg/default, since we'd like the user to be able to edit it (e.g. to specify different chroot ordering in the menus or list them in submenus or whatever), I propose that ltsp-update-kernels puts the ifcpu64 call in TFTP/pxelinux.cfg/ltsp, and that pxelinux.cfg/default INCLUDEs that
17:40
So all in all we'll be writing some files under the pxelinux.cfg/ dirs, but we'll only be regenerating the ltsp and ltsp-old ones
17:40
<vagrantc>
alkisg: ok, so AMD64="amd64 $PAE" PAE="686-pae 686-bigmem 686 $I386" I386="486 686"
17:40
<alkisg>
OK, in the opposite order of declaration
17:41
<vagrantc>
well, we can just append them, and if things are repeated, that shouldn't matter?
17:41
<alkisg>
No I mean that the $PAE variable isn't yet declared if you declare AMD64 first
17:41
<vagrantc>
by repeating 686 in PAE, i think that solves the little problem you mentioned, and all pae supporting stuff can run 686
17:42
alkisg: well, thta was more concceptually
17:42
<alkisg>
Those would go in /etc/ltsp/update-kernels.conf, shipped by distros, right?
17:42
<vagrantc>
alkisg: i think the code would be more like for variant in $AMD64 $PAE $I386 ; do ...
17:42
alkisg: that's what i'm thining
17:43
<alkisg>
ifcpu64_amd_entry=$(list_kernels $AMD64 | head -n 1)
17:43
No need to loop
17:44
<vagrantc>
list_kernels $AMD64 $PAE $i386 for amd64, list_kernels $PAE $I386 for pae, and list_kernels $I386 for the rest
17:44komunista has joined IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk)
17:44
<alkisg>
Sounds better
17:44
<vagrantc>
that way you don't have to AMD64="amd64 $PAE"
17:44
<alkisg>
Right
17:44
<vagrantc>
sorry i didn't explain myself better
17:45* vagrantc keeps using pseudo-code ideas and failing
17:45
<alkisg>
Although in Ubuntu we'd probably have to leave AMD64="" because of the same kernel names with I386, to prevent duplicates
17:45
<vagrantc>
:(
17:46
alkisg: could also ship a different update-kernels.conf in amd64 vs. i386
17:46
<stgraber>
yeah, as of 12.10 we'll have linux-image-generic on both i386 and amd64. The i386 one being a PAE kernel, we won't have non-PAE variants anymore.
17:46
<vagrantc>
well, that simplifies things a bit.
17:47
<stgraber>
we have slightly different naming conventions for the ARM kernel though and as ogra wants to have proper ARM support for 12.10, we might need some magic for these
17:47
<alkisg>
stgraber: pxelinux doesn't work in arm, does it?
17:47
<stgraber>
(as ARM tends to work on a per-SOC basis...)
17:47
<alkisg>
All those are pxelinux related...
17:47
<stgraber>
alkisg: not sure for pxelinux itself but we definitely have PXE support on ARM now (in uboot)
17:47
<vagrantc>
y'all need to fix your ltsp-build-client plugins to work better on arm :P
17:48
<stgraber>
vagrantc: yeah, I believe I gave ogra a work item for that ;)
17:48
<vagrantc>
it currently defaults to imx5 or something
17:48
<alkisg>
(08:46:49 μμ) vagrantc: well, that simplifies things a bit. => nah it even makes it impossible to have a pae and an 64bit kernel, which worked in 12.04. But meh all this is way beyond my use cases :)
17:49
<vagrantc>
alkisg: i've got weird use-cases :)
17:49* alkisg will leave most of the pxemenus implementation and testing to vagrantc then, after the design process :P
17:50
<alkisg>
I need to dive in sch-scripts this month, we have a seminar for them in the 21th
17:51
<vagrantc>
sounds reasonable.
17:53
<alkisg>
Having full tftp paths also helps in deciding the nbd or nfs name when ipappend=3 is used, where rootpath isn't available
17:53
And we could make 2 attempts to retrieve lts.conf, one in the subdir and if that's missing maybe also check for a master one in TFTP/lts.conf
17:54
<vagrantc>
alkisg: yeah, i've thought about that sometimes
17:55
it would be nice, actually, to have a single lts.conf, as long as it was possible to override on per-chroot basis.
17:56
<alkisg>
We could easily add them... Although I don't want to invest in lts.conf too much, I prefer an /etc/ltsp/lts.conf.d dir with shell scripts...
17:57
<vagrantc>
mhmm
17:58Parker955 is now known as Parker955_Away
17:59Parker955_Away is now known as Parker955
18:00
<alkisg>
So, get the master lts.conf, evaluate it, get the subdir lts.conf, evaluate it - it overrides the master options
18:01
<vagrantc>
alkisg: you could implement it as an early running ltsp_config.d hook, no?
18:03
<alkisg>
Sure
18:04
<vagrantc>
which could overwrite the existing lts.conf, or simply set variables later.
18:04
<alkisg>
It could save it with a different name, and we'd source both of them when needed
18:05
<vagrantc>
you can do anything you put your mind to :)
18:07
speaking of which, i was going to be testing ldm
18:10* alkisg thinks ltsp_config is too complex and too slow and needs a rewrite :-/
18:11
<alkisg>
(not for now, for/if when we implement the /etc/ltsp/lts.conf.d mechanism)
18:11* vagrantc would definitely prefer that for ltsp 5.5 ...
18:37Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Quit: "Achievement is not the end, its the beginning of new journey !!!")
18:38
<vagrantc>
alkisg: ok, so LDM_DESKTOP forces use of the specified desktop? LDM_DESKTOP_DEFAULT sets the default but allows the user to override?
18:43bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
18:54
<vagrantc>
alkisg: there's some weird issue with the new LDM ... after logging in ... the login window/logo shift to the left ...
18:59
<alkisg>
vagrantc: about LDM_DESKTOP, yes. I did hear someone say that LDM_SESSION _doesn't_ force a session though...
18:59
(from the greeter)
18:59
vagrantc: about the login window/logo, it's something related to wwm, I noticed it a few months ago
19:00
<vagrantc>
and something's hosed my LXDE :(
19:04
alkisg: i know i've tested LDM_SESSION forcing a session recently...
19:04
alkisg: but if it fails to find the forced session, it will fallback to the defaults
19:05
<alkisg>
OK I can ignore the other source then :)
19:05
help2man -s 8 -N --version-string 5.4.0 server/ltsp-update-sshkeys -o /tmp/ltsp-update-sshkeys.8 && man /tmp/ltsp-update-sshkeys.8
19:05* alkisg wishes he knew that before spending time in manpages :)
19:05
<vagrantc>
alkisg: i can test again
19:06
alkisg: so, with all the sourced files ... how do we get our scripts to run?
19:06
do they source full paths or relative paths?
19:07
that was what killed my ability to try that before.
19:08
<alkisg>
The usage doesn't/shouldn't need sourced files, except for ltsp-build-client... we could make some special case in his plugin sourcing code
19:09
...we'll need some restructuring :-/
19:09
<vagrantc>
and then VENDOR=Ubuntu ltsp-build-client won't obviously have the right manpage on Debian ... but that's an unusual enough case folks will probably cut us slack :)(
19:09
alkisg: restructuring ... not now! not now!
19:09
<alkisg>
Nope, don't worry :D
19:14
<vagrantc>
alkisg: putting LDM through it's paces now with the LDM_DESKTOP, LDM_DEFAULT_DESKTOP and soon LDM_SESSION testting
19:14lefteris_nik has joined IRC (lefteris_nik!~Lefteris@ppp141237208190.dsl.hol.gr)
19:20
<vagrantc>
alkisg: ok, so LDM_SESSION isn't overriding the session- you can override with selectingg from the menu.
19:20
<alkisg>
That should be fixed in the greeter, right?
19:20
<vagrantc>
alkisg: and if that's the case, should maybe rename LDM_DEFAULT_DESKTOP to LDM_DESKTOP and LDM_DESKTOP to LDM_FORCE_DESKTOP ?
19:21
<alkisg>
I like that better
19:21
Most people would want to set the default, not force it
19:21
<vagrantc>
right
19:22
<alkisg>
vagrantc: but LDM_SESSION currently overrides the user's .dmrc
19:22
So in any case we do need to fix the greeter
19:22
<vagrantc>
alkisg: didn't for me.
19:22
alkisg: or hmm ... let me check
19:23
alkisg: oh, you're right ... it overrides ~/.dmrc
19:23
that seems buggy to me.
19:24
LDM_FORCE_SESSION (or LDM_SESSION_FORCE) could be implemented that way.
19:25
alkisg: ok, i'm going to rename LDM_DESKTOP to LDM_DESKTOP_FORCE and LDM_DEFAULT_DESKTOP to LDM_DESKTOP ... and maybe implement LDM_SESSION_FORCE, and try and get LDM_SESSION to not override ~/.dmrc ... ?
19:25
alkisg: or do you prefer LDM_FORCE_DESKTOP ?
19:26
<alkisg>
vagrantc: no, LDM_DEFAULT_SESSION shouldn't override the user's dmrc
19:26
(currently)
19:26
so after the rename, LDM_SESSION will be fine, the problem will be in LDM_DEFAULT_SESSION
19:26komunista has left IRC (komunista!~slavko@adsl-195-168-242-147.dynamic.nextra.sk, Quit: Leaving.)
19:26
<alkisg>
...which will need to be fixed in the greeter
19:26
<vagrantc>
LDM_FORCE_SESSION
19:26
<alkisg>
Sorry, yes
19:26
<vagrantc>
or LDM_SESSION_FORCE ?
19:27
FORCE_SESSION makes more sense in english, SESSION_FORCE sorts better.
19:27
i might have to do this later in the evening.
19:27
but the LDM_DESKTOP stuff seems to be workinng well.
19:28
<alkisg>
LDM_FORCE_SESSION
19:28
(no strong preference though)
19:31
<vagrantc>
ok.
19:31
<alkisg>
vagrantc: what handles the translations that use eval_gettext? Is support for it embedded in some of the tools we use? ...why didn't they use a smaller function name, like `_ "text"` or $(_ "text") instead?! :(
19:32
<vagrantc>
oh, there's already an LDM_DEFAULT_SESSION
19:32
<alkisg>
vagrantc: yes, and it should be working fine, that's what I was trying to say
19:32
<vagrantc>
alkisg: which tools are you talking about?
19:32
<alkisg>
vagrantc: the ones that generate the .po files
19:32
That parse the source and extract the strings
19:32
<vagrantc>
alkisg: in ldm or ltsp?
19:32
<alkisg>
ltsp, in any shell file
19:33
E.g. ltsp-build-client --extra-help is localized
19:33
Because it uses eval_gettext to translate the options
19:33
...but I'm wondering which tool reads our source code and extracts the text to translate from the eval_gettext parameters
19:34
<vagrantc>
alkisg: oh, that was ax nightmare to implement ...
19:34
alkisg: look at po/Makefile
19:35
GETTEXTFILES
19:35
$(DOMAIN).pot
19:35
<alkisg>
Ah, xgettext -L shell
19:35
<vagrantc>
yup
19:36
alkisg: we did some insanity in order to generate the gettext-able commandline options from plugins.
19:36
alkisg: i haven't touched it since.
19:36
2006
19:36
<alkisg>
vagrantc: it'd be nice to have it for the other tools too
19:37
cat <<EOF
19:37
-b, --base $(_ "The LTSP base")
19:37
EOF
19:37
That's the syntax I'd like to have, but if eval_gettext is a standard.. :-/
19:38
<vagrantc>
alkisg: experiment and see if it still works
19:38
alkisg: i do recall having issues with _
19:40
<alkisg>
Or even $(_ "File %s does not exist." "$file") - which isn't usual in shell, but it's what other language use, and what translators are used to
19:41
<vagrantc>
sure
19:41
<alkisg>
The _() function is easy to implement, the difficult is the xgettext part
19:42
<vagrantc>
alkisg: what if LDM_SESSION didn't touch ~/.dmrc at all ?
19:43
<stgraber>
alkisg: don't we already have something like that in ldm-trunk? I thought we had translated shell in there
19:43
<alkisg>
stgraber: haven't look, will check about it
19:43
vagrantc: let's talk with DEFAULT and FORCE in order to not get confused by the old/new names
19:43
<vagrantc>
i think only the C code in ldm is translated
19:43
<stgraber>
alkisg: apparently at least ltsp-cluster-info is translated with the right xgettext magic in the makefiles
19:44
<vagrantc>
alkisg: i want to drop default
19:44
<alkisg>
vagrantc: err why?
19:44
<vagrantc>
alkisg: because i think DEFAULT should be assumed, and FORCE should be specified.
19:44
<stgraber>
vagrantc: nope, we have some translated rc.d hooks and ltsp-cluster-info is also translated (po/rc.d and po/ltsp-cluster-info)
19:45
<alkisg>
vagrantc: agreed about the names, I just wasn't sure when you said LDM_SESSION if you were talking about its old meaning or its new meaning
19:45
<vagrantc>
i.e. LDM_SESSION and LDM_DESKTOP behave like defaults, and LDM_FORCE_SESSION and LDM_FORCE_DESKTOP appropriately.
19:45
<alkisg>
That's why I proposed that we talk with DEFAULT and FORCE, but of course you won't commit the DEFAULT word anywhere
19:45
<vagrantc>
got it.
19:46
alkisg: so, i don't think FORCE should ever save to ~/.dmrc
19:46
<alkisg>
vagrantc: and when would we write to .dmrc? Only when the user selects it from the menu?
19:46
Then we'd need a third variable passed from ldm
19:47
I agree with the concept, not sure about the necessary code changes...
19:47
<vagrantc>
and LDM_DESKTOP should be written to ~/.dmrc, but LDM_(default)_SESSION shouldn't.
19:47
<alkisg>
Ah
19:47
<vagrantc>
wait, no ... LDM_(default)_DESKTOP shouldn't either ... hrm.
19:47
<alkisg>
I think that LDM_DESKTOP shouldn't be written either... ^ :)
19:48
<vagrantc>
i've just confused myself, and need to head soon ... i'll have to work on more of this later.
19:49
<alkisg>
stgraber: ltsp-cluster appears to be using eval_gettext too, I was looking if we could use a shorter name in order to for things like those to be more readable:
19:49
usage() {
19:49
cat <<EOF
19:49
-a, --arch $(_ "The architecture of the chroot.")
19:49
EOF
19:49
}
19:50
...but xgettext won't detect $(_ ) I believe
19:53
Hehe bash -D, handy!!!
19:56
<vagrantc>
will hopefully tweak ldm later and upload ... gotta head out for a while.
20:00vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
20:37andygraybeal has joined IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net)
20:49uskerine has left IRC (uskerine!~uske@80.30.244.131, Ping timeout: 260 seconds)
21:06
<alkisg>
OK, here's my proposal for translations: http://paste.ubuntu.com/1022071/
21:09
echo `_ 'Automatic login in %d seconds' 10`
21:09
At least visually it seems quite good
21:19litlebuda has joined IRC (litlebuda!~litlebuda@204.0.166.178.rev.vodafone.pt)
21:21ricotz has left IRC (ricotz!~rico@unaffiliated/ricotz, Quit: Ex-Chat)
21:31uskerine has joined IRC (uskerine!~uske@80.30.244.131)
21:42bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 252 seconds)
21:49andygraybeal has left IRC (andygraybeal!~andy@h167.93.213.151.dynamic.ip.windstream.net, Ping timeout: 246 seconds)
22:07alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
22:17uskerine has left IRC (uskerine!~uske@80.30.244.131, )
22:20sideffect has joined IRC (sideffect!sideffect@gateway/shell/bshellz.net/x-bvosoxjrjdvdykxh)
22:26Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving)
23:15lefteris_nik has left IRC (lefteris_nik!~Lefteris@ppp141237208190.dsl.hol.gr, Remote host closed the connection)