Lluís Batlle i Rossell <vi...@viric.name> writes: > On Mon, Nov 19, 2012 at 02:26:00PM +0100, Mathijs Kwik wrote: >> Marco Maggesi <magg...@math.unifi.it> writes: >> >> > For the record, I still use 2.6.35 which is the newest kernel >> > supporting BLCR presently available in NixoOS (BLCR needs kernels <= >> > 2.6.38). >> > By the way, for what I can say, this makes NixOS the only distribution >> > which currently supports easily BLCR (just add two lines in >> > configuration.nix). >> > Seems that the development of BLCR has been resumed recently, but it >> > still difficult to predict when there will be a new version that >> > supports 3.x.y kernels. >> >> We will keep 2.6.35 for now and it will become the only 2.6.x version. >> Mainly because our current default kernel-headers version is 2.6.35 as >> well. So in the short term, you're fine. >> >> After next stdenv-upgrades-merge however, it seems 3.5.x will be chosen for >> the >> headers, which might cause problems for older kernels. >> Also, I would like to stabilize on long-term-supported kernels, which >> means 2.6.32 or 2.6.34 in the 2.6.x range. >> >> To combat the headers-problem, we can add a headers-compat/headers-2.6 >> package and have the system use those if the chosen kernel is lower than >> our default (3.4 or 3.6 probably). This will cause rebuilds for almost >> every other package, and probably hydra will not produce binaries for >> systems that want to stay on 2.6, so it will take some more >> building-from-source, but at least it keeps the possibility >> to run older kernels open. I think that's a good trade-off. > > As for glibc, the glibc has to be told the minimum kernel version to build > for. > It will use not all syscalls available in the headers, but only those which > match the 'configure' argument requirement. > > But I imagine Eelco wants glibc to be built for 3.5 kernels or above.
As 3.5 is dead, we should probably choose 3.4 or 3.6. > > In trunk we have glibc using an absurdly low kernel, and I think it ends up > not > having 'fstatat' making proper direct syscalls or something like that. Upgrading this to a recent 3.4+ level sounds like a good idea. Keeping an additional low/compat target around (headers + glibc minimum for 2.6.32) sounds like a good thing too, with the consequence that if you want to use it, you need to compile a lot from source. Sounds like a good trade-off. I suspect most uses for these lower kernel versions to be related to specialized hardware or virtual machine targets, probably not needing big X11 / desktop stuff, so it's not too bad. > > Regards, > Lluís. > >> > 2012/11/19 Eelco Dolstra <eelco.dols...@logicblox.com>: >> >> Hi, >> >> >> >> On 18/11/12 20:58, Mathijs Kwik wrote: >> >> >> >>> Indeed I didn't think about 2.6.35 being our current headers, so >> >>> indeed we should keep 2.6.35 until stdenv-upgrades. >> >> >> >> FWIW, the stdenv branch already uses Linux 3.5.x for the kernel headers. >> >> >> >> -- >> >> Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ >> >> _______________________________________________ >> >> nix-dev mailing list >> >> nix-dev@lists.science.uu.nl >> >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> > _______________________________________________ >> > nix-dev mailing list >> > nix-dev@lists.science.uu.nl >> > http://lists.science.uu.nl/mailman/listinfo/nix-dev >> _______________________________________________ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev