IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 1 April 2012 (all times are UTC)
| 00:05 | alexqwesa has left IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net, Quit: Хана X'ам !!!) | |
| 00:34 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 00:55 | risca has joined IRC (risca!~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net) | |
| 00:55 | adrianorg_ has left IRC (adrianorg_!~adrianorg@187.115.106.11, Ping timeout: 245 seconds) | |
| 01:02 | adrianorg_ has joined IRC (adrianorg_!~adrianorg@177.18.182.89) | |
| 01:09 | mischko has joined IRC (mischko!~Scott@ip68-101-108-132.oc.oc.cox.net) | |
| 01:10 | mischko has left IRC (mischko!~Scott@ip68-101-108-132.oc.oc.cox.net, Read error: Connection reset by peer) | |
| 03:10 | risca has left IRC (risca!~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net, Quit: Lämnar) | |
| 03:19 | alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net) | |
| 03:25 | Parker955 is now known as Parker955_Away | |
| 04:49 | adrianorg_ has left IRC (adrianorg_!~adrianorg@177.18.182.89, Read error: Operation timed out) | |
| 05:02 | monteslu_ has joined IRC (monteslu_!~monteslu@ip68-109-174-213.ph.ph.cox.net) | |
| 05:06 | monteslu__ has left IRC (monteslu__!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 265 seconds) | |
| 05:16 | dead_inside has joined IRC (dead_inside!~dead_insi@host-98-127-5-151.grf-mt.client.bresnan.net) | |
| 05:41 | risca has joined IRC (risca!~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net) | |
| 06:48 | dead_inside has left IRC (dead_inside!~dead_insi@host-98-127-5-151.grf-mt.client.bresnan.net, Quit: Leaving...) | |
| 06:51 | komunista has left IRC (komunista!~slavko@adsl-195-168-227-135.dynamic.nextra.sk, Ping timeout: 260 seconds) | |
| 07:43 | risca has left IRC (risca!~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net, Quit: Lämnar) | |
| 07:50 | khildin has joined IRC (khildin!~khildin@ip-80-236-223-213.dsl.scarlet.be) | |
| 09:52 | komunista has joined IRC (komunista!~slavko@adsl-195-168-227-135.dynamic.nextra.sk) | |
| 10:25 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 10:50 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection) | |
| 10:53 | danishman has joined IRC (danishman!~kvirc@62.243.156.218) | |
| 10:58 | danishman has left IRC (danishman!~kvirc@62.243.156.218, Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/) | |
| 11:30 | adrianorg_ has joined IRC (adrianorg_!~adrianorg@186.215.22.99) | |
| 11:53 | khildin has left IRC (khildin!~khildin@ip-80-236-223-213.dsl.scarlet.be, Ping timeout: 246 seconds) | |
| 11:54 | khildin has joined IRC (khildin!~khildin@ip-80-236-223-213.dsl.scarlet.be) | |
| 12:19 | markit has joined IRC (markit!~marco@88-149-177-66.staticnet.ngi.it) | |
| 12:21 | komunista has left IRC (komunista!~slavko@adsl-195-168-227-135.dynamic.nextra.sk, Ping timeout: 252 seconds) | |
| 13:11 | adrianorg_ has left IRC (adrianorg_!~adrianorg@186.215.22.99, Ping timeout: 265 seconds) | |
| 13:54 | khildin has left IRC (khildin!~khildin@ip-80-236-223-213.dsl.scarlet.be, Ping timeout: 246 seconds) | |
| 14:11 | Parker955_Away is now known as Parker955 | |
| 14:40 | komunista has joined IRC (komunista!~slavko@adsl-195-168-227-135.dynamic.nextra.sk) | |
| 15:22 | Parker955 is now known as Parker955_Away | |
| 15:57 | irule has joined IRC (irule!~irule@200.92.100.171) | |
| 16:05 | Parker955_Away is now known as Parker955 | |
| 16:26 | Lns has left IRC (Lns!~Lns@pdpc/supporter/professional/lns, Quit: Leaving) | |
| 16:30 | khildin has joined IRC (khildin!~khildin@ip-80-236-223-213.dsl.scarlet.be) | |
| 16:36 | vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net) | |
| 16:38 | Parker955 has left IRC (Parker955!~parker@74.112.203.151, Quit: ZNC - http://znc.in) | |
| 16:40 | Parker955 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:56 | alkisg 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:58 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 16:59 | <knipwim> still at the conference probably :)
| |
| 16:59 | alkisg 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:43 | Parker955 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:44 | Parker955 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:08 | chrstphrchvz 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:10 | Parker955 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:13 | Parker955_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:27 | adrianorg_ 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:37 | toscalix 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:57 | vagrantc 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:58 | vagrantc 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:13 | toscalix 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:45 | bobby_C has joined IRC (bobby_C!~bobby@188.20.161.210) | |
| 19:52 | komunista 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:09 | chrstphrchvz has left IRC (chrstphrchvz!47157331@gateway/web/freenode/ip.71.21.115.49) | |
| 20:10 | Parker955 is now known as Parker955_Away | |
| 20:17 | markit has left IRC (markit!~marco@88-149-177-66.staticnet.ngi.it, ) | |
| 20:21 | risca has joined IRC (risca!~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net) | |
| 20:31 | khildin 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:15 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 21:31 | bobby_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:21 | risca 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:05 | enyc has joined IRC (enyc!~enyc@muddle.enyc.org.uk) | |
| 23:39 | klausade has joined IRC (klausade!~klaus@cm-84.215.157.180.getinternet.no) | |