[gentoo-user] Re: emerge latest in a certain version series of a package
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) hth, James James
[gentoo-user] Re: emerge latest in a certain version series of a package
Thanasis thanasis at asyr.hopto.org writes: Currently, that would be version 3.10.28. I know I can specify it like so, emerge =sys-kernel/gentoo-sources-3.10.28 Opps, I did not read very deeply, still on first java_fix but then it would not get auto-updated when a newer version of that series (for example 3.10.29) becomes available in portage. Once the newer kernel series come out, the newer versions of a series (usually) slow way down on being delivered. Maybe a wildcard with the kernel series name in your world file might work. At some point, the long kernel series revisions are usually only about tweaking a few given features. 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. 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 hth, James
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: Portage performance dropped considerably
hasufell wrote: snip If we support disabling all useflags on package level (and we do), then we support disabling all on global level as well. All _unexpected_ breakage that occurs due to that are ebuild bugs that have incorrect dependencies or missing REQUIRED_USE constraints. Defaults are just a usability thing, nothing more. Amen. The notion that a particular USE flag combination is 'wrong' for a package is nonsensical. The notion that a user is culpable for QA issues that are solely the preserve of the maintainer even the more so. Any such issues should either be fixed or the options afforded to the user redacted if the maintainer is unwilling or incapable of supporting them. Scolding those users who have the audacity to configure Gentoo to serve their requirements is a distraction, to put it politely. --Kerin
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.
[gentoo-user] Re: emerge latest in a certain version series of a package
On Wed, 29 Jan 2014 16:09:31 +0200, Thanasis thana...@asyr.hopto.org
wrote:
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}*
I think you got it, but then I confused you with a poorly chosen
example. The problem I referred to; if you try this exact method to
follow the 3.2.x kernels, you will switch to 3.20.0 when that comes
around. Similarly, it does not currently work with 3.1.x, and could
eventually (in a very long time, like you commented :P ) break for
other versions.
It would be nice to have a better way to accomplish this, perhaps
with some sort of world file variant supporting version ranges. That
could also be more intuitive and less prone to unintended consequences
(especially in the face of SLOTs) than package.mask-ing newer versions
to keep an old version of something around.
--
eroen
signature.asc
Description: PGP signature
[gentoo-user] Re: emerge latest in a certain version series of a package
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. James
[gentoo-user] Re: emerge latest in a certain version series of a package
Thanasis thanasis at asyr.hopto.org writes: 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). 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 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. The purpose of the long-term maintained kernels is in-fact and indeed, so that folks do not have to change kernels often. 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. It mu Sometimes folks have to stay with a kernel series, because a vendor binary patch forces them into this situation. 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. 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, without expending some extra effort yourself? You seem to be in a place (a want meerely?) that the good-conservative folks associated with kernel responsibility, do not provide for, because not many people have a valid reason for such? 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. (um tweaks are another way of saying bug/feature fix/stabilization). My situation, is not so complicated hopefully :P Do tell the specifics As some who has files of thousands of kernel build notes and goes back into kernel sources, as far back as 2.0 series, mostly for embedded reasons: Dude, I'm scratching my head, wondering whats up with your need... James
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
[gentoo-user] xorg-server crashing, back to log-in screen
After recent upgrade I've noticed my xorg-server is crashing, and sending me back to log-in screen on two of my computers. It happens mostly when when I click a tab in firefox or try to log-out. I'm using firefox-24.1.1 -- Joseph
Re: [gentoo-user] Re: xterms --featureRICH --suggestions?
On Tue, Jan 28, 2014 at 04:06:19PM +, James wrote Walter Dnes waltdnes at waltdnes.org writes: In your bash profile (if you use bash), howsabout export PS1='[\h][\u][\w]' Actually, I go for a fancy technicolour prompt export PS1='[\[\033[01;32m\]\h\[\033[00m\]][\[\033[01;34m\]\u\ [\033[00m\]][\[\033[01;36m\]\w\[\033[00m\]]' Either way, the host name shows up at the beginning of the prompt. I like to see the IP addresses of the systems I've sshd into. I work on a myriad of embedded and small systems, so IP addresses works best for me. In that case, try something like export PS1='[\[\033[01;32m\]192.168.0.1\033[00m\]][\[\033[01;34m\]\u\[\033[00m\]][\[\033[01;36m\]\w\[\033[00m\]]' If you have to determine it after logging in, you can export an environment variable to PS1, e.g. export PS1=[\$FOO]$ ***NOTE THE LEADING BACKSLASH*** See http://stackoverflow.com/questions/7359652/how-to-insert-an-environment-variable-inside-the-bash-prompt -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] xorg-server crashing, back to log-in screen
On Thu, Jan 30, 2014 at 11:20 AM, Joseph syscon...@gmail.com wrote: After recent upgrade I've noticed my xorg-server is crashing, and sending me back to log-in screen on two of my computers. Did you remember to rebuild all the xorg drivers after the xorg-server update? emerge @x11-module-rebuild
Re: [gentoo-user] xorg-server crashing, back to log-in screen
On 01/30/14 12:01, Adam Carter wrote: On Thu, Jan 30, 2014 at 11:20 AM, Joseph [1]syscon...@gmail.com wrote: After recent upgrade I've noticed my xorg-server is crashing, and sending me back to log-in screen on two of my computers. Did you remember to rebuild all the xorg drivers after the xorg-server update? emerge @x11-module-rebuild Yes, I did run: emerge -1av $(qlist -IC x11-drivers) -- Joseph
Re: [gentoo-user] Re: Portage performance dropped considerably
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2014 02:06 PM, Alan McKinnon wrote: On 27/01/2014 13:59, Tanstaafl wrote: On 2014-01-26 1:04 PM, hasufell hasuf...@gentoo.org wrote: So, not sure where your optimism comes from. But... some devs are interested in starting from scratch or picking up pkgcore (which would be the most sane thing to do IMO). ? If the problem is really this potentially serious, why start from scratch, when Paludis is already very mature? Is it pure politics (someone just doesn't like Ciaran)? No-one likes to admit it, but I think there's some NIH going on I just tried paludis again (after some time). Things that make it currently impossible to properly migrate my portage config: * you cannot unmask USE flags at all, not without hackery... and that is really non-trivial for unmasking abi_x86_32 globally, because those masks are scattered across a lot of files in profiles/ The explanation from the paludis developer is simply wrong: http://paludis.exherbo.org/trac/ticket/817 * seems there is no equivalent to --dynamic-deps=y (which is default in emerge)... either I am missing something or this is a pretty good reason to not use it -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS6cwfAAoJEFpvPKfnPDWz+MoIAJvH9zDbsVQaRwyb+yMEowJ8 qXjaLmDTx5BFyyL7tSelFEYyNwh0DN1ypyOQu2VkScNOTNIbqfffWXsAPoe4GJrP pngtb9xo4H4/IIdtr7i8fwRU937UK5V4Fq0Er/e56SGpdHG3G+emxrBeuB2Y6n0M m+gdEI1xmSuB/YOd/byDc+t9qK1688qM23fHJd/SsW732FY9ooUlfSZuO39ltjpk 96ojLyGe4TAp5zkk2BNBbpLXyuAtszwsc8U5nPN89v87gbC7gH5pIrJDXbQkRfMF EP0ouZ6nfB4cDqFM1/GVvJ2+V24jleWkpV3UQmCPDAd18T6Qa/fkujz0JuijXAg= =FfQN -END PGP SIGNATURE-
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.
