IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 4 January 2014 (all times are UTC)
| 00:36 | imox has joined IRC (imox!~imox@p4FC5D2D7.dip0.t-ipconnect.de) | |
| 01:02 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 01:13 | imox has left IRC (imox!~imox@p4FC5D2D7.dip0.t-ipconnect.de, Quit: imox) | |
| 01:30 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 02:37 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Ping timeout: 272 seconds) | |
| 02:52 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
| 03:10 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 252 seconds) | |
| 03:29 | gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113) | |
| 04:03 | ogden has joined IRC (ogden!47514457@gateway/web/freenode/ip.71.81.68.87) | |
| 04:04 | <ogden> anyone on for a quick question?
| |
| 04:54 | ogden has left IRC (ogden!47514457@gateway/web/freenode/ip.71.81.68.87, Ping timeout: 272 seconds) | |
| 05:54 | mattcen has left IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au, Ping timeout: 240 seconds) | |
| 06:07 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
| 06:15 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 06:19 | <alkisg> vagrantc: hi! should I do the "symlinks to ltsp-update-kernels" change?
| |
| 06:20 | <vagrantc> alkisg: if you're up for it, otherwise i can hopefully do it in the next two days
| |
| 06:21 | <alkisg> Sure np, so, I'll just remove the kernel_links() function from update-kernels, add the INITRD_NAME variable to the .conf file, and then add some kernel_links() function to ltsp-update-kernels, ok?
| |
| 06:22 | <vagrantc> you'll need the initrd_name in the .conf file, no?
| |
| 06:22 | i.e. it's chroot-specific?
| |
| 06:22 | <alkisg> Yes, it's chroot specific
| |
| 06:22 | * vagrantc misread | |
| 06:22 | <alkisg> So I'll need either a variable or a function for it
| |
| 06:22 | <vagrantc> saw "and" instead of "add"
| |
| 06:22 | <alkisg> Ah
| |
| 06:25 | vagrantc: also if you don't mind, I'd like to put code to create the vmlinuz/initrd.img symlinks if they don't exist or if they're dagling
| |
| 06:25 | Do we want those to be cross-distro, i.e. just have them map to the first kernel/initrd?
| |
| 06:26 | <vagrantc> so, i remember when messing with the default config ...
| |
| 06:26 | copyinng over a symlink would actually change the contents of the file it referenced with "cp -a" at least ...
| |
| 06:27 | <alkisg> There are ways to deal with such issues, don't worry about that...
| |
| 06:29 | <vagrantc> this is just forr consistant naming of files?
| |
| 06:29 | we're not going to mess with the menus or anything like that just yet?
| |
| 06:30 | <alkisg> Yes, just for consistency with what we already have
| |
| 06:30 | So that people that have already created pxelinux.cfg/01-mac-address files with "vmlinuz" in them, won't have to change them in ltsp 5.5.
| |
| 06:30 | <vagrantc> how will you decide what gets the vmlinuz link?
| |
| 06:30 | <alkisg> The first kernel
| |
| 06:30 | <vagrantc> and first is?
| |
| 06:31 | most recent version, any flavour?
| |
| 06:31 | <alkisg> In ltsp-update-kernels I want to avoid the kernel ordering variables
| |
| 06:31 | And I found some sorting order that happens to select the correct kernels on debian, ubuntu and gentoo
| |
| 06:31 | I.e. alphabetically sort the flavors
| |
| 06:32 | 486 is before 686, generic is before generic-pae etc
| |
| 06:32 | <vagrantc> ok.
| |
| 06:32 | <alkisg> So, I'm thinking "sort the flavors alphabetically and get the most recent version of that"
| |
| 06:33 | <vagrantc> so if there's a more recently versioned pae you'd prefer the non-pae one?
| |
| 06:33 | <alkisg> Of course that won't work for the general case, but I'd like to avoid getting it too complicated... now it only needs 2 variables to work
| |
| 06:33 | Yes
| |
| 06:34 | <vagrantc> i'd think most recent version should always come first ...
| |
| 06:34 | <alkisg> If you have concerns about the implementation, I don't mind leaving it for you, there's no hurry and I do have other ltsp-related things to work on in the meantime...
| |
| 06:35 | <vagrantc> which will *typically* be the most recently installed one
| |
| 06:35 | <alkisg> I have ubuntu server with non-pae clients
| |
| 06:35 | ...I install debian's 486 kernel
| |
| 06:35 | That's usually lower version than my server's kernel
| |
| 06:35 | So the 486 should be preferred, not the most recent one (in this case at least)
| |
| 06:36 | 486 < generic
| |
| 06:36 | <vagrantc> that's a use-case that you might want to use vmlinuz-486, no?
| |
| 06:36 | and not vmlinuz?
| |
| 06:36 | <alkisg> I'd like my pxelinux.cfg/default to have a link for vmlinux-486 on top of it, yeah
| |
| 06:37 | <vagrantc> also, ifcpu detection seems perfect for that...
| |
| 06:37 | <alkisg> *an entry
| |
| 06:37 | <vagrantc> ifcpu64, that is
| |
| 06:37 | <alkisg> If I take the time to set up ifcpu then I don't need kernel ordering
| |
| 06:38 | But, talking _only_ about kernel ordering, 486 should come first in this case
| |
| 06:38 | <vagrantc> sounds like a very particular use-case to generalize to the default.
| |
| 06:38 | <alkisg> Let's talk about debian. You have 3.2-486 and 3.12-686. Which one do you want to have as the default for unknown clients?
| |
| 06:39 | (and no you're not using ifcpu64 in this example :))
| |
| 06:39 | <vagrantc> if the admin is mixing such disparate versions they had better know what they're doing
| |
| 06:39 | and configure it manually
| |
| 06:40 | which is why i question the usefulness of the vmlinuz symlink
| |
| 06:40 | <alkisg> Wait, we're not talking about the vmlinuz symlink now, forget that part,
| |
| 06:40 | <vagrantc> if they want 4866 to be the default, they should configure it that way.
| |
| 06:40 | <alkisg> we're only talking about "if we have different kernel versions somehow, does the newer version win, or the alphabetically first one?"
| |
| 06:41 | <vagrantc> i think the newer version should win
| |
| 06:41 | <alkisg> Because in the normal case, he'd have 3.12-486 and 3.12-686, and the 486 would win again
| |
| 06:41 | mattcen has joined IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au) | |
| 06:41 | <vagrantc> because they should install the newer version of all variants they want to support
| |
| 06:41 | <alkisg> vagrantc: have you also considered that versions might *not* be comparable?
| |
| 06:42 | It's not necessary that they'll consist of 4 digits separated with dashes etc
| |
| 06:42 | They might even start with bpo-1.2.3.4 in some distro...
| |
| 06:42 | And not 1.2.3.4-bpo
| |
| 06:43 | <vagrantc> so we code for the hypothetically poorly versioned distro? :P
| |
| 06:43 | <alkisg> So you can't compare kernel "A" with version: bpo-1.2.3.4 with kernel "B" with version: 1.2.3.5-asdf, and see which comes first
| |
| 06:43 | <vagrantc> you're no more likely to have comarable versions than comparable flavours
| |
| 06:44 | <alkisg> Sure, but I don't see any use case where comparing versions would help
| |
| 06:44 | In the default case, all versions would be equal
| |
| 06:44 | <vagrantc> but i don't see how you can compare the flavours any more than you can the versions...
| |
| 06:45 | <alkisg> It just happens to suit us with some known flavor names
| |
| 06:45 | We either sort by "flavor, version" or by "version, flavor", and it just happens that the first method has something to offer
| |
| 06:46 | While the second method doesn't offer anything in the default case, since all versions are the same, so it stills orders by flavor
| |
| 06:47 | <vagrantc> it seems overly complicated.
| |
| 06:47 | <alkisg> With only 2 variables?
| |
| 06:47 | <vagrantc> KERNEL_NAMES and INITRD_NAME ?
| |
| 06:47 | <alkisg> Yup
| |
| 06:47 | No need for each distro to list the preferred ordering of their kernel flavors...
| |
| 06:48 | It just happens to cover all the real use cases I've had so far, so it's good enough for me, everything that it doesn't cover can be done by the sysadmin (ifcpu64 etc)
| |
| 06:48 | <vagrantc> but the possibiltiy of an ancient kernel showing up as the default just because it happens to have an alphanumerically winning name... seems silly.
| |
| 06:48 | <alkisg> Why is that kernel there?
| |
| 06:48 | If the sysadmin put it manually, e.g. copied it from another distro, he can rename it to whatever he wants
| |
| 06:49 | And have it always come lst
| |
| 06:49 | <vagrantc> i've heard many tales of systems with lots of leftover kernels
| |
| 06:49 | <alkisg> *last
| |
| 06:49 | <vagrantc> sometimes the names change and whatnot
| |
| 06:50 | <alkisg> Inside a distro series?
| |
| 06:50 | <cyberorg> vagrantc, hi, kiwi-ltsp is packaged for openSUSE, not for SLE
| |
| 06:50 | <alkisg> I.e. would it be possible to have a debian chroot that uses -486, then that gets deprecated and doesn't receive new versions, so that the new -686 kernel comes second?
| |
| 06:50 | <vagrantc> cyberorg: just had someone coming in asking about LTSP on SuSE, and the closest thinng i know of is opensuse
| |
| 06:51 | <alkisg> ...and the 486 kernel would be there as part of the package system, and never get updated etc?!
| |
| 06:51 | <cyberorg> vagrantc, yes, saw the log :)
| |
| 06:51 | <vagrantc> alkisg: well, if you're talking about debian, i'm sure the versions will always sort sanely as well.
| |
| 06:51 | alkisg: the most recent kernel version doesn't seem like an unreasonable default
| |
| 06:52 | <alkisg> cyberorg: hi, what are the usual kernel names for opensuse? give us an example of x32 kernel, pae kernel, and x64 kernel please...
| |
| 06:53 | vagrantc: sorting by "flavor, version" happens to help in all the use cases I know, while by "version, flavor" in no real use case I know. That's all I'm saying, if you don't want to prefer that, I'll just have to write a few instructions more for teachers that need a non-pae or a debian kernel, it's not that significant...
| |
| 06:54 | E.g. I'll tell them to rename the debian kernel to 4.x :)
| |
| 06:54 | <vagrantc> heh
| |
| 06:55 | alkisg: if we do have default vmlinuz/initrd symlinks ... how can the sysadmin override them?
| |
| 06:55 | alkisg: by not using them?
| |
| 06:56 | alkisg: they'll be present on most debian (and maybe ubuntu) chroots, and so will get copied over when ltsp-update-kernels runs... but the ltsp-update-kernels will potentially change them?
| |
| 06:56 | * alkisg needs to think about this a little more ... | |
| 06:57 | <cyberorg> vmlinuz-3.11.6-4-whateverflavor (default, desktop, pae)
| |
| 06:57 | and initrd-3.11.6-4-flavor
| |
| 06:57 | <vagrantc> the names of flavours are particularly interesting here
| |
| 06:57 | <alkisg> cyberorg: default is 32 bit?
| |
| 06:58 | <vagrantc> alkisg: my main concern is messing with symlinks that are already likely there.
| |
| 06:58 | alkisg: and all the hassles it takes to manage that
| |
| 06:59 | <alkisg> cyberorg: we want to see if the flavor names, as sorted alphabetically, happen to list 32 bit before the pae kernel, etc etc
| |
| 06:59 | <vagrantc> i guess i assumed distros didn't ship vmlinuz-flavour symlinks...
| |
| 07:00 | <cyberorg> http://pastebin.com/uEi2BkAp
| |
| 07:00 | <alkisg> vagrantc: I have 2 things in mind, (1) people that have already created vmlinuz symlinks - but ok we can expect them to change them to e.g. vmlinuz-generic, and (2) writing wiki pages, e.g. it's easier to give an example with vmlinuz than selecting between vmlinuz-generic, vmlinuz-486...
| |
| 07:00 | vagrantc: both of those things seem insignificant on second thought, so OK I agree in not doing anything about the vmlinuz symlinks
| |
| 07:01 | Neither create them nor use them
| |
| 07:01 | cyberorg: I'm guessing there's no 64bit kernel in that list, right? Thanks!
| |
| 07:01 | vagrantc: it happens that default < pae too ;)
| |
| 07:01 | <cyberorg> alkisg, no
| |
| 07:01 | <alkisg> It's even default < desktop :D
| |
| 07:02 | Oh come on, the whole universe agrees on "flavor, version" ordering :P
| |
| 07:02 | <cyberorg> alkisg, for ltsp we create linux-profilename and initrd-profilename symlinks
| |
| 07:03 | <alkisg> cyberorg: that sound interesting... what is an example "profile" name? and, how do you decide which profile to map to which kernel? hardcoded in the code?
| |
| 07:03 | <vagrantc> we've been busy rewriting the ltsp-update-kernels stuff, hoping to drag more distros into our trap, er code.
| |
| 07:04 | <alkisg> btw in gentoo it's x86 < x86_64, it's ok there too
| |
| 07:04 | <vagrantc> i386 > amd64 in debian
| |
| 07:04 | ?
| |
| 07:05 | what sort of sort rules is it?
| |
| 07:05 | <alkisg> Win some, lose some... :)
| |
| 07:05 | <vagrantc> er, ... hrm
| |
| 07:05 | <alkisg> Look, the alternative is to have the distro maintainer list all kernel versions
| |
| 07:05 | <vagrantc> but that's just architecture, there's no i386 kernel
| |
| 07:05 | the kernels are 686*, 486*, amd64*
| |
| 07:05 | <alkisg> We did that previously, and now it doesn't make sense in ubuntu at all because the x32 and x64 kernels have the _same_ name
| |
| 07:06 | <cyberorg> alkisg, we don't create x86_64 client images, default profile name is i386, but user can create their own profiles with any name
| |
| 07:06 | <alkisg> And the other distros don't use LIST_KERNELS at all, so now the code is actually debian-specific
| |
| 07:07 | cyberorg: suppose I have 10 clients that support pae and 10 clients that don't, what would I need to do to create 2 profiles and send the correct kernel to each group?
| |
| 07:07 | <cyberorg> ltsp http://pastebin.com/zWUYMY5p
| |
| 07:07 | https://sourceforge.net/p/kiwi-ltsp/code/HEAD/tree/trunk/kiwi-ltsp/ltsp/include/kiwi-ltsp-functions.sh all that stuff is done in there
| |
| 07:08 | https://sourceforge.net/p/kiwi-ltsp/code/HEAD/tree/trunk/kiwi-ltsp/ltsp/include/kiwi-ltsp
| |
| 07:09 | <alkisg> vagrantc: let's pinpoint our differences.... (1) you prefer "version, flavor", while me "flavor, version". (2) You think distros should specify LIST_KERNELS, I don't. Correct?
| |
| 07:09 | <cyberorg> LTSP_MAC_FOR_name="<space separated list of ma:ca:dd:re:ss:es>"
| |
| 07:09 | <vagrantc> alkisg: i prefer "version, flavor" when there's no premise of i386/pae/amd64
| |
| 07:10 | <alkisg> cyberorg: and after that you run some code to generate all the pxelinux.cfg/01-mad-address files?
| |
| 07:10 | vagrantc: tell me about (2), e.g. in ltsp6, do you want distros to specify LIST_KERNELS?
| |
| 07:10 | <cyberorg> alkisg, yes
| |
| 07:10 | <alkisg> cyberorg: thanks :)
| |
| 07:10 | <cyberorg> https://sourceforge.net/p/kiwi-ltsp/code/HEAD/tree/trunk/kiwi-ltsp/ltsp/kiwi-ltsp-setup
| |
| 07:10 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 07:11 | <vagrantc> alkisg: can we provide an optional variable that defines the sort order, and defaults to what you want?
| |
| 07:11 | <cyberorg> kiwi-ltsp-setup is the script, kiwi-ltsp-functions.sh (what name says) and /etc/sysconfig/kiwi-ltsp is the central config for ltsp related stuff
| |
| 07:12 | <alkisg> vagrantc: btw, 486 < 686 < amd64, so it's OK there too
| |
| 07:12 | <cyberorg> sorry that was wrong link https://sourceforge.net/p/kiwi-ltsp/code/HEAD/tree/trunk/kiwi-ltsp/ltsp/include/kiwi-ltsp-setup
| |
| 07:13 | <alkisg> vagrantc: ignore the sorting for a bit... do we want distros to specify the 32bit, 64bit, -pae kernels like we tried to do in ltsp 5.4 ?
| |
| 07:13 | I think it's too complicated, and now with the new ubuntu versioning, it doesn't even apply there
| |
| 07:14 | <vagrantc> alkisg: i want those to be specified if it makes sense ... otherwise i don't think it's worth the bother
| |
| 07:14 | <alkisg> If you agree to remove them, then we automatically agree on "sort the flavors alphabetically", which is the main part
| |
| 07:14 | <vagrantc> alkisg: with the -flavour symlinks, it's fairly easy to craft an ifcpu64 stanza to my liking
| |
| 07:14 | <alkisg> Right
| |
| 07:14 | OK, so I think we solved (2), we'll remove the LIST_KERNEL* variables in the future,
| |
| 07:14 | and the only thing that remains is (1), i.e. "flavor, version" or "version, flavor",
| |
| 07:16 | * vagrantc would actually like the ifcpu64 stanza to be autogenerated... but it's easy enough to document | |
| 07:16 | <alkisg> ...I'd really lke to default to "flavor, version", because it helps in numerous cases and I don't see where "version, flavor" would help, but it's not that significant, I'll find some workaround...
| |
| 07:16 | Even if really is to rename the debian or non-pae kernel to 4.x
| |
| 07:17 | <vagrantc> those numerous cases where it helps, while legitimate, seem like the corner cases
| |
| 07:17 | <alkisg> I don't see any non-corner case at all
| |
| 07:18 | I don't think you provided any non-corner example...
| |
| 07:18 | <vagrantc> in the default case, there should only be one kernel anyways :)
| |
| 07:18 | <alkisg> Right, so it works fine there. Other cases?
| |
| 07:19 | If I normally install and upgrade kernels, their versions would be the same, so it's fine there too, both sorting methods give the same results
| |
| 07:19 | <vagrantc> fair enough.
| |
| 07:19 | but mangling symlinks present in the chroot?
| |
| 07:19 | <alkisg> So the use cases where it makes a difference are e.g. install -486 on ubuntu, or have an ancient kernel somehow left over without the package system knowing about it
| |
| 07:20 | <vagrantc> right
| |
| 07:20 | <alkisg> In that case, if the sysadmin puts some kernel that the package system doesn't know about, he'd just use its flavor name to put it where he wants, not mess with the version part,
| |
| 07:20 | so again "flavor, version" is better there
| |
| 07:20 | And finally, in the menus:
| |
| 07:20 | how do you want to see the long listing of the kernels?
| |
| 07:21 | <vagrantc> currently, it just dumps all the versioned entries into a sub-menu
| |
| 07:21 | well, one sub-menu per rootfs method
| |
| 07:21 | <alkisg> 3-geneiric, 2-generic, 3-geneiric-pae, 2-generic-pae
| |
| 07:21 | or: 3-geneiric-pae, 3-geneirc, 2-generic-pae, 2-generic ?
| |
| 07:22 | <vagrantc> i don't follow?
| |
| 07:22 | <alkisg> Sorted by "flavor, version" or by "version, flavor"?
| |
| 07:22 | <vagrantc> doesn't really matter.
| |
| 07:22 | <alkisg> Do you want to see all the recent versions on top, or all e.g. the -generic flavors on top?
| |
| 07:22 | OK
| |
| 07:23 | <vagrantc> as it is now, it puts the most compatible kernel in the top three entries, and then lists submenus with all the options.
| |
| 07:23 | <alkisg> All the options sorted by...?
| |
| 07:23 | <vagrantc> er, most compatbile kernel is the first entry, and i have no idea how it's sorted in the submenus
| |
| 07:23 | <alkisg> ok
| |
| 07:24 | <vagrantc> there's one menu entry for each boot method that's "unversioned" at the top, and then a sub-menu for each boot method with all versions.
| |
| 07:24 | <alkisg> grub uses "flavor, version" too
| |
| 07:25 | OK just give up :P
| |
| 07:25 | It lists generic 3.8, 3.2 etc, and then goes to generic-pae
| |
| 07:30 | Ah, to avoid having to use `eval` in INITRD_NAME, we can request that it is a sed expression that replaces "vmlinuz" with "initrd"
| |
| 07:32 | <vagrantc> all distros use vmlinu[zx] ?
| |
| 07:32 | <alkisg> No no
| |
| 07:32 | I meant, "replace the distro-specific kernel name with the distro-specific initrd name"
| |
| 07:32 | A sed expression for that, provided by the distro
| |
| 07:32 | <vagrantc> right
| |
| 07:33 | i hope that's easy.
| |
| 07:33 | <alkisg> ls /boot/vmlinu* | sed 's/vmlinuz/initrd.img/'
| |
| 07:34 | That sed gives the initrd names if one knows the vmlinuz names
| |
| 07:34 | That's all we're asking for... that sed expression
| |
| 07:34 | INITRD_NAME='s/vmlinuz/initrd.img/'
| |
| 07:35 | INITRD_NAME='s/.*//' for distros with no initrd at all :P
| |
| 07:36 | <vagrantc> i'll use INITRD_NAME='s/vmlinu[xz]/initrd.img/' for Debian then?
| |
| 07:36 | <alkisg> Yes, but I'm not sure that vmlinux maps to the same initrd, does it?
| |
| 07:36 | <vagrantc> admittedly, the arches using vmlinux are getting more and more obsolete
| |
| 07:37 | <alkisg> vmlinux is uncompressed, and vmlinuz is compressed?
| |
| 07:37 | And if so, do both of them use the same initrd?
| |
| 07:37 | <vagrantc> alkisg: i don't believe there are flavours in debian in which some use vmlinux and some use vmlinuz
| |
| 07:38 | <alkisg> OK, I think we have everything worked out for all the use cases we know so far. It's good enough for me :)
| |
| 07:38 | <vagrantc> for each given flavor, there is only one per architecture
| |
| 07:38 | <alkisg> I can do the ltsp-update-kernels links implementation today, if you think we agree on how to do it...
| |
| 07:38 | <vagrantc> there's amd64 for both i386 and amd64 ... but those are also both vmlinuz
| |
| 07:39 | <alkisg> If you're still worried for some reason, I don't mind leaving it for you for another day
| |
| 07:39 | <vagrantc> alkisg: you can always make it work and i can alwaays break it :)
| |
| 07:40 | <alkisg> Hehe
| |
| 07:40 | That goes both ways!
| |
| 07:40 | <vagrantc> oh, good. sometimes i worry!
| |
| 07:41 | alkisg: i think we've spent more time hashing out pxelinux configuration and related kernel symlinks than just about any other part of ltsp...
| |
| 07:42 | <alkisg> Haha... true, but we've not even started talking about the ltspd configuration file syntax just yet :D
| |
| 07:42 | <vagrantc> true, true.
| |
| 07:42 | <alkisg> To be fair, it was a hard topic
| |
| 07:42 | <vagrantc> we're *trying* to be cross-distro without many other distros in on the discussion ...
| |
| 07:43 | <alkisg> I'm starting to really like the idea that sbalneav proposed for ltsp6
| |
| 07:43 | To start with a clean tree, and import whatever we care about
| |
| 07:43 | If noone imports something, it means noone cares enough to do it :)
| |
| 07:43 | <vagrantc> there's something to be said for that....
| |
| 07:44 | i'll miss all the vcs history ...
| |
| 07:44 | <alkisg> Things will change too much for the older history to be useful
| |
| 07:45 | And there'll always be the ltsp5 tree
| |
| 07:45 | <vagrantc> it's not that useful now, but i find it amusing at times
| |
| 07:45 | like "wow, that 'fi' hasn't changed since the initial commit!"
| |
| 07:47 | * alkisg finds the "wow, we finally got rid of XXX part" much more amusing! :D | |
| 08:01 | <gdi2k> quick question regarding epoptes: I cannot use the Execute -> Open terminal -> User, locally and Root, locally functions. Nothing happens when the item is selected. I think this maybe a socat issue. I cannot launch socat; I get error while loading shared libraries: libreadline.so.5. I've googled quite a bit to try and correct this, but no luck so far. This is on 12.04 64 bit with 32 bit clients
| |
| 08:01 | (it worked fine on previous installs)
| |
| 08:02 | <alkisg> You cannot launch socat on fat clients?
| |
| 08:02 | <gdi2k> I can launch on the clients, but not on the server
| |
| 08:03 | <alkisg> socat - -
| |
| 08:03 | What's the error message there?
| |
| 08:04 | * alkisg finds that "quick questions" are never quick... | |
| 08:04 | <gdi2k> when launching socat:
| |
| 08:04 | socat: error while loading shared libraries: libreadline.so.5: cannot open shared object file: No such file or directory
| |
| 08:05 | <alkisg> dpkg -l libreadline*
| |
| 08:06 | $ dpkg -L libreadline5 | grep libreadline.so
| |
| 08:06 | /lib/i386-linux-gnu/libreadline.so.5.2
| |
| 08:06 | /lib/i386-linux-gnu/libreadline.so.5
| |
| 08:06 | <gdi2k> http://pastebin.ubuntu.com/6689522/
| |
| 08:07 | I have the same as you, only with x86_64 versions not i386
| |
| 08:08 | <alkisg> $ strace -e trace=file socat - - 2>&1 | grep libreadline.so
| |
| 08:08 | open("/lib/i386-linux-gnu/libreadline.so.5", O_RDONLY|O_CLOEXEC) = 3
| |
| 08:11 | <gdi2k> http://pastebin.ubuntu.com/6689532/
| |
| 08:13 | <alkisg> So this doesn't exist ? /lib/x86_64-linux-gnu/libreadline.so.5
| |
| 08:13 | (10:07:54 πμ) gdi2k: I have the same as you, only with x86_64 versions not i386
| |
| 08:14 | If you have it mentioned in dpkg -L libreadline5, and it's not in the file system, then you've had file system failure at some point
| |
| 08:14 | ...and need to reinstall libreadline5
| |
| 08:15 | <gdi2k> you're right, it's not there - only /lib/x86_64-linux-gnu/libreadline.so.6 is there, but not 5. Will work on that, thank you
| |
| 08:18 | <alkisg> apt-get install --reinstall libreadline5
| |
| 08:21 | If you've had file system failure at some point, you should be trying to find a way to validate files for all packages :)
| |
| 08:21 | <gdi2k> that did it! :) yes, was just thinking that...
| |
| 08:21 | <alkisg> dpkg has md5sums of the files it ships
| |
| 08:22 | Google on how to use them to validate at least most of the files in your file system, to see the extend of the problem
| |
| 08:24 | <gdi2k> got it, thanks. debsums looks like the way forward
| |
| 08:24 | <alkisg> example: md5sum -c /var/lib/dpkg/info/zenity.md5sums
| |
| 08:25 | cd /; for f in /var/lib/dpkg/info/*.md5sums; do LANG=C md5sum -c "$f" | grep -v OK; done
| |
| 08:25 | That ^ should help..
| |
| 08:26 | <gdi2k> uh. extent of problem looks massive
| |
| 08:26 | thousands of missing files
| |
| 08:27 | <alkisg> I only have 10 lines after running it for 2 minutes
| |
| 08:27 | So epoptes wasn't the problem here :)
| |
| 08:27 | <gdi2k> yes, it's uncovered quite the can of worms!
| |
| 08:31 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
| 08:37 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 272 seconds) | |
| 08:54 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 09:10 | stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, *.net *.split) | |
| 09:10 | ageis has left IRC (ageis!kevin@ageispolis.net, *.net *.split) | |
| 09:10 | Selveste1 has left IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net, *.net *.split) | |
| 09:10 | elias_a has left IRC (elias_a!elias@hilla.kapsi.fi, *.net *.split) | |
| 09:10 | gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, *.net *.split) | |
| 09:10 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, *.net *.split) | |
| 09:10 | zamba has left IRC (zamba!marius@flage.org, *.net *.split) | |
| 09:10 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, *.net *.split) | |
| 09:10 | work_alkisg has left IRC (work_alkisg!~alkisg@194.63.234.224, *.net *.split) | |
| 09:10 | adrianorg has left IRC (adrianorg!~adrianorg@187.115.109.115, *.net *.split) | |
| 09:10 | FGXR6 has left IRC (FGXR6!~phantom@ppp59-167-136-109.static.internode.on.net, *.net *.split) | |
| 09:10 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, *.net *.split) | |
| 09:10 | gvy has left IRC (gvy!~mike@altlinux/developer/mike, *.net *.split) | |
| 09:10 | lee has left IRC (lee!~lee@loathe.ms, *.net *.split) | |
| 09:10 | shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, *.net *.split) | |
| 09:10 | NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es, *.net *.split) | |
| 09:10 | Parker955_Away has left IRC (Parker955_Away!~parker@74.112.203.151, *.net *.split) | |
| 09:10 | bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, *.net *.split) | |
| 09:10 | hachque has left IRC (hachque!james@2600:3c01::f03c:91ff:fe96:5060, *.net *.split) | |
| 09:10 | mattcen has left IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au, *.net *.split) | |
| 09:10 | ||cw has left IRC (||cw!~chris@phpgroupware/cw, *.net *.split) | |
| 09:10 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, *.net *.split) | |
| 09:10 | Zaphoid has left IRC (Zaphoid!~karabats@173.236.244.111, *.net *.split) | |
| 09:10 | Lumiere has left IRC (Lumiere!~jstraw@unaffiliated/jstraw, *.net *.split) | |
| 09:10 | Ryan52 has left IRC (Ryan52!~ryan52@freegeek/ryan52, *.net *.split) | |
| 09:10 | ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, *.net *.split) | |
| 09:10 | rickogden has left IRC (rickogden!~Rick@host.hifirevolution.com, *.net *.split) | |
| 09:10 | book` has left IRC (book`!~book`@li125-242.members.linode.com, *.net *.split) | |
| 09:10 | spectra_ has left IRC (spectra_!~spectra@eregion.nardol.org, *.net *.split) | |
| 09:10 | andygraybeal has left IRC (andygraybeal!~andy@h96.194.213.151.dynamic.ip.windstream.net, *.net *.split) | |
| 09:10 | lmds_ has left IRC (lmds_!~lmds@tui.pi-et-ro.net, *.net *.split) | |
| 09:10 | Patina has left IRC (Patina!~tomas@dhcp-5-103-105-144.seas-nve.net, *.net *.split) | |
| 09:10 | GEEGEEGEE has left IRC (GEEGEEGEE!~PrepareYo@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net, *.net *.split) | |
| 09:10 | monteslu has left IRC (monteslu!~monteslu@ip68-109-175-67.ph.ph.cox.net, *.net *.split) | |
| 09:10 | |Paradox| has left IRC (|Paradox|!iamparadox@c-71-206-130-134.hsd1.va.comcast.net, *.net *.split) | |
| 09:10 | riddle has left IRC (riddle!riddle@us.yunix.net, *.net *.split) | |
| 09:10 | highvoltage has left IRC (highvoltage!~highvolta@abathur.jonathancarter.org, *.net *.split) | |
| 09:10 | sbalneav has left IRC (sbalneav!~sbalneav@50.71.200.173, *.net *.split) | |
| 09:10 | mmetzger has left IRC (mmetzger!~mmetzger@99-71-214-107.lightspeed.mdldtx.sbcglobal.net, *.net *.split) | |
| 09:10 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, *.net *.split) | |
| 09:10 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, *.net *.split) | |
| 09:10 | sutula has left IRC (sutula!sutula@nat/hp/x-ijslmppdhjreqlqc, *.net *.split) | |
| 09:10 | telex has left IRC (telex!~telex@freeshell.de, *.net *.split) | |
| 09:10 | dberkholz has left IRC (dberkholz!~dberkholz@gentoo/developer/dberkholz, *.net *.split) | |
| 09:10 | TatankaT has left IRC (TatankaT!~tim@193.190.253.114, *.net *.split) | |
| 09:10 | Hyperbyte has left IRC (Hyperbyte!jan@middelkoop.cc, *.net *.split) | |
| 09:10 | prem__ has left IRC (prem__!~boss@218.248.24.19, *.net *.split) | |
| 09:10 | Enslaver has left IRC (Enslaver!~Enslaver@fedora/Enslaver, *.net *.split) | |
| 09:10 | dead_inside has left IRC (dead_inside!~taylor@76.75.3.174, *.net *.split) | |
| 09:10 | slackish has left IRC (slackish!amcphall@mcphall.org, *.net *.split) | |
| 09:10 | ramcq has left IRC (ramcq!~robot101@iota.hadesian.co.uk, *.net *.split) | |
| 09:10 | yanu_ has left IRC (yanu_!~yanu@178-117-230-250.access.telenet.be, *.net *.split) | |
| 09:10 | vlt has left IRC (vlt!~hrst@lvps178-77-99-218.dedicated.hosteurope.de, *.net *.split) | |
| 09:10 | markosu has left IRC (markosu!marko5@kapsi.fi, *.net *.split) | |
| 09:31 | stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber) | |
| 09:31 | Patina has joined IRC (Patina!~tomas@dhcp-5-103-105-144.seas-nve.net) | |
| 09:31 | lmds_ has joined IRC (lmds_!~lmds@tui.pi-et-ro.net) | |
| 09:31 | andygraybeal has joined IRC (andygraybeal!~andy@h96.194.213.151.dynamic.ip.windstream.net) | |
| 09:31 | gvy_ has joined IRC (gvy_!~mike@195.239.66.165) | |
| 09:31 | F-GTSC has joined IRC (F-GTSC!~phantom@ppp59-167-136-109.static.internode.on.net) | |
| 09:31 | vlt has joined IRC (vlt!~hrst@lvps178-77-99-218.dedicated.hosteurope.de) | |
| 09:31 | yanu_ has joined IRC (yanu_!~yanu@178-117-230-250.access.telenet.be) | |
| 09:31 | slackish has joined IRC (slackish!amcphall@mcphall.org) | |
| 09:31 | dead_inside has joined IRC (dead_inside!~taylor@76.75.3.174) | |
| 09:31 | ramcq has joined IRC (ramcq!~robot101@iota.hadesian.co.uk) | |
| 09:31 | Enslaver has joined IRC (Enslaver!~Enslaver@fedora/Enslaver) | |
| 09:31 | prem__ has joined IRC (prem__!~boss@218.248.24.19) | |
| 09:31 | zamba has joined IRC (zamba!marius@flage.org) | |
| 09:31 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 09:31 | gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113) | |
| 09:31 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 09:31 | adrianorg has joined IRC (adrianorg!~adrianorg@187.115.109.115) | |
| 09:31 | GEEGEEGEE has joined IRC (GEEGEEGEE!~PrepareYo@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net) | |
| 09:31 | markosu has joined IRC (markosu!marko5@kapsi.fi) | |
| 09:31 | mattcen has joined IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au) | |
| 09:31 | ||cw has joined IRC (||cw!~chris@phpgroupware/cw) | |
| 09:31 | ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de) | |
| 09:31 | hachque has joined IRC (hachque!james@2600:3c01::f03c:91ff:fe96:5060) | |
| 09:31 | staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 09:31 | Zaphoid has joined IRC (Zaphoid!~karabats@173.236.244.111) | |
| 09:31 | rickogden has joined IRC (rickogden!~Rick@host.hifirevolution.com) | |
| 09:31 | Parker955_Away has joined IRC (Parker955_Away!~parker@74.112.203.151) | |
| 09:31 | Ryan52 has joined IRC (Ryan52!~ryan52@freegeek/ryan52) | |
| 09:31 | Lumiere has joined IRC (Lumiere!~jstraw@unaffiliated/jstraw) | |
| 09:31 | shawnp0wers has joined IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers) | |
| 09:31 | telex has joined IRC (telex!~telex@freeshell.de) | |
| 09:31 | dberkholz has joined IRC (dberkholz!~dberkholz@gentoo/developer/dberkholz) | |
| 09:31 | TatankaT has joined IRC (TatankaT!~tim@193.190.253.114) | |
| 09:31 | Hyperbyte has joined IRC (Hyperbyte!jan@middelkoop.cc) | |
| 09:31 | lee has joined IRC (lee!~lee@loathe.ms) | |
| 09:31 | monteslu has joined IRC (monteslu!~monteslu@ip68-109-175-67.ph.ph.cox.net) | |
| 09:31 | |Paradox| has joined IRC (|Paradox|!iamparadox@c-71-206-130-134.hsd1.va.comcast.net) | |
| 09:31 | riddle has joined IRC (riddle!riddle@us.yunix.net) | |
| 09:31 | highvoltage has joined IRC (highvoltage!~highvolta@abathur.jonathancarter.org) | |
| 09:31 | sbalneav has joined IRC (sbalneav!~sbalneav@50.71.200.173) | |
| 09:31 | mmetzger has joined IRC (mmetzger!~mmetzger@99-71-214-107.lightspeed.mdldtx.sbcglobal.net) | |
| 09:31 | telex has left IRC (telex!~telex@freeshell.de, Max SendQ exceeded) | |
| 09:31 | telex has joined IRC (telex!~telex@freeshell.de) | |
| 09:35 | lee is now known as 20WAASSE4 | |
| 09:35 | ageis has joined IRC (ageis!kevin@ageispolis.net) | |
| 09:35 | Selveste1 has joined IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net) | |
| 09:35 | elias_a has joined IRC (elias_a!elias@hilla.kapsi.fi) | |
| 09:44 | work_alkisg has joined IRC (work_alkisg!~alkisg@194.63.234.224) | |
| 09:44 | alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47) | |
| 09:44 | book` has joined IRC (book`!~book`@li125-242.members.linode.com) | |
| 09:44 | spectra_ has joined IRC (spectra_!~spectra@eregion.nardol.org) | |
| 09:48 | alkisg has joined IRC (alkisg!~alkisg@ppp089210070222.access.hol.gr) | |
| 09:53 | NeonLich1 has joined IRC (NeonLich1!~NeonLicht@darwin.ugr.es) | |
| 09:53 | freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun) | |
| 09:53 | sutula has joined IRC (sutula!sutula@nat/hp/x-ijslmppdhjreqlqc) | |
| 09:53 | GEEGEEGEE has left IRC (GEEGEEGEE!~PrepareYo@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net, Ping timeout: 272 seconds) | |
| 10:48 | bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com) | |
| 11:14 | GEEGEEGEE has joined IRC (GEEGEEGEE!~PrepareYo@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net) | |
| 11:45 | staffencasa_ has joined IRC (staffencasa_!~staffenca@8-220.ptpg.oregonstate.edu) | |
| 11:45 | staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Read error: Connection reset by peer) | |
| 12:11 | <alkisg> stgraber: a newer nbd version was released in debian, but it won't be automatically synced with ubuntu because ubuntu has a small .diff in the debian nbd package
| |
| 12:12 | The .diff is that debian/nbd-client.modprobe is not included in ubuntu, because its contents, "options nbd max_part=15", already match the kernel defaults
| |
| 12:13 | ...if they already match the defaults, why not keep it there and avoid the .diff and the manual syncing process completely?
| |
| 12:46 | <GEEGEEGEE> im a girl
| |
| 12:46 | adrianorg has left IRC (adrianorg!~adrianorg@187.115.109.115, Ping timeout: 252 seconds) | |
| 12:48 | <alkisg> We don't mind :)
| |
| 12:48 | adrianorg has joined IRC (adrianorg!~adrianorg@187.113.249.92) | |
| 13:18 | gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, Ping timeout: 246 seconds) | |
| 14:00 | imox has joined IRC (imox!~imox@p4FC5CB1F.dip0.t-ipconnect.de) | |
| 14:06 | freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish) | |
| 14:24 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 252 seconds) | |
| 14:44 | Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net) | |
| 14:44 | Gremble is now known as Guest65515 | |
| 14:52 | imox has left IRC (imox!~imox@p4FC5CB1F.dip0.t-ipconnect.de, Quit: imox) | |
| 14:58 | PhoenixSTF has joined IRC (PhoenixSTF!~rudi@78.29.154.124) | |
| 15:16 | alkisg has left IRC (alkisg!~alkisg@ppp089210070222.access.hol.gr, Quit: Leaving.) | |
| 15:21 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 15:56 | NeonLich1 is now known as NeonLicht | |
| 16:04 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 16:40 | imox has joined IRC (imox!~imox@p4FC5CB1F.dip0.t-ipconnect.de) | |
| 18:20 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 18:25 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 18:28 | PhoenixSTF has left IRC (PhoenixSTF!~rudi@78.29.154.124, Quit: Leaving) | |
| 18:42 | imox has left IRC (imox!~imox@p4FC5CB1F.dip0.t-ipconnect.de, Quit: imox) | |
| 18:46 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 18:48 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 19:03 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 19:09 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 19:41 | PhoenixSTF has joined IRC (PhoenixSTF!~rudi@78.29.154.124) | |
| 19:42 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
| 20:12 | rwvnx has joined IRC (rwvnx!iamparadox@c-71-206-130-134.hsd1.va.comcast.net) | |
| 20:16 | |Paradox| has left IRC (|Paradox|!iamparadox@c-71-206-130-134.hsd1.va.comcast.net, Ping timeout: 272 seconds) | |
| 20:16 | rwvnx is now known as |Paradox| | |
| 20:46 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection) | |
| 21:09 | kwmiebach has joined IRC (kwmiebach!sid16855@gateway/web/irccloud.com/x-tchdovzuxwthdlmd) | |
| 22:09 | telex has left IRC (telex!~telex@freeshell.de, Remote host closed the connection) | |
| 22:12 | telex has joined IRC (telex!~telex@freeshell.de) | |
| 22:33 | Guest65515 has left IRC (Guest65515!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Ping timeout: 246 seconds) | |
| 22:34 | Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net) | |
| 22:35 | Gremble is now known as Guest34699 | |
| 23:01 | Guest34699 has left IRC (Guest34699!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Ping timeout: 264 seconds) | |
| 23:50 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |