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


Channel log from 1 April 2012   (all times are UTC)

00:05alexqwesa has left IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net, Quit: Хана X'ам !!!)
00:34alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
00:55risca has joined IRC (risca!~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net)
00:55adrianorg_ has left IRC (adrianorg_!~adrianorg@187.115.106.11, Ping timeout: 245 seconds)
01:02adrianorg_ has joined IRC (adrianorg_!~adrianorg@177.18.182.89)
01:09mischko has joined IRC (mischko!~Scott@ip68-101-108-132.oc.oc.cox.net)
01:10mischko has left IRC (mischko!~Scott@ip68-101-108-132.oc.oc.cox.net, Read error: Connection reset by peer)
03:10risca has left IRC (risca!~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net, Quit: Lämnar)
03:19alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net)
03:25Parker955 is now known as Parker955_Away
04:49adrianorg_ has left IRC (adrianorg_!~adrianorg@177.18.182.89, Read error: Operation timed out)
05:02monteslu_ has joined IRC (monteslu_!~monteslu@ip68-109-174-213.ph.ph.cox.net)
05:06monteslu__ has left IRC (monteslu__!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 265 seconds)
05:16dead_inside has joined IRC (dead_inside!~dead_insi@host-98-127-5-151.grf-mt.client.bresnan.net)
05:41risca has joined IRC (risca!~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net)
06:48dead_inside has left IRC (dead_inside!~dead_insi@host-98-127-5-151.grf-mt.client.bresnan.net, Quit: Leaving...)
06:51komunista has left IRC (komunista!~slavko@adsl-195-168-227-135.dynamic.nextra.sk, Ping timeout: 260 seconds)
07:43risca has left IRC (risca!~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net, Quit: Lämnar)
07:50khildin has joined IRC (khildin!~khildin@ip-80-236-223-213.dsl.scarlet.be)
09:52komunista has joined IRC (komunista!~slavko@adsl-195-168-227-135.dynamic.nextra.sk)
10:25alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
10:50alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
10:53danishman has joined IRC (danishman!~kvirc@62.243.156.218)
10:58danishman has left IRC (danishman!~kvirc@62.243.156.218, Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/)
11:30adrianorg_ has joined IRC (adrianorg_!~adrianorg@186.215.22.99)
11:53khildin has left IRC (khildin!~khildin@ip-80-236-223-213.dsl.scarlet.be, Ping timeout: 246 seconds)
11:54khildin has joined IRC (khildin!~khildin@ip-80-236-223-213.dsl.scarlet.be)
12:19markit has joined IRC (markit!~marco@88-149-177-66.staticnet.ngi.it)
12:21komunista has left IRC (komunista!~slavko@adsl-195-168-227-135.dynamic.nextra.sk, Ping timeout: 252 seconds)
13:11adrianorg_ has left IRC (adrianorg_!~adrianorg@186.215.22.99, Ping timeout: 265 seconds)
13:54khildin has left IRC (khildin!~khildin@ip-80-236-223-213.dsl.scarlet.be, Ping timeout: 246 seconds)
14:11Parker955_Away is now known as Parker955
14:40komunista has joined IRC (komunista!~slavko@adsl-195-168-227-135.dynamic.nextra.sk)
15:22Parker955 is now known as Parker955_Away
15:57irule has joined IRC (irule!~irule@200.92.100.171)
16:05Parker955_Away is now known as Parker955
16:26Lns has left IRC (Lns!~Lns@pdpc/supporter/professional/lns, Quit: Leaving)
16:30khildin has joined IRC (khildin!~khildin@ip-80-236-223-213.dsl.scarlet.be)
16:36vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
16:38Parker955 has left IRC (Parker955!~parker@74.112.203.151, Quit: ZNC - http://znc.in)
16:40Parker955 has joined IRC (Parker955!~parker@74.112.203.151)
16:53
<vagrantc>
hrm. functions.d/DISTRO/* directly into /usr/share/ltsp ??
16:53
shouldn't it go into something like /usr/share/ltsp/functions.d ?
16:56alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
16:56
<vagrantc>
ah, i see, the functions.d stuff is just a single file.
16:56
seems like an unusual use of a .d infrastructure
16:56* alkisg waves
16:57
<markit>
hi alkisg :)
16:58
<vagrantc>
.d type things normally allow dropping an arbitrary number of things into them, that then get included...
16:58* vagrantc waves to alkisg
16:58alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
16:59
<knipwim>
still at the conference probably :)
16:59alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
16:59
<vagrantc>
heh
16:59
this seems like one file per tool ... which i wouldn't bother to call functions.d
17:00
i think it would be even more useful if we could actually implement more of a genuine .d structure
17:00
i guess i can implement that as part of each of debian's vendor-functions
17:01
<knipwim>
you mean like a file for each function?
17:01
<alkisg>
vagrantc: if functions.d is not a proper name, we can just rename it to plain functions/, only a packaging change will be needed, nothing in the binary file contents changes
17:02
I thought the .d part would also cover different tools, instead of different packages
17:02
<vagrantc>
it misled me as to what the actual purpose was at first glance
17:02* vagrantc notes that the ancient screen.d is another examplke of this sort of thing
17:03
<alkisg>
(08:00:19 μμ) vagrantc: i think it would be even more useful if we could actually implement more of a genuine .d structure ==> for the common functions, to be included by all tools?
17:03
<vagrantc>
for functions for specific things, that's not as useful.
17:05
so ltsp-server-vendor-functions is the vendor-specific parts that used to be ltsp-common-functions ?
17:05
<alkisg>
Yes, so that we don't need vendor detection in ltsp-server/client-functions, and the code is completely common there
17:05
<vagrantc>
and then i see a vendor-specific ltsp-chroot-functions ... is that for things that are just so vendor-specific there are no common functions?
17:06
<alkisg>
The common functions are needed by all tools
17:06
The tool specific functions only by one tool
17:06
<vagrantc>
yes, but why not ltsp-chroot-vendor-functions?
17:06
<alkisg>
That's a naming issue
17:07
...moment...
17:08
<vagrantc>
just want to make sure i'm not misunderstanding something... but at first glance it doesn't seem consistant
17:08
<alkisg>
The idea is that the functions of ltsp-tool can be contained inside ltsp-tool
17:08
You don't need an extra file, like ltsp-common-functions (for this tool's functions)
17:08
So the ltsp-info-functions would _only_ be vendor specific
17:09
<vagrantc>
ah, got it.
17:09
<alkisg>
But since the binary package will only contain one such file, no ltsp-info-functions AND ltsp-info-vendor-functions, there's no need to choose the longer file name
17:09
<vagrantc>
because the "common" functions go directly into the tool itself.
17:09
<alkisg>
We can't do that same thing with ltsp-server/client-functions because it's not a script, it's a library
17:09
<vagrantc>
makes sense.
17:09
<alkisg>
Right
17:10
We should make notes of all that, but where? In some part of the code, or in the wiki?
17:10
<vagrantc>
in the code, please.
17:11
<alkisg>
vagrantc: also, did you notice the problem with ldm and ltsp-common-functions?
17:11
<vagrantc>
maybe a README in the functions.d directory?
17:11
<alkisg>
http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk/revision/1427
17:12
<vagrantc>
i know there's an issue there, yes.
17:12
but that's a simple patch
17:12
<alkisg>
For the ltsp-common-functions => ltsp-[server/client]-functions rename to succeed, the packages should be uploaded simultaneously etc
17:12
<vagrantc>
sure.
17:12
<alkisg>
I think in the server/ dir I saw some notes file... /me checks...
17:13
ltsp-trunk/server/doc/
17:13
We have codingstyle and everything else there, maybe we can put a packaging-hints too?
17:14
...or a README, sure, that sounds good too
17:14
functions.d/README, it doesn't make packaging any harder
17:15
<vagrantc>
right, it's more a note to the packages
17:15
packagers
17:16
<alkisg>
Or a src-layout that describes what each dir contains, and packagers can understand how to handle it then
17:17
<vagrantc>
it's almost like we should review our documentation on many levels... :)
17:19
<alkisg>
Indeed, in the doc/ dir there are many advices that no longer apply
17:37
<vagrantc>
hrm? ltsp-server-functions sources both ltsp-server-vendor-functions and ltsp-client-vendor-functions ?
17:37
this doesn't really work with the problem of possibly having different versions installed...
17:41
to fix that, iguess we'd need a ltsp-server-functions/ltsp-client-functions wrapper that was aware of which it was trying to source...
17:41
with ltsp-server-base-functions and ltsp-client-base-functions
17:41
unless there's a way to tell which we're sourcing
17:42
<alkisg>
In bash one can tell the sourced script name from the script itself, but not from shell
17:43Parker955 has left IRC (Parker955!~parker@74.112.203.151, Quit: ZNC - http://znc.in)
17:43
<alkisg>
Also it shouldn't source both of them, just the first one it finds,
17:43
and of course if we can find a way to source the "correct" one, in case of version mismatches...
17:44Parker955 has joined IRC (Parker955!~parker@74.112.203.151)
17:44
<vagrantc>
alkisg: well, we'd have to add another layer ...
17:44
alkisg: i.e. ltsp-server-functions and ltsp-client-functions would diverge on which files they source.
17:45
<alkisg>
Also, some functions may be server specific, and some of the client specific
17:45
*them
17:45
So that layer could serve that purpose as well
17:45
<vagrantc>
so split ltsp-server-functions into a separate ltsp-server-base-functions, and then the only duplicate file would be ltsp-server-base-functions
17:46
<alkisg>
Right, and the vendor functions would be sourced from the new and small ltsp-server-functions
17:46
<vagrantc>
exactly.
17:46
and ditto for ltsp-client-functions/ltsp-client-base-functions
17:46
<alkisg>
Maybe name them ltsp-server-common-functions to resemble the old name?
17:47
Instead of -base...
17:47
<vagrantc>
sure.
17:47
should i "make it so" ?
17:48
<alkisg>
Sounds fine to me, please do
17:48* vagrantc also wants to rename functions.d to functions
17:48
<alkisg>
Sure
17:49
I think only knipwim will need a two-character change in his packaging for that, nothing else will be needed
17:51
vagrantc: would it make sense to put a common/ folder in the trunk?
17:51
With only one file there for now, and symlinks to that as we know them,
17:51
just to make it clearer that that file belongs to 2 packages, and in case more are needed later on...
17:52
common/ltsp-common-functions, server/@ltsp-server-common-functions, client/@ltsp-client-common-functions
17:54
<vagrantc>
the symlinks between these two.
17:54
the symlinks between client and server are confusing ...
17:55
that sounds a bit better, yes.
17:59
alkisg: so symlink to the common file, instead of symlinking from client -> server ?
18:03
<alkisg>
vagrantc: yup
18:06
<vagrantc>
pushed. hopefully i didn't bork it.
18:07
oh, i changed the order ... the tool functions come before the vendor-functions...
18:08
<alkisg>
It shouldn't really matter, the tools shouldn't ever override the common functions
18:08chrstphrchvz has joined IRC (chrstphrchvz!47157331@gateway/web/freenode/ip.71.21.115.49)
18:08
<alkisg>
It would become too complex then
18:08
<vagrantc>
yes.
18:09
could make the tool sourcing a function?
18:10
<alkisg>
vagrantc: err what?
18:10Parker955 is now known as Parker955_Away
18:11
<alkisg>
ltsp-info sources ltsp-server-functions which sources ltsp-server-common-functions and ltsp-info-functions
18:11
<vagrantc>
alkisg: could make the tool-sourcing code a function, that then gets executed last.
18:12
alkisg: but ltsp-vendor-functions gets sourced after ltsp-tool-functions
18:13
<alkisg>
OK gotcha, I misunderstood before, let me see...
18:13
<vagrantc>
if we *wanted* to make sure the tool, the most specific functionality, overrides all the rest, we could turn the ltsp-info-functions sourcing into a function that sources ...ltsp-tool-functions
18:13Parker955_Away is now known as Parker955
18:13
<vagrantc>
but that's probably overkill.
18:13
hopefully :)
18:15
<alkisg>
Yeah I think it's overkill, let's try not to rely on that ever
18:15
Function overriding should only happen for (tool => vendor) or (common => vendor), tools shouldn't ever have the same function names as common
18:16
<vagrantc>
so they could call their own *similar* function instead of overriding a common function.
18:17
<alkisg>
Ah the only time I can think it would matter is:
18:17
<vagrantc>
can't think of a use-case, but it is one difference from the previous commit i noticed that i just introduced...
18:18
<alkisg>
if ltsp-tool-functions had some code to be executed, not just functions,
18:18
then that code would probably rely on the overrides introduced in ltsp-server-vendor-functions
18:19
But we should avoid having code in ltsp-tool-functions too
18:27adrianorg_ has joined IRC (adrianorg_!~adrianorg@186.215.22.99)
18:28
<alkisg>
Btw why do we have lts.conf in ltsp/<arch>/lts.conf instead of in e.g. ltsp/lts.conf?
18:28
In which case would one need a different lts.conf per arch?
18:30
<Hyperbyte>
alkisg, when one wants to have different client settings for different architectures.
18:30
<alkisg>
Hyperbyte: ok, but why would one want that? What's an actual use case?
18:31
E.g. I boot a client as thin and I want a different resolution from when I boot it as fat?
18:31
<Hyperbyte>
alkisg, I understood the question, just messing with you. :P
18:31* Hyperbyte pokes alkisg ;-)
18:31
<alkisg>
:P /me just came from a conference and is multitasking too much to understand subtle humor, try something more verbose :P
18:32
<Hyperbyte>
OMG YOUR PANTS ARE ON FIRE!
18:33
<alkisg>
Haha that might have worked but on 1st April it's fool's day in Greece, noone would believe that :D
18:37toscalix has joined IRC (toscalix!~toscalix@52.176.219.87.dynamic.jazztel.es)
18:39
<chrstphrchvz>
Before I ask my question, I was thinking a similar thing about using multiple lts.conf files. I would like to have a multiarch deployment but it would make sense to have a single file, only specifying the arch of the client after it inherits with LIKE and before some last specs with its MAC. Though I can see it getting long for some deployments to navigate possibly.
18:40
<alkisg>
chrstphrchvz: it sounds like you have a complicated setup there. At some point in the future we'll redesign the ltsp configuration system, so, could you give us some of your extreme configuration cases?
18:40
I.e. where would you need LIKE, MAC and ARCH for the same client?
18:42
<chrstphrchvz>
I only have a few parameters that apply to all clients, e.g. VOLUME=100, and after the arch for a few groups of clients I would specify their resolutions, that's about it at the moment.
18:44
But in case I have any parameters I'd like for all clients, having one file removes a step, but I can see the inverse where someone wants a new parameter but only for x64 for example, wouldn't have to worry about specifying his clients' archs.
18:45
Anyways, heres's what I'd like help with. I am trying to setup LTSP in an enviroment requiring proxy DHCP and essentially 1 NIC. I started with Edubuntu 12.04 Beta 1 AMD64 default LTSP configuration, ran updates, and tried it out and it worked as-is...
18:46
When I remove the internal DHCP, add dnsmasq, following the Ubuntu comunity docs for latest versions available, I can get clients to load pxelinux.cfg/default off tftp, but they all end up with BusyBox (initramfs) prompt on terminal 1...
18:46
<stgraber>
alkisg: hey there, will you be around tomorrow to look at the current ltsp-trunk, release and look at the packaging changes we need for it?
18:47
<chrstphrchvz>
On terminal 7, after splash dissapears, it shows "Error: Socket failed: Connection refused Exiting." followed by mounts failing and "No init found."...
18:47
<alkisg>
stgraber: yes I'll be around my usual hours :)
18:47
<chrstphrchvz>
I have looked through what causes "Error: Socket failed..." and have only found issues relating to prior configurations (e.g. pertaining to 9.10) of inetd and nbd-server, e.g. which conf files should be present and specifying name exports vs ports. Can restart hardware, run sudo ltsp-update-sshkeys && sudo ltsp-update image -a i386 to no avail. Anything I should check?
18:47
<vagrantc>
alkisg: having the possibility of a different lts.conf for different chroots is useful if i have different versions of chroots hosted on the same server ...
18:47
alkisg: lts.conf options may change meaning or functionality between versions
18:48
<stgraber>
alkisg: cool :) there seems to be quite a few changes that happened recently so I want to take the time to review these and make sure we don't risk any regression as it's getting really late in the cycle now (next milestone is final release ...)
18:49
<alkisg>
stgraber: yup, understandable. Question about epoptes, we've fixed a few bugs and we've no known bugs left now, should we ask vagrantc for a new epoptes release asap, or should we wait for a while in case another bug report gets filed?
18:50
chrstphrchvz: sudo netstat -nap | grep 10809
18:50
<knipwim>
vagrantc: didn't you mean to source ltsp-client-vendor-functions in ltsp-client-functions?
18:51
<chrstphrchvz>
tcp 0 0 0.0.0.0:10809 0.0.0.0:* LISTEN 1836/nbd-server
18:51
<vagrantc>
knipwim: good catch! you want to commit or should i?
18:52
<knipwim>
i'll do it
18:52
<vagrantc>
i copied it (obviously) and then changed one entry but not the other.
18:54
<alkisg>
chrstphrchvz: on the client busybox: nbd-client server-ip -N ltsp_i386 /dev/nbd0
18:54
vagrantc: would you have time for an epoptes upload any time soon? (today is fine too, we only put a few bug fixes, no big changes this time... :D)
18:56
I can upload a changelog any time you want me too, I don't have any TODOs in my list, I was just waiting in case any other bugs were filed...
18:57vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Ping timeout: 276 seconds)
18:58
<chrstphrchvz>
alkisg: getaddrinfo failed: No address associated with hostname
18:58
<alkisg>
chrstphrchvz: ip, not name
18:58vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
18:58
<alkisg>
chrstphrchvz: what's your server's ip address?
18:59
<stgraber>
alkisg: Probably best to release a fixed version of epoptes so that more people can test without these bugs and maybe file some more
18:59
<alkisg>
(09:54:49 μμ) alkisg: vagrantc: would you have time for an epoptes upload any time soon? (today is fine too, we only put a few bug fixes, no big changes this time... :D)
18:59
(09:56:06 μμ) alkisg: I can upload a changelog any time you want me too, I don't have any TODOs in my list, I was just waiting in case any other bugs were filed...
18:59
(sorry if you already got them, I saw you got disconnected...)
18:59
stgraber: thanks :)
19:00
<knipwim>
vagrantc: i'll also rename client/functions.d to client/function
19:00
<vagrantc>
for init-ltsp.d we could include a common -> . and DISTRO -> . symlinks to check for breakages
19:00
<knipwim>
and resymlink to the server/functions
19:00
<vagrantc>
knipwim: i looked for that, and didn't see it. huh.
19:00
<chrstphrchvz>
alksig: Sorry, thought it would work with server-ip variable. Goes through now: Negotiation: ..size = 263MB bs=1024 sz=276709376 bytes
19:01
<vagrantc>
knipwim: thanks for the review :)
19:01
<knipwim>
np :)
19:01
<alkisg>
stgraber: we'll need http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk/revision/1427 in order to package the latest ltsp trunk, or we can commit a temporary workaround (source either ltsp-common-functions or ltsp-client-functions, whichever's available) in ltsp-trunk
19:01
<vagrantc>
alkisg: might be able to upload epoptes today or tomorrow
19:02
<alkisg>
vagrantc: thank you, I'll commit a changelog in a few minutes
19:02
chrstphrchvz: put this file to pastebin: /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default
19:03
<vagrantc>
hrm. epoptes has two more days to miggrate to testing :(
19:04
<alkisg>
vagrantc: we can wait, no problem
19:04
<vagrantc>
would be nice to get 0.5.1 into testing first
19:04
<alkisg>
Ah, unless you can't upload for the next week or so after tomorrow :)
19:04
<vagrantc>
alkisg: i can test it tomorrow and do a delayed upload.
19:04
<stgraber>
alkisg: that's ldm so we need vagrantc to upload that bit first then
19:05
<chrstphrchvz>
http://pastebin.com/BwSKtTLt
19:05
<vagrantc>
ltsp's also got two more days to hit testing ... i'd like to wait on ldm/ltsp uploads as well.
19:05
<alkisg>
chrstphrchvz: put this at a new line at the end of that file: ipappend 3
19:06
<vagrantc>
there are a lot of code changes with ltsp ...
19:07
<alkisg>
vagrantc: OK I'll have epoptes ready in a few minutes, and you can upload it in 2 days or whenever you have time, thank you
19:11
<chrstphrchvz>
Works, thank you very much. I though that following this https://help.ubuntu.com/community/UbuntuLTSP/ProxyDHCP#Adjusting_pxelinux.cfg.2BAC8-default_for_Ubuntu_10.04 would have placed the "ipappend 3" option in there.
19:11
<stgraber>
vagrantc: ok, then I'll probably cherry-pick that ldm-trunk commit and upload it as an ubuntu delta tomorrow until a new ldm hits Debian and I sync it
19:12
vagrantc: I really want ltsp uploaded tomorrow to maximize the testing time as it looks like ltsp-trunk changed quite a bit since the last upload :)
19:13
<vagrantc>
stgraber: sounds feasible.
19:13toscalix has left IRC (toscalix!~toscalix@52.176.219.87.dynamic.jazztel.es, Remote host closed the connection)
19:23
<alkisg>
vagrantc: done, epoptes should now be completely ready for the upload (after 2 days as we said)
19:45bobby_C has joined IRC (bobby_C!~bobby@188.20.161.210)
19:52komunista has left IRC (komunista!~slavko@adsl-195-168-227-135.dynamic.nextra.sk, Quit: Leaving.)
19:54_gentgeen_ has joined IRC (_gentgeen_!~kevin@c-98-236-71-64.hsd1.pa.comcast.net)
19:55
<vagrantc>
stgraber: you'll also need to update ltspfs, as well.
19:57
<stgraber>
vagrantc: right...
19:59
<vagrantc>
shouldn't require a new upstream version, just packaging changes
19:59
(although long-term, the new upstream version will likely require further packaging changes)
20:01
ditto for ldm, really.
20:09chrstphrchvz has left IRC (chrstphrchvz!47157331@gateway/web/freenode/ip.71.21.115.49)
20:10Parker955 is now known as Parker955_Away
20:17markit has left IRC (markit!~marco@88-149-177-66.staticnet.ngi.it, )
20:21risca has joined IRC (risca!~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net)
20:31khildin has left IRC (khildin!~khildin@ip-80-236-223-213.dsl.scarlet.be, Quit: I'm gone, bye bye)
20:32
<vagrantc>
meh. all these symlinks everywhere require everything to be manually installed :(
20:33
<alkisg>
Which symlinks?
20:33
<vagrantc>
client/ltsp-client-common-functions -> ../common/ltsp-common-functions
20:34
i have to manually mangle those in debian/rules.
20:34
because in the package, it should be a copy rather than a symlink
20:34* vagrantc suspected this would be an issue, but hoped for the best
20:34
<alkisg>
vagrantc: I think that debian/install copies symlinks
20:35
Not as symlinks, as files
20:35
<vagrantc>
alkisg: as symlinks.
20:35
alkisg: not on any debian package i've used in the last 10 years :P
20:35
alkisg: it definitely doesn't, this was a proof-of-fail test drive
20:37
i've already got to override dh_install anyways, so this will just be a little more complication
20:37
stgraber: heads up on that ... i wouldn't recommend uploading LTSP without testing
20:37* vagrantc wouldn't generally recommend that...
20:38
<stgraber>
vagrantc: yeah, so we basically need to rm the symlink and do a cp...
20:38
<vagrantc>
i'll just call install directly.
20:38
from debian/rules
20:39
then we can rename in place.
20:39
<stgraber>
alkisg: can I get ltsp-client-core to also cp that file to the good old ltsp-common-functions so that I don't need patching ldm/ltspfs just yet?
20:40
<vagrantc>
then you break the whole goal.
20:40
<stgraber>
no
20:40
<alkisg>
stgraber: that's what I proposed above, we can do a temporary workaround
20:40
<vagrantc>
ah, the server-side doesn't ship it...
20:40
<stgraber>
I would only ship it in ltsp-client-core, not ltsp-server
20:40
<alkisg>
So in the next ldm upload, you remove that from the packaging
20:40
<vagrantc>
that's a reasonable workaround ... would still need one-directional conflicts
20:40
<stgraber>
yeah, once we make sure nothing references -common-functions anymore, I can drop the line
20:47
<vagrantc>
we could either install directly in debian/rules, or copy somewhere in debian/rules and then remove in clean.
20:48
dunno which is less crazy.
20:50
<alkisg>
vagrantc: instead of removing the ltsp-client-common-functions symlink, why not put common/ltsp-common-functions in debian/install?
20:50
The symlink is not necessary in -trunk, it's just there as a reminder...
20:53
<vagrantc>
alkisg: because you can't rename files using dh_install
20:53
i'm not messing with the symlink, i'm installing directly in debian/rules
20:55
there are two approaches to this that i can think of ... install directly from debian/rules
20:55
or to copy and rename the files elsewhere and include them in debian/*.install, and remove them in the clean target.
20:56
<alkisg>
It sounds lame that one can't do that from a dh_helper
20:56
<vagrantc>
that it may be, but it's been that way for quite some time ...
20:57
dh_move* once existed, but got deprecated.
20:58
alkisg: the problem is a syntax which properly distinguishes between an installed directory and a rename
20:59
though really, it could just specify a compat level, and deal with it unambiguously...
20:59
by consistantly using trailing/prefixed slashes
21:15alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
21:31bobby_C has left IRC (bobby_C!~bobby@188.20.161.210, Ping timeout: 260 seconds)
21:55
<vagrantc>
ok, i've got a working ltsp package based off of ltsp-trunk
21:55
only bug is a simply change to ltspfs
22:21risca has left IRC (risca!~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net, Quit: Lämnar)
22:44
<vagrantc>
and ltspfs could probably be made to support both...
23:05enyc has joined IRC (enyc!~enyc@muddle.enyc.org.uk)
23:39klausade has joined IRC (klausade!~klaus@cm-84.215.157.180.getinternet.no)