Re: [gentoo-user] Re: emerge latest in a certain version series of a package
on 01/30/2014 08:30 AM Mick wrote the following: On Wednesday 29 Jan 2014 19:37:39 Thanasis wrote: Sometimes folks have to stay with a kernel series, because a vendor binary patch forces them into this situation. That's my case, ie Nvidia drivers for a relatively old hardware (AGP Graphics). Wouldn't nouveau drivers overcome this problem, or is some other reason keeping you with the proprietary NVidia drivers? In 3D performance, the nouveau driver is my 2nd option.
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
on 01/30/2014 12:50 AM Alan McKinnon wrote the following: On 30/01/2014 00:14, Thanasis wrote: Yea, but I think, this is the case for *all* packages, not only kernel sources, at least until now, isn't it? No, not at all. Kernels are different and portage treats them very differently. Everything else gets sane defaults that you can tweak if you want to, or leave as-is if you don't. With kernels, you do not have this choice - you MUST tweak and customize it to get something that even runs at all. OK, maybe bootloaders are also a bit special too.. There is no common basis of comparison between kernels and everything else, that is how different they are. Sort of like saying rabbits work like horses because they both have 4 legs. Yes, the bit about legs is true but it also completely misses the point - there's no realistic situation in everyday life where a rabbit works like a horse. You are just going to have to face it - kernels are special. You either deal with them The Gentoo Way, or run Ubuntu. Even genkernel doesn't change this - all genkernel does is defer that same action onto someone else, but the actions remain the same. You are right, and I am not arguing about that. Of course kernels *are* and have *always* been treated differently, than other packages. All I wanted to say is, that even for other SLOTed packages, there is no option in general (except for the special cases where VARIABLES are assigned values in make.conf) for the user to choose to follow a number of specific subseries of versions of a package.
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
On 30/01/2014 11:54, Thanasis wrote: on 01/30/2014 12:50 AM Alan McKinnon wrote the following: On 30/01/2014 00:14, Thanasis wrote: Yea, but I think, this is the case for *all* packages, not only kernel sources, at least until now, isn't it? No, not at all. Kernels are different and portage treats them very differently. Everything else gets sane defaults that you can tweak if you want to, or leave as-is if you don't. With kernels, you do not have this choice - you MUST tweak and customize it to get something that even runs at all. OK, maybe bootloaders are also a bit special too.. There is no common basis of comparison between kernels and everything else, that is how different they are. Sort of like saying rabbits work like horses because they both have 4 legs. Yes, the bit about legs is true but it also completely misses the point - there's no realistic situation in everyday life where a rabbit works like a horse. You are just going to have to face it - kernels are special. You either deal with them The Gentoo Way, or run Ubuntu. Even genkernel doesn't change this - all genkernel does is defer that same action onto someone else, but the actions remain the same. You are right, and I am not arguing about that. Of course kernels *are* and have *always* been treated differently, than other packages. All I wanted to say is, that even for other SLOTed packages, there is no option in general (except for the special cases where VARIABLES are assigned values in make.conf) for the user to choose to follow a number of specific subseries of versions of a package. Yes, I see what you mean. Portage restricts you to $arch and the SLOTs, there's no mechanism whereby the user can easily pin down the exact ranges or versions they want to have. Your only option is to eternally fiddle with keywords and masks, but this is a high maintenance route. You also have to keep checking that your masks match what is in portage today. For most folks, that is much more trouble than it's worth. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
On 30/01/2014 17:25, James wrote: As part of the open source community, I would think you have a repsonsibility to *reward those vendors that work generously with the greater open source community* ? No, not actually. The only responsibility he has is to do whatever he feels like doing. It is nice to favour vendors who work with us but no-one is obligated to do so; trying to so is enforcing your moral code on another. That other is free to entirely reject your moral code at will. I get what you are saying but your statement is more accurate if you omit or change the word responsibility. It does not belong. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
On Thursday 30 Jan 2014 15:25:47 James wrote: Nividia is a *VENDOR* that chooses not to provide information so drivers can be properly maintained, historically. ATI (AMD now) is a vendor who provides information so drivers can be maintained, even optimized, into perpetuity. Maybe you chose unwisely?(get ATI next time) unless you have a valid reason for choosing a prick as your vendor? I've used nVidia cards for many years. When I bought my first one (maybe 20 years ago) ATI support in Linux was woeful, and the doggerel had it that the hardware was less competent too, so I chose nVidia. Since then I've seen more cries for help on this list from ATI owners than nVidia, so it's not clear to me which is the better choice these days. Since I don't do bigotry my choice is on technical grounds, and I don't need hardware 3D acceleration. So the jury's still out as far as I'm concerned. Well, maybe CUDA might ramp up my contribution rate to BOINC projects a bit. Again, no obvious winner. -- Regards Peter
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
on 01/30/2014 11:04 PM James wrote the following: Peter Humphrey peter at prh.myzen.co.uk writes: Maybe you chose unwisely?(get ATI next time) unless I've used nVidia cards for many years. When I bought my first one (maybe 20 years ago) ATI support in Linux was woeful, and the doggerel had it that the hardware was less competent too, so I chose nVidia. Since then I've seen more cries for help on this list from ATI owners than nVidia, so it's not clear to me which is the better choice these days. Since I don't do bigotry my choice is on technical grounds, and I don't need hardware 3D acceleration. So the jury's still out as far as I'm concerned. Well, maybe CUDA might ramp up my contribution rate to BOINC projects a bit. Again, no obvious winner. I agree with all you have said. However Nvidia's policies, not their hardware, is the problem, hence the degraded comment on their reputation. A company may struggle with the latest, robust hardware, but they do not have to behave as jerks. Nvidia's lack of copperation with their old hardware, puts them in the jerks column in my mindset. Even cisco provides full and complete sources, (from russia with love!). The person is using old hardware, and for a very long time, ATI has been the better choice for folks using old (video) hardware. He's not pushing the limits of performance; he just wants (needs?) a video card with an open source solution. I like to (stongly) suggest to folks to use their checkbook to influence the behavior of vendors, ymmv. Folks with low_dollars are almost aways better off with ATI, particualar if they intend to run 'vintage video hardware', imho. James, I agree with you in general about supporting open source friendly vendors, but in this case, I would agree with Peter, because I find that Nvidia although not so open as ATI, has been better supporting (quicker to release drivers) for its newer cards than ATI does. On the other hand, the old system I was talking about, is an Athlon 754 socket, with an NVIDIA G71 [GeForce 7800 GS] (rev a2) card. I believe this card can use up the system's AGP bus (and the CPU) to its limits, so I don't feel I should bother to change the card to an ATI one, since I wouldn't gain any performance, except perhaps, for a radeon driver in the kernel, which I doubt would perform as well as the Nvidia's one. Anyway, this Nvidia-vs-ATI discussion is going OT in the current thread. And I think that we can close the current thread here. Thanks to all for your help :)
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
On 29/01/2014 15:23, James wrote: Alan McKinnon alan.mckinnon at gmail.com writes: Is there a way to specify that I want to install (emerge) the latest 3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with the latest gentoo-sources? that won't work as each kernel ebuild is in it's own unique slot consisting of one and only one kernel version. I doubt the kernel team are going to change that. What you are asking is fundamentally not possible as slots are used in a very incompatible way with your idea. Hm. There might be a work around that suites your needs? # emerge -pv =gentoo-sources-3.10.28 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild NS ~] sys-kernel/gentoo-sources-3.10.28:3.10.28 [3.10.25:3.10.25, 3.13.0-r1:3.13.0-r1] USE=-build -deblob -experimental -symlink 557 kB Total: 1 package (1 in new slot), Size of downloads: 557 kB Does that work for you? (Note: I also have this in my package.keywords: sys-kernel/gentoo-sources) Ah but there's a catch to that. 3.10.28 is ~arch, so if you keyword it and don't mask later versions, you get 3.13.0-r1 when updating world. The OP wants automagic installation of sources when 3.10.28-r1 or 3.10.29 comes around, and portage don't do that. For kernels, we're supposed to examine kernels closely, make a decision and install sources for the very specific version of our choice. The only automagic is for the very very latest of whatever arch we run -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
on 01/29/2014 03:23 PM James wrote the following: There might be a work around that suites your needs? # emerge -pv =gentoo-sources-3.10.28 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild NS ~] sys-kernel/gentoo-sources-3.10.28:3.10.28 [3.10.25:3.10.25, 3.13.0-r1:3.13.0-r1] USE=-build -deblob -experimental -symlink 557 kB Total: 1 package (1 in new slot), Size of downloads: 557 kB Does that work for you? No, because as I said in a previous post, the matter is that when a newer version 3.10.X is in the tree, and you do an update of the world set, the newer kernel source of the 3.10.X series won't appear as an update. You'll have to emerge it again manually and likewise manually unmerge the older one.
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
on 01/28/2014 10:12 PM eroen wrote the following:
On Tue, 28 Jan 2014 21:29:21 +0200, Thanasis thana...@asyr.hopto.org
wrote:
Is there a way to specify that I want to install (emerge) the latest
3.10.X series of sys-kernel/gentoo-sources as a slot, in parallel with
the latest gentoo-sources?
Currently, that would be version 3.10.28.
I know I can specify it like so,
emerge =sys-kernel/gentoo-sources-3.10.28
but then it would not get auto-updated when a newer version of that
series (for example 3.10.29) becomes available in portage.
Afaik there is no configuration-only way to do this, but you can make
it happen by adding your own virtual ebuilds in a local overlay[1],
say virtual/thanasis-sources, then adding that to world.
You can make one ebuild for each kernel-series you want, each in its
own slot, using the =cat/pkg-3.10* syntax for RDEPEND. Find attached a
(barely tested) suggestion for
virtual/thanasis-sources/thanasis-sources-3.10.ebuild .
Thanks eroen, I tested it and it looks like it works.
One caveat,
=cat/pkg-3.10* also matches cat/pkg-3.107.1,
I guess that kernel versions = 3.100 are going to be in the tree, if
ever, probably in about a decade from now :P
which could become an
issue if you wanted, say, the 3.2 series.
Why would that be a problem?
In the ebuild, you specified the value
RDEPEND==sys-kernel/gentoo-sources-${PV}*
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
on 01/29/2014 03:36 PM James wrote the following: Once the newer kernel series come out, the newer versions of a series (usually) slow way down on being delivered. Not necessarily, if some devs are maintaining a series as long term, which, I think, is the case for the 3.10.X series (if I am not wrong). Maybe a wildcard with the kernel series name in your world file might work. Yes, maybe. And that's why am I asking. At some point, the long kernel series revisions are usually only about tweaking a few given features. And bugs. If that is your situation, dig into the kernel sources, read the docs and find the guy hacking on that option. Many will add additional testers, if you know what your are doing. My situation, is not so complicated hopefully :P Alternatively, run a cron job where you manually query the gentoo-sources can parse out what you wnat by kernel series number, and then mail that to yourself, if it is all that important That would be another option, for another manual way. Thanks for the idea though.
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
on 01/29/2014 05:59 PM James wrote the following: Once the newer kernel series come out, the newer versions of a series (usually) slow way down on being delivered. Not necessarily, if some devs are maintaining a series as long term, which, I think, is the case for the 3.10.X series (if I am not wrong). Long term kernel series usually have one key guy (Cox historically) versus thousands of devs work on things for new/latest/upcoming kernel releases. I am a big fan of Alan Cox, as many of us are, and he is quite prolific to be sure, but what you are saying, makes you appear, ignorant of kernel development processes. I know I am mostly ignorant of kernel development processes. I only use Alan Cox, as an example; I have no idea who the long-term kernel maintainer is now, but historically it's been somebody with a vested interest, or some poor-unappreciated sapimho. Googling about kernel maintainer for long term 3.10, I found the following page: http://kroah.com/log/blog/2013/08/04/longterm-kernel-3-dot-10/ Would he (Greg) be the one? The purpose of the long-term maintained kernels is in-fact and indeed, so that folks do not have to change kernels often. Yea, maybe, but not my case though (see below). Those features that are fixed in a kernel series, are also pulled-forward into the newer kernels series. FEW have valid reasons not to upgrade to the newer series of stable kernels. Right, unless ... Sometimes folks have to stay with a kernel series, because a vendor binary patch forces them into this situation. That's my case, ie Nvidia drivers for a relatively old hardware (AGP Graphics). In that case, the vendor supplied patch might not even work (compile) with newer kernels in a particular series. Commercial vendor support of a binary wedged into a linux kernel, is fraught with all sorts of issues quite often. Staying within a given kernel series is easier (mostly) for companies to maintain a binary patch, with a poorly qualified (learning?) noob kernel hacker, imho. Bingo :) If you want further help, you have to precisely define why you need to stay in a particular kernel series, but yet you need to be notified, immediately, Well, I didn't say or mean immediately, but, you know...make our time easier... maybe invest it better... without expending some extra effort yourself? snip My situation, is not so complicated hopefully :P Do tell the specifics.. I'm scratching my head, wondering whats up with your need... Nothing special. I am merely a home user, maintaining a few PCs. That's all. Thanks James :)
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
On 29/01/2014 17:35, James wrote: Thanasis thanasis at asyr.hopto.org writes: No, because as I said in a previous post, the matter is that when a newer version 3.10.X is in the tree, and you do an update of the world set, the newer kernel source of the 3.10.X series won't appear as an update. You'll have to emerge it again manually and likewise manually unmerge the older one. Manual control/determination of kernels may appear overtly clumsy, but it is far better to expend a bit of extra time, manually, than in panic mode; which is why I think you see a lack of feature rich granularity in gentoo related to kernels, imho. Plus, the target market for Gentoo is folks who know how kernels work, know what they want and know how to enable it without hand-holding. If the target market doesn't know how to do this, they almost always have the skills *and desire* to learn it, and usually do so very rapidly. Add it all up with what you said and you get a complete explanation for why gentoo-sources works like it does. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
On 29/01/2014 21:37, Thanasis wrote: I only use Alan Cox, as an example; I have no idea who the long-term kernel maintainer is now, but historically it's been somebody with a vested interest, or some poor-unappreciated sapimho. Googling about kernel maintainer for long term 3.10, I found the following page: http://kroah.com/log/blog/2013/08/04/longterm-kernel-3-dot-10/ Would he (Greg) be the one? That's the one, he goes by the friendly name of gregkh. Greg is something of a modern miracle, every time I try add up how many kernel subsystems he maintains I get a number bigger than the number of subsystems in the kernel go figure :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
on 01/29/2014 11:41 PM Alan McKinnon wrote the following: On 29/01/2014 17:35, James wrote: Thanasis thanasis at asyr.hopto.org writes: No, because as I said in a previous post, the matter is that when a newer version 3.10.X is in the tree, and you do an update of the world set, the newer kernel source of the 3.10.X series won't appear as an update. You'll have to emerge it again manually and likewise manually unmerge the older one. Manual control/determination of kernels may appear overtly clumsy, but it is far better to expend a bit of extra time, manually, than in panic mode; which is why I think you see a lack of feature rich granularity in gentoo related to kernels, imho. Plus, the target market for Gentoo is folks who know how kernels work, know what they want and know how to enable it without hand-holding. If the target market doesn't know how to do this, they almost always have the skills *and desire* to learn it, and usually do so very rapidly. Add it all up with what you said and you get a complete explanation for why gentoo-sources works like it does. Yea, but I think, this is the case for *all* packages, not only kernel sources, at least until now, isn't it?
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
On 30/01/2014 00:14, Thanasis wrote: on 01/29/2014 11:41 PM Alan McKinnon wrote the following: On 29/01/2014 17:35, James wrote: Thanasis thanasis at asyr.hopto.org writes: No, because as I said in a previous post, the matter is that when a newer version 3.10.X is in the tree, and you do an update of the world set, the newer kernel source of the 3.10.X series won't appear as an update. You'll have to emerge it again manually and likewise manually unmerge the older one. Manual control/determination of kernels may appear overtly clumsy, but it is far better to expend a bit of extra time, manually, than in panic mode; which is why I think you see a lack of feature rich granularity in gentoo related to kernels, imho. Plus, the target market for Gentoo is folks who know how kernels work, know what they want and know how to enable it without hand-holding. If the target market doesn't know how to do this, they almost always have the skills *and desire* to learn it, and usually do so very rapidly. Add it all up with what you said and you get a complete explanation for why gentoo-sources works like it does. Yea, but I think, this is the case for *all* packages, not only kernel sources, at least until now, isn't it? No, not at all. Kernels are different and portage treats them very differently. Everything else gets sane defaults that you can tweak if you want to, or leave as-is if you don't. With kernels, you do not have this choice - you MUST tweak and customize it to get something that even runs at all. OK, maybe bootloaders are also a bit special too.. There is no common basis of comparison between kernels and everything else, that is how different they are. Sort of like saying rabbits work like horses because they both have 4 legs. Yes, the bit about legs is true but it also completely misses the point - there's no realistic situation in everyday life where a rabbit works like a horse. You are just going to have to face it - kernels are special. You either deal with them The Gentoo Way, or run Ubuntu. Even genkernel doesn't change this - all genkernel does is defer that same action onto someone else, but the actions remain the same. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: emerge latest in a certain version series of a package
On Wednesday 29 Jan 2014 19:37:39 Thanasis wrote: Sometimes folks have to stay with a kernel series, because a vendor binary patch forces them into this situation. That's my case, ie Nvidia drivers for a relatively old hardware (AGP Graphics). Wouldn't nouveau drivers overcome this problem, or is some other reason keeping you with the proprietary NVidia drivers? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
