1165536006 M * daniel_hozac yep, should be.
1165536026 M * Wonka when's 2.2.0 due?
1165536060 M * Bertl Wonka: we need some feedback from testers ... 2.2.0-rc2 is already out
1165536066 M * hardwire Michael J Freedman are you in here!?
1165536086 M * Wonka Bertl: i can't reboot this box here too often...
1165536095 M * Wonka Bertl: but maybe i'll try at home
1165536107 M * Bertl should work with almost any laptop ...
1165536115 M * Wonka Bertl: problem is, at home i need misdn, which doesn't compile against 2.6.19 yet.
1165536139 M * Wonka my notebook won't get a vserver kernel. 256mb ram, and always about 90% full
1165536288 M * daniel_hozac does a vserver kernel really use 25 MiB more RAM than a vanilla?
1165536293 M * daniel_hozac if so, we're doing something really wrong.
1165536306 M * Wonka dunno.
1165536323 M * Wonka but i won't have the ram to atcually run a vserver
1165536374 M * daniel_hozac well, it shouldn't need a lot of RAM...
1165536397 M * daniel_hozac Bertl: does vc_enter_namespace(xid, vc_get_space_mask() & ~(CLONE_NEWNS|CLONE_FS)) on migrate make sense?
1165536439 M * Bertl no
1165536439 M * Wonka the processes need ram...
1165536458 M * daniel_hozac Bertl: ok, so what did i miss? :)
1165536465 M * Bertl Wonka: a guest can be as lightweight as a single sshd
1165536477 M * Bertl Wonka: do you fear to start sshd on your laptop?
1165536491 M * Wonka Bertl: but would that be useful testing?
1165536508 M * daniel_hozac Wonka: all testing is useful.
1165536512 M * Bertl daniel_hozac: your call masks out NEWNS and FS, I don't think that is intentional
1165536521 M * daniel_hozac well, yes.
1165536529 M * daniel_hozac vnamespace should handle that part.
1165536547 M * daniel_hozac (this is for the userspace implementation of vc_ctx_migrate)
1165536550 M * Bertl so, you want to enter all namespaces, except for NEWNS and FS?
1165536554 M * daniel_hozac right.
1165536568 M * Bertl okay, then that is correct
1165536605 M * Wonka 'nother point: i need my notebook _working_, not possibly crashing...
1165536634 M * Wonka aw f***, i need more hardware
1165536653 Q * harry Ping timeout: 480 seconds
1165536656 M * Bertl Wonka: np with that, but then do not bother us with questions like 'when will it be released ... ' :)
1165536673 M * Wonka :)
1165536693 M * Bertl if I get 10 different reports that it is working properly, we can release that weekend :)
1165536721 M * Wonka 'k...
1165536731 M * Wonka .oO( vserver and UML? )
1165536741 M * Bertl is supposed to work fine
1165536746 M * Wonka 'k
1165536767 M * Bertl and would even count special, as it test a typically untested arch :)
1165536816 M * Wonka *download*
1165536821 M * Bertl daniel_hozac: do you see a problem if I put the interfaces in inode_cmd.h?
1165536834 M * daniel_hozac not at all.
1165536852 M * daniel_hozac Wonka: UML _will_ require quite a bit of RAM though :)
1165536858 M * Bertl would you prefer to pass a 'handle' (open device) or a filename?
1165536880 M * Wonka daniel_hozac: atm, i don't need firefox - biggest memory hog gone
1165536884 M * daniel_hozac i guess filenames would be safer?
1165536907 M * daniel_hozac i assume there are devices that aren't noops to open.
1165536917 A * Wonka needs a 1GB SODIMM fitting this notebook...
1165536918 M * Bertl okay, we have that interface for the attributes, so IMHO it makes sense to use that
1165536942 M * Bertl Wonka: get some virtual memory on your harddisk :)
1165536969 M * Wonka Bertl: hd is damn slow on this crapbook
1165537155 P * stefani I'm Parting (the water)
1165537266 Q * yarihm Quit: Leaving
1165538068 J * harry ~harry@d54C2508C.access.telenet.be
1165538333 M * Bertl daniel_hozac: http://vserver.13thfloor.at/Experimental/delta-dmap-feat01.diff how does that look for you?
1165538383 M * daniel_hozac what's the mask for?
1165538389 M * daniel_hozac and why isn't it in the compat interface?
1165538402 M * Bertl I asked that myself right now :)
1165538417 M * daniel_hozac i guess DATTR_error/default etc. are forthcoming?
1165538429 M * Bertl consider it removed ... yes, will add those
1165538461 M * Bertl well, actually we have 3 options
1165538461 M * daniel_hozac looks good to me then.
1165538480 M * Bertl we can make things like error/default implicit
1165538489 M * Bertl we can make it explicit with some flags
1165538496 M * Bertl we can add a 'type' argument
1165538508 M * daniel_hozac yeah, i realized the implicitability right after hitting enter...
1165538522 M * Bertl the implicit would be to specify NULL and REMAP for defaults
1165538523 M * daniel_hozac the lack of OPEN/CREATE would cause EPERM, right?
1165538528 M * Bertl exactly
1165538538 M * daniel_hozac yeah, so we don't need those then.
1165538559 M * Bertl without remap, the original device will persist
1165538570 M * Bertl (regardless of the specified target)
1165538586 M * daniel_hozac so that's for just allowing access.
1165538594 M * Bertl yep
1165538616 M * Bertl are we missing anything then (except for the mask removal)
1165538629 M * daniel_hozac nope, not that i can think of.
1165538634 Q * harry Read error: Operation timed out
1165538648 M * Bertl okay, I will draft up an interface for the network stuff now
1165538661 M * daniel_hozac ah, shouldn't void __user * in the CONFIG_COMPAT case be compat_uptr_t?
1165538708 J * harry ~harry@d54C2508C.access.telenet.be
1165538718 Q * jayeola Quit: leaving
1165538723 Q * haxier Quit: using sirc version 2.211+KSIRC/1.3.12
1165538840 M * Bertl no, we get that passed as argument
1165538849 M * Bertl (arguments are auto converted)
1165538868 M * Bertl (syscall arguments, that is)
1165538915 M * Bertl we could have eliminated the entire compat stuff when we added 2 more ptr arguments to each vserver syscall :)
1165538989 M * daniel_hozac ah, hehe.
1165539014 M * daniel_hozac is that why strace things vserver takes 5 arguments? :)
1165539022 M * daniel_hozac s/things/thinks/ sigh.
1165539027 M * Bertl does it?
1165539050 M * Bertl if so, then that is wrong ... but I guess it is just a 'default'
1165539071 M * daniel_hozac yeah, i guess so too.
1165539101 M * Bertl ah, btw, you did look at the ipv6 stuff, right?
1165539113 M * daniel_hozac well, only briefly to get it to compile.
1165539132 M * daniel_hozac why?
1165539145 M * Bertl what do you think of keeping two separate match tables one for ipv4 and one for ipv6 and allow to enable/disable them separately with a net flag?
1165539164 M * Bertl that would also simplify ipv6 checks with ipv4 addresses
1165539189 M * Bertl (i.e. ipv4 in ipv6 notation addresses could be checked against ipv4)
1165539249 Q * derjohn2 Ping timeout: 480 seconds
1165539250 M * daniel_hozac hmm, good idea.
1165539251 J * derjohn2 ~aj@dslb-084-058-218-187.pools.arcor-ip.net
1165539277 M * Bertl in this case, we simply do separate interfaces from userspace too
1165539298 M * Bertl one for ipv4 the other for ipv6
1165539374 M * daniel_hozac that lets us keep the structures pretty too.
1165539382 M * Bertl precisely
1165539578 Q * meandtheshell Quit: Leaving.
1165539981 M * Bertl something like this? : http://vserver.13thfloor.at/Experimental/delta-match-feat01.diff
1165540018 M * Bertl type and flags still to come, of course
1165540073 M * daniel_hozac why the uint32_t[4] for the IPv6 addresses?
1165540086 M * Bertl better suggestion?
1165540091 M * daniel_hozac struct in6_addr?
1165540119 Q * derjohn2 Ping timeout: 480 seconds
1165540122 M * daniel_hozac i think the kernel has some functions/macros for dealing with those.
1165540124 M * Bertl why uint32_t for ipv4 then?
1165540130 M * daniel_hozac well, true.
1165540155 M * Bertl I have no problem with in6_addr
1165540162 J * derjohn2 ~aj@dslb-084-058-199-249.pools.arcor-ip.net
1165540206 M * Bertl but it has two implication 
1165540254 M * Bertl we immediately switch from cpu endianess to big endian
1165540270 M * Bertl (i.e. userspace has to do the conversion)
1165540303 M * Bertl and we depend on userspace having the same notion of in_addr/in6_addr
1165540329 M * daniel_hozac hmm.
1165540342 M * daniel_hozac i was certain we were big endian before as well.
1165540359 M * daniel_hozac for IPv6, at least.
1165540369 M * daniel_hozac IPv4, i mean.
1165540378 M * Bertl we should have host endianess
1165540390 M * Bertl maybe we do not, then it is a bug :)
1165540418 M * daniel_hozac i was under the impression addresses were handled as big endian by the kernel.
1165540421 M * Bertl in which case we can easily switch the interfaces and claim it was always this way :)
1165540423 M * daniel_hozac at all times.
1165540461 M * daniel_hozac i guess vcmd should be able to tell.
1165540497 M * Bertl vcmd has code to parse ips in dotted quad
1165540580 M * daniel_hozac ./vcmd -i 666 -ABC net_create_v0 -- ./vcmd -i 666 -AB -C net_add .ip[0]=0x0f000001 .mask[0]=0xff000000 .count=1 .type=1 -- cat /proc/self/ninfo
1165540585 M * daniel_hozac V4Root[0]:      1.0.0.15/0.0.0.255
1165540593 M * daniel_hozac so i'd say the interface is already big endian :)
1165540652 M * Bertl good point
1165540662 M * Bertl actually a strong argument :)
1165540698 M * Bertl unless I do some mapping in vcmd, which I do not know right now ...
1165540714 M * Bertl (but I don't think I do :)
1165540822 M * Bertl well, I do network to host conversion on the dotted quad
1165540873 M * Bertl the question now is, how can that work? :)
1165540899 M * daniel_hozac how can what work?
1165540918 M * Bertl could you try with:
1165540926 M * Bertl .ip[0]=1.2.3.4 ?
1165540938 M * daniel_hozac works fine.
1165540957 M * daniel_hozac ntohl==htonl though.
1165540976 M * daniel_hozac (at least for little/big endian)
1165540987 M * Bertl huh?
1165541003 M * daniel_hozac or is that not what you were talking about?
1165541019 M * daniel_hozac htonl and ntohl do the same thing.
1165541020 M * Bertl vcmd does val = ntohl(val)
1165541042 M * daniel_hozac y = htonl(x); z = ntohl(x); y == z
1165541051 M * Bertl yeah, I agree
1165541067 M * Bertl network order is?
1165541071 M * daniel_hozac MSB.
1165541083 M * Bertl so, big endian, right?
1165541086 M * daniel_hozac right.
1165541096 M * Bertl okay, x86* is little endian, right?
1165541118 M * daniel_hozac right.
1165541132 M * Bertl okay, so we _do_ swap the dotted quad, in vcmd
1165541151 M * daniel_hozac right, as we should.
1165541157 M * Bertl an, now I get what you mean
1165541186 M * Bertl nah, I dont :(
1165541192 M * daniel_hozac hmm?
1165541217 M * Bertl vcmd builds the uint by assembling the quads
1165541232 M * Bertl per definition the quads are little endian
1165541245 M * daniel_hozac how so?
1165541258 M * daniel_hozac 127.0.0.1 should end up as 0x7f0000001, no?
1165541258 M * Bertl the way vcmd assembles them
1165541278 M * Bertl yes, that is little endian, no?
1165541283 M * daniel_hozac no, that's big endian.
1165541285 M * daniel_hozac MSB.
1165541303 M * daniel_hozac (do i have my big/little endian mixed up again? i can never remember which is which...)
1165541325 M * Bertl well, 0x7f,0,0,1 is little endian IMHO
1165541336 M * Bertl while 1,0,0,0x7f would be be
1165541352 M * daniel_hozac why do you say that?
1165541357 J * Aiken_ ~james@tooax8-137.dialup.optusnet.com.au
1165541373 M * Bertl that's how I remember it :)
1165541375 M * daniel_hozac the left most bits are the most significant, right?
1165541426 M * Bertl http://en.wikipedia.org/wiki/Endianess
1165541436 M * daniel_hozac ok, time to read up :)
1165541484 M * Bertl but I guess you're right
1165541501 M * daniel_hozac that seems to support what i'm saying.
1165541534 M * Bertl okay, so what we actually want is htonl() there, right?
1165541547 M * daniel_hozac to be semantically correct, yeah.
1165541555 M * Bertl and the 'interface' currently defines be addresses
1165541568 M * daniel_hozac right.
1165541585 M * Bertl okay, then I see absolutely no reason not to switch
1165541593 M * Bertl to in_addr and in6_addr there
1165541614 M * Bertl would that be a big change for the tools if we 'revise' the interfaces?
1165541640 M * daniel_hozac the current interface? or the new one?
1165541649 M * daniel_hozac though neither should be much of a problem at all.
1165541654 M * Bertl the current, it would stay binary compatible
1165541674 M * daniel_hozac should just be a simple update to the syscall wrapper.
1165541682 Q * Aiken Ping timeout: 480 seconds
1165541689 M * Bertl as we are already in network order, otherwise ppc would fail, if you pass be (unswitched) data
1165541727 M * daniel_hozac right.
1165541752 M * daniel_hozac or well, ppc is where it would work?
1165541767 M * daniel_hozac because it's already be, whereas x86 requires the switching?
1165541787 M * Bertl yeah, but you said, you already pass it in network order
1165541794 M * Bertl (so be always)
1165541817 M * daniel_hozac ah, right.
1165541832 M * Bertl I think the only thing we have to test is x86 + ppc after a switch to in_addr
1165541844 M * daniel_hozac yeah.
1165541845 M * Bertl if it still works, we are fine :)
1165541855 M * daniel_hozac which reminds me, did you get a change to test 0.30.212-rcX on ppc?
1165541869 M * Bertl not yet, x86 and x86_64
1165541878 M * daniel_hozac i _think_ i got the prefix->netmask algorithm right, but i'm not entirely sure.
1165541887 M * Bertl should get to ppc and sparc this weekend
1165541892 M * daniel_hozac (i just couldn't stand the for loop)
1165541952 M * Bertl okay, so we switch from uint32_t (which is wrong) to in_addr for  vcmd_net_addr and friends
1165541976 M * daniel_hozac okay.
1165542155 M * Bertl but I think, the best will be to copy the definition to the cmd, otherwise we end up with varying userspace headers, no?
1165542205 M * Bertl ah, no, I'll check which one are exported first
1165542236 M * daniel_hozac well, i think it's pretty much set in stone.
1165542241 M * Bertl ah, great, in and in6 are there
1165542256 Q * rgl Quit: Fui embora
1165542377 M * daniel_hozac humm. why would vc_enter_namespace return -EACCES?
1165542391 M * daniel_hozac ah, no, EPERM.
1165542393 M * daniel_hozac doh.
1165542421 M * daniel_hozac still doesn't explain... oh! i have to enter the namespace before i migrate, don't i?
1165542425 M * Bertl you mean, vc_enter_space() right? :)
1165542436 M * daniel_hozac well, right :)
1165542460 M * Bertl yes, I'd say, either SETUP or enter spaces first
1165542474 M * Bertl but that should not have changed ...
1165542522 M * Bertl if you enable the switch debugging 
1165542526 M * daniel_hozac nah, just my altered vc_ctx_migrate tried to enter the namespace after migrating.
1165542537 M * daniel_hozac i did ;) that's how i found out which command was actually failing.
1165542549 M * Bertl then you will get a (somewhat) meaningfull explanation
1165542576 Q * Piet_ Quit: Piet_
1165542593 M * Bertl note: some folks might disagree here, that 5 numbers in brackets are meaningfull :)
1165542606 M * daniel_hozac hehe.
1165542613 M * daniel_hozac it's the most meaningful of all :)
1165542626 M * daniel_hozac interpretation is the difficult part, i guess.
1165542644 M * Bertl yeah, but it helped me a lot to figure certain things
1165542725 M * daniel_hozac doh.
1165542730 M * daniel_hozac now that i fixed it, i got an oops.
1165542739 M * Bertl hmm, great!
1165542851 M * Bertl is it a BUG_ON()? or just a dereference?
1165542860 M * daniel_hozac dereference.
1165542879 M * Bertl so I guess I overlooked a special case
1165542882 M * daniel_hozac http://paste.linux-vserver.org/740
1165542910 M * Bertl addr2line of c0136bf2
1165542932 M * daniel_hozac at the bottom ;)
1165542936 M * Bertl btw, your unwind information is partially wrong :)
1165542942 M * Bertl ah, good :)
1165542978 A * Bertl is not used to folks doing that by default :)
1165542983 M * daniel_hozac hehe.
1165542999 M * Bertl ah, yes, the fs is empty
1165543011 M * Bertl and the copy_fs_struct barfs on that
1165543023 M * Bertl we should return EINVAL there too I guess
1165543038 M * Bertl or probably just ignore that one ... 
1165543039 M * daniel_hozac hmm, fs should only be changed on CLONE_FS, i though?
1165543044 M * daniel_hozac +t
1165543052 M * Bertl yeah, the case you hit is this:
1165543061 M * Bertl - context created empty
1165543065 M * daniel_hozac ah, yeah, i see it now.
1165543073 M * Bertl okay, for the lazy folks:
1165543084 M * Bertl - namespace but not fs assigned
1165543095 M * Bertl - enter with all (or including fs)
1165543096 M * daniel_hozac well, no filesystem namespace assigned.
1165543110 M * daniel_hozac just IPC and uts (as done by create_v0).
1165543115 M * Bertl I see two options here:
1165543115 M * daniel_hozac and then enter to IPC and uts.
1165543133 M * Bertl - we simply ignore the fs for this case
1165543140 M * Bertl - we barf out with EINVAL
1165543147 M * Bertl I guess you prefer the former
1165543152 M * daniel_hozac shouldn't we limit copying the fs to the if where it's assigned?
1165543178 M * daniel_hozac IMHO this should leak memory as is.
1165543180 M * Bertl yes, but what do we do on the 'all' case, when there is no fs?
1165543207 M * daniel_hozac well, in that case, i think we should return EINVAL.
1165543210 M * daniel_hozac no?
1165543234 M * daniel_hozac because an 'all' set will set the fs too.
1165543262 M * daniel_hozac and vx_set_space should leak as well.
1165543264 M * Bertl maybe we should take a completely different approach here
1165543287 M * daniel_hozac (copying (possibly unnecessarily) without freeing)
1165543288 M * Bertl I think the best would be to add a mask to the kernel struct
1165543298 M * Bertl (the context struct)
1165543310 M * daniel_hozac of the set namespaces?
1165543312 M * Bertl and set a bit for each 'assigned' space
1165543329 M * Bertl then, when you request the enter, with the mask
1165543343 M * Bertl mask that again, and use the result
1165543354 M * Bertl (and return the result mask, of course)
1165543367 M * daniel_hozac i think i'd prefer the EINVAL.
1165543386 M * Bertl well, it's slightly more complicated
1165543403 M * Bertl for example the following case:
1165543415 M * Bertl - UTS is assigned, but IPC not
1165543428 M * Bertl - you enter the guest with UTS|IPC (or all)
1165543439 M * Bertl what am I supposed to do now?
1165543468 Q * FireEgl Remote host closed the connection
1165543476 M * Bertl with the 'imlicit' mask in the kernel, the latter
1165543491 M * Bertl would return UTS and you would have entered that, but not IPC
1165543510 M * Bertl of course, we can alternatively fail, and return the mask
1165543566 M * daniel_hozac why would you try to enter a guest's namespaces if it doesn't have them?
1165543584 M * Bertl because you have a 'default' enter somewhere?
1165543597 M * Bertl (i.e. enter all assigned spaces)
1165543617 M * daniel_hozac right, okay. but then you should've done the 'default' set as well, no?
1165543640 M * Bertl I don't know, you tell me how that would look/work with util-vserver
1165543663 M * Bertl I'm perfectly fine with returning EINVAL when the subset doesn't match the kernel's view
1165543683 M * Bertl i.e. when spaces are selected, which have not be assigned yet
1165543689 M * daniel_hozac well, UTS|IPC should be set by create_v0, and entered by migrating.
1165543707 M * Bertl we can also do ESRCH in this case?
1165543714 M * daniel_hozac while NS|FS should be set/entered by vnamespace.
1165543718 M * Bertl nah, already used by the vxi
1165543753 M * Bertl so EINVAL when something is specified, which was not assigned, yes?
1165543772 M * daniel_hozac sounds good to me.
1165543847 M * Bertl okay, should have a patch shortly
1165545031 J * FireEgl ~FireEgl@adsl-61-147-76.bhm.bellsouth.net
1165545806 J * proteus proteus@2001:5c0:84dc:1:211:9ff:feca:b042
1165545825 M * Bertl welcome proteus!
1165545900 M * Bertl daniel_hozac: 
1165545903 M * Bertl http://vserver.13thfloor.at/Experimental/delta-space-fix01.diff
1165545921 M * Bertl will add something to the virtual/info/status too
1165545934 M * Bertl (so one can check what it assigned :)
1165545954 M * Bertl the mask is currently defined twice, which will be cleaned up shortly
1165546009 M * Bertl (it's just the version I tested here :)
1165546031 M * daniel_hozac hehe, i was just about to ask about it.
1165546052 M * daniel_hozac looks fine other than that.
1165546081 Q * Johnnie Read error: Connection reset by peer
1165546082 M * Bertl I think, at some point we can merge the set and get
1165546098 M * Bertl set and enter that is
1165546107 M * daniel_hozac yeah, they seem to share a lot of code.
1165546121 M * Bertl but that is something for cleanup
1165546333 Q * proteus Quit: ...
1165546617 M * Bertl http://vserver.13thfloor.at/Experimental/delta-space-fix02.diff
1165546625 M * Bertl ontop of fix01
1165546652 Q * DreamerC_ Quit: leaving
1165546673 J * DreamerC ~dreamerc@59-115-50-39.dynamic.hinet.net
1165546701 J * Johnnie ~jdlewis@jdlewis.org
1165546714 M * Bertl wb DreamerC! Johnnie!
1165547005 M * daniel_hozac Bertl: hmm, i guess the vxi->vx_nsmask should be |=?
1165547020 M * daniel_hozac in vx_set_space.
1165547022 M * Bertl ah, right!
1165547208 Q * FireEgl Remote host closed the connection
1165547322 M * Bertl fixed that one in place, I guess you added it manually
1165547355 M * daniel_hozac yeah.
1165547506 M * daniel_hozac chcontext --xid 666 sleep 30 & cat /proc/virtual/666/status oopses though.
1165547518 M * Bertl ah, paste?
1165547567 M * daniel_hozac http://paste.linux-vserver.org/741
1165547594 M * Bertl hum, on proc reading ... interesting
1165547607 M * daniel_hozac indeed.
1165547639 M * Bertl any compile messages?
1165547658 M * Bertl (maybe my patches got out of sync, was working on three branches at once :)
1165547673 Q * Johnnie Read error: Connection reset by peer
1165547677 M * daniel_hozac no, none.
1165547695 M * daniel_hozac i really don't see what would cause it.
1165547754 J * southtel ~slester@c-76-17-115-183.hsd1.ga.comcast.net
1165547762 M * daniel_hozac is the file too long? that seems unlikely.
1165547776 M * Bertl nah, limit should be a page
1165547782 M * daniel_hozac yeah.
1165547784 M * southtel Is there a "best practices" way to change a vserver's name after it's been created?
1165547795 M * Bertl hey southtel!
1165547814 M * Bertl southtel: which one, the uts name, the guest name or the path?
1165547825 M * southtel In other words, is it safe to just do a find/replace in /etc/vservers and then change the root dir name?
1165547837 M * southtel Bertl: both.
1165547862 M * Bertl is is safe if you get the symlinks right
1165547863 M * southtel (and good evening to you Bertl!)
1165547873 M * Bertl tx
1165547889 M * Bertl daniel_hozac: looks like a miscompilation to me
1165547898 M * daniel_hozac yeah, that's the only way i can explain it.
1165547902 M * Bertl ah, no
1165547914 M * Bertl let me check somethng ...
1165547973 M * Bertl hmm ...
1165548001 M * Bertl you should either get cat: /proc/virtual/666/status: No such file or directory
1165548010 M * Bertl or the correct result
1165548030 M * Bertl but it is not deterministic which one ... so
1165548042 M * Bertl maybe we can get to a state where vxi becomes 0?
1165548053 M * daniel_hozac i'm testing that now.
1165548078 M * daniel_hozac (added a vxdprintk(1, "xid = %u", xid); to proc_vx_info_read)
1165548093 M * Bertl okay
1165548127 M * daniel_hozac cat /proc/virtual/667/status did return ENOENT as expected, so it has to be something else.
1165548146 M * Bertl no, that case is handled in proc_vx_info_read()
1165548174 M * Bertl we lookup the info, (grabbing a referece) then we exit if there is none
1165548192 M * Bertl only case we don't do that is when xid=0
1165548208 M * Bertl (that is the exeption for the toplevel functions)
1165548214 M * daniel_hozac right.
1165548232 M * Bertl maybe we should special case that (and move it out)
1165548249 M * daniel_hozac hmm, works fine now.
1165548269 M * daniel_hozac xid is 666 as expected.
1165548310 M * daniel_hozac must've been a miscompilation or something.
1165548417 M * daniel_hozac well, i'm having problems keeping my eyes open, so i'm gonna get some sleep. good night all!
1165548428 M * Bertl okay, have a good one!
1165548450 J * _dmax ~semaj@bl4-57-153.dsl.telepac.pt
1165548507 J * s0undt3ch_ ~s0undt3ch@81.193.57.153
1165548546 Q * dmax Ping timeout: 480 seconds
1165548551 Q * comfrey Ping timeout: 480 seconds
1165548555 N * _dmax dmax
1165548571 Q * s0undt3ch Ping timeout: 480 seconds
1165548571 N * s0undt3ch_ s0undt3ch
1165549201 Q * southtel Remote host closed the connection
1165549607 J * comfrey ~comfrey@201.243.174.242
1165550567 J * FireEgl ~FireEgl@adsl-61-147-76.bhm.bellsouth.net
1165552085 M * Bertl okay, off to bed now too ... have a good one everyone! and cya!
1165552099 N * Bertl Bertl_zZ
1165552881 Q * hardwire Ping timeout: 480 seconds
1165553088 J * tamitall ~tam@nettam.com
1165554246 Q * comfrey Ping timeout: 480 seconds
1165554954 Q * jpachec Remote host closed the connection
1165559661 J * Aiken__ ~james@tooax6-146.dialup.optusnet.com.au
1165559987 Q * Aiken_ Ping timeout: 480 seconds
1165564288 N * otaku42_away otaku42
1165567340 Q * thunder1 Remote host closed the connection
1165567353 J * thunder1 ~thu@tor-irc.dnsbl.oftc.net
1165567923 J * MJesus pat@14.Red-213-97-177.staticIP.rima-tde.net
1165568496 J * prae ~Benjamin@host.187.57.23.62.rev.coltfrance.com
1165568828 J * dna ~naucki@250-206-dsl.kielnet.net
1165568974 P * MJesus 
1165569106 Q * mrrm Remote host closed the connection
1165569111 J * mrrm ~urkel@tor-irc.dnsbl.oftc.net
1165569309 Q * mrrm Remote host closed the connection
1165569335 Q * prae Quit: Quitte
1165569526 J * mrrm ~urkel@tor-irc.dnsbl.oftc.net
1165570120 Q * phreak`` Quit: leaving
1165570780 Q * shedi Quit: Leaving
1165571020 J * phreak`` ~phreak``@styx.xnull.de
1165571022 Q * derjohn2 Quit: Verlassend
1165571329 J * meandtheshell ~markus@85.124.38.0
1165571988 Q * djrise Read error: Connection reset by peer
1165572925 J * djrise ~djrise2b@109-125.252-81.static-ip.oleane.fr
1165573051 J * DavidS ~david@chello062178045213.16.11.tuwien.teleweb.at
1165573251 J * lilalinux ~plasma@80.69.41.2
1165573873 J * _Rusty ~rusty@a1052.adsl.pool.eol.hu
1165573876 M * _Rusty hello guys :)
1165575618 M * meebey vprocunhide applies to all vservers, correct?
1165576069 J * Piet hiddenserv@tor.noreply.org
1165576441 Q * bj Remote host closed the connection
1165576457 J * bj ~bj@insanefactory.com
1165579247 Q * ensc Killed (NickServ (GHOST command used by ensc_))
1165579257 J * ensc ~irc-ensc@p54B4E0AE.dip.t-dialin.net
1165579588 J * Curus ~Curus@kbhn-vbrg-sr0-vl209-213-185-8-10.perspektivbredband.net
1165579631 M * Curus How is progress on the network virtualization in vserver? I only found an old page with references to obsolete kernel patches
1165580002 Q * Aiken__ Quit: Leaving
1165580093 J * sebastian ~info@pD957E533.dip.t-dialin.net
1165580720 J * comfrey ~comfrey@201.243.174.242
1165580885 Q * lilalinux Remote host closed the connection
1165581049 J * lilalinux ~plasma@80.69.41.2
1165581069 Q * sebastian Ping timeout: 480 seconds
1165581070 J * sebastian ~info@pD957E533.dip.t-dialin.net
1165582051 J * djrise2b ~djrise2b@109-125.252-81.static-ip.oleane.fr
1165582051 Q * djrise Read error: Connection reset by peer
1165583663 J * shedi ~siggi@inferno.lhi.is
1165583893 Q * comfrey Ping timeout: 480 seconds
1165584445 J * virtuoso_ ~s0t0na@shisha.spb.ru
1165584503 Q * virtuoso Read error: Connection reset by peer
1165584612 Q * djrise2b Remote host closed the connection
1165584737 J * comfrey ~comfrey@201.243.174.242
1165584940 M * daniel_hozac util-vserver 0.30.212-rc4: http://people.linux-vserver.org/~dhozac/p/uv/experimental/util-vserver-0.30.212-rc4.tar.bz2
1165584963 M * daniel_hozac should work in a more expected fashion on 2.6.19 than previous versions.
1165584983 M * daniel_hozac any and all feedback would be appreciated.
1165585224 Q * comfrey Ping timeout: 480 seconds
1165585607 J * rgl ~Rui@84.90.8.214
1165585614 A * rgl waves
1165585626 M * daniel_hozac hello
1165586265 M * daniel_hozac Bertl_zZ: i got the proc oops again, xid was 0 this time.
1165586414 M * daniel_hozac it seems to be completely reproducable now.
1165586985 M * Curus What happened to util-vserver rc3?
1165587044 M * daniel_hozac i used it internally for my test builds prior to rc4 :)
1165587167 M * Curus Ah... Are we getting closer to full network virtualization by the way?
1165587190 M * daniel_hozac i.e. virtualized network stack?
1165587254 M * daniel_hozac Bertl_zZ's leaving that to the mainline folks, while 2.3 is getting an improved isolation.
1165587335 M * daniel_hozac (like IPv6 support, per-guest isolated loopback, etc.)
1165587497 M * Curus Ok
1165587519 M * Curus I'm stuck with openvz on a couple of servers
1165587535 M * daniel_hozac why's that?
1165587564 M * Curus I need a virtualized network stack, with routing
1165587569 M * daniel_hozac why?
1165587578 M * Curus Because I'm doing routing with them
1165587591 M * Curus That's their primary purpose in life. Poor man's MPLS
1165587611 J * Johnnie ~jdlewis@jdlewis.org
1165587672 M * daniel_hozac what kind of routing are you doing with them?
1165587756 M * Curus Customers are each getting their own virtual router
1165587805 M * Curus I started with policy routing, but dynamic policy routing is fairly difficult to pull off
1165588070 M * daniel_hozac i guess i'm just dense, but i don't see why i'd want to buy a virtual router :)
1165588774 J * shuri ~shuri@hq01.electronicbox.net
1165589260 Q * _Rusty 
1165589550 M * tamitall This is probably dumb, but where do I find the ln modified to work with vhashify?
1165589565 M * daniel_hozac there is no ln modified to work with vhashify.
1165589613 M * tamitall hm. ok.
1165589620 M * tamitall "ln -0s" uses a Vserver extention to create a unified link. from the wiki
1165589625 M * tamitall led me to think there was.
1165589647 M * tamitall My ln won't take -0s
1165589653 M * daniel_hozac yeah. i have no idea where that comes from
1165589676 M * tamitall a normal soft link is called for then?
1165589685 M * daniel_hozac or well, i know where the ln -0s comes from, but not the explanation.
1165589685 M * daniel_hozac yes.
1165589695 M * tamitall Thank you!
1165589704 M * tamitall Can I ask another one? :D
1165589713 M * daniel_hozac sure.
1165589738 M * tamitall When vhashify'ing.. Should I dedicate a vserver to being the default? or just use the first one I create?
1165589752 M * daniel_hozac the default what?
1165589764 M * tamitall The default hash source
1165589776 M * daniel_hozac the upside of hashification is that you don't need a reference server, as you do with unification.
1165589781 M * tamitall I'm still trying to wrap my head around this, sorry.
1165589800 M * tamitall Ok, I suspected that, but had not yet gotten to that conclusion yet.
1165589815 M * daniel_hozac just run vserver <guest> hashify for all your guests on a regular basis, and they should be hashified.
1165589838 M * daniel_hozac (and find /vservers/.hash -links 1 -print0 | xargs -0 rm -f to clean up unused files)
1165589855 M * tamitall Thank you!
1165589957 M * daniel_hozac np.
1165590164 P * otaku42 
1165590192 Q * thunder1 Remote host closed the connection
1165590221 J * thunder1 ~thu@tor-irc.dnsbl.oftc.net
1165590439 J * Thiago ~w0w@200-158-228-232.dsl.telesp.net.br
1165590459 Q * Thiago 
1165591684 M * Curus daniel_hozac: You would like a virtual router when you're leasing a bunch of lines from us and want routing between them. Well unless you'd like to pay $$$$ and get a real router
1165591748 M * Curus (Plus rent of rack space and electricity)
1165591880 M * DavidS Curus: why not xen? there each domain has a whole kernel, and for routing you'll only need minimal ram per domain ...
1165591985 M * Curus Minimal RAM would be something like 40MB dedicated
1165592001 M * Curus That quickly gets out of hand
1165592028 M * Curus And the CPU caches won't like all the context switching
1165592060 M * DavidS hmm .. you probably have a few more customers than i was thinking about ...
1165592069 Q * DavidS Quit: Leaving.
1165592126 M * derjohn Curus, maybe UML ....
1165592142 M * daniel_hozac or, you know, OpenVZ :)
1165592171 M * cehteh Curus: i played with linux bridge devices to give each vserver a own interface which is routeable
1165592172 M * derjohn or muliple routing tables ....
1165592181 M * cehteh dunno if that scales
1165592201 M * Curus They need more than one interface
1165592247 M * cehteh thats not the problem .. you can create many bridges in linux dynamically .. i just dont know their overhead
1165592332 M * Curus Ok, but the routing table is still in the host kernel
1165592343 M * cehteh yes
1165592355 M * daniel_hozac that's true for OpenVZ as well ;)
1165592358 M * Curus That's not useful, I need to manipulate routing from the guests
1165592362 M * Curus Well true
1165592375 M * Curus But with openvz it LOOKS like the routing is in the guest
1165592391 M * cehteh with some effort you can do that with vserver too
1165592442 M * Curus I don't believe I can get away with doing ip route add ... in the guest
1165592448 M * cehteh without kernel changes ... just userland tool i would say
1165592449 M * Curus Except in ngnet perhaps
1165592480 M * Curus The vserver kernel doesn't do routing virtualization, so you're back to policy routing
1165592488 M * cehteh writing a 'ip' replacement which delegates the call to the host kernel .. verifies it and then applies it there
1165592500 M * cehteh yes sure
1165592552 M * cehteh virtual network isnt there .. so you need to think about another solution 
1165592564 M * Curus Well the other solution is openvz so far
1165592571 M * cehteh then go with it
1165592578 M * Curus I was just curious about when I could switch
1165592585 M * Curus I'm not exactly an openvz fan
1165592614 M * Curus We're using vserver for other servers, and it works beautifully.
1165592618 M * cehteh dunno if a bounty for ngnet is up and you want to put something in the bucket
1165592657 M * cehteh so you can either wait for it, or pay for it i would say
1165594011 M * daniel_hozac as always ;)
1165595733 N * Bertl_zZ Bertl
1165595738 M * Bertl morning folks!
1165595750 M * daniel_hozac morning Bertl!
1165595766 Q * sebastian Ping timeout: 480 seconds
1165595846 J * sebastian ~info@pD957E17B.dip.t-dialin.net
1165595855 M * Bertl Curus: who does administrate the guests?
1165595905 M * Bertl I mean, are there 3rd party admins with root capabilities on those guests?
1165596197 J * stefani ~stefani@tsipoor.banerian.org
1165596215 M * Bertl welcome stefani! LTNS!
1165596229 M * stefani hola.  yes.  work. 
1165596253 M * Bertl daniel_hozac: could you try the http://vserver.13thfloor.at/Experimental/delta-proc-fix01.diff
1165596271 M * Bertl (regarding the proc issue)
1165596274 M * daniel_hozac well, i'm unable to reproduce it now since i rebooted to a kernel with more debugging printks...
1165596304 M * Bertl IMHO it should be fixed there, but yes, proc is kind of racy atm :)
1165596448 M * daniel_hozac shouldn't we be returning -ENOENT or so on !vxi?
1165596459 M * Bertl probably
1165596579 M * Bertl okay, off for dinner now ... back shortly
1165596586 N * Bertl Bertl_oO
1165597678 N * Bertl_oO Bertl
1165597699 M * daniel_hozac wb
1165598219 M * Bertl okay, I'm translocating now ... will be back later ...
1165598268 N * Bertl Bertl_oO
1165599227 J * the_hydra ~a_mulyadi@202.59.168.29
1165601548 Q * Johnnie Ping timeout: 480 seconds
1165601681 J * bonbons ~bonbons@83.222.39.117
1165602040 M * tamitall Why is my vyum ignoring my /etc/yum.conf on my host?
1165602044 M * tamitall any ideas?
1165602048 M * daniel_hozac because that's not the file it uses.
1165602061 M * tamitall ahah!
1165602092 M * daniel_hozac for already installed guests, see /vservers/.pkg/<guest>/yum/etc/yum.conf
1165602120 M * tamitall thank you.
1165602171 Q * virtuoso_ Ping timeout: 480 seconds
1165602365 Q * Smutje Remote host closed the connection
1165602378 J * Smutje ~Smutje@xdsl-87-78-98-134.netcologne.de
1165603030 J * matti matti@linux.gentoo.pl
1165603121 J * Johnnie ~jdlewis@jdlewis.org
1165603169 Q * the_hydra Quit: gtg people
1165603706 Q * Johnnie Ping timeout: 480 seconds
1165604211 Q * Smutje Ping timeout: 480 seconds
1165604238 J * Johnnie ~jdlewis@jdlewis.org
1165604422 J * Smutje ~Smutje@xdsl-87-78-98-134.netcologne.de
1165604538 Q * matti Ping timeout: 480 seconds
1165604756 Q * Johnnie Ping timeout: 480 seconds
1165605022 J * matti matti@linux.gentoo.pl
1165605278 M * Snow-Man OOPS in vc_wait_exit?
1165605284 M * Snow-Man 2.6.18-3
1165605292 M * Snow-Man Debian/vserver
1165605308 M * daniel_hozac you too? that's very interesting.
1165605316 M * daniel_hozac do the Debian kernels have debugging information available?
1165605316 M * Snow-Man amd64, still busted?
1165605329 M * Snow-Man I can post a full oops...
1165605345 M * daniel_hozac well, IIRC ensc posted that Oops to the pastebin.
1165605355 M * daniel_hozac but his kernel was undebuggable.
1165605356 M * Snow-Man hrmpf.
1165605357 M * daniel_hozac but please do.
1165605360 M * Snow-Man ok.
1165605369 M * Snow-Man Where?
1165605373 M * daniel_hozac paste.linux-vserver.org
1165605393 J * virtuoso ~s0t0na@shisha.spb.ru
1165605469 M * Snow-Man http://paste.linux-vserver.org/743
1165605478 M * daniel_hozac waldi: is the unstripped vmlinux available somewhere for the Debian kernels?
1165605538 M * Snow-Man aratan:~# file /boot/vmlinuz-2.6.18-3-vserver-amd64
1165605538 M * Snow-Man /boot/vmlinuz-2.6.18-3-vserver-amd64: Linux kernel x86 boot executable RO-rootFS, root_dev 0x801, swap_dev 0x1, Normal VGA
1165605548 M * daniel_hozac that's the bzImage.
1165605566 M * daniel_hozac the vmlinux should be something like 50 MiB.
1165605567 M * Snow-Man Got the System.map and whatnot too, if it helps..
1165605579 M * Snow-Man heh, definitely not in the deb.
1165605585 M * daniel_hozac well, the symbols are in the trace already.
1165605599 M * daniel_hozac it's more a question of where in the functions, although i already have a pretty good idea...
1165605610 M * waldi daniel_hozac: no
1165605635 M * Snow-Man It was during a 'vserver xxx stop'
1165605638 M * daniel_hozac yeah.
1165605644 M * daniel_hozac waldi: okay, too bad.
1165605649 M * waldi daniel_hozac: why?
1165605656 M * daniel_hozac Snow-Man: is it at all reproducible?
1165605665 M * Snow-Man Dunno, just got it
1165605667 M * daniel_hozac waldi: no addr2line?
1165605679 M * Snow-Man We'll try in a sec.
1165605740 M * waldi daniel_hozac: System.map?
1165605751 M * daniel_hozac waldi: how will that tell me what line it is?
1165605758 M * waldi ah, it will not
1165605762 M * daniel_hozac waldi: as i said, we already know which symbols.
1165605850 J * Simbalin ~Simba@deb30.mgts.by
1165605854 M * daniel_hozac (well, sort of. vc_wait_exit doesn't call add_wait_queue, __wait_exit does)
1165605951 J * Johnnie ~jdlewis@jdlewis.org
1165606318 J * Johnsie ~jdlewis@jdlewis.org
1165606498 Q * Johnnie Ping timeout: 480 seconds
1165606528 J * _dmax ~semaj@bl9-225-176.dsl.telepac.pt
1165606575 Q * Johnsie 
1165606596 Q * dmax Ping timeout: 480 seconds
1165606599 N * _dmax dmax
1165606691 Q * s0undt3ch Ping timeout: 480 seconds
1165606998 J * Johnnie ~jdlewis@jdlewis.org
1165607208 J * s0undt3ch ~s0undt3ch@bl9-225-176.dsl.telepac.pt
1165607429 M * Snow-Man daniel_hozac: reproducable
1165607449 M * Snow-Man Just got it again, basically the same thing.
1165607459 M * Snow-Man Happens on one box but not on another.
1165607470 M * Snow-Man Which are damn near identical machines. :(
1165607614 M * daniel_hozac well, that's interesting.
1165607621 M * daniel_hozac same kernel?
1165607887 M * Snow-Man yes
1165607896 M * Snow-Man Exactly the same package set on the hosts
1165607900 Q * Smutje Remote host closed the connection
1165607912 M * Snow-Man the system that oops is running, in the vserver, apache and postgres
1165607912 J * Smutje ~Smutje@xdsl-87-78-98-134.netcologne.de
1165607918 M * Snow-Man The system that doesn't is running, in the vserver, sshd
1165607957 M * daniel_hozac how long does it take from vserver ... stop to oops?
1165607971 M * Snow-Man It happens during the stop
1165607996 M * daniel_hozac so just a second or below from the time you hit enter to oops?
1165607996 M * Snow-Man Like, maybe a second after the 'stop' has started, but before it finishes?  I'll double-check
1165608207 M * Snow-Man yea
1165608229 M * daniel_hozac ok.
1165608388 M * Snow-Man hmmm.
1165608424 M * Snow-Man entering the vserver, stopping apache & postgres, then logging out, also caused the oops
1165608440 M * daniel_hozac the same one?
1165608538 M * Snow-Man Not 100% sure, but think so, sec.
1165608542 J * shedii ~siggi@inferno.lhi.is
1165608589 Q * shedii 
1165608604 M * Snow-Man http://paste.linux-vserver.org/744
1165608608 M * Snow-Man That was the one from the logout, I think
1165608632 M * Snow-Man Just got an oops with just apache2 having been started, when doing a stop
1165608640 M * Snow-Man Gonna try w/ just PG now
1165608650 M * Snow-Man rebooting takes too damn long. :)
1165608748 M * daniel_hozac looks like that paste is missing the first few lines.
1165608807 M * Snow-Man That's where it started in syslog, sorry. :(
1165608835 M * daniel_hozac no worries, i think i know what it said...
1165608872 Q * s0undt3ch Read error: Operation timed out
1165608874 Q * shedi Ping timeout: 480 seconds
1165608896 M * Snow-Man k
1165608936 Q * dmax Ping timeout: 480 seconds
1165608998 M * daniel_hozac ah!
1165609001 M * daniel_hozac okay, got it.
1165609010 M * daniel_hozac would it be possible for you to test a fix?
1165609012 M * Snow-Man oh?
1165609014 M * Snow-Man sure!
1165609218 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/delta-cacct-fix01.diff
1165609224 M * daniel_hozac it's not compile tested yet though.
1165609228 M * matti daniel_hozac: How are you :)
1165609240 M * daniel_hozac matti: fine thanks, you?
1165609261 M * matti Fine, fine, thanks :)
1165609370 M * Snow-Man Gonna take a few to rebuild, etc.
1165611289 J * DavidS ~david@chello062178045213.16.11.tuwien.teleweb.at
1165611533 Q * lilalinux Remote host closed the connection
1165611536 Q * Simbalin Ping timeout: 480 seconds
1165611940 J * Aiken ~james@tooax8-021.dialup.optusnet.com.au
1165612070 Q * Johnnie Read error: Connection reset by peer
1165612303 J * Simbalin ~Simba@deb30.mgts.by
1165612332 J * shedi ~siggi@inferno.lhi.is
1165613354 Q * bonbons Quit: Leaving
1165614019 M * Snow-Man Dude, is this kernel ever going to finish compiling?
1165614091 J * Piet_ hiddenserv@tor.noreply.org
1165614173 M * Snow-Man wtf
1165614176 M * Snow-Man make[2]: *** [debian/stamps/build-amd64-vserver-amd64-kernel-package] Error 1
1165614182 M * Snow-Man :(
1165614257 M * Snow-Man So much for that, and I don't even know wtf went wrong
1165614283 N * Bertl_oO Bertl
1165614288 M * Bertl back now ...
1165614294 M * Snow-Man happened right after what looks like the System.map
1165614298 M * Bertl Snow-Man: maybe out of disk space?
1165614305 M * Snow-Man /dev/mapper/vg0-data   99G  4.5G   90G   5% /data
1165614309 M * Snow-Man Don't think so...
1165614316 M * Snow-Man tmpfs                 256M     0  256M   0% /tmp
1165614322 M * Snow-Man Unless it needs more than that..
1165614344 M * Bertl well, check the logs
1165614353 M * Snow-Man yeah, uh, ok, *what* logs, exactly? :)
1165614373 M * Bertl guess debian has build logs ... no idea where they are though
1165614400 M * Snow-Man me neither, heh, and I don't know that they do unless you actively redirect stdout/stderr during the build process
1165614426 M * Snow-Man Oh well, I gotta head out.
1165614434 M * Bertl well, check out #debian then, or RTFM :)
1165614436 M * Snow-Man Rebuilding w/ a log of stdout/stderr
1165614438 M * Snow-Man pah
1165614446 M * Snow-Man waldi knows, but he's not paying attention
1165614464 M * Snow-Man anyway, not gonna wait for this thing to recompile, I'll check the fix on Monday.
1165614471 M * Snow-Man Bertl: Did you see the fix from daniel_hozac, btw?
1165614475 M * Snow-Man http://people.linux-vserver.org/~dhozac/p/k/delta-cacct-fix01.diff
1165614483 M * Snow-Man Hoping it'll fix the oopsen I've been getting.
1165614510 M * waldi Snow-Man: what?
1165614522 M * Snow-Man waldi: Debian build system keep a log somewhere for me?
1165614526 Q * Piet Ping timeout: 480 seconds
1165614530 M * Snow-Man When just doing a dpkg-buildpackage?
1165614532 M * waldi if you use debuild, it is in ..
1165614538 M * Snow-Man heh.
1165614546 M * Snow-Man Got an error right after what looked like the system.map or something.
1165614552 M * Snow-Man zl10353_write                                    version: 0x354515dc -> 0xeee97d66
1165614555 M * Snow-Man zone_table                                       version: 0x52c88b2a -> 0x0f9da8a1
1165614558 M * Snow-Man etc
1165614559 M * Bertl Snow-Man: that looks like for an older kernel, I think all recent versions should have that already
1165614570 M * waldi Snow-Man: you add a patch?
1165614574 M * Snow-Man waldi: yes
1165614580 M * daniel_hozac Bertl: no, it's missing in 2.0.2.2-rc8.
1165614581 M * Snow-Man err, well, hacked an existing one, heh.
1165614596 M * Bertl daniel_hozac: really?
1165614598 M * waldi Snow-Man: change the abiname setting in debian/arch/defines
1165614598 M * Snow-Man daniel_hozac: Which, of course, is what Debian's using, hehe. :)
1165614603 M * daniel_hozac Bertl: indeed.
1165614607 M * Bertl daniel_hozac: but it is in the other branches, yes?
1165614625 M * Snow-Man waldi: Bump it to 4 you mean?
1165614646 M * waldi Snow-Man: no, use a personal identifier or you'll get in trouble when we use 4
1165614649 M * daniel_hozac Bertl: yeah.
1165614682 M * Snow-Man Looks like I need to do a clean or something?
1165614686 M * Snow-Man This target is made to fail intentionally, to make sure
1165614686 M * Snow-Man etc
1165614710 M * Snow-Man oh, hah, yea, so now I actually *read* it..
1165614899 M * Snow-Man mkay, compiling will reboot/test on monday, thanks!
1165616217 Q * shuri Remote host closed the connection
1165617082 Q * sebastian 
1165618930 M * daniel_hozac okay, i consider 0.30.212 to be ready... unless someone tells me otherwise, i'll be releasing it in a couple of hours...
1165618981 M * Bertl sounds good, should be able to test it in 2-3 hours on ppc
1165619003 M * daniel_hozac ok, thanks.
1165619322 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/uv/experimental/util-vserver-0.30.212-rc5.tar.bz2 has an important fix from -rc4 (migrating to spectator didn't work).
1165619416 M * daniel_hozac which i guess means nobody has had time to test it yet :)
1165619434 Q * meandtheshell Quit: Leaving.
1165619824 Q * DavidS Quit: Leaving.
1165620287 Q * rgl Quit: Fui embora
1165621106 J * DavidS ~david@chello062178045213.16.11.tuwien.teleweb.at
1165622207 Q * DavidS Read error: Connection reset by peer