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


Channel log from 4 January 2014   (all times are UTC)

00:36imox has joined IRC (imox!~imox@p4FC5D2D7.dip0.t-ipconnect.de)
01:02Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
01:13imox has left IRC (imox!~imox@p4FC5D2D7.dip0.t-ipconnect.de, Quit: imox)
01:30vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
02:37freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Ping timeout: 272 seconds)
02:52freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
03:10Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 252 seconds)
03:29gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113)
04:03ogden has joined IRC (ogden!47514457@gateway/web/freenode/ip.71.81.68.87)
04:04
<ogden>
anyone on for a quick question?
04:54ogden has left IRC (ogden!47514457@gateway/web/freenode/ip.71.81.68.87, Ping timeout: 272 seconds)
05:54mattcen has left IRC (mattcen!~mattcen@c110-22-201-130.sunsh4.vic.optusnet.com.au, Ping timeout: 240 seconds)
06:07vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
06:15alkisg 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:41mattcen 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:10Phantomas 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:31vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
08:37alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 272 seconds)
08:54alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
09:10stgraber has left IRC (stgraber!~stgraber@ubuntu/member/stgraber, *.net *.split)
09:10ageis has left IRC (ageis!kevin@ageispolis.net, *.net *.split)
09:10Selveste1 has left IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net, *.net *.split)
09:10elias_a has left IRC (elias_a!elias@hilla.kapsi.fi, *.net *.split)
09:10gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, *.net *.split)
09:10cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, *.net *.split)
09:10zamba has left IRC (zamba!marius@flage.org, *.net *.split)
09:10Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, *.net *.split)
09:10work_alkisg has left IRC (work_alkisg!~alkisg@194.63.234.224, *.net *.split)
09:10adrianorg has left IRC (adrianorg!~adrianorg@187.115.109.115, *.net *.split)
09:10FGXR6 has left IRC (FGXR6!~phantom@ppp59-167-136-109.static.internode.on.net, *.net *.split)
09:10alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, *.net *.split)
09:10gvy has left IRC (gvy!~mike@altlinux/developer/mike, *.net *.split)
09:10lee has left IRC (lee!~lee@loathe.ms, *.net *.split)
09:10shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, *.net *.split)
09:10NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es, *.net *.split)
09:10Parker955_Away has left IRC (Parker955_Away!~parker@74.112.203.151, *.net *.split)
09:10bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, *.net *.split)
09:10hachque has left IRC (hachque!james@2600:3c01::f03c:91ff:fe96:5060, *.net *.split)
09:10mattcen 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:10staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, *.net *.split)
09:10Zaphoid has left IRC (Zaphoid!~karabats@173.236.244.111, *.net *.split)
09:10Lumiere has left IRC (Lumiere!~jstraw@unaffiliated/jstraw, *.net *.split)
09:10Ryan52 has left IRC (Ryan52!~ryan52@freegeek/ryan52, *.net *.split)
09:10ogra_ has left IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de, *.net *.split)
09:10rickogden has left IRC (rickogden!~Rick@host.hifirevolution.com, *.net *.split)
09:10book` has left IRC (book`!~book`@li125-242.members.linode.com, *.net *.split)
09:10spectra_ has left IRC (spectra_!~spectra@eregion.nardol.org, *.net *.split)
09:10andygraybeal has left IRC (andygraybeal!~andy@h96.194.213.151.dynamic.ip.windstream.net, *.net *.split)
09:10lmds_ has left IRC (lmds_!~lmds@tui.pi-et-ro.net, *.net *.split)
09:10Patina has left IRC (Patina!~tomas@dhcp-5-103-105-144.seas-nve.net, *.net *.split)
09:10GEEGEEGEE has left IRC (GEEGEEGEE!~PrepareYo@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net, *.net *.split)
09:10monteslu 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:10riddle has left IRC (riddle!riddle@us.yunix.net, *.net *.split)
09:10highvoltage has left IRC (highvoltage!~highvolta@abathur.jonathancarter.org, *.net *.split)
09:10sbalneav has left IRC (sbalneav!~sbalneav@50.71.200.173, *.net *.split)
09:10mmetzger has left IRC (mmetzger!~mmetzger@99-71-214-107.lightspeed.mdldtx.sbcglobal.net, *.net *.split)
09:10alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, *.net *.split)
09:10freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, *.net *.split)
09:10sutula has left IRC (sutula!sutula@nat/hp/x-ijslmppdhjreqlqc, *.net *.split)
09:10telex has left IRC (telex!~telex@freeshell.de, *.net *.split)
09:10dberkholz has left IRC (dberkholz!~dberkholz@gentoo/developer/dberkholz, *.net *.split)
09:10TatankaT has left IRC (TatankaT!~tim@193.190.253.114, *.net *.split)
09:10Hyperbyte has left IRC (Hyperbyte!jan@middelkoop.cc, *.net *.split)
09:10prem__ has left IRC (prem__!~boss@218.248.24.19, *.net *.split)
09:10Enslaver has left IRC (Enslaver!~Enslaver@fedora/Enslaver, *.net *.split)
09:10dead_inside has left IRC (dead_inside!~taylor@76.75.3.174, *.net *.split)
09:10slackish has left IRC (slackish!amcphall@mcphall.org, *.net *.split)
09:10ramcq has left IRC (ramcq!~robot101@iota.hadesian.co.uk, *.net *.split)
09:10yanu_ has left IRC (yanu_!~yanu@178-117-230-250.access.telenet.be, *.net *.split)
09:10vlt has left IRC (vlt!~hrst@lvps178-77-99-218.dedicated.hosteurope.de, *.net *.split)
09:10markosu has left IRC (markosu!marko5@kapsi.fi, *.net *.split)
09:31stgraber has joined IRC (stgraber!~stgraber@ubuntu/member/stgraber)
09:31Patina has joined IRC (Patina!~tomas@dhcp-5-103-105-144.seas-nve.net)
09:31lmds_ has joined IRC (lmds_!~lmds@tui.pi-et-ro.net)
09:31andygraybeal has joined IRC (andygraybeal!~andy@h96.194.213.151.dynamic.ip.windstream.net)
09:31gvy_ has joined IRC (gvy_!~mike@195.239.66.165)
09:31F-GTSC has joined IRC (F-GTSC!~phantom@ppp59-167-136-109.static.internode.on.net)
09:31vlt has joined IRC (vlt!~hrst@lvps178-77-99-218.dedicated.hosteurope.de)
09:31yanu_ has joined IRC (yanu_!~yanu@178-117-230-250.access.telenet.be)
09:31slackish has joined IRC (slackish!amcphall@mcphall.org)
09:31dead_inside has joined IRC (dead_inside!~taylor@76.75.3.174)
09:31ramcq has joined IRC (ramcq!~robot101@iota.hadesian.co.uk)
09:31Enslaver has joined IRC (Enslaver!~Enslaver@fedora/Enslaver)
09:31prem__ has joined IRC (prem__!~boss@218.248.24.19)
09:31zamba has joined IRC (zamba!marius@flage.org)
09:31cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
09:31gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113)
09:31Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
09:31adrianorg has joined IRC (adrianorg!~adrianorg@187.115.109.115)
09:31GEEGEEGEE has joined IRC (GEEGEEGEE!~PrepareYo@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net)
09:31markosu has joined IRC (markosu!marko5@kapsi.fi)
09:31mattcen 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:31ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
09:31hachque has joined IRC (hachque!james@2600:3c01::f03c:91ff:fe96:5060)
09:31staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
09:31Zaphoid has joined IRC (Zaphoid!~karabats@173.236.244.111)
09:31rickogden has joined IRC (rickogden!~Rick@host.hifirevolution.com)
09:31Parker955_Away has joined IRC (Parker955_Away!~parker@74.112.203.151)
09:31Ryan52 has joined IRC (Ryan52!~ryan52@freegeek/ryan52)
09:31Lumiere has joined IRC (Lumiere!~jstraw@unaffiliated/jstraw)
09:31shawnp0wers has joined IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers)
09:31telex has joined IRC (telex!~telex@freeshell.de)
09:31dberkholz has joined IRC (dberkholz!~dberkholz@gentoo/developer/dberkholz)
09:31TatankaT has joined IRC (TatankaT!~tim@193.190.253.114)
09:31Hyperbyte has joined IRC (Hyperbyte!jan@middelkoop.cc)
09:31lee has joined IRC (lee!~lee@loathe.ms)
09:31monteslu 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:31riddle has joined IRC (riddle!riddle@us.yunix.net)
09:31highvoltage has joined IRC (highvoltage!~highvolta@abathur.jonathancarter.org)
09:31sbalneav has joined IRC (sbalneav!~sbalneav@50.71.200.173)
09:31mmetzger has joined IRC (mmetzger!~mmetzger@99-71-214-107.lightspeed.mdldtx.sbcglobal.net)
09:31telex has left IRC (telex!~telex@freeshell.de, Max SendQ exceeded)
09:31telex has joined IRC (telex!~telex@freeshell.de)
09:35lee is now known as 20WAASSE4
09:35ageis has joined IRC (ageis!kevin@ageispolis.net)
09:35Selveste1 has joined IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net)
09:35elias_a has joined IRC (elias_a!elias@hilla.kapsi.fi)
09:44work_alkisg has joined IRC (work_alkisg!~alkisg@194.63.234.224)
09:44alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
09:44book` has joined IRC (book`!~book`@li125-242.members.linode.com)
09:44spectra_ has joined IRC (spectra_!~spectra@eregion.nardol.org)
09:48alkisg has joined IRC (alkisg!~alkisg@ppp089210070222.access.hol.gr)
09:53NeonLich1 has joined IRC (NeonLich1!~NeonLicht@darwin.ugr.es)
09:53freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
09:53sutula has joined IRC (sutula!sutula@nat/hp/x-ijslmppdhjreqlqc)
09:53GEEGEEGEE has left IRC (GEEGEEGEE!~PrepareYo@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net, Ping timeout: 272 seconds)
10:48bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
11:14GEEGEEGEE has joined IRC (GEEGEEGEE!~PrepareYo@cpc8-sprt2-2-0-cust26.17-2.cable.virginm.net)
11:45staffencasa_ has joined IRC (staffencasa_!~staffenca@8-220.ptpg.oregonstate.edu)
11:45staffencasa 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:46adrianorg has left IRC (adrianorg!~adrianorg@187.115.109.115, Ping timeout: 252 seconds)
12:48
<alkisg>
We don't mind :)
12:48adrianorg has joined IRC (adrianorg!~adrianorg@187.113.249.92)
13:18gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, Ping timeout: 246 seconds)
14:00imox has joined IRC (imox!~imox@p4FC5CB1F.dip0.t-ipconnect.de)
14:06freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
14:24Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 252 seconds)
14:44Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net)
14:44Gremble is now known as Guest65515
14:52imox has left IRC (imox!~imox@p4FC5CB1F.dip0.t-ipconnect.de, Quit: imox)
14:58PhoenixSTF has joined IRC (PhoenixSTF!~rudi@78.29.154.124)
15:16alkisg has left IRC (alkisg!~alkisg@ppp089210070222.access.hol.gr, Quit: Leaving.)
15:21alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
15:56NeonLich1 is now known as NeonLicht
16:04alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
16:40imox has joined IRC (imox!~imox@p4FC5CB1F.dip0.t-ipconnect.de)
18:20Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
18:25alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
18:28PhoenixSTF has left IRC (PhoenixSTF!~rudi@78.29.154.124, Quit: Leaving)
18:42imox has left IRC (imox!~imox@p4FC5CB1F.dip0.t-ipconnect.de, Quit: imox)
18:46alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
18:48alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
19:03alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
19:09alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
19:41PhoenixSTF has joined IRC (PhoenixSTF!~rudi@78.29.154.124)
19:42Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
20:12rwvnx 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:16rwvnx is now known as |Paradox|
20:46alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
21:09kwmiebach has joined IRC (kwmiebach!sid16855@gateway/web/irccloud.com/x-tchdovzuxwthdlmd)
22:09telex has left IRC (telex!~telex@freeshell.de, Remote host closed the connection)
22:12telex has joined IRC (telex!~telex@freeshell.de)
22:33Guest65515 has left IRC (Guest65515!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Ping timeout: 246 seconds)
22:34Gremble has joined IRC (Gremble!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net)
22:35Gremble is now known as Guest34699
23:01Guest34699 has left IRC (Guest34699!~Ben@cpc35-aztw23-2-0-cust207.18-1.cable.virginm.net, Ping timeout: 264 seconds)
23:50Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)