15:15 | ltsp has joined IRC (ltsp!bot@ltsp.org) | |
15:17 | dsugar100 has left IRC (dsugar100!~dsugar@columbia.tresys.com, Remote host closed the connection) | |
15:20 | dsugar100 has joined IRC (dsugar100!~dsugar@columbia.tresys.com) | |
15:26 | <sbalneav> jammcq: Pong
| |
15:27 | jammcq: Oh, looks to be up now.
| |
15:27 | Slow, though
| |
15:37 | alexxtasi has left IRC (alexxtasi!~alex@unaffiliated/alexxtasi) | |
15:50 | arj_ has joined IRC (arj_!5d516feb@gateway/web/freenode/ip.93.81.111.235) | |
15:54 | <arj_> Hi! I have problems with qt apps, such as qupzilla, qtcreator, on thin client. They are renders very slow. Same problem: http://ubuntuforums.org/showthread.php?t=2115560
| |
15:55 | How to fix it?
| |
15:58 | Mikee_ has joined IRC (Mikee_!c274c6b9@gateway/web/freenode/ip.194.116.198.185) | |
15:59 | Mikee_ has left IRC (Mikee_!c274c6b9@gateway/web/freenode/ip.194.116.198.185, Client Quit) | |
16:07 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
16:09 | arj_ has left IRC (arj_!5d516feb@gateway/web/freenode/ip.93.81.111.235, Quit: Page closed) | |
16:11 | willianm_ has joined IRC (willianm_!~textual@187.4.15.116) | |
16:12 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Ping timeout: 245 seconds) | |
16:12 | willianm_ is now known as willianmazzardo | |
16:16 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Ping timeout: 250 seconds) | |
16:29 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
16:37 | gbaman has joined IRC (gbaman!~gbaman@host81-134-114-61.in-addr.btopenworld.com) | |
16:38 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
16:38 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
16:54 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Ping timeout: 245 seconds) | |
17:17 | mmetzger_ is now known as mmetzger | |
17:23 | <alkisg> jammcq, sbalneav: nice to have the server up again :) Though it's always very very slow and hangs frequently and needs apache restart... maybe Hyperbyte could host it instead?
| |
17:24 | Hi vagrantc, do you have any plans to tag ltsp in the near future?
| |
17:24 | <vagrantc> my plans seem to get perpetually delayed
| |
17:25 | * alkisg knows the feeling | |
17:25 | <vagrantc> might try for today
| |
17:25 | <alkisg> https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
| |
17:25 | 16 February 6th Debian Import Freeze
| |
17:25 | 18 February 20th FeatureFreeze
| |
17:26 | <vagrantc> the import freeze is irrelevent- that only applys to things that get automatically synced, and ubuntu carries a diff
| |
17:26 | <alkisg> True... btw note that you'll need a small packaging change,
| |
17:26 | I added a "--version" option to most of our scripts, but it needs to be generated by the build tools
| |
17:27 | http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2543
| |
17:27 | So the build tools need to update ltsp-common-functions
| |
17:27 | (--version and --help are mandatory, according to gnu policy... and it helped with older versions of help2man)
| |
17:28 | So, sed 's/ltsp_tool 1.0/ltsp_tool $version/' -i ltsp-common-functions...
| |
17:30 | <vagrantc> could just ship a version file...
| |
17:31 | <alkisg> Sure, feel free to change that and echo $version in ltsp_version()...
| |
17:31 | But we'd need 2 files, one for server and one for client
| |
17:31 | <vagrantc> right
| |
17:31 | <alkisg> ltsp-common-functions was handy there because we already split it to 2 files
| |
17:33 | <vagrantc> having to distinguish between server and client version might be tricky...
| |
17:33 | <alkisg> The server tools source the server functions, the client tools the client functions
| |
17:33 | <vagrantc> yes, that's not hard, but how would the function know which to use?
| |
17:35 | <alkisg> The sourcing of the version file wouldn't go into -common, but into ltsp-server-functions / ltsp-client-functions
| |
17:35 | # Source common server settings, e.g. BASE
| |
17:35 | if [ -f /etc/ltsp/ltsp-server.conf ]; then
| |
17:35 | . /etc/ltsp/ltsp-server.conf
| |
17:35 | fi
| |
17:36 | ....something like that, which we already have there...
| |
17:37 | (or, from /usr/share/...)
| |
17:38 | <vagrantc> it's been a while since i looked this over ... ok, so we ship ltsp-server-functions and ltsp-client-functions, which source the corresponding common-functions ... so we'd have two identically named ltsp_version functions, instead of putting it into common-functions
| |
17:44 | maybe just sedding it in place is fine...
| |
17:46 | highvoltage has left IRC (highvoltage!~highvolta@ubuntu/member/highvoltage, Read error: Operation timed out) | |
17:46 | SmallR2003 has left IRC (SmallR2003!~Robert@c-98-253-173-240.hsd1.il.comcast.net, Read error: Operation timed out) | |
17:46 | SmallR2002 has joined IRC (SmallR2002!~Robert@c-98-253-173-240.hsd1.il.comcast.net) | |
17:49 | highvoltage has joined IRC (highvoltage!~highvolta@ubuntu/member/highvoltage) | |
17:54 | dsugar100 has left IRC (dsugar100!~dsugar@columbia.tresys.com, Write error: Broken pipe) | |
17:55 | dsugar100 has joined IRC (dsugar100!~dsugar@columbia.tresys.com) | |
18:08 | <alkisg> vagrantc: we'd have /usr/share/ltsp/ltsp_server_version and /usr/share/ltsp/ltsp_client_version, but I don't see why sedding would be wrong, maybe even from the makefile
| |
18:08 | Or, a .in file
| |
18:09 | The ltsp-server-version file would contain LTSP_VERSION=xxx, and ltsp_version() would just echo it
| |
18:11 | <vagrantc> right
| |
18:11 | or simple cat it
| |
18:12 | any of these approaches would work...
| |
18:12 | <alkisg> cat would require ltsp_version() to be different, in order to know which file to cat
| |
18:12 | Sourcing would go to ltsp-server-functions, while ltsp_version() to common
| |
18:12 | <vagrantc> ah, i see.
| |
18:12 | <alkisg> In common we don't have an easy way to decide which file to source
| |
18:13 | * alkisg prefers sed or a file.in though | |
18:13 | <vagrantc> right
| |
18:14 | ok, so i'll have to sed it in the packaged version, but that shouldn't be hard since we already rename it in debian/rules
| |
18:15 | <alkisg> Yes I think I have it committed already in my packaging mirror... let me see...
| |
18:15 | vagrantc: https://code.launchpad.net/~ts.sch.gr/sch-scripts/ltsp-debian-packaging
| |
18:16 | ...I think those 2 are untested though...
| |
18:18 | <vagrantc> is DEBVERS set?
| |
18:18 | <alkisg> Not sure...
| |
18:18 | We can read VERSION from release.conf if needed..
| |
18:20 | DEBVERS ?= $(shell dpkg-parsechangelog | sed -n -e 's/^Version: //p')
| |
18:20 | VERSION ?= $(shell echo '$(DEBVERS)' | sed -e 's/^[[:digit:]]*://' -e 's/[-].*//')
| |
18:20 | ...at least that's what google says
| |
18:20 | <vagrantc> yes, something like that
| |
18:20 | i just didn't see any such code there
| |
18:21 | alkisg: should it contain the upstream version, or the debian version?
| |
18:22 | reading from release.conf only works for released versions, i'd rather pull it from debian/changelog when building on debian derivatives
| |
18:23 | when i'm doing pre-release testing, i don't mess with release.conf at all
| |
18:23 | <alkisg> dpkg -l coreutils => 8.21-1ubuntu4, man cat => 8.21
| |
18:23 | ...so the usual would be "upstream version", but personally I'd prefer the debian version :)
| |
18:25 | * vagrantc is finding the meaningless launchpad translation updates disruptive... | |
18:25 | <vagrantc> makes it hard to see "what were the changes since the last time i tested this"
| |
18:26 | when 90% of the changes are changes to comments in the .po files
| |
18:27 | wish i could just ignore .po files...
| |
18:27 | <alkisg> OK, let's disable the ltsp-trunk translation commits too, until 1 day before tagging
| |
18:28 | <vagrantc> this happens because something about our process deletes some file?
| |
18:29 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
18:32 | <vagrantc> alkisg: the one reason i'd suggest using files instead of sed, would be if some other thing wanted to check what version was available without sourcing common-functions ...
| |
18:32 | alkisg: i.e. ltsp-info could check what version a chroot was
| |
18:33 | or what versions multiple chroots were ...
| |
18:34 | but it is more to keep track of
| |
18:35 | also, i.e. python, shell, c could all read the same file
| |
18:35 | <alkisg> (08:28:51 μμ) vagrantc: this happens because something about our process deletes some file? => no that was in ldm-trunk
| |
18:36 | (08:35:23 μμ) vagrantc: also, i.e. python, shell, c could all read the same file => good point
| |
18:37 | Although .c files would need it in a #define format, not in a VERSION=xxx format
| |
18:38 | And .py would probably need it in an __init__.py file, as __version etc etc
| |
18:38 | <vagrantc> if it were just a file that contained the version, it would be easy enough to read
| |
18:39 | <alkisg> I think that's what makefiles are for... to replace version in source files
| |
18:39 | .h in C, .py in python, .sh in shell
| |
18:40 | I.e. maybe it makes more sense to leave it inside the source file, and when needed, create a makefile for other languages
| |
18:41 | So when needed, we'd have __init__.py.in, config.h.in, and ltsp-common-functions.in
| |
18:41 | <vagrantc> but that doesn't allow things we don't build from source to read the version ... maybe ldm would want to know what version of ltsp, for example...
| |
18:42 | <alkisg> chroot $ROOT ltsp-info --version
| |
18:42 | <vagrantc> doesn't work cross-arch
| |
18:42 | <alkisg> True...
| |
18:42 | <vagrantc> or chrootless
| |
18:43 | <alkisg> OK I agree for a shell file with VERSION=number, and when other languages need it we'll see
| |
18:43 | <vagrantc> i think creating stubs for python and c are needlessly complicated
| |
18:44 | VERSION= shouldn't be hard to parse out in any language
| |
18:44 | so shell can simply source, and other languages can do what they need to do
| |
18:45 | <alkisg> I think compiled languages usually embed the version, so that tools like modinfo can read it without running the executables... but ok that doesn't matter much, we'll see then
| |
18:45 | <vagrantc> although having server-side stuff possibly reset the VERSION= variable when reading client-side stuff ... need to pay some attention to that
| |
18:46 | no idea how extensively this will be used
| |
18:46 | really, iw as hoping to just upload and run :)
| |
18:47 | <alkisg> sed is fine, we don't have to solve the version problem right now
| |
18:47 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 272 seconds) | |
18:48 | <alkisg> It was hardcoded until a couple of weeks ago, no need to change it now :)
| |
18:48 | We can do all those ^ nice things in ltsp 6...
| |
18:51 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
18:55 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Client Quit) | |
18:58 | <vagrantc> suppose so
| |
18:58 | alkisg: what triggered the change at all? old versions of help2man? like in precise/wheezy?
| |
18:59 | alkisg: or more like lucid/squeeze/lenny ?
| |
19:00 | <alkisg> vagrantc: help2man in lenny, but --version is mandatory by gnu anyway
| |
19:01 | About debian vs upstream version again, another reason to use the debian version is because our man pages may be different between distros
| |
19:01 | (some things may only be supported in some of the distros)
| |
19:03 | <vagrantc> makes sense
| |
19:04 | how do we get help2man working correctly during the build? there are all sources of files sourced that have full paths, no?
| |
19:04 | i mean, i've seen it work, but it surprises me
| |
19:05 | <alkisg> knipwim put an "if /usr/share/ltsp/* exists, source it, else try in ../../*" logic
| |
19:06 | ...the other way around more probably, relative first
| |
19:17 | adrianorg has left IRC (adrianorg!~adrianorg@179.187.25.54.dynamic.adsl.gvt.net.br, Read error: Connection reset by peer) | |
19:19 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection) | |
19:22 | adrianorg has joined IRC (adrianorg!~adrianorg@179.180.165.49) | |
19:23 | * vagrantc glares as ALTLinux and nbd-proxy | |
19:27 | <vagrantc> if systemd does land as the default init for debian... i hope they provide an /sbin/init ...
| |
19:27 | upstart works like that, yes?
| |
19:28 | otherwise, we'll need to rethink how init=/sbin/init-ltsp works...
| |
19:28 | <ogra_> they provide everything
| |
19:28 | you cant even use syslog anymore once you have systemd
| |
19:29 | (crond, inetd, tftpd, syslog, dbus, init, udev ... are all swallowed by systemd, most cant be replaced with anything else without heavy investment to cut down systemd)
| |
19:30 | (dbus = system dbus here)
| |
19:32 | <vagrantc> yes, i'm not really pleased with seemingly overly tight coupling/bundling of so much functionality
| |
19:32 | <ogra_> yup
| |
19:32 | and it indeed completely ties you to the kernel version through kdbus
| |
19:33 | <vagrantc> the whole debate is tiresome
| |
19:33 | <ogra_> it is ...
| |
19:33 | cliebow has joined IRC (cliebow!~cliebow@WatchGuard.ellsworth-hs.ellsworth.k12.me.us) | |
19:34 | <ogra_> what bothers me is that something like running debian on top of a 3.0 android kernel will become impossible
| |
19:34 | (well, unless you patch the needed bits into the kernel etc)
| |
19:38 | awilliams has left IRC (awilliams!~awilliams@unaffiliated/mistik1, Ping timeout: 272 seconds) | |
20:03 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Computer has gone to sleep.) | |
20:59 | Patina has left IRC (Patina!~tomas@dhcp-5-103-105-144.seas-nve.net, Ping timeout: 252 seconds) | |
21:00 | <vagrantc> alkisg: well, that didn't appear to work
| |
21:00 | alkisg: the substitutions didn't take ...
| |
21:00 | jammcq has left IRC (jammcq!~jam@c-69-245-75-255.hsd1.mi.comcast.net, Quit: WeeChat 0.3.7) | |
21:00 | <vagrantc> probably some weird makefile/shell quoting issues
| |
21:13 | vmlintu has left IRC (vmlintu!~vmlintu@nblzone-240-143.nblnetworks.fi, Ping timeout: 265 seconds) | |
21:29 | Patina has joined IRC (Patina!~tomas@dhcp-5-103-105-144.seas-nve.net) | |
21:31 | Parker955_Away has joined IRC (Parker955_Away!~parker@74.112.203.151) | |
21:35 | khildin has left IRC (khildin!~khildin@ip-213-49-84-175.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
21:50 | gdi2k_ has joined IRC (gdi2k_!~gdi2k@120.28.223.155) | |
21:54 | gdi2k has left IRC (gdi2k!~gdi2k@112.198.244.25, Ping timeout: 272 seconds) | |
22:06 | gbaman has left IRC (gbaman!~gbaman@host81-134-114-61.in-addr.btopenworld.com, Remote host closed the connection) | |
22:16 | gbaman has joined IRC (gbaman!~gbaman@host81-134-114-61.in-addr.btopenworld.com) | |
22:47 | awilliams has joined IRC (awilliams!~awilliams@unaffiliated/mistik1) | |
22:48 | * vagrantc sighs | |
22:48 | <vagrantc> i spend hours and hours trying to get this code to build with the new version code sedded in...
| |
22:48 | and the manpages still include the wrong version string.
| |
22:49 | the worst is, i still don't even know what actually fixed it....
| |
22:49 | well, "fixed" it.
| |
22:51 | the manpages are generated before we fix the version
| |
22:51 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 264 seconds) | |
22:52 | <vagrantc> and use the in-source copy rather than the version in the package
| |
22:54 | willianmazzardo has joined IRC (willianmazzardo!~textual@187.4.15.116) | |
23:02 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
23:02 | willianmazzardo has left IRC (willianmazzardo!~textual@187.4.15.116, Quit: Textual IRC Client: http://www.textualapp.com/) | |
23:12 | awilliams has left IRC (awilliams!~awilliams@unaffiliated/mistik1, Ping timeout: 246 seconds) | |
23:18 | gbaman has left IRC (gbaman!~gbaman@host81-134-114-61.in-addr.btopenworld.com, Remote host closed the connection) | |
23:22 | <vagrantc> well, that's no fun.
| |
23:22 | meh.
| |
23:23 | whole day spent supporting an ancient version of debian that i don't have any interest in, and still no ltsp upload :(
| |
23:52 | gbaman has joined IRC (gbaman!~gbaman@host81-134-114-61.in-addr.btopenworld.com) | |
23:53 | gbaman has left IRC (gbaman!~gbaman@host81-134-114-61.in-addr.btopenworld.com, Client Quit) | |