[01:59] loger joined #vserver. [02:01] later guys [02:01] JonB (~jon@129.142.112.33) left irc: Quit: zzzzzzzz [02:04] ensc, any way I can make it use /usr/lib64 or shall I just make a symlink ;) [02:05] Simon: I do not use /usr/lib64. 'vserver ... build' does not copy files from there [02:06] once again we see that */lib is _not_ the right place for such files ... [02:06] Bertl: which number is CAP_QUOTACTL? 30? [02:06] depends on the patch/kernel ... [02:07] is this error coming from apt then? [02:07] # vserver test build -m apt-rpm -- -d mdk92 [02:07] E: The method driver /usr/lib/apt/methods/file could not be found. [02:07] W: Release files for some repositories could not be retrieved or authenticated. Such repositories are being ignored. [02:07] E: The method driver /usr/lib/apt/methods/file could not be found. [02:07] Simon: are the method files in /usr/lib64/apt/methods? [02:07] yes [02:07] @simon make a link from /usr/lib64/apt to /usr/lib/apt [02:07] Simon: do you have /etc/apt/apt.conf? [02:07] but that's an ugly hack Bertl ;P [02:08] ln -s ../lib64/apt /usr/lib/apt [02:08] I do.... [02:08] Simon: is Dir::Bin::methods set there? [02:08] that is the _only_ correct thing in this scenario ... [02:08] no [02:09] I don't see any reason for apt files to be 32/64 bit localized, do you? [02:09] Simon: insert 'Dir { Bin { methods "/usr/lib64/apt/methods"; } }' into this file [02:10] ok that worked [02:11] Simon: I am not sure, if you have to copy this apt.conf file to /etc/vservers/.distributions/mdk92/apt [02:11] hmm I am seeing this for almost every package installed [02:11] /sbin/ldconfig: Can't open configuration file /etc/ld.so.conf: No such file or directory [02:11] and [02:11] /sbin/ldconfig: Can't open configuration file /etc/ld.so.conf: Permission denied [02:12] maybe /etc/ld64.so.conf ;) [02:12] Simon: what gives 'rpm -qf /etc/ld.so.conf' on the host-system? [02:12] I have /etc/ld.so.conf on the host server [02:12] # rpm -qf /etc/ld.so.conf [02:12] glibc-2.3.2-14mdk [02:13] ls -la /etc/ld.so.conf /etc [02:13] strange... exists this file in /vservers//etc/ld.so.conf ? [02:13] ls -lda /etc/ld.so.conf /etc [02:13] glibc should be installed very early [02:13] drwxr-xr-x 54 root root 4096 Oct 24 11:07 /etc/ [02:13] -rw-r--r-- 1 root root 32 Oct 12 02:46 /etc/ld.so.conf [02:14] okay this is inside the vserver, I assume ... [02:14] it exists in the vserver [02:14] -rw-r--r-- 1 root root 0 Sep 4 03:54 ld.so.conf [02:14] no that first was on the host server [02:14] hmm, zero size ... [02:15] well, why not .. what kernel/patches are active? [02:15] Simon: can you chroot into the vserver and invoke 'ldconfig' manually? [02:16] ok done, it's still zero [02:16] that only creates the /etc/ld.so.cache ... [02:16] oh yeah [02:17] Simon: is /sbin/ldconfig the only failing scriptlet? [02:17] on the host server it only contains [02:17] or are there other messages? [02:17] /usr/X11R6/lib64 [02:17] /usr/X11R6/lib [02:17] which I don't really want anyway [02:17] again, what kernel/patches are active? [02:18] 2.4.22-c17h+quota [02:18] context tagging activated? [02:18] hold on I'll upload the whole lot (errors) [02:19] yeah, using 32/32 [02:19] @simon please just answer my questions .. [02:19] okay, you most likely got a ctx permission failure ... [02:20] @enrico does this stuff use dynamic context switches? [02:20] yes, /etc/ld.so.conf is created by rpm in ctx-0, but scriptlet runs in another ctx [02:20] what ctx? [02:20] random one/this of the running vserver [02:21] okay so you've got a problem there ... doesn't work with context tagging ... [02:21] http://www.expio.co.nz/~sgarner/terra/vserver-build.txt [02:21] you can't use dynamic contexts with context tagging ... [02:22] @simon if you want to test this, just do 'chcontext --ctx 1000 cat /vservers//etc/ld.so.conf' you'll get a permission denied too ... [02:23] nope... [02:23] just says New security context is 1000 [02:24] did you edit something in the same directory since you had the error? [02:24] only running ldconfig... [02:24] okay, try the 'original' install again ... [02:25] Simon: 'vapt-get -- dist-upgrade' should do the same [02:25] lsctx shows all the files are in ctx 0 [02:26] hmm, and the error still occurs? [02:26] Reading Package Lists... Done [02:26] Building Dependency Tree... Done [02:26] Calculating Upgrade... Done [02:26] 0 packages upgraded, 0 newly installed, 0 removed and 0 not upgraded. [02:26] Simon: install a new package ( ... -- install ) [02:26] should be a library then ... right? [02:27] Bertl: as long as the 'chmod 000' hack is active, rpm/cpio will create files in ctx 0 [02:27] Bertl: yes, something with a scriptlet [02:27] /vservers is 755 [02:27] I don't see any other reason for '/sbin/ldconfig: Can't open configuration file /etc/ld.so.conf: [02:28] Permission denied' [02:28] than a ctx permission issue ... [02:28] Simon: this does not matter, I am assuming a secure installation with 000 mask [02:36] @enrico, is there a problem with including the newvserver in your package? [02:37] Bertl: I could include it, but I would not have a good feeling since I can not test it and would not detect the simplest syntax errors [02:37] hmm er. [02:37] I have new idea how to deal with the quota-ctx problem: create new namespace, mount all rpm/apt-binaries/libraries into the vserver + resolv.conf + ..., chroot into the vserver, change context and invoke the programs [02:37] I ran the build again and the only thing it installed was filesystem [02:37] but this needs some work... [02:38] Simon: what gives 'vrpm -- -qa'? [02:38] @enrico it would be sufficient to add a --ctx to the creation process ... [02:38] Simon: the system is configured to abort after the first error [02:38] Bertl: no. rpm works everytime in ctx 0 [02:38] that is not a problem ... [02:38] hmm it thinks a whole list of libs and stuff is installed [02:39] Simon: remove the /vservers/.pkg/ directory [02:39] ctx 0 can read/write/exec everything ... and every context can read/write/exec ctx 0 [02:39] ahh [02:39] Bertl: then I do not understand the permission denied... [02:40] inter context issues only arise if ctx1 = 100 and ctx2 = 101 for example ... [02:40] if you use dynamic contexts, you can not be sure that you always get the same ... [02:40] okay... I ran the build again and it's done the same thing [02:40] Bertl: ah, yes. every scriptlet is run in another context when vserver is not active [02:40] http://www.expio.co.nz/~sgarner/terra/vserver-build.txt [02:41] chcontext grep ctx /proc/self/status [02:41] shows the problem in all colors ;) [02:41] New security context is 141 [02:41] ctxticks: 10 10 1 [02:41] ctxflags: 0 [02:41] ? [02:42] try again ... [02:42] the context number increments with each go ;) [02:42] we should get rid of those dynamic contexts as soon as possible ... [02:43] or at least assign an orthogonal space for them ... [02:44] I do not want to think about the possible issues when the dynamic context numbers pass over statically assigned ones ... [02:45] shall I just lose the quotas for the moment? :) [02:45] are there other capabilities bits on AMD64? [02:46] I am using a fixed bitmask, so the permission denieds could be caused by that? [02:46] @simon this would solve the problem, but give you headache when you hit tagged files ... [02:47] quota rule #1, don't use dynamic contexts 8-) [02:48] quota rule #2, if you can't do that, follow rule #1 [02:48] Simon: you you replace /sbin/ldconfig with a script which calls 'exec strace -f /sbin/ldconfig_' where /sbin/ldconfig_ is the original ldconfig? [02:48] Simon: then, install another library [02:48] (after you install strace) ;) [02:48] @simon in the vserver ;) [02:50] .oO(who needs ldconfig ;)) [02:53] enrico, could you imagine to add another branch to util-vserver ? [02:53] Bertl: you mean 0.23.2xx? [02:54] I mean 'VServer' side by side with Stable, Devel and Alpha ... [02:54] stable will be merged with 'devel' soon [02:54] I don't car about your numbering, as I do not understand it ... but this would allow to have synchronization points with the kernel patches ... [02:55] s/car/care/ [02:56] I do not know how I could express such a three-dimensional versioning... [02:56] current one is: the higher the number, the more features [02:57] near '100' means release candidate [02:57] the current 1xx is a temporary issue which should not occure in future release [02:57] s [02:57] you can use any number you like ... but each version in VServer should correspond with a kernel release ... [02:58] I mean a vserver kernel patch release ... [02:58] why? What is when a kernel release is just a bugfix? [02:58] my numbering uses this style: [02:58] vserver-1.0 (first release) [02:58] vserver-1.0.1 (bugfix ;) [02:59] vserver-1.1.0 devel branch ... [02:59] vserver-1.1.99 last devel version (for example) [02:59] vserver-1.2 (second release) [02:59] vserver-1.2.1 (bugfix) [02:59] vserver-1.2.2 (bugfix) [02:59] vserver-1.3.0 devel [02:59] vserver-1.2.3 (bugfix) [03:00] vserver-1.3.1 devel [03:00] got it? [03:00] my numbering will be 'x.y' for releases, 'x.[y+1]' for bugfixes, 'x.y.z' (z<<100) for devel versions, x.y.z (z near 100) for release candidates [03:01] so be it, but I would like a designate version of your tools (wherever it comes from) which is designated as _the_ tools for vserver-1.2 for example .... [03:02] if you do bugfixes, then do them, if you do development, okay ... if we have a vserver release, you name some tool version, and add those tools in the VServer branch ... possible? [03:03] ok, that is possible. But savannah does not support annotations to branches/files in branches [03:04] then just check it in as new update or something like this ... [03:05] maybe it's not so bad to have one-step incrementals from one vserver correlated tool version to the other ... [03:06] maybe the tools should be named similar to how mod_ssl is, e.g. util-vserver-1.2.0-1.3 would be tools 1.3 for vserver 1.2.0 [03:06] imo, featuresets are too different to keep numbers in sync [03:06] Nick change: riel -> unriel [03:07] Simon: no, this would be very difficultly for packaging [03:07] mmk [03:07] as I said, I don't care about your numbering ... [03:08] well it would be nice to have the same version number on releases, but I don't see a way to do this ... ;) [03:09] so do you see a way to make this VServer branch happen? [03:11] Bertl: IMO, this is just a documentation issue. What would be the sense of a vserver branch? The user will see lots of files in a list with the heading 'VServer'? [03:12] and would know that each one corresponds to exactly one vserver release ... [03:13] I do not see a way to explain to the user why he can use 0.23.92 or 0.23.194 but not 0.23.93 (just an example) [03:13] why 'exactly'? Each version should be backward compatible and should work with previous kernels also [03:13] but will not and does not as we know ... [03:14] we have to do some testing before each release ... to make sure the tools _work_ together with the kernel ... [03:14] your example (non working 0.23.93) should not happen [03:15] well IIRC we had the 0.92 working with c17h but we had problems with 0.93 right? [03:15] latest and greatest version of each branch should work with all kernels [03:15] Bertl: no. .92 had problems which are fixed in .93 [03:16] okay, so .92 would work with c17h but only partially right? [03:16] .92 does not work with the old syscall on the new number [03:16] perfect, so we have this situation: [03:17] c17f uses this scenario, therefor it will not work with .92 [03:17] but it will work with .91 right? [03:17] or even better with 0.23.5 ... [03:18] the 0.23.x vs 0.23.yz is a little bit special, and will/should not repeat in the future [03:19] it can and _will_ happen again ... trust me ... [03:20] you may have the situation that a version is buggy and you have to downgrade/wait on a new release. But this is not related to kernel-numbers. [03:21] release-canditates are there to reduce the possibility of such events [03:21] but I do not want a known buggy version in a release ... [03:22] and another issue would be some special arrangements, like for example putting in the newvserver stuff .. or something like that ... [03:22] 0.23.93 is still a 'release-candidate'. 0.23.6 is the last stable version (naming is not consequent because of synchronization with Jacques's vserver-0.23) [03:24] think about it like a 'special' version just for the kernel-patch release ... [03:24] new kernel features will result in a new util-vserver version [03:25] okay, consider the following 'very likely' situation ... [03:25] vserver-1.0 was released ... [03:25] in vserver-1.1.0 I add syscall 0815, to test it ... [03:26] in vserver-1.1.1 I remove it, because the same can be done via ioctl ... [03:26] in vserver-1.1.2 I decide to move the stuff to /proc ... [03:29] how and when do you intend to sync up? [03:30] for that, the syscall versioning shall/must be used. When you release a kernel with a feature, this feature must be supported by all util-vserver versions [03:30] no bloody chance for a development release ... sorry ;) [03:31] there must be always a clean upgrade path the util-vserver package [03:32] the stable releases will follow that for sure ... [03:32] I can create an 'experimental' branch for development releases ;) [03:33] well do what you have to do, but give me a pendant to each vserver (stable) release and mark it somehow as such ... [03:35] ok, I can create empty files like 'USE-THAT-FOR-VSERVER-X.Y-AND-LATER' in the branch [03:35] hmm, guess this should do the trick then ... [03:35] sorry to butt in... but how do I stop it from trying to install piles of junk I don't want? there must be some way to start with the host server's package list... [03:36] CTRL-C ;) [03:36] heh [03:36] Simon: the initial set (the packages in rpmpriorities) should be a really minimal set of packages [03:37] yeah it is. but it's trying to install gnome and things [03:37] maybe some minor dependancies ... [03:38] Simon: this is a mandrake packaging problem... [03:38] uhh [03:38] nope, it's a minimal set problem ... [03:38] Bertl: apt-get calculates a minimal set [03:40] Simon: you could create pseudo-packages which are providing the needed Gnome2 stuff, and add this file to rpmpriorities [03:40] hmm ... how then is it, that my DNS vserver is complete (closure) with 102 packages, excluding any X stuff? [03:41] Bertl: you do not have an AMD64? [03:41] hmm, good point .. [03:41] Simon: try 'vrpm ... -- -e --test lib64gnomecanvas2_0' and see which packages are requiring it/what [03:41] but do you really think amd64 requires gnome2 ? [03:41] I don't have half the packages it is installing installed on the host server [03:42] ensc, no output [03:42] here you are, the minimal set is wrong ... [03:43] Simon: and 'vapt-get ... -- remove lib64gnomecanvas2_0' ? [03:43] 0 packages upgraded, 0 newly installed, 1 removed and 0 not upgraded. [03:46] Simon: what is the content of /vservers/.pkg/.../apt/etc/rpmpriorities? [03:46] Essential: [03:46] netrose (~john877@CC3-24.171.21.47.charter-stl.com) joined #vserver. [03:46] basesystem [03:46] coreutils [03:46] filesystem [03:46] glibc [03:46] setup [03:48] strange... perhaps there are dependencies which are fulfilled by multiple packages and apt-get takes both/the wrong one [03:48] rpm -q --requires basesystem [03:49] and check for any gnome stuff ... [03:49] can't see any [03:49] probably, there is a virtual package or libraries [03:50] ahh what is the setup? [03:50] this probably includes the drake tools ... [03:50] nope [03:50] on rh, this is the base-setup (first package which will be installed) [03:51] hmm, it's /etc configs on mdk ... [03:51] Simon: can you provide the rpm-database (/vservers/.pkg/.../rpm/state) somewhere? (tar & bzip2 it first) [03:53] http://www.expio.co.nz/~sgarner/terra/rpmstate.tar.bz2 [04:08] strange... I just see ambiguities between perl-base and perl, and lib64gtk+-x11 and lib64gtk+-linuxfg [04:12] @simon try 'urpmq -d basesystem' [04:12] and look for anything which contains X11 or gtk/gnome [04:13] Simon: can you remove the non existing packages from your /usr/lib/util-vserver/...distributions/.../rpmpriorities? (basesystem, coreutils) [04:19] Bertl, only line would be [04:19] vim-minimal|vim-enhanced|vim-X11 [04:19] ensc, non existing? [04:19] hmm, could it be that vim-X11 is selected? [04:20] Simon: where is this vim-X11 line? [04:20] `01urpmq -d basesystem` [04:21] serving (~serving@213.186.191.3) left irc: Ping timeout: 480 seconds [04:22] I dont have vim-X11 installed on the host (but do have minimal and enhanced) [04:22] if the apt stuff selects all instead of the first ... then you'll drag in X11+co ... [04:23] From where is urpm taking the 'basesystem' package? It is not installed in your vserver [04:23] from the host I guess [04:24] hhm, vapt-get should not be influenced by information from the host [04:24] well [04:25] it is trying to install basesystem on the vserver, but it fails, that's why it's not installed [04:25] http://www.expio.co.nz/~sgarner/terra/vserver-build.txt does not show this error [04:26] look at the last line, something about /sbin/halt [04:26] while trying to install lib64gnomecanvas (which I dont even want) [04:27] Simon: this line comes from the 'vserver ... build' post-script, but not from the package installation [04:28] I am trying to cleanup /etc/init.d, but my scripts are Red Hat based [04:28] hmm [04:28] then why is it not installing basesystem? [04:29] that would explain why lots of stuff is missing ;) [04:29] Simon: remove 'baseystem' from the 'rpmpriorities' file, see what is missing and add it [04:30] as said before: my shipped config files are redhat based; on Mandrake you may have other packages [04:30] here, basesystem is very simple and requires 'setup' and 'filesystem' only [04:31] a minimal system is e.g. http://www-user.tu-chemnitz.de/~ensc/rpmDirectoryCheck/results/rpm.png [04:31] you need basesystem on mandrake ... [04:32] Simon: what says 'vapt-get ... -- install basesystem'? [04:33] http://www.expio.co.nz/~sgarner/terra/install.txt [04:34] looks good to me ... [04:34] Zoiah (Zoiah@81.17.52.139) got netsplit. [04:34] gaertner (~gaertner@212.68.83.129) got netsplit. [04:34] but as I said, if apt-rpm satisfies vim with vim-X11 you are doomed ... [04:35] gaertner (~gaertner@212.68.83.129) returned to #vserver. [04:35] Zoiah (Zoiah@81.17.52.139) returned to #vserver. [04:35] Simon: go this list down: e.g. 'vapt-get ... -- install initscripts' [04:35] take vim first! [04:35] initscripts depends util-linux [04:35] Simon: try it for util-linux [04:36] depends shadow-utils.. :) [04:36] again... [04:36] isn't there an option to build the closure (like urpmq -d ?) [04:36] 0 packages upgraded, 0 newly installed, 0 removed and 0 not upgraded. [04:36] shadow-utils is already the newest version. [04:37] sorry, util-linux was [04:37] util-linux: Depends: shadow-utils (>= 20000902-5) but 1:4.0.3-5mdk is to be installed [04:37] Simon: aah, this is probably an epoch problem [04:38] which rpm version is installed on the host? [04:38] huh? what? [04:38] btw for vim... [04:38] Package vim is a virtual package provided by: [04:38] vim-minimal 6.2-11mdk [04:38] vim-enhanced 6.2-11mdk [04:38] vim-X11 6.2-11mdk [04:38] You should explicitly select one to install. [04:38] rpm-4.2-19mdk [04:40] Simon: the gnome2 packages are caused by vim, and you can override it by putting 'vim-minimal' into rpmpriorities [04:40] hmm, why doesn't anybody listen to me :( [04:41] Bertl: the epoch problem is, since comparision would be 1:4.0.3-5mdk < 1:20000902-5 [04:42] ok :) [04:42] Action: Simon tries again [04:43] that worked... [04:44] what's this thing with 'halt'? [04:44] this epoch-problem will be scary in future vapt-get operations, I guess... :( [04:45] maybe, never had it on rpm ... [04:45] /etc/init.d/halt is the last script executed in runlevel 6. See /usr/lib/util-vserver/distributions/redhat/initpost [04:46] Simon: for mandrake, adapt this script, and replace the initpost-symlink in .../mdk92/ with it [04:46] don't you mean runlevel 0? [04:47] and please please please, if you made it work, publish everything and write some notes ... will you? [04:47] no, runlevel 0 is 'halt', but 'vserver ... stop' invokes runlevel 6 [04:47] ok [04:48] Bertl, me? I don't know if I can remember what I did ;) [04:48] use history then! [04:49] so this vserver .. build only installs Essential packages? everything I want I have to add as essential? [04:50] Simon: this is a shortcut; 'vapt-get dist-upgrade' tries to install everything in this list. You can add packages into ...distributions/.../pkgs/... also [04:51] 01 and 02? [04:51] you can create own "distributions" (strings given to '-d') for special classes [04:51] ooh ok [04:52] Simon: this are just number which will be evaluated in order [04:52] on rh they are needed because of some difficulties [04:53] and the packages all have to be in RPMS.os..? [04:53] what if there is an updated package, openssh say, I dump it in there, I have to genbasedir again? [04:54] and I have to figure out all the update-dependencies myself also? [04:54] Simon: you can create an own RPMS.update directory + base/release.update. [04:54] Then, add 'update' as an additional component to sources.list [04:55] you have to invoke 'genbasedir --partial --progress --bz2only --bloat --flat `pwd` update' then [04:56] (the final 'update' is your component name, and the '--partial' is important to keep the 'os' information) [04:57] Simon: I am rsync'ing from official redhat update mirrors [04:57] where was the sources.list file again ;) [04:57] oh there it is [04:57] in /etc/vservers/.distributions/... [04:58] I see... [04:58] Simon: it is documented in http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/doc/configuration.xml?rev=1.2&content-type=text/vnd.viewcvs-markup but I have not found somebody who wrote an XSLT stylesheet to transform it into something human-readable [05:02] okay let's go back a step, any ideas why this initpost wouldn't be working, it looks fine... [05:02] what dir is it looking for 'halt' in? [05:02] Simon: do you have /etc/init.d/halt ? [05:02] on the host, yes [05:03] on the vserver it is a link to /bin/true [05:03] Simon: that should it be after script has been run [05:03] what is this line supposed to do? [05:03] mv -f halt{,.orig} [05:03] it is expanded to 'mv -f halt halt.orig' [05:04] this way you can save about 2 keystrokes ;) [05:04] oh right [05:04] ;) [05:05] but only on keyboards where {} can be reached without using a modifier ;) [05:05] so, I dont have a (real) halt in the vserver... [05:05] Simon: yes, 'initscripts' are not installed, are they? [05:05] how do I tell? [05:05] this is the epoch problem... :( [05:06] Simon: try to remove the 01 and 02 files in pkgs/ [05:06] are w going around in circles again? [05:06] hehe [05:06] Bertl: this is a *very* complicated rpm problem [05:07] Bertl: current rpm tries to solve it by assuming 'Epoch: 0' when epoch is not specified [05:07] Bertl: mandrake rpm, assume the same epoch of already installed package [05:08] on rpm-list there was lot of traffic some months ago about it [05:08] doh [05:08] fortunately I'm not subscribed ... [05:09] Basically it is solved now by requiring explicit '0:' epochs on versioned requirements [05:10] but I fail to see the relation between some 'is-the-new-version-newer-than-the-old-version' issue and a package (initscripts) not installed, car to explain? [05:10] s/car/care/ [05:12] util-linux has 'Requires: shadow-utils >= 200000902-5', installed is 1:4.0.3-5mdk. When rpmvercmp is called in a potential candidate, it promotes the '1:' epoch of the already installed epoch, and thinks that 1:200000902-5 is required, but only 1:4.0.3-5mdk be installec [05:13] since 1:4.0.3-5mdk is lower than 1:200000902-5, this package will not fulfill the requirement [05:13] cant follow you, what is the relation to bootstrapping a mandrake vserver? [05:14] which package should be installing initscripts? [05:14] Simon: initscripts are implicated by basesystem [05:14] the package is initscripts ... [05:14] and I dont have basesystem... [05:15] or do I now? [05:16] 'apt-get dist-upgrade' tries to calculate a closure for basesystem, but shrinks this closure silently when not all constraints can be fulfilled. [05:16] serving (~serving@213.186.190.62) joined #vserver. [05:16] how do I see if a package is installed on the vs? [05:17] hey, the constrains can be fulfilled, otherwise he would not have installed hist system, right? [05:17] vrpm ... -- -qa ... [05:17] Bertl: no, urpmq has perhaps special code to circumvent the epoch-problem [05:17] cool, package basesystem is not installed [05:18] maybe urpm is just smarter than apt-rpm then? [05:19] Bertl: no, it has just special code to cope with broken packes [05:19] whats the advantage of using apt anyway... [05:19] s!packes!packages! [05:20] Simon: automatic dep-resolving, works on rh, repositories can be created easily, you can build vservers with it [05:20] ahh, I see, and this 'advantage' to cope with arbitrary 'broken' packages, of course can't be called smart, right? [05:20] Bertl: in this situation, it is smart. But such heuristics can break in other ones [05:21] hmm, for example for non broken packages? [05:21] Bertl: I do not know. The epoch issue is very complex [05:22] read rpm-list and apt-list for details [05:22] if you mention it once again, I'll change the syscall switch interface immediately 8-) [05:22] ;) [05:24] Simon: are you able to rebuild the util-linux package on your machine? [05:25] are we sure thats the only one... [05:25] If so, replace the 'Requires: shadow-utils >= 20000902-5' line with 'Requires: shadow-utils >= 0:20000902-5', increase release and put it in an repository [05:26] Simon: probably, it is just a fistful of packages [05:26] ok [05:28] virtuoso (~shisha@ip114-115.adsl.wplus.ru) joined #vserver. [05:28] hi virtuoso! [05:28] Hi Bertl [05:29] I thought only I do not sleep. :) [05:29] well, as somebody already pointed out (on irc), I'm nocturnal ... [05:31] I know of the daystar from stories passed on from generation to generation over cenuries ... [05:31] lol :D [05:32] Even so. :) [05:32] where should I put this new rpm ensc? [05:33] Bertl: And can you see your reflection in a mirror? :) [05:33] Simon: e.g. into RPMS.local/ (same directory like the RPMS.os) [05:33] Simon: then, create release.local and invoke genbasedir [05:33] ok [05:33] genbasedir --partial --progress --bz2only --bloat --flat `pwd` local [05:34] then, add this 'local' component to your sources.list (first, try it in /vservers/.pkg/.../apt/etc/) [05:35] I think some shell scripts or whatever may be needed to make this process a little easier... [05:35] Simon: yes; when polling periodic updates, such scripts are very usefully ;) [05:37] now what? :) [05:38] call 'vapt-get ... -- update' and then 'vapt-get ... -- dist-upgrade' [05:38] (or ... -- install basesystem) [05:39] woohoo! [05:39] heh, it installed the kernel in the vs [05:41] kernel is required probably by some package; you can prevent it by creating a pseudo-kernel package which 'Provides: kernel = ...' [05:44] does any of this do any hard-link unification? [05:45] Simon: not yet; vunify is not ported yet [05:46] and you have that with rpm anyway ... [05:46] does vrpm --unify work? [05:46] just use the 'original' vunify on the installed rpms ... [05:47] Simon: no, vunify has not been ported yet ;) [05:47] umm ok [05:47] apt-get calls rpm [05:48] Bertl: original vunify will not work since rpm-database is stored outside of vserver [05:48] jacques tools don't work with c17h do they? [05:49] @enrico, well a symlink will do nicely, right? [05:49] @simon, you don't have to use all of it ... just vunify ... [05:50] can I use the old build system? [05:50] Bertl: I would copy it; there is already a symlink from /var/lib/rpm -> /.rpmdb; perhaps /.rpmdb -> ../.pkg//rpm/state ;) [05:50] Simon: minimum files are not supported yet [05:51] @simon probably ... just replacing chcontext and chbind could work ... [05:51] do we still have the immutable-linkage-invert bit? [05:51] yes [05:55] oh that's right... jacques tools would never compile for me [05:56] Simon: util-vserver-0.23.190+x are alpha; for new kernel-features and old userspace-features use 0.23.9x [05:58] serving (~serving@213.186.190.62) left irc: Read error: Connection reset by peer [05:58] Action: Simon screams [05:58] ;) [06:01] serving (~serving@213.186.190.62) joined #vserver. [06:03] ah. 0.23.93 still has the broken build which doesn't copy anything [06:03] guess I have to do it myself [06:04] Simon: why broken? I just do not want that vserver gets all my host files (inclusive e.g. /etc/shadow) [06:05] well, as built, it doesn't work [06:05] what's the point in having a build command if you still have to do it yourself? it may as well just make the conf file [06:06] Simon: just do 'cp -ax /sbin /bin /etc /usr /var /lib /vservers/$1/' manually, when you really want it [06:06] yes [06:07] well I agree with enrico that you do not want that ... but I don't agree how he solves that ... [06:07] obviously I dont want /etc/shadow copied, I do want /bin copied [06:08] this copy-all method is stupid [06:08] the best approach would be to list the rpms installed on the base system, and use this list for the vserver ... [06:08] though the user will always have to customise it because each distribution will be different I suppose [06:09] Bertl: no. Define your own set of packages and install them. This is exactly that, what apt-get is doing [06:09] Bertl, yes, that's what I said... [06:09] forgot the IMHO of course ... [06:09] ensc, then I have to go through and figure out all the hundreds of packages that I need? [06:09] Bertl: I want e.g. to have RH9 vservers on a RH7.3 host [06:10] Simon: no. rpmpriorities lists only <10 packages. The rest is implicated and can not be omitted [06:10] enrico, you got me wrong, not exclusively, but as an option ... [06:10] What? [06:11] Bertl: I will implement the minimum-list method, but it has a lower priority only [06:11] if somebody has already tailored his system to become a server .. he doesn't want to do it again ... [06:11] exactly! [06:11] host-requirements != vserver-requirements [06:11] wrong! [06:11] and he doesn't want to f** araound with fancy minimum installs .. although this would be better in the long run ... [06:12] when I configure the host I pick what packages I want to see in the vserver, there will only be a few packages (like kernel etc) which I don't want in the vs [06:12] Simon: for what do you need a kernel in a vserver? [06:12] or initscripts? [06:12] it's a difference between Q&D and Cool ... but the user will not always go for cool ... [06:12] or util-vserver? [06:13] maybe ... ;) [06:13] nothing, but you're doing it the wrong way around, unwanted packages should be excluded rather than having to write the whole package list over again [06:13] well obviously the vserver install fails without initscripts so I guess it is needed? [06:13] Simon: rpmpriorities is really small and will be constant for a distribution [06:14] Simon: create own pseudo-package with 'Provides: initscripts' [06:14] or provide it by your init-concept [06:14] Im not creating an pseudo packages [06:15] it was the init-post script wanted the /etc/init.d/halt [06:15] @enrico give the user enough rope to shoot himself in the foot, if I just could remember who said that ;) [06:15] you mean hang himself ;) [06:16] okay, give him enough ammunition to ahng himself, then ... ;) [06:16] Simon: the questionable initpost is for the standard rh-installation. Create your own distribution-directory with other sources.list entries and you can remove this script [06:18] how does vunify work? [06:18] any chance I can use it with urmpi? [06:18] urpmi* [06:19] you can use it with any rpm database .. so yes ... [06:19] how does it work? :) [06:19] Simon: it invokes 'rpm -ql' on both vservers and compares both lists; then it removes and links common files [06:19] you run it after installing the packages? [06:19] ok cool [06:20] IIRC you have to specify the packages to vunify .. but that should not be a problem [06:20] Bertl: most time, I use 'ALL' [06:21] that _is_ an option ;) [06:23] perhaps, it should be generalized to be independent from package-management: just iterate over the entire filesystem and remove/link same files (time,size) [06:23] that sounds good [06:23] (with the exception of some special directories like /var or /etc) [06:23] how does this work with context-quotas? [06:24] hmm, IIRC there was a project for debian which did this pretty good ... [06:24] ad context-quota: simple, you have to do it in context 0 ... [06:25] ah ok, sounds reasonable [06:25] this way we could get rid of the ILI for context tagged unifications ... [07:43] okay .. time to go to bed ... (just before sunrise ;) [07:43] cul8er ... [07:43] Nick change: Bertl -> Bertl_zZ [07:54] jtholmes (~jtholmes@c-24-98-237-254.atl.client2.attbi.com) joined #vserver. [07:56] jtholmes (~jtholmes@c-24-98-237-254.atl.client2.attbi.com) left #vserver. [09:28] shuri (~ipv6@3ffe:bc0:189:1:ab99:bc87:dc87:ac45) got netsplit. [09:29] shuri (~ipv6@CroCrodile.HuNter.blacktaboovideo.com) joined #vserver. [10:36] shadow (~umka@212.86.233.226) joined #vserver. [10:56] moin [11:29] virtuoso (~shisha@ip114-115.adsl.wplus.ru) left irc: Remote host closed the connection [11:31] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [11:34] virtuoso (~shisha@ip114-115.adsl.wplus.ru) joined #vserver. [11:51] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Remote host closed the connection [12:00] mugwump (~sv@cpc2-glfd1-4-0-cust28.glfd.cable.ntl.com) joined #vserver. [12:03] ircmp echo request -> 255.255.255.255 [12:05] Last message repeated 2 time(s). [12:05] ircping: channel empty [12:07] bye all [12:07] shadow (~umka@212.86.233.226) left irc: Quit: bye [12:17] say (~say@212.86.243.154) joined #vserver. [12:17] say_ (~say@212.86.243.154) left irc: Read error: Connection reset by peer [12:18] mugwump (~sv@cpc2-glfd1-4-0-cust28.glfd.cable.ntl.com) left irc: Quit: better go to work... [13:26] kloo (~kloo@213-84-79-23.adsl.xs4all.nl) joined #vserver. [13:35] alekibango (~john@b59.brno.mistral.cz) joined #vserver. [13:58] dst (~dst@p4b23e3d4.np.schlund.de) joined #vserver. [13:58] hi all [14:30] Simon (~sgarner@apollo.quattro.net.nz) left irc: Quit: so long, and thanks for all the fish [15:02] kloo (~kloo@213-84-79-23.adsl.xs4all.nl) left irc: Remote host closed the connection [16:10] hi there [16:47] netrose (~john877@CC3-24.171.21.47.charter-stl.com) left irc: Ping timeout: 485 seconds [17:04] Nick change: unriel -> riel [17:41] dst (~dst@p4b23e3d4.np.schlund.de) left irc: Quit: going home [18:33] shadow (~umka@212.86.233.226) joined #vserver. [18:33] hi all [18:34] morning [18:34] evening :) [18:36] morning [18:48] Action: shadow look a time.. 5:49 pm [18:48] :) [18:49] crazyimp (~crazyimp@p508B7811.dip.t-dialin.net) joined #vserver. [18:49] hi [19:38] Nick change: Bertl_zZ -> Bertl [19:38] hi Crazy Imp? [19:40] hi alex! [19:41] Hi Herbert [19:41] How are you ? [19:41] fine thanks, how are you? [19:43] excellent :) [19:43] good to hear, let's talk about the command matrix then ... [19:43] after half year i have leased internet line :) [19:44] wow, congrats! [19:45] I'm still on dial-up, an expensive hobby :( [19:47] Bertl> in taganrog, i have dial-up - but 52Kbit connect and stable line.. i sevastopol dial-up line have low quality :( up to 31K and have retrain after 1-2 minutes connection.. [19:50] well.. return to talk about command matrix ? [19:50] yup! [19:51] I have re-read your email, and I assume you meant: we could not finish the talk ..., in the first line, right? [19:53] right [19:53] I agree on most sub commands you proposed, but I would like to reorganize the category blocks ... [19:55] and we already reserved some command numbers (0, 61,62,63) for special purpose ... so we should not touch that ... [19:58] so if we agree that a 8 by 6 matrix is sufficient ... we don't have to change much ... [19:58] i not assign numbers (except 0) - it only structuresed list.. [19:59] okay ... so I would do a MAIN/SYSTEM/HOST category (name to be found/fixed) which contains: [19:59] - create virtual context [19:59] - destroy virtual context [20:00] - migrage to context [20:00] - send signal to all processes in context [20:00] - change context features/flags .. [20:01] what do you think about that? [20:02] more precise I would like to have the following columns: [20:02] - CREATE/DESTROY [20:02] - MODIFY [20:02] - SWITCH [20:02] - CONTROL [20:02] - SETUP [20:02] - OTHER [20:03] where names are again not fixed ;) [20:04] you merge process and context category ? [20:04] not necessarily ... [20:04] those are the columns ... the rows would be: [20:05] - SYSTEM [20:05] - CPU [20:05] - NET [20:06] - DISK [20:06] - VFS [20:06] - MEMORY [20:06] - VERSION [20:06] - OTHER [20:07] (not in this sequence) [20:07] for 2.4 maybe, for 2.6 I would like to split the resource stuff from the virtual context stuff [20:07] rik, you can split what you want, you have 255 commands per category matrix field ... [20:07] and you don't have to use a field where present ... [20:08] but we should agree on a superset for this matrix .. okay? [20:08] space_phoenix (~morrigan@MAIL.13thfloor.at) joined #vserver. [20:09] Action: shadow draw matrix [20:09] @riel if you only use the VERSION and OTHER category, that is fine ... [20:15] Bertl> hm.. i accept rows but SWITCH need only for process and DISK/VFS :-\ and you not think add 2 subcategory [set|get] for resorce control - decide problem with statistic ? [20:16] okay maybe we drop the switch and call it STATS? [20:17] /s/switch/SWITCH/ [20:20] shuri (~ipv6@CroCrodile.HuNter.blacktaboovideo.com) left irc: Remote host closed the connection [20:21] matrix be comforted only if categoryes congenericals :-\ [20:21] create\destroy not need for memory :-\ [20:22] well, we will not be able to satisfy all fields, but I have no problem to leave some empty or use it in a similar way ... [20:23] for example could create/destroy be used to enable/disable memory accounting/checks ... [20:25] @riel, could you comment on that, please? [20:30] hm. it`s have sense :-\ [20:31] hi all [20:32] okay, need something to eat, brb ca 15min ... [20:33] but in stats you want return all statistics from category in one structure ? [20:36] okey.. i prepare tea :) [20:37] hmm. as i see i'm very lucky :) [20:38] i'm in and all people is out in one moment :) [20:38] Hi say :) [20:47] hi say! [20:48] @alex not one structure, remeber we have 255 commands for each field ... so you can have up to 255 different status commands for each column (8) [20:51] hm.. 3D matrix... it interestred.. [20:52] it's called tensor ;) [20:57] well.. switch functions - moved to OTHER. STATS be added.. [20:58] create\destroy = renamed to enable\disable.. [20:58] right ? [20:58] good idea ... [20:58] space_phoenix (~morrigan@MAIL.13thfloor.at) left irc: Quit: Lost terminal [21:01] but.. other idea .. switch functions - moved to modify.. because switch file from one context to another it modify context state for file :-\ [21:02] task migrate is modify - context state for task :-\ [21:02] CAT_CREATE, CAT_MODIFY, CAT_CONTROL, CAT_STATS, CAT_OTHER seems sufficient ... modulo the names ... [21:03] maybe we should not explicitely implement the matrix, only keep it in mind when selecting specific CATEGORIES? [21:04] hmm, why doesn't rik participate in this discussion? [21:08] what about the following thematic columns: [21:08] - (VERSION,STATS,QUERY) col 0 [21:09] - (CREATE,DESTROY,SETUP) col 1 [21:09] - (MODIFY,ALTER) col 2 [21:09] - (MIGRATE,CHANGE,MOVE) col 3 [21:09] - (CONTROL,LIMIT) col 4 [21:09] - (OTHER) col 5 [21:09] what it QUERY and ALTER ? [21:10] those are just thematic concepts .. no commands there yet ... [21:10] and the rows: [21:10] - (SYSTEM,HOST,MAIN) row 0 [21:11] - (CPU,PROCESS,SCHEDULER) row 1 [21:11] - (NETWORK) row 2 [21:11] - (DISK,VFS) row 3 [21:11] (MEMORY,SWAP) row 4 [21:11] - (OTHER) row 5 [21:11] it`s good. [21:12] then we select specific commands like VCMD_CREATE_CONTEXT [21:12] which would be in col 1, row 0 for example ... [21:14] good.. [21:15] Action: riel is back [21:15] okay, let me see how we could fit this into the current assignment .. [21:16] 0,0 = VERSION (perfect) [21:16] note that the syscall switch for 2.4 and 2.6 doesn't need to be exactly the same [21:16] only the commands that exist in both versions should be the same, I guess [21:16] that is correct ... [21:16] Herbert - what number you assigment for max col and max row ? [21:16] but you should have plenty space to put your commands in the correct fields ... [21:18] i would suggest rows (0-7) and cols (0-7) this would fit into the 2^6 fields currently used ... [21:18] row 7 would become other ... column 7 could become compat ;) [21:19] column 5 could become experimental ... [21:20] this way we would not have to change any assignment already done ;) [21:20] but if many alike commands be placed in OTHER - me can be create new colum or row.. [21:20] mhepp (~mhepp@r72s22p13.home.nbox.cz) joined #vserver. [21:20] hmm, not really possible, because no space will be left :( [21:21] but can be assign 0-16 for range ? [21:21] not if we fit it into the 2^6 bits used now ... [21:22] only 8x8 is possible ... [21:23] do you see any commands going into OTHER? either row or column? [21:23] but me can fit into 2^8 bits :) [21:23] space_phoenix (~morrigan@www.13thfloor.AT) joined #vserver. [21:24] if me create greate category - simmular block_device - it need row ? but if we create new operation (supported on most categories) be add colum... [21:25] okay just give me an operation which doesn't fit into one of those columns ... [21:30] we could extend this to 8 bits, but I won't change this unless there is a really good reason to do so ... nevertheless we all (rik,alex,myself) agreed on the current bitmask (2^6 cat, 2^8 command, 2^12 version) [21:33] what we can do, is leave row 7 and the first 5 columns of row 8 for general purpose categories, not defined yet ... so you could add up to 12 non fitting categories ... [21:33] hm.. you realy need support 4k versions for all commands ? [21:34] no, I don't need it, but do you relly need more than 64 categories? [21:36] even byte splits are easier to parse in a debugger [21:36] but we not used all from this matrix. one big category i named - in old future we can add control access for block\char devices... [21:36] or even just nybble-aligned splits [21:36] @rik, well we have that, right? [21:37] "2^6 cat" splits a nybble, doesn't it? [21:37] http://vserver.13thfloor.at/Stuff/virtual.h [21:37] *sigh* [21:37] Action: riel looks [21:37] heh ok, sorry [21:38] somebody said, please reserve some space for future, if I just could remeber who that was? ;) [21:39] @alex the block device would not fit into DISK/VFS ? [21:40] not. [21:40] what block device is it? [21:42] tape driver for exaple :-\ it not have FS on it.. [21:43] hrm, well if you have a tape driver syscall for virtual context, you can put it into OTHER, I guess ;) [21:43] or you can add the new ALEX_TAPE category ;) [21:44] space_phoenix (~morrigan@www.13thfloor.AT) left irc: Quit: ircII EPIC4-1.1.12 -- Are we there yet? [21:44] i say about control access for devices.. [21:44] maybe DISK/DEVICES/VFS ... as thematic row then? [21:44] also hava char devices.. as mouse.. [21:45] it can be fit in personal category - devices. [21:46] or DEVICES/OTHER/WOSSNAME row .. or as you suggested a personal DEVICES category, I would consider this appropriate ... [21:47] okay, does this look sound now? [21:48] if so, let me write the matrix and we try to add the commands ... [21:48] with added device - good. [21:52] if it corrent - start added commands... [21:53] but with it`s categories me have small command on every... [21:56] crazyimp (~crazyimp@p508B7811.dip.t-dialin.net) left irc: Ping timeout: 485 seconds [22:00] Nick change: riel -> unriel [22:00] http://vserver.13thfloor.at/Stuff/syscall2.0.txt [22:00] what do you think about that ... [22:00] hello [22:01] hi matt! [22:01] so did MrBawb ever test O1? [22:01] I don't know .. haven't seen him since ... [22:01] hrm [22:01] oh well... [22:03] so whats new? [22:03] hmm, device mapper 1.00.05 ;) [22:04] whats that? [22:04] LVM 2.0 ... [22:04] oh [22:04] or EVMS ... if you prefer ... [22:05] any news on your part? [22:05] not much, everything is running good [22:05] well, that is good news then, right? [22:05] i'd say the -aa VM really helps on that server that was using 800MB of swap [22:05] 2.4.23pre7 [22:06] I have a good feeling with 2.4.23 too ... [22:06] hopefully marcello decides to release it soon ... [22:06] can't say for sure till after a week of uptime, but almost 4 days now and much better management [22:06] and I can't say enough praise about the O(1) on that server ... [22:07] crazyimp (~crazyimp@p508B7450.dip.t-dialin.net) joined #vserver. [22:07] loads used to jump to 100 quite often (mainly when 1-2 updatedb's were running), and with my one client running his mail lists it was always lagged and loads of 8+ [22:07] well, you could look at Sam's -ac version ... this should contain a working O(1) smp scheduler ... [22:07] now it's always responsive and according to sar average load is 1.27 [22:08] hi crazyimp? [22:08] well, i need your dl/ml patches more :) [22:08] seeing that my non-o1 server is smp and has 3GB of ram [22:08] i'd like to see what running 2.4.23pre7 on it would do [22:08] as according to a few posts HIGHMEM support isn't slow anymore [22:09] it seems it was improved somewhat, especially for I/O bounce buffers ... [22:09] 1300+ procs on that server too [22:09] for 3GB it is worth a try, at 1GB I'd just disable HIGHMEM ... [22:10] Bertl: well, the post I saw was by a guy that was doing testing and he said he normally told people with only 1GB to turn it off but that has changed :) [22:10] http://kerneltrap.org/node/view/1038 [22:10] are you interested in improving the ml patches/ adding the RSS limits? [22:11] rss limits arn't a big deal to me, and even though I have gripes about the accounting it really is correct [22:12] hmm, okay no problem with that, just assumed you would like to add this one ... [22:13] as far as rss guarantee? [22:13] I didn't know there was a way to do that without rmap? [22:15] you see Con's comment at the bottom re: highmem [22:15] hrm, now that I re-read he's not going against his recommendation [22:15] just say it's good news :) [22:16] what is the dentry cache? [22:17] memory for cache directory entries [22:18] oh [22:19] @matt no rss limit/guarantee only with rmap, but we have rmap, don't we? [22:19] Bertl: yes, but do you mind maintaining it? seems like a lot of work for you to port [22:19] matta: I wasn't able to compile the one patch and the other one didn't have the ctx stuff in it [22:19] MrBawb: right [22:19] MrBawb: O1c17g2 has 3 build errors... [22:20] and the other didn't have ctx stuff [22:20] heh [22:20] exactly :) [22:20] MrBawb: the first one you just need to include include/majors.h in quota.c, then remove the #if CONFIG_SMP sections in sched.c and ksym.c [22:20] did you have any problems with the non-ctx O1 patch? [22:20] nope, it compiled and booted fine [22:21] how long was it booted? [22:21] 3 hours or so [22:21] it wasn't doing much, though [22:21] oh, any load? [22:23] I ran out of time before I was able to test anything on it [22:23] well the maintaining isn't the problem, although I would prefer if rik would rediff the rmap .. [22:29] okay so what do we do regarding the O(1) now ... [22:29] shall I adapt the c17h for the new O(1)? [22:30] yeah [22:30] i mean, i'm sure the build errors and something with my fix was the problem [22:31] and it's running stable and fast on UP [22:31] major improvement, i went from taking people off of the server to actually putting on more (to replace the ones I took off :) [22:33] i'll be willing to test SMP again in a few days [22:33] like 3-4 [22:38] Nick change: surriel -> riel [22:39] jack (~jack@206.162.172.138) joined #vserver. [22:39] hi jack! [22:39] Hi everyone [22:42] IIRC you said you are willing to maintain your vserver tools in the future? right? [22:44] hi jack [22:46] JonB (~jon@129.142.112.33) joined #vserver. [22:46] hi jon! [22:47] Yes somewhat. Let me explain [22:47] hey Bertl [22:48] For me what we have as ctx-NN stuff is the current stable feature set. Many people relied on that in production. So I intend to maintain ctx-NN + my vserver package to support those [22:48] until the new stuff is stable. [22:48] At some point, this will become pointless and everyone will move to the new stuff, whatever the price [22:48] hmm, let me make a suggestion here ... [22:48] By price, I mean, whatever upgrade path, configuration change [22:49] I agreed to release the c17f as first STABLE release for vserver kernel patch, right? [22:50] and if you make some tiny modifications to the 0.24er tools, this will work and be compatible too, right? [22:50] I guess [22:50] there is no sense in maintaining/having two kernel patches for the same functionality/target/kernel ... [22:51] and I think you can consider c17f stable in your sense too, right? [22:52] in the next month we can move to the syscall switch and adapt your commands, the same way as enricos commands do right now ... [22:52] I have not reviewed 17f, but I think this is just a rework/cleanup of the previous ctx-17 [22:52] Bertl: i was thinking, was anyone thinking about adding a feature to start vservers from within vservers ? [22:52] http://vserver.13thfloor.at/Stuff/split-2.4.20-c17f/ [22:52] http://vserver.13thfloor.at/Stuff/split-2.4.21-c17f/ [22:52] http://vserver.13thfloor.at/Stuff/split-2.4.22-c17f/ [22:53] Ok let me restart this. Quite frankly, I don't understand why this seems so complicate [22:53] Basically, there is a project in production at several places. Unfortunatly this project does not evolve at the pace it should [22:54] A second project is create to solve this issue [22:54] The new project has many goals: Rework interfaces, new functionnatliy, better conformance, and so on [22:55] But there are users out there in production already running many many vservers. [22:55] So I suggest we have a clear line (and don't get back to ctx-a and b and c as confusing, this is the past and I was stuck with no time) [22:55] quite frankly, it _is_ so complicate, because you made me maintainer/project leader, but continue to compete, instead of help, by throwing out-of-line versions on the community ... don't get me wrong, but this isn't a GoodThing(tm) to do ... [22:56] and regarding the versioning, we will have a new name and number ... but with the same features as your last stable release (ctx-17c) which is c17f in my nomenglature ... [22:57] Really this is a major miss-understanding. While the project was starting (and you were talkiing about november) I had some time and I had things not published [22:57] So I kind of clear the house [22:57] Yes this is really what I want. I asked for that. Think of it as linux 2.0 and linux 2.1 [22:57] well I expected you to send them to me, post a note on the mailing list, and let me decide what to do with it ... [22:58] So ctx-NN + my vserver package is 2.0 and I do maintain it [22:58] and vserver-XX is yours [22:58] now we have folks installing ctx-18pre1 and asking why it doesn't work as expected ... [22:58] Bertl: then just keep your stuff at linux-vserver.org, and jack's at his place [22:59] It was part of the clear the house move, not an atttempt to compete. [22:59] well it added unnecessary confusion, with jack gone a minute later ... [22:59] This is the idea. I maintain 2.0 and you go with 2.1 (so to speak) [22:59] What do you mean (gone a minute later) [23:00] okay, lets forget the past, lets discuss the future ... [23:00] I would prefer the following concept ... [23:01] 1) there is a main/stable branch on vanilla 2.4 [23:01] 2) there is an experimental branch on 2.4 (rmap/O(1)/features/etc) [23:02] 3) there are several side branches for specific kernels (-ac/-aa/whatever) [23:02] Bertl: what about the 2.6 kernels ? [23:02] 4) rik will start/maintain the 2.6 branch [23:03] my name/version scheme will look like this ... [23:03] vserver-1.0 (first stable release) [23:03] vserver-1.1.0 (development of 1.0) [23:04] hrm [23:04] vserver-1.1.1 (next devel ...) [23:04] why not more like FreeBSD? :) [23:04] vserver-1.1.99 (pre release ...) [23:04] Bertl: i don't think that's optimal... [23:04] vserver-1.2 (second stable release) [23:04] hrm [23:04] oh, didn't see 1.1.0 [23:05] that's just like the kernel [23:05] congrats! [23:05] it's less confusing as it's alreadly in our heads [23:05] and it's a scheme that's already been decided by others [23:06] i'm sure there were many flame wars over the version scheme of the kernel, and that's what they settled on [23:06] sounds good [23:06] how about 1.0.0 instead of 1.0? :) [23:06] @jack I would appreciate _not_ to have a special jack branch .. if we can work together on the devel/main branch ... [23:07] i agree [23:07] @jack I think the vserver-1.0 (now c17f) will satisfy your stability needs ... and the future stable releases will provide a smooth upgrade path ... [23:10] Yes [23:11] okay, the only thing I would need you to add to your tools, are some capability settings ... CAP_QUOTACTL and CAP_PTRACE IIRC ... [23:11] and because the chsaferoot() isn't in c17f, it would be nice to remove the warning message ... [23:12] everything else should work out of the box ... [23:13] @MrBawb simple 1.0 is simpler than 1.0.0 and if there is no 1.0.1 it is pretty superfluous ... [23:14] and if required 1.0.1, 1.0.2 will be used for critical bugfixes ... [23:17] Is this CAP_SYS_PTRACE ? [23:17] Is CAP_QUOTACTL an enhancement, not officially in linux kernel ? [23:17] yes to both ;) [23:19] What is the ID allocated to CAP_QUOTACTL ? [23:19] +#define CAP_QUOTACTL 29 [00:00] --- Sat Oct 25 2003