IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 2 September 2015 (all times are UTC)
| 00:50 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 240 seconds) | |
| 00:54 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 00:55 | dgroos has joined IRC (dgroos!~dgroos@mail.troop187.org) | |
| 01:28 | AlexPortable has left IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-vnsnhecartnmzzov, Quit: Connection closed for inactivity) | |
| 02:05 | <dgroos> My ltsp-pnp clients are now booting. That is good!
| |
| 02:06 | I use powerbroker for AD binding and during login, things are confusing:
| |
| 02:08 | On the one hand, a student attempts to login, a terminal screen is briefly shown, and they are returned to the login screen (here’s the terminal message: http://ibin.co/2EDD519nwZjN
| |
| 02:10 | On the other hand, when I look in /home I see that login at least partly succeeded since students now have a home directory—though only with 3 items.
| |
| 02:11 | Based on the briefly visible terminal screen linked above, I thought that the Cisco AnyConnect software might be causeing problems—make sense?
| |
| 02:12 | <maldridge> that looks much more like the final outputs from the terminal booting up, are you sure that the system has a graphical environment available?
| |
| 02:13 | <dgroos> So, I searched for the name of the cisco package/s so I could use the RM_SYSTEM_SERVICES option in lts.conf so that it wouldn’t be copied to the client…
| |
| 02:13 | maldridge: hi!
| |
| 02:13 | <maldridge> greetings
| |
| 02:14 | <dgroos> Well, some more strange stuff…
| |
| 02:15 | my test user is able to boot in unity—worked last night, and this user does go through AD, too. But…
| |
| 02:16 | Something different—When I first logged in last night with the test user, I left the session in it’s default settings, flashback maybe or fallback (which I had installed).
| |
| 02:17 | I wonder if a user first logs in with a flashback session, they are there-after able to log in with the ubuntu/unity session.
| |
| 02:17 | is that possible?
| |
| 02:18 | <maldridge> well, one thing that will kill the ability to login is a lack of home folder
| |
| 02:18 | <dgroos> I should have tried logging in with a different test user with flashback…
| |
| 02:18 | <maldridge> are your users home folders being mounted from the network
| |
| 02:18 | ?
| |
| 02:18 | <dgroos> No, they are on the ltsp server.
| |
| 02:19 | isn’t a home folder created upon first login?
| |
| 02:19 | <maldridge> not generally
| |
| 02:19 | you'd need pam_mkhome for that, but iirc ltsp short circuits around the pam stack
| |
| 02:21 | <dgroos> That’s right! I remember that there is some preference in powerbroker I need to set so as home folders are created…
| |
| 02:22 | hmmm… I’ll check that out tomorrow, as well as trying to log in first with the flashback session.
| |
| 02:22 | So you think it has nothing to do with the cisco program?
| |
| 02:22 | <maldridge> yeah, I'm not really familiar with powerbroker, but home folders is my guess
| |
| 02:23 | flashback might be actually making folders, that isn't really standard; No, I don't think it has to do with the cisco program
| |
| 02:24 | <dgroos> OK, I’ll check the docs for powerbroker tonight. I’ll let you know what I find out tomorrow. Gracias again for you help.
| |
| 02:26 | <maldridge> cool, I've not played with powerbroker, we ditched our windows domain this last summer; I'm interested to know how it works
| |
| 02:26 | it could be quite good with ltsp
| |
| 02:28 | <dgroos> I used its previously-branded “likewise-open” version since 2010. I really like it since I don’t have to deal with student learning a new log in/dealing with forgotten passwords etc.
| |
| 02:44 | dgroos_ has joined IRC (dgroos_!~dgroos@vpn.mpls.k12.mn.us) | |
| 02:46 | dgroos has left IRC (dgroos!~dgroos@mail.troop187.org, Ping timeout: 246 seconds) | |
| 02:46 | dgroos_ is now known as dgroos | |
| 03:31 | dgroos has left IRC (dgroos!~dgroos@vpn.mpls.k12.mn.us, Ping timeout: 268 seconds) | |
| 03:59 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |
| 04:31 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 04:32 | telex has joined IRC (telex!teletype@94.247.40.156) | |
| 05:00 | ltsp has left IRC (ltsp!~pe-LTSP@76-10-176-231.dsl.teksavvy.com, Remote host closed the connection) | |
| 05:03 | ricotz has joined IRC (ricotz!~rico@p5B2A82A5.dip0.t-ipconnect.de) | |
| 05:03 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
| 05:10 | work_alkisg is now known as alkisg | |
| 06:51 | vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi) | |
| 08:33 | khildin has joined IRC (khildin!~khildin@ip-213-49-84-113.dsl.scarlet.be) | |
| 08:33 | <alkisg> Guys, https://bugs.launchpad.net/ltsp/+bug/1352038 needs an SRU, if anyone is using Ubuntu 14.04 (I'm still on 12.04) then do the SRU request because ltsp-pnp will not work with 14.04.3
| |
| 08:34 | stgraber, do I have rights to upload a new ltsp version myself, or are you needed to approve the SRU? ^
| |
| 08:34 | (sorry, not a full new ltsp version, only the updated ltsp-update-image script from r2661)
| |
| 08:50 | vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi, Ping timeout: 252 seconds) | |
| 09:04 | mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk) | |
| 09:05 | alkisg is now known as work_alkisg | |
| 09:55 | NeonLicht has joined IRC (NeonLicht!~NeonLicht@darwin.ugr.es) | |
| 10:51 | telex has left IRC (telex!teletype@94.247.40.156, Ping timeout: 272 seconds) | |
| 10:52 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 11:41 | Faith has joined IRC (Faith!~paty@unaffiliated/faith) | |
| 12:08 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 12:10 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 12:19 | adrianorg has left IRC (adrianorg!~adrianorg@187.113.216.236, Ping timeout: 272 seconds) | |
| 12:21 | adrianorg has joined IRC (adrianorg!~adrianorg@201.22.230.187) | |
| 12:27 | uXus has left IRC (uXus!~uXus@217.77.222.72, Quit: ail bi bek) | |
| 12:29 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 12:32 | uXus has joined IRC (uXus!~uXus@217.77.222.72) | |
| 12:34 | F-GT has left IRC (F-GT!~phantom@ppp121-44-204-54.lns20.syd7.internode.on.net, Read error: No route to host) | |
| 12:36 | <vagrantc> work_alkisg:
| |
| 12:37 | work_alkisg: looking at ltsp-update-image ... does it do any bind mounts anymore? you added comments about bind mounts
| |
| 12:37 | F-GT has joined IRC (F-GT!~phantom@ppp121-44-204-54.lns20.syd7.internode.on.net) | |
| 12:53 | vmlintu has joined IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi) | |
| 13:10 | championofcyrodi has left IRC (championofcyrodi!~cott@50-205-35-98-static.hfc.comcastbusiness.net, Ping timeout: 265 seconds) | |
| 13:30 | work_alkisg is now known as alkisg | |
| 13:31 | <alkisg> Hi vagrantc
| |
| 13:32 | No, I completely skipped them since by doing it your way they weren't needed anymore
| |
| 13:32 | The lower layers are ro...
| |
| 13:32 | * vagrantc just tested out the new ltsp-update-image | |
| 13:32 | <vagrantc> ok, so it's just cruft in the comments about bind mounts, then
| |
| 13:32 | i thought so, so yay
| |
| 13:32 | <alkisg> Ah, I haven't removed those? Sorry
| |
| 13:33 | They were left over because I started with my previous revision
| |
| 13:33 | <vagrantc> right
| |
| 13:33 | no worries, it works. :)
| |
| 13:33 | <alkisg> With overlay(fs), it was possible to not see the work dirs at all, for them to be inside chroot/.work
| |
| 13:33 | And not see the tmp dir either, tmpdir=cowdir
| |
| 13:34 | <vagrantc> i should test with aufs too
| |
| 13:34 | <alkisg> I did some tests with aufs, it seemed to work
| |
| 13:34 | <vagrantc> ah, good.
| |
| 13:34 | <alkisg> With a separate /boot as well
| |
| 13:35 | <vagrantc> the module handling was a bit confusing ... first you check if it's already loaded... and prioritize modules already loaded?
| |
| 13:35 | <alkisg> Yup
| |
| 13:35 | <vagrantc> no idea how that will handle with built-ins.
| |
| 13:35 | <alkisg> So that we don't modify the server's modules
| |
| 13:35 | I'm using sys/module like you said, so it should be fine
| |
| 13:35 | overlay > overlayfs > aufs,
| |
| 13:35 | but if e.g. aufs is loaded and the others aren't, it's used instead
| |
| 13:36 | <vagrantc> ah, it only loads the module if one of the preferred modules isn't already loaded?
| |
| 13:36 | <alkisg> Right
| |
| 13:36 | E.g. suppose a server has aufs loaded and while it supports overlay, it doesn't have it loaded. We'll use aufs.
| |
| 13:36 | <vagrantc> although modprobe is confusing in that it's also used to check if the feature is enabled (module or otherwise)
| |
| 13:36 | <alkisg> So no modprobes/rmmods involved at all
| |
| 13:37 | No, modprobe isn't used to check if it's enabled
| |
| 13:37 | <vagrantc> but that's just weirdness in modprobe
| |
| 13:37 | <alkisg> I use sys/module there
| |
| 13:37 | modprobe overlayfs in ubuntu says "ok" but loads "overlay" instead
| |
| 13:37 | So it was useless for checking
| |
| 13:37 | <vagrantc> sure
| |
| 13:38 | so the only question remaining, which isn't a huge deal, is how it behaves if aufs/overlay(fs) are built-in rather than modules.
| |
| 13:38 | <alkisg> The same, afaik
| |
| 13:38 | For which part are you worried?
| |
| 13:39 | <vagrantc> weather it leaves /sys/module/$X where X is a builtin
| |
| 13:39 | er, weather it exists
| |
| 13:40 | <alkisg> I think `ls /sys/module` shows that all build-ins are there
| |
| 13:40 | # We also want to bind-mount whatever submounts the chroot has, e.g. /boot. ==> # We also want to mount whatever submounts the chroot has, e.g. /boot.
| |
| 13:41 | <vagrantc> alkisg: sounds good.
| |
| 13:42 | alkisg: i see at least one built-in that is listed in /sys/module so yeah, that should work. and it's a fairly unlikely case... most distros build those as modules as far as i know
| |
| 13:42 | <fiesh> is there a way to make ldm log more verbosely? I do not understand why the ssh times out, and it doesn't tell me any more
| |
| 13:42 | <vagrantc> alkisg: you want the honors of committing it?
| |
| 13:43 | <fiesh> tcpdump would be my only hope to find out something otherwise
| |
| 13:43 | <alkisg> vagrantc: the "bind" part? haha, if you allow me a --overwrite :P You'd do one uncommit and then pull :)
| |
| 13:43 | fiesh: try ssh user@server from screen_02
| |
| 13:43 | !screen_02
| |
| 13:43 | <ltsp`> screen_02: To get a root shell on an Ubuntu thin client: https://help.ubuntu.com/community/UbuntuLTSP/ClientTroubleshooting#Using_a_shell_SCREEN
| |
| 13:43 | <vagrantc> alkisg: i'd rather see a fixup commit :P
| |
| 13:43 | <fiesh> normal ssh works just fine
| |
| 13:44 | <alkisg> fiesh: replace "user" with an existing username, and leave "server" exactly as it is, don't put the server hostname there
| |
| 13:44 | <fiesh> oh
| |
| 13:44 | <alkisg> When you try that, tell me if you saw any warnings about keys
| |
| 13:44 | <fiesh> where is "server" supposed to be defined, in /etc/hosts?
| |
| 13:44 | <alkisg> vagrantc: haha ok, is that all?
| |
| 13:44 | fiesh: ltsp automatically puts it in /etc/hosts while the client boots
| |
| 13:44 | <fiesh> ah, ok, thanks!
| |
| 13:45 | I'll try really quickly..
| |
| 13:45 | <vagrantc> alkisg: there was an ltsp-config --overwrite patch phantomas proposed, i think ... i haven't checked it over yet
| |
| 13:45 | i'll also look through some of the other bugs, but otherwise am ready to commit
| |
| 13:45 | <alkisg> OK that's a different issue, I meant with ltsp-update-image, e.g. bad english language in the comments or something...
| |
| 13:45 | <vagrantc> alkisg: nothing that jumped out at me
| |
| 13:45 | <alkisg> Cool
| |
| 13:47 | <vagrantc> hrm. ltsp-config --overwrite works for me ...
| |
| 13:47 | <fiesh> hmm ok, it tries to add the server ECDSA host key to .ssh/known_hosts
| |
| 13:47 | so I guess the key isn't known to the client, which is surprising to me, because the old (working) image's /etc and the new image's /etc don't really differ
| |
| 13:47 | <alkisg> fiesh: now switch to vt7 and try to login again
| |
| 13:48 | <vagrantc> ah, the --overwrite issue was specific to ltsp-config nbd-server
| |
| 13:48 | <fiesh> in particular their /etc/ssh/ssh_known_hosts are the same
| |
| 13:49 | <alkisg> vagrantc: pushed
| |
| 13:50 | <vagrantc> alkisg: thanks.
| |
| 13:50 | <fiesh> aha! fuck my life... there are two keys in ssh_known_hosts, one the ecdsa key, and the dss key -- and it seems the update from ssh 6.7 to 6.9 changed the behavior somehow to make it care about that, because it finds one conflicting and the other not
| |
| 13:51 | alkisg: thanks, now I can fix this
| |
| 13:51 | <alkisg> fiesh: you're welcome
| |
| 13:52 | vagrantc: do you want us to have a quick look at the bugs list, in case we can solve something quickly before releasing?
| |
| 13:53 | ben_roose has joined IRC (ben_roose!~roose@roose.cs.wichita.edu) | |
| 13:55 | <maldridge> alkisg: not sure if you read all your scrollback, but was there a better way to solve dgroos tftp issue?
| |
| 13:55 | <vagrantc> alkisg: it'd be good
| |
| 13:55 | https://bugs.launchpad.net/ltsp/+bug/1273680
| |
| 13:55 | one-liner patch
| |
| 13:55 | not sure i have a jetpipe setup to test...
| |
| 13:56 | https://bugs.launchpad.net/ltsp/+bug/1487333
| |
| 13:56 | <alkisg> maldridge: ltsp-pnp uses dnsmasq for tftp, not tftpd-hpa, so they probably conflict with each other
| |
| 13:56 | <vagrantc> the ltsp-config --overwrite nbd-server ... onyl concern is that it might needlessly overwrite /etc/nbd-server/config
| |
| 13:57 | <maldridge> alkisg: given that he had no process running for tftp, is there something to configure dnsmasq automagically for ltsp and/or start it?
| |
| 13:57 | <vagrantc> https://bugs.launchpad.net/ltsp/+bug/1483682
| |
| 13:57 | <alkisg> maldridge: the instructions are in the ltsp-pnp page that dgroos had already followed
| |
| 13:57 | !ltsp-pnp
| |
| 13:57 | <ltsp`> ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
| |
| 13:57 | <vagrantc> poweroff/reboot issues in ubuntu
| |
| 13:58 | <alkisg> maldridge: he probably missed doing the "disable ubuntu's internal dnsmasq" steps or something
| |
| 13:58 | vagrantc: that last one will be hard to solve
| |
| 13:58 | <maldridge> ah
| |
| 13:59 | <alkisg> vagrantc: I know exactly what needs to be done, and why it fails, but I don't know how to tell systemd to run the code at the appropriate point
| |
| 13:59 | <vagrantc> alkisg: i'm fine with putting it off
| |
| 13:59 | <alkisg> Cool, let's postpone that one
| |
| 14:00 | About jetpipe, I don't have a working setup either, let's ask in the channel... :)
| |
| 14:00 | GUYS IS SOMEONE USING PRINTER=xxx IN LTS.CONF, SO THAT HE CAN TEST A ONE-LINE PATCH? https://bugs.launchpad.net/ltsp/+bug/1273680
| |
| 14:00 | <vagrantc> heh
| |
| 14:01 | * alkisg feels his vocal chords stressed after so much yelling :P :D | |
| 14:01 | <vagrantc> well, as long as we can start jetpipe ... we can test if NMAP crashes it ...
| |
| 14:01 | i guess we can't test that it doesn't break printing, though
| |
| 14:02 | * alkisg doesn't see anything urgent+easy in https://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;dist=unstable;archive=0;src=ltsp;repeatmerged=0 ... | |
| 14:03 | <alkisg> LP #816139 Kiosk mode fails when using generated xorg.conf ==> I think this one can be solved by using a relative path
| |
| 14:03 | * vagrantc wonders how many of those "fix committed" bugs are released | |
| 14:04 | <alkisg> vagrantc, usually I'm changing those to "fix released" when you release them in debian
| |
| 14:04 | <vagrantc> alkisg: relative to what
| |
| 14:04 | <alkisg> Relative to PWD
| |
| 14:05 | I.e. instead of /path/to/xorg.conf, to use something like ../path/to/xorg.conf
| |
| 14:05 | <vagrantc> yeah, i think X has silly ideas about the security of relative paths...
| |
| 14:06 | <alkisg> Related, I think that xorg in debian runs as the user with kms drivers, and as root with non-kms ones
| |
| 14:06 | So to reproduce it one would need a kms driver
| |
| 14:06 | <vagrantc> easy enough to test https://bugs.debian.org/785636
| |
| 14:07 | dbus dependency for SCREEN_XX to work
| |
| 14:07 | well, in the near future, X should run as a user in all cases ... seem to recall hearing about that at debconf
| |
| 14:09 | <alkisg> That will break the kiosk login in all cases :D
| |
| 14:09 | <vagrantc> wheee
| |
| 14:11 | https://bugs.launchpad.net/ltsp/+bug/1300728 some quoting issue in LDM?
| |
| 14:11 | * alkisg was reading that one now... | |
| 14:12 | <alkisg> I think he just misunderstood the code
| |
| 14:12 | The unlocking is not working because of pam, not because of that
| |
| 14:12 | I'm marking it as invalid
| |
| 14:13 | ...or ok as incomplete to be less rude :)
| |
| 14:13 | mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving) | |
| 14:14 | championofcyrodi has joined IRC (championofcyrodi!~cott@50-205-35-98-static.hfc.comcastbusiness.net) | |
| 14:14 | AlexPortable has joined IRC (AlexPortable!uid7568@gateway/web/irccloud.com/x-xuztxchcqskbmcsh) | |
| 14:16 | <alkisg> lauri: ping?
| |
| 14:16 | <vagrantc> i'd say invalid, because it's actually a problem in another system entirely... maybe include a link to the LDM_HASH_PASS stuff or something?
| |
| 14:17 | <alkisg> It won't solve the unlocking problem
| |
| 14:17 | I did mark it invalid though
| |
| 14:17 | * alkisg checks the locale a-z issue, https://bugs.launchpad.net/ltsp/+bug/1491066 | |
| 14:17 | <vagrantc> maybe it was a thin client?
| |
| 14:18 | i guess i'd better enable estonian on my LTSP server :)
| |
| 14:18 | <alkisg> I think it's lightdm that unlocks the keyring, so using su or ssh won't cut it
| |
| 14:20 | We could probably fool pam_gnome_keyring so that it thinks that su/ssh is lightdm that calls it, but I don't think it's trivial
| |
| 14:24 | for SCRIPT in $(find -L $RCDIRS -type f -name "$SCRIPTS" -printf '%f\n' |
| |
| 14:24 | tr ' ' '\n' | egrep ^[0-9a-zA-Z_\-]*$ | sort -u)
| |
| 14:24 | Hmm that could sort them the wrong way, messing up everything...
| |
| 14:27 | Although the effect would be limited to X50-<here>, i.e. the possibly wrong sorting would come after the X50- part
| |
| 14:28 | <vagrantc> we really need predictible sorting rules...
| |
| 14:31 | <alkisg> Actually we shouldn't rely on sorting after the numeric part
| |
| 14:32 | We currently do, but I think that's bad, if one renames the script after the numeric part it can break it
| |
| 14:32 | <vagrantc> how would you not rely on sorting?
| |
| 14:33 | <alkisg> Example: /usr/share/ldm/rc.d/X50-generate-env needs to be ran after /usr/share/ldm/rc.d/X50-dmrc-processing
| |
| 14:33 | So it should be X51-generate-env instead
| |
| 14:34 | Saying "50" there should mean "I don't care if it runs in parallel with all the other 50's"
| |
| 14:34 | <vagrantc> all of our code is sequential
| |
| 14:35 | what i don't want is to have to renumber the scripts all the time...
| |
| 14:35 | i guess there might be some cod ethat could run in parallel... but we're nowhere near implementing anything like that
| |
| 14:36 | <alkisg> I think the numbers there are supposed to change when something relies on something else
| |
| 14:38 | <vagrantc> if we're going to switch to dependency based, we should drop numbered ordering entirely
| |
| 14:38 | <alkisg> No, I mean that the number ordering doesn't imply letter ordering too
| |
| 14:38 | Let me find a better example...
| |
| 14:39 | <vagrantc> i think i understand what you're saying, it would just be a lot of code to implement
| |
| 14:39 | <alkisg> No I'm not expressing it correctly, I don't want to run things in parallel (which would btw be just a couple of lines of code), I just want the numbers to mean something
| |
| 14:40 | <vagrantc> well, i would rather avoid numbers entirely
| |
| 14:40 | if you're going to go to such lengths
| |
| 14:40 | they're a lazy way of defining code ordering, and prone to huge amounts of rewriting
| |
| 14:41 | <alkisg> Suppose some software defines that other packages can drop configuration at /etc/program.d/
| |
| 14:41 | And it says, 20- is for packages, 50- for the sysadmin etc
| |
| 14:42 | Well, 20- means that you don't have any guarantee that your script will run before or after other scripts from other packages
| |
| 14:42 | but you do have a guarantee that it will run before the sysadmin scripts
| |
| 14:42 | <vagrantc> sure
| |
| 14:42 | <alkisg> That's what I'm trying to say that I like it when "numbers have a meaning, but letters not"
| |
| 14:43 | <vagrantc> but such distinctions are silly ... if a sysadmin needs to run it during the "20" phase, then the whole thing breaks down
| |
| 14:43 | <alkisg> So for us, X50 would be some specific step, but we wouldn't go to such lengths as to implement dependency checking...
| |
| 14:44 | <vagrantc> for, say, configuration files, that can make sense, but for arbitrary hooks, not so much
| |
| 14:45 | <alkisg> In the end what I'm asking is to increase the number when something significant happens, e.g. "passwd is ready" or "home/username is mounted"
| |
| 14:45 | Anyway, it's not a big deal. For now we do need letter ordering as well though.
| |
| 14:46 | So changing a-z to [:alpha:] isn't enough... we'd need to temporarily unset LANGUAGE, LC_ALL, and set LANG=C.UTF-8
| |
| 14:46 | RIght?
| |
| 14:46 | <vagrantc> but the interoperability in those numbers can be nightmarish ... if ltsp and ltspfs have ldm hooks ... getting all the numbers to line up correctly can result in a domino effect
| |
| 14:47 | alkisg: forcing the locale to C.UTF-8 seems the sanest approach to me.
| |
| 14:47 | alkisg: or *maybe* C if there's some worry about backportability
| |
| 14:47 | Faith has left IRC (Faith!~paty@unaffiliated/faith, Quit: Saindo) | |
| 14:47 | * vagrantc isn't sure how new C.UTF-8 is | |
| 14:47 | <alkisg> I think we tried it in wheezy and it was there
| |
| 14:47 | <vagrantc> works for me, then.
| |
| 14:51 | * vagrantc will commit the patch to ltsp-config but leaving nbd-server/config alone. | |
| 14:57 | <stgraber> alkisg: try to upload it, if it doesn't let you, let me know and I'll sponsor
| |
| 14:58 | <alkisg> stgraber: can I file the SRU and also do the upload, or it'd better be done by 2 different people?
| |
| 14:58 | The verification step would be done by dgroos, not by me, of course...
| |
| 14:58 | <stgraber> alkisg: you can, I usually do that when fixing my bugs :)
| |
| 14:59 | <alkisg> Hehe, nice
| |
| 14:59 | <stgraber> alkisg: even validation can be done by the uploader nowadays, otherwise most SRU would be stuck in -proposed :(
| |
| 14:59 | let me know when it's uploaded and I'll review it in the queue and if all good, let it into -proposed
| |
| 14:59 | <alkisg> Thanks, I'll wait for a while in order to get more people motivated to do SRUs, but if noone does it, I'll do it myself later on
| |
| 15:01 | * vagrantc is thinking about adding a recommends on dbus to resolve https://bugs.debian.org/785636 | |
| 15:02 | <vagrantc> technically, maybe it needs a depends ... and ltsp-client/ldm will pull in dbus anyways...
| |
| 15:03 | <alkisg> We don't actually need dbus though, do we?
| |
| 15:03 | <vagrantc> for SCREEN_XX to work with systemd, we do in debian.
| |
| 15:03 | <alkisg> Why?
| |
| 15:03 | <vagrantc> that's a more complicated question
| |
| 15:03 | <alkisg> Isn't that just a lame workaround that the bug reported found?
| |
| 15:04 | *reporter
| |
| 15:04 | <vagrantc> i guess a better workaround would be to implement screen scripts as systemd service files...
| |
| 15:04 | <alkisg> I think the problem there is that we don't support systemd properlyl
| |
| 15:04 | Right
| |
| 15:05 | The fact that installing dbus happens to mysteriously resolve the issue, doesn't sound like a good workaround...
| |
| 15:06 | So I'd say, leave the bug open and we'll re-check it after we properly support systemd. It's for ltsp-client-core without ltsp-client anyway, which isn't the default installation...
| |
| 15:06 | systemd supports services with instances, I think that's what we need for ltsp screens
| |
| 15:07 | Those will override the getty instances, so the problem will be solved properly
| |
| 15:07 | (we could also completely deprecate SCREEN_02=shell completely and replace it with ROOT_PASSWORD_HASH=xxx")
| |
| 15:11 | <vagrantc> alright, will keep the workaround out of the code, it's a smple workaround documented in the bug itself
| |
| 15:13 | khildin has left IRC (khildin!~khildin@ip-213-49-84-113.dsl.scarlet.be, Ping timeout: 265 seconds) | |
| 15:25 | khildin has joined IRC (khildin!~khildin@ip-80-236-242-25.dsl.scarlet.be) | |
| 15:50 | Faith has joined IRC (Faith!~paty@unaffiliated/faith) | |
| 16:20 | geekgirl has joined IRC (geekgirl!ce4a3d81@gateway/web/freenode/ip.206.74.61.129) | |
| 16:41 | <alkisg> vagrantc: I pushed fixes for LP #1491066 but I was in a bit of a hurry, so they need a review...
| |
| 16:41 | both ltsp + ldm
| |
| 16:41 | * alkisg waves | |
| 16:41 | alkisg is now known as work_alkisg | |
| 16:42 | * vagrantc will look | |
| 17:02 | Faith has left IRC (Faith!~paty@unaffiliated/faith, Quit: Saindo) | |
| 17:14 | geekgirl has left IRC (geekgirl!ce4a3d81@gateway/web/freenode/ip.206.74.61.129, Ping timeout: 246 seconds) | |
| 18:21 | F-GT has left IRC (F-GT!~phantom@ppp121-44-204-54.lns20.syd7.internode.on.net, Ping timeout: 250 seconds) | |
| 18:21 | F-GT has joined IRC (F-GT!~phantom@ppp121-44-204-54.lns20.syd7.internode.on.net) | |
| 19:09 | <vagrantc> work_alkisg: any reason why cleanup.d/50-update-kernels only runs update-kernels if /boot/pxelinux.cfg doesn't exist?
| |
| 19:09 | work_alkisg: seems like it should be safe to run in either case.
| |
| 19:18 | telex has left IRC (telex!teletype@freeshell.de, Remote host closed the connection) | |
| 19:20 | telex has joined IRC (telex!teletype@freeshell.de) | |
| 19:30 | khildin has left IRC (khildin!~khildin@ip-80-236-242-25.dsl.scarlet.be, Ping timeout: 244 seconds) | |
| 19:35 | <vagrantc> after applying phantomas's patch, i get noise every time i run ltsp-update-image about not overwriting the nbd config files...
| |
| 19:37 | TheProf has joined IRC (TheProf!~TheProf@76-10-176-231.dsl.teksavvy.com) | |
| 19:41 | work_alkisg is now known as alkisg | |
| 19:42 | <alkisg> vagrantc: about 50-update-kernels, that file should be deleted completely
| |
| 19:42 | I only wrote that because at the time you refused to do it on postinst
| |
| 19:42 | <vagrantc> i don't think we're doing it on postinst yet...
| |
| 19:43 | <alkisg> Right, I tried to convince you a couple times but we didn't reach a decision :)
| |
| 19:43 | <vagrantc> introduce some more bugs to convince me :P
| |
| 19:44 | <alkisg> Hehe
| |
| 19:44 | <vagrantc> honestly, i guess we should just do it from ltsp-client-core.postinst
| |
| 19:44 | <alkisg> Yup!!!! Finally!!! :)
| |
| 19:44 | <vagrantc> because how it happens now depends on if ltsp-client-core was installed before or after linux-image-*
| |
| 19:45 | which is stupid and confusing
| |
| 19:45 | though i really did like having it only in the image file...
| |
| 19:45 | <alkisg> Yup. But above that, cleanup is for cleaning up things, not for running update-kernels
| |
| 19:46 | Having it only in the image file is a big problem in some cases,
| |
| 19:46 | e.g. when ltsp-update-image -c path/to/vdi is used instead of /
| |
| 19:46 | ...at that example, I may want to directly serve the .vdi instead of cleaning it up...
| |
| 19:46 | <vagrantc> this feature i've been hearing about for years... :)
| |
| 19:47 | <alkisg> Serving a raw btrfs image doesn't need any new code....
| |
| 19:47 | (btrfs for compression, it could be ext4 too...)
| |
| 19:48 | ltsp-update-kernels currently will read pxelinux.cfg frominside it
| |
| 19:48 | I wrote that part of the code years ago, it's been functional ever since...
| |
| 20:12 | pumpkin time :)
| |
| 20:13 | alkisg is now known as work_alkisg | |
| 20:15 | * vagrantc waves | |
| 21:07 | TheProf has left IRC (TheProf!~TheProf@76-10-176-231.dsl.teksavvy.com) | |
| 21:10 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat) | |
| 21:14 | vmlintu has left IRC (vmlintu!~vmlintu@a91-152-200-13.elisa-laajakaista.fi, Ping timeout: 260 seconds) | |
| 21:45 | NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es, Ping timeout: 246 seconds) | |
| 22:11 | Freejack has left IRC (Freejack!~Freejack@unaffiliated/freejack, Read error: No route to host) | |
| 22:21 | dgroos has joined IRC (dgroos!~dgroos@vpn.mpls.k12.mn.us) | |
| 22:22 | ben_roose has left IRC (ben_roose!~roose@roose.cs.wichita.edu, Remote host closed the connection) | |
| 22:46 | dgroos has left IRC (dgroos!~dgroos@vpn.mpls.k12.mn.us, Quit: dgroos) | |
| 23:22 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving) | |