1174090716 Q * FireEgl Quit: ...
1174093797 N * DoberMann DoberMann[ZZZzzz]
1174094478 Q * yarihm Quit: Leaving
1174098989 Q * softi42 Ping timeout: 480 seconds
1174100081 J * softi42 ~softi@p549D7398.dip.t-dialin.net
1174104393 Q * ensc Killed (NickServ (GHOST command used by ensc_))
1174104403 J * ensc ~irc-ensc@p54B4F2F9.dip.t-dialin.net
1174107963 J * FireEgl Proteus@adsl-61-136-122.bhm.bellsouth.net
1174108696 J * DoberMann_ ~james@AToulouse-156-1-143-91.w90-30.abo.wanadoo.fr
1174108808 Q * DoberMann[ZZZzzz] Ping timeout: 480 seconds
1174118705 Q * s0undt3ch Read error: Operation timed out
1174120694 J * besonen__ ~besonen@209-180-234-92.eugn.qwest.net
1174120793 Q * tokkee Read error: Operation timed out
1174120860 Q * CHTEKK osmotic.oftc.net oxygen.oftc.net
1174120860 Q * michal` osmotic.oftc.net oxygen.oftc.net
1174120860 Q * renihs osmotic.oftc.net oxygen.oftc.net
1174120860 Q * derjohn osmotic.oftc.net oxygen.oftc.net
1174120860 Q * matti_ osmotic.oftc.net oxygen.oftc.net
1174120860 Q * besonen_ osmotic.oftc.net oxygen.oftc.net
1174120860 Q * cdrx osmotic.oftc.net oxygen.oftc.net
1174120860 Q * ruskie osmotic.oftc.net oxygen.oftc.net
1174120860 Q * micah osmotic.oftc.net oxygen.oftc.net
1174120911 J * matti matti@acrux.romke.net
1174120931 J * CHTEKK ~chtekk@84.55.211.45
1174120931 J * renihs ~penguin@83-65-34-34.arsenal.xdsl-line.inode.at
1174120931 J * derjohn ~derjohn@80.69.41.3
1174120931 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net
1174120931 J * micah ~micah@micah.riseup.net
1174120932 N * matti Guest127
1174120981 J * tokkee tokkee@ssh.faui2k3.org
1174120993 Q * renihs Read error: Operation timed out
1174121001 J * michal` ~michal@www.rsbac.org
1174121016 J * renihs ~penguin@83-65-34-34.arsenal.xdsl-line.inode.at
1174121041 J * ruskie ruskie@ruskie.user.oftc.net
1174122495 J * bonbons ~bonbons@83.222.39.9
1174122507 Q * phedny Ping timeout: 480 seconds
1174122524 J * phedny ~mark@ip56538143.direct-adsl.nl
1174123386 J * dna ~naucki@p54BCCD7F.dip.t-dialin.net
1174123582 Q * dghill Ping timeout: 480 seconds
1174123844 J * meandtheshell ~markus@85-124-206-19.dynamic.xdsl-line.inode.at
1174124475 J * dghill dghill@office.mel.illuminate.com.au
1174127148 J * User_MakSimka ~netu@89.20.97.66
1174127305 P * User_MakSimka 
1174127640 Q * Aiken Quit: Leaving
1174128531 Q * nebuchadnezzar Remote host closed the connection
1174128877 Q * dghill Ping timeout: 480 seconds
1174130290 Q * michal` Ping timeout: 480 seconds
1174130383 N * DoberMann_ DoberMann
1174130707 J * michal` ~michal@www.rsbac.org
1174131836 N * Guest127 matti
1174131877 J * ema ~ema@rtfm.galliera.it
1174132418 N * Bertl_zZ Bertl
1174132422 M * Bertl morning folks!
1174135528 Q * phreak`` Quit: leaving
1174135830 M * phedny hi Bertl 
1174135836 M * phedny (after an hour)
1174135942 M * neuralis Bertl: morning
1174136299 J * phreak`` ~phreak``@deimos.barfoo.org
1174136679 M * Bertl neuralis: good morning!
1174136692 M * Bertl hey phedny!
1174137034 M * Bertl neuralis: how's it going?
1174137059 M * neuralis busy, haven't slept in a while, etc
1174137072 M * neuralis hopefully i'll take a nap in a few minutes
1174137097 M * neuralis we should have the patches merged in our kernel any day now
1174137111 M * Bertl ah, then have a good nap and let me know if you need anything
1174137128 M * neuralis the mail i sent you was because greg wanted to know what he could work on to help us out, and our answer was "get vserver upstream" :)
1174137150 M * Bertl ookay ....
1174137184 M * neuralis he doesn't feel like he knows enough about the area to work on it, so he'll be working on driver stuff for now
1174137245 M * neuralis but i wanted you to know where the e-mail came from (_i_ knew the answers to the faqs you sent, but your response was still useful to everyone else on the cc list
1174137248 M * neuralis )
1174137259 M * Bertl makes sense ... it might make sense to advocate L3 isolation towards mainline
1174137296 M * neuralis aye
1174137306 M * Bertl because currently the tendancy goes like this: L2 Virtualization does all we need, and we can ignore havin some overhead on fast machines ...
1174137326 M * Bertl (forgetting about embeded systems and such :)
1174137362 M * neuralis yeah, that was the response that i attacked in the previous mail on which you weren't ccd ;)
1174137363 M * Bertl but let's postpone that until you got some sleep .. yes?
1174137367 M * neuralis yeah
1174137374 M * neuralis talk to you soon.
1174137377 A * neuralis &
1174138048 Q * ema Quit: leaving
1174138206 M * harry Bertl: is there an eta for 2.2.0?
1174138308 M * Bertl harry: any time now
1174138323 M * harry ow, so it's like the any key ;)
1174138328 M * Bertl there are two things I'm currently investigating
1174138352 M * harry i'd say, which ones, maybe i can help, but i have to be off in like 10 mins or so
1174138355 M * Bertl if they turn out fine for 2.2.0, I think we do a release this weekend
1174138358 M * harry so i'd be useless :)
1174138376 M * Bertl the issue reported with 2.6.16 on the ML
1174138389 M * Bertl and the utime patch from daniel_hozac 
1174138443 M * daniel_hozac the utime patch should be fine.
1174138450 M * daniel_hozac it's the same changes we did for utimes.
1174138469 M * harry ow btw, i see you reverted the TAST_SIZE/3*2 patch :)
1174138487 M * harry for... i can't remember what it was
1174138495 M * daniel_hozac it shouldn't have been there for a long tinme.
1174138516 M * harry as i said more than a year ago :)
1174138534 M * harry it's never been there in my patches :)
1174138538 M * harry well... it was in the first :)
1174138575 M * Bertl it was useful back with the memory splits
1174138594 M * Bertl daniel_hozac: so you think we should add that to 2.2.x?
1174138607 M * Bertl (i.e. you consider it safe)
1174138868 M * daniel_hozac yeah, i think it's safe.
1174138995 M * daniel_hozac let me make sure though, i don't remember how much i tested it.
1174139353 M * Bertl okay, np, just let me know ...
1174139554 J * shuri ~shuri@QUBCPQ14-1168110898.sdsl.bell.ca
1174139570 M * shuri Hi
1174139579 M * shuri ltns
1174139853 M * Bertl hey shuri! how's going?
1174139947 M * daniel_hozac Bertl: i can't find anything wrong with it.
1174140022 M * shuri fine Bertl  thx :)
1174140203 J * shedi ~siggi@ftth-237-144.hive.is
1174140606 M * Bertl daniel_hozac: okay, then we include it in a final rc18
1174140620 M * daniel_hozac sounds good.
1174140632 M * Bertl I should have results for the ML issue in an hour or so
1174140666 M * daniel_hozac okay, thanks.
1174140673 M * daniel_hozac i was meaning to look at that.
1174140706 M * Bertl can't hurt if we both do :)
1174140819 M * daniel_hozac indeed.
1174140828 M * daniel_hozac do you have any pointers?
1174140838 M * daniel_hozac or should i just start from scratch?
1174140852 M * Bertl not yet, I'm compiling and testing the 2.6.16.* atm
1174140862 M * daniel_hozac okay.
1174140876 M * daniel_hozac so confirmed to not happen on recent releases?
1174140886 M * Bertl not yet either ...
1174140895 M * Bertl I first want to confirm it happen on old releases :)
1174140934 M * daniel_hozac hehe, good idea.
1174140967 M * daniel_hozac does seem to happen on the 2.6.20.1-vs2.2.0-rc15 i had booted on my test box.
1174141039 M * Bertl ah, okay, so you can confirm it for 2.2.0 on recent too
1174141177 M * daniel_hozac i think it's due to a NULL dev.
1174141195 M * daniel_hozac (in dev_in_nx_info)
1174143038 M * daniel_hozac Bertl: http://people.linux-vserver.org/~dhozac/p/k/delta-NULL-dev-fix01.diff seems to fix it here.
1174143531 Q * dev-zero Remote host closed the connection
1174143572 M * Bertl daniel_hozac: okay, sounds reasonable, but please combine that in one check
1174143593 M * Bertl daniel_hozac: unless we want to return 0 in the !dev case
1174143618 M * Bertl I think it also makes sense to do the dev check first
1174143629 M * Bertl because if inlined that will save the context dereference
1174144481 J * nebuchadnezzar ~nebu@zion.asgardr.info
1174144827 M * Bertl welcome nebuchadnezzar!
1174144940 M * nebuchadnezzar hi Bertl 
1174147518 M * Bertl daniel_hozac: IMHO if (!dev) goto out; might be more appropriate?
1174147582 M * daniel_hozac Bertl: wouldn't that require setting ret to 1 first?
1174147600 M * Bertl the question is, do we really want to return 1 in this case?
1174147603 M * daniel_hozac the !dev || !nxi seems best to me.
1174147616 M * daniel_hozac hmm, why wouldn't we?
1174147630 M * daniel_hozac why would we want to hide an interface that isn't an interface?
1174147641 M * Bertl well, the kernel is asking if a (non existing) device is part of that context
1174147658 M * Bertl my first thought would be to answer 'no'
1174147705 M * Bertl the next question IMHO is:
1174147714 M * Bertl would returning 0 change the current behaviour?
1174147736 M * Bertl my first impression here would be: no, except for avoiding the oops :)
1174147791 M * daniel_hozac sure.
1174147823 M * daniel_hozac but then the route would look strange, i think.
1174147853 M * Bertl okay, do we currently have cases where dev==0 works without oopsing?
1174147887 M * daniel_hozac we can't. that should always oops, unless there's no network context.
1174147889 M * Bertl IMHO no, because the oops probably happens here:
1174147892 M * Bertl         struct in_device *in_dev = dev->ip_ptr;
1174147905 M * Bertl in __in_dev_get_rcu()
1174147927 M * daniel_hozac right.
1174147931 M * Bertl okay, so in the case we have no network context, we return 1
1174147948 M * Bertl which is perfectly fine, yes?
1174147954 M * daniel_hozac definitely.
1174147996 M * Bertl so, we are talking about a case, which didn't give anything (except an oops) before
1174148007 M * Bertl and you still think the route will look strange?
1174148034 M * Bertl I'm fine with testing both cases and comparing the results
1174148061 M * daniel_hozac in the cases where routes with no interface is used (i.e. reject routes), yes.
1174148100 M * Bertl how do we know that they belong to/are relevant for the guest
1174148115 M * Bertl are they checked via ip separately?
1174148135 M * daniel_hozac routeS?
1174148182 M * Bertl we do the dev check to avoid routes and other stuff which do not affect the guest, right?
1174148229 M * daniel_hozac hmm, do we? IMHO it's merely hiding the interface names which aren't available in the guest.
1174148254 M * daniel_hozac net/ipv4/fib_hash.c:fib_seq_show
1174148317 M * daniel_hozac well, it's hiding a bit more stuff.
1174149009 Q * infowolfe Read error: Connection reset by peer
1174149235 M * Bertl daniel_hozac: how does internalize/externalize work?
1174149256 M * daniel_hozac pkgmgmt?
1174149261 M * Bertl or more precisely, if I have a guest with internal rpm databases
1174149272 M * Bertl which was created from a template (tar)
1174149284 M * Bertl can I still externalize that?
1174149304 M * Bertl and if, how do I tell it that it is rpm based?
1174149305 M * daniel_hozac i think so, assuming the db versions are compatible...
1174149378 M * daniel_hozac echo mandrake > /etc/vservers/<guest>/apps/pkgmgmt/style should do it, i think.
1174149452 M * Bertl okay, let's try that then ...
1174149471 M * daniel_hozac i guess mandriva has a /etc/mandriva-release these days?
1174149478 M * Bertl probably
1174149495 M * Bertl actually they still have both
1174149508 M * Bertl mandrakelinux-release, mandrake-release, mandriva-release
1174149523 M * daniel_hozac hmm, so the check should work then...
1174149558 M * Bertl hmm
1174149562 M * Bertl # vserver mdv001 pkgmgmt externalize
1174149562 M * Bertl Vserver 'mdv001' has already external packagemanagment; skipping it...
1174149584 M * Bertl am I supposed to the the echo after externalizing?
1174149658 M * Bertl # vrpm mdv001 -- -qa
1174149658 M * Bertl Can not find file for 'RPMSTATEDIR'; aborting
1174149679 M * daniel_hozac do you have a /etc/vservers/<guest>/apps/pkgmgmt/internal?
1174149691 M * daniel_hozac (i've never used externalize before, so this is all rather new to me)
1174149714 M * Bertl nope, but you can check yourself, if you like
1174149746 M * Bertl maybe template based builds should default to internal?
1174149759 M * Bertl it might also be helpfull to allow specifying a distr
1174149761 M * Bertl +o
1174149783 M * daniel_hozac for style?
1174149802 M * Bertl yeah, maybe?
1174149811 M * daniel_hozac i'd prefer to just add distributions to the script, so it's automatic.
1174149863 M * daniel_hozac so if you create internal, are you able to externalize it?
1174149884 M * Bertl how do I create an internal from a template?
1174149897 M * Bertl ah, you mean just the file
1174149932 M * daniel_hozac rather peculiar that it's not able to figure out the distribution on its own though...
1174149988 M * daniel_hozac or did i just assume that?
1174149990 M * Bertl at least the externalize did work with the file
1174150002 M * daniel_hozac did you get "Can not determine packagemanagement style" before?
1174150008 M * Bertl vrpm mdv001 -- -qa
1174150008 M * Bertl secure-mount: chdir("/.rpmdb"): No such file or directory
1174150027 M * Bertl daniel_hozac: nope
1174150085 M * daniel_hozac did you get any errors before putting mandrake in the file, or were you just asking how to use it?
1174150095 M * Bertl strange thing is, now I have a dir
1174150102 M * Bertl /vservers/.pkg/rpm
1174150118 M * Bertl which seems to contain some stuff, but shouldn't that be per guest?
1174150127 M * daniel_hozac indeed...
1174150139 M * Bertl well, it definitely isn't right now :)
1174150377 M * Bertl and internalize doesn't work now either (same error)
1174150377 M * Bertl so I consider that a bug (or at least missing feature :)
1174150377 M * daniel_hozac definitely. i'll look in to it.
1174150428 M * Bertl thanks!
1174154421 Q * shuri Ping timeout: 480 seconds
1174155410 J * ema ~ema@rtfm.galliera.it
1174155642 J * duckx ~Duck@tox.dyndns.org
1174155837 N * DoberMann DoberMann[PullA]
1174157742 Q * duckx Remote host closed the connection
1174157927 J * duckx ~Duck@tox.dyndns.org
1174158102 Q * meandtheshell Remote host closed the connection
1174158269 J * meandtheshell ~markus@85-124-38-134.dynamic.xdsl-line.inode.at
1174158599 Q * duckx Remote host closed the connection
1174158759 J * duckx ~Duck@tox.dyndns.org
1174158772 Q * softi42 Read error: Connection timed out
1174159245 Q * duckx Remote host closed the connection
1174159278 J * duckx ~Duck@tox.dyndns.org
1174159742 Q * duckx Remote host closed the connection
1174159847 J * mire ~mire@52-167-222-85.adsl.verat.net
1174159914 J * duckx ~Duck@tox.dyndns.org
1174159942 J * softi42 ~softi@p549D7398.dip.t-dialin.net
1174160329 J * Piet hiddenserv@tor.noreply.org
1174162139 M * daniel_hozac sladen: (really OT) ping, ever get https://launchpad.net/ubuntu/+source/qemu/+bug/32060 fixed?
1174162167 M * daniel_hozac (or is the patch available somewhere?)
1174162310 M * Bertl it was fixed in qemu 9.0 IIRC
1174162326 M * Bertl no idea, which version ubuntu is using ATM
1174162329 M * daniel_hozac really?
1174162347 M * Bertl not 100% sure, but I remember it being discussed on the ml
1174162365 M * daniel_hozac i'm using the binary 0.9.0 build, and i seem to be running in to that problem.
1174162391 M * Bertl that would suggest that it wasn't fixed despite all the discussions :)
1174162503 M * daniel_hozac i'll have to test the fix then.
1174162763 J * Aiken ~james@ppp250-73.lns2.bne4.internode.on.net
1174162929 M * Bertl morning Aiken!
1174163000 M * Aiken hello
1174163126 M * Bertl Aiken: how are the test results for 2.2.0?
1174163182 M * Aiken I have not done any testing for a few weeks
1174163189 N * DoberMann[PullA] DoberMann
1174163225 M * Aiken between wifes father having a heart attack and changing distro on all my machine life has been, um, interesting lately
1174163243 M * daniel_hozac is he okay now?
1174163273 M * Aiken slowly getting better
1174163296 M * Aiken lived with us for 2 weeks after a tripple bypass and he has only just moved home again
1174163341 M * daniel_hozac oh, i hope he gets well soon.
1174163342 M * Bertl well, our best wishes then ...
1174164027 M * Aiken all of my x86 is now ubuntu and alpha/ultra are both etch
1174164039 M * Aiken how good are their versions of the tools?
1174164059 M * Aiken would it be fine using them or should I stay with compiling my own copy?
1174164121 M * daniel_hozac etch should be fine.
1174164141 M * daniel_hozac no idea about ubuntu.
1174164196 M * Aiken with ubuntu I am using what will become the next release and it says 0.30.212 for the tools version
1174164216 M * daniel_hozac assuming they work, that should be fine...
1174164260 M * daniel_hozac (unless you hit any of the bugs fixed in 0.30.213-rcX, that is ;))
1174164393 M * Bertl daniel_hozac: yes, I'd appreciate a 0.30.213 for 2.2.0 actually
1174164404 M * Bertl is that reasonable?
1174164459 M * daniel_hozac assuming i can get the externalize fixed (i think i've found the cause already), and nothing serious pops up in my testing, it should be released tomorrow...
1174164474 M * Bertl excellent
1174164655 M * Aiken so I might go with making my own .deb of the tools then
1174165020 Q * phreak`` Quit: leaving
1174165081 J * phreak`` ~phreak``@deimos.barfoo.org
1174165139 Q * ema Quit: leaving
1174166399 Q * Johnnie Remote host closed the connection
1174166426 J * Johnnie ~jdlewis@jdlewis.org
1174166946 M * Bertl daniel_hozac: do we have a final verdict whether 'if (!dev) goto out;' is appropriate?
1174166971 M * Bertl if so, I would add that to the branches and upload the patches
1174167167 M * daniel_hozac i still think we should return 1.
1174167197 M * daniel_hozac i'll check whether it makes any difference...
1174167228 M * Bertl okay, great, tx!
1174167778 M * daniel_hozac okay, doesn't seem to make a difference.
1174167798 M * Bertl okay, then we go with a dev check before the in_dev conversion
1174167813 M * Bertl I'll prepare a patch and upload it in a few minutes
1174167819 M * daniel_hozac not before the nxi check?
1174167837 M * Bertl no, in this case we want to return 1
1174167848 M * daniel_hozac ah right, yeah.
1174167893 M * Bertl probably the if (!in_dev) is bogus
1174167931 M * Bertl nah, that one is fine
1174168025 M * Bertl http://vserver.13thfloor.at/Experimental/delta-devin-fix01.diff
1174168029 M * Bertl looks okay?
1174168215 M * daniel_hozac yep.
1174168433 M * daniel_hozac will add that to 2.6.16 as well.
1174168452 M * Bertl I have a recent 2.6.16 tree here, I will do a patch for that too
1174168455 M * Bertl 2.0.3-rc2
1174168463 M * Bertl (with all your changes)
1174168466 M * daniel_hozac okay, thanks.
1174168482 M * Bertl (assuming that you didn't add something since yesterday :)
1174168523 M * daniel_hozac nah, i only fix things there if people tell me they're broken ;)
1174168534 M * Bertl good approach ...
1174168541 M * daniel_hozac (i don't even use it myself)
1174168563 M * Bertl yeah, had to dig out the kernel!!
1174168600 M * Bertl but it would be nice to have a final 2.0.3 release for 2.6.16 :)
1174168617 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.16.43-vs2.0.3-rc2.diff
1174168621 M * daniel_hozac yeah.
1174168642 M * daniel_hozac hmm, you should remove localversion-vs.
1174168716 M * Bertl k, reload, tx
1174168738 M * daniel_hozac (i'm using that to avoid merge problems on every cg-update)
1174168747 M * Bertl yeah, I remember ...
1174168747 M * daniel_hozac looks better, thanks.
1174168791 M * Bertl 2.6.19.7 is still latest?
1174168812 M * daniel_hozac AFAIK.
1174169160 Q * michal` Ping timeout: 480 seconds
1174169197 M * Bertl daniel_hozac: you have fc6 running?
1174169205 M * daniel_hozac yeah.
1174169212 M * Bertl with yum or apt-rpm?
1174169223 M * daniel_hozac yum.
1174169241 M * Bertl okay, could you tell me what package includes install-info?
1174169275 M * daniel_hozac info
1174169279 M * Bertl hmm, no, that isn't my problem actually
1174169287 M * Bertl but why do I get:
1174169293 M * Bertl rpm -U /var/cache/yum/updates/packages/screen-4.0.3-2.fc6.i386.rpm 
1174169293 M * Bertl install-info: No such file or directory for /usr/share/info/screen.info.gz
1174169312 M * daniel_hozac %_excludedocs?
1174169332 M * Bertl means? (for a mdk guy :)
1174169352 M * daniel_hozac i guess you did not set that then :)
1174169362 M * Bertl where should I set that? and why?
1174169369 M * daniel_hozac (RPM macro that inhibits the install of %doc tagged files)
1174169378 M * Bertl and when I want doc?
1174169406 M * daniel_hozac well, i just thought that the error might be caused by having set that...
1174169413 M * Bertl ah, maybe
1174169425 M * Bertl where would I unset it?
1174169444 M * daniel_hozac well, if it is set, rpm --showrc should show it.
1174169466 M * Bertl -14: _excludedocs	1
1174169470 M * Bertl seems it is set
1174169485 M * daniel_hozac look in /etc/rpm/macros.* then
1174169511 M * Bertl there it is .. tx a bunch!
1174169516 M * daniel_hozac (that really is a bug in the package though)
1174169530 M * daniel_hozac you're welcome!
1174169540 M * Bertl okay, I have another one (gpm, IIRC) if you want to report :)
1174169607 M * daniel_hozac i think there's already some ongoing effort to clean up the scriptlets.
1174169639 M * daniel_hozac should be caught in the review for Fedora 7.
1174169675 J * michal` ~michal@www.rsbac.org
1174169705 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.19.7-vs2.2.0-rc18.diff
1174169771 M * daniel_hozac 2.6.20.3 coming soon?
1174169786 M * Bertl yep
1174170134 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.20.3-vs2.2.0-rc18.diff
1174170153 M * Bertl let me know what patches are missing and/or what junk I included :)
1174170244 M * daniel_hozac delta-utime-fix01.diff seems to be missing from 2.6.19.7.
1174170263 M * Bertl ah, right!
1174170272 M * Bertl also from 2.6.20 then
1174170290 M * daniel_hozac okay, hadn't gotten that far yet :)
1174170313 M * daniel_hozac but yep.
1174170353 M * Bertl np
1174170840 M * daniel_hozac let me know when they're updated, and i'll update them on helios too.
1174170913 M * Bertl I don't know what my diff is waiting for
1174170929 M * Bertl but it is currently diffing two hard linked trees for over 5 minutes?
1174170960 M * Bertl the fascinating part is, it seems to do the right thing
1174170972 M * Bertl must be some I/O scheduler corner case :)
1174170986 M * Bertl okay, both are updated in place
1174171116 M * daniel_hozac okay.
1174171207 M * daniel_hozac should be updated on helios now too.
1174171216 M * Bertl excellent! tx!
1174171228 T * Bertl http://linux-vserver.org/ | latest stable 2.0.2.1, 2.0.3-rc2, 2.2.0-rc18, devel 2.3.0.11, stable+grsec 2.0.2.1, 2.2.0-rc17 | util-vserver-0.30.212 | libvserver-1.0.2 & vserver-utils-1.0.3 | He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the Wiki, and we'll forget about the minute ;)
1174171473 M * daniel_hozac hmm, where should i put 2.0.3-rc2 on the wiki?
1174171508 M * Bertl lost and found? (just kidding :)
1174171518 M * daniel_hozac "The latest prepatch version of the stable Linux-VServer patch is:"?
1174171524 M * daniel_hozac hehe.
1174171538 M * Bertl old but maintained releases
1174171580 M * daniel_hozac but that sort of categorization isn't present today ;)
1174171590 M * daniel_hozac i agree that's what we need though.
1174171698 M * daniel_hozac so we have {stable,devel} {maintained,unmaintained} releases
1174171716 M * daniel_hozac do we want to have the unmaintained ones on the front page?
1174171788 M * Bertl not necessarily
1174171829 M * daniel_hozac i'd rather we didn't, but i guess 2.6.17.13-vs2.0.2.1 isn't exactly "maintained", but it is the latest stable release and not having that on it would seem somewhat strange.
1174171896 M * daniel_hozac what kind of categorization would you prefer?
1174172080 M * Bertl hmm right, we should update that to 2.0.3-rc2 too
1174172136 M * daniel_hozac 2.6.18? or what?
1174172197 M * Bertl yes, or maybe the 2.6.17 branch to the latest patch
1174172205 M * Bertl shouldn't be that hard
1174172263 M * Bertl I do not understand how somebody could live with yum :)
1174172288 M * daniel_hozac hehe, why not?
1174172302 M * Bertl pastebin is down again :(
1174172308 M * daniel_hozac coffee break every time you need to install something is rather nice ;)
1174172319 M * daniel_hozac pastebin.com?
1174172326 M * daniel_hozac paste.linux-vserver.org is up from here.
1174172330 M * Bertl aha?
1174172395 M * Bertl ah, issue on my side ...
1174172445 M * Bertl daniel_hozac: how do I go about this: http://paste.linux-vserver.org/1293
1174172498 M * daniel_hozac rpm -e elfutils-libelf?
1174172517 M * Bertl rpm -e elfutils-libelf
1174172517 M * Bertl error: "elfutils-libelf" specifies multiple packages
1174172534 M * daniel_hozac might want to add elfutils-libelf to that command then.
1174172537 M * Bertl ah, we have two of them installed, nice :)
1174172555 M * daniel_hozac x86_64 with multilib?
1174172560 M * Bertl nope
1174172564 M * Bertl elfutils-libelf-0.126-1.fc6
1174172564 M * Bertl elfutils-libelf-0.123-1.fc6
1174172567 M * daniel_hozac ah, failed scriptlet.
1174172568 M * daniel_hozac nice.
1174172584 M * Bertl thanks for the hint, though!
1174172625 M * daniel_hozac np
1174172632 M * Bertl are there plans to replace yum in the near future?
1174172672 M * Bertl or is that wishful thinking :)
1174172726 M * daniel_hozac i doubt it. everything's built on yum.
1174172734 M * Bertl daniel_hozac: did you get to a conclusion with the 'Jarek Dylag' issue?
1174172747 M * daniel_hozac no, it's still a mystery to me.
1174172755 M * Bertl what about the fix he did?
1174172767 M * Bertl humbug? nonsense? solution?
1174172777 M * daniel_hozac it's ugly and might trigger in cases where it shouldn't, IMHO.
1174172788 Q * FireEgl Quit: ...
1174172815 M * Bertl can you describe the issue to me as far as you figured?
1174172933 M * daniel_hozac basically, sometimes when the controlling tty hangs up, there's nothing in the exception fd list in select, nor a SIGHUP.
1174172946 M * daniel_hozac only something to read (EOF) on stdin.
1174172993 M * daniel_hozac so it goes into an infinite loop of select() and read().
1174173125 M * daniel_hozac i suppose setting stdin to blocking and checking for a 0-byte read in do_vlogin would work, but it still seems like it should be solved in a cleaner way, IMHO.
1174173342 M * Bertl why does reading not remove the data/signal eof?
1174173583 M * daniel_hozac a 0-byte read is the EOF-signal.
1174173614 M * daniel_hozac AFAIK.
1174173615 M * Bertl yes, but who continues after that and/or ignored eof?
1174173621 M * Bertl *ignores
1174173664 M * daniel_hozac vlogin ;)
1174173679 M * Bertl hum, why so?
1174173776 M * daniel_hozac well... because the code doesn't really lend itself to checking for it.
1174173791 M * Bertl hum hum ...
1174173816 M * Bertl if (read() == 0) break/goto exit/end=1 ?
1174173855 M * daniel_hozac but the read is performed in non-blocking mode.
1174173876 M * daniel_hozac so a 0-byte read could occur under normal circumstances too, no?
1174173895 M * doener daniel_hozac: the exception set in select() is not what you expect of it, as I just learned from reading the select_tut manpage
1174173907 J * dghill dghill@office.mel.illuminate.com.au
1174173908 M * daniel_hozac ah no, looking at the wrong function.
1174173913 M * daniel_hozac doener: oh? what is it then?
1174173920 M * doener for checking for OOB data
1174173921 M * Bertl welcome dghill!
1174173933 M * daniel_hozac ah.
1174173964 M * matti ROTFL
1174173971 M * matti LMAO
1174173973 M * matti LOL
1174173980 M * Bertl hmm?
1174173993 A * doener hides matti's drugs
1174173998 M * doener those are bad for you!
1174174002 M * doener ;)
1174174003 M * matti My neighbours are indeed living proof, that human stupidity is in fact infinite.
1174174008 M * matti doener: Hehehehe.
1174174014 M * matti doener: Thanks :)
1174174022 M * matti Well.
1174174024 M * arachnist matti: :)
1174174028 M * arachnist matti: you're alive ;>
1174174038 M * doener matti: how so?
1174174050 M * matti Well let me explain.
1174174065 M * matti My neighbours where using WEP since today.
1174174070 M * Bertl no no! don't explain! let us guess :)
1174174080 M * matti Bertl: Hehe.
1174174086 M * arachnist :>
1174174090 M * matti Bertl: No, this time is not about Elvis ;p
1174174092 M * daniel_hozac doener, Bertl: ok, so efds is a dead end. but why doesn't SIGHUP do what i expect?
1174174108 M * doener matti: There's a wiimote stuck in their window?
1174174129 M * matti They probably discovered that I was playing in their network a bit and they switched to WPA-PSK.
1174174152 M * matti So, I was up to testing WPA cracking technique ;)
1174174159 M * matti And...
1174174167 M * matti I use de-authorization attack.
1174174180 M * matti Grabbed enough EAPOL frames.
1174174198 M * matti And then, I stareted brute-force attack by using cowpatty.
1174174219 M * matti I was thinking, that this may take a while
1174174226 M * matti Or I will not sucess at all :)
1174174233 M * matti But in contrary :)
1174174249 M * Bertl good that this channel isn't logged ... and the police doesn't know where you are living :)
1174174265 M * matti After a +-10 min, cowpatty finished.
1174174273 M * matti I was surprised.
1174174282 M * matti Ale guess, how the PSK looks like ;]
1174174306 M * daniel_hozac secret?
1174174316 M * matti No!
1174174319 M * doener matti?
1174174321 M * matti PSK = "12345678"
1174174325 M * matti :)
1174174329 M * matti Brilliant :)
1174174332 M * matti Just brilliant ;]
1174174351 M * matti The end.
1174174360 M * arachnist lol
1174174379 M * doener matti: You're obviously not a DailyWTF reader, otherwise you'd know that that is "Brillant" with one "i" ;)
1174174407 M * doener http://worsethanfailure.com/Articles/The_Brillant_Paula_Bean.aspx
1174174463 M * matti This is a proof, that even any sophisticated way of securing network will fail because of peoples common laziness and stupidity :)
1174174476 M * matti Einstein was right ;]
1174174485 M * matti Human stupidity is indeed infinite :)
1174174518 M * matti Well, sorry for that :)
1174174523 M * doener heh
1174174549 M * matti BTW, do NOT use WEP :) My C2D laptop needs 5 min to find a key for 128 bit WEP from 800,000 IVS frames.
1174174552 M * matti ;p
1174174580 M * matti 64 bit WEP 2-3 min ;]
1174174584 M * matti That's bad ;p
1174174699 M * matti doener: ROTFL @ URL ;]
1174174719 M * matti Bertl: I am a white hat :)
1174174735 M * matti Bertl: I never do bad things ;) I just crack it for fun ;]
1174174748 M * Bertl matti: so you went over and explained it to them, yes?
1174174763 M * matti Yes and no.
1174174777 M * matti I leaved a text file on the desktop on their machine.
1174174799 M * matti Becuase they've C: partition shared with full access rights without password.
1174174804 Q * brcc_ Ping timeout: 480 seconds
1174174857 M * matti But, this was even before WEP.
1174174886 J * yarihm ~yarihm@84-74-16-109.dclient.hispeed.ch
1174174899 M * matti They're evolving :) No protection -> WEP 64 bit -> WEP 128 -> WPA-PSK.
1174174902 M * matti :)
1174174985 Q * dna Quit: Verlassend
1174175061 M * matti Of course, access point is proteced by user admin with password admin ;]
1174175065 M * matti Which is very wise ;]
1174175066 M * matti :)
1174175440 Q * Johnnie Remote host closed the connection
1174175466 J * Johnnie ~jdlewis@jdlewis.org
1174175496 M * doener daniel_hozac: how did you test your SIGHUP patch?
1174175519 M * matti Ehh, sorry :<
1174175520 M * daniel_hozac with the original reproducer.
1174175543 A * matti will be quiet right now...
1174175626 M * doener so the child process was a bash, right?
1174175653 M * daniel_hozac yeah.
1174175726 M * doener hm, I thought that the child process eventually ignored SIGHUP, as your patch relies on the child process quitting in response to SIGHUP
1174175766 M * daniel_hozac yeah, TERM would probably be better.
1174175800 M * doener well, you could send SIGHUP to the child and then quit, just like a "real" terminal would do (I think).
1174175826 M * doener or maybe even just exit(), which might cause a SIGHUP to be sent anyway
1174175880 M * daniel_hozac hmm, why would that cause a HUP?
1174175889 M * daniel_hozac isn't the child's controlling tty the new one?
1174175964 M * doener the child's ctty should be the one created by openpty, with the master being owned by vlogin, and if vlogin quits, the master is closed. Anything I'm missing?