[gentoo-dev] Re: crossdev and multilib interference
On Fri, Jun 20, 2014, Ian Stakenvicius wrote:
On 19/06/14 05:20 PM, Steven J. Long wrote:
Well I've spent far too long at crossdev code, only to see this and
realise you can simply hard-mask:
cross-i686-pc-linux-gnu/{binutils,gcc,glibc,pkg-config} in the
amd64 multilib profile, unless I'm missing something. You'd be
hard-pushed to install a clashing crossdev with such a mask,
afaict.
If you do want to change crossdev[1], afaict you're looking at
interaction between toolchain.eclass (and toolchain-binutils, and
likely -funcs), crossdev and gcc-config. I could well be wrong, as
ever. This is just my preliminary understanding, and maybe it'll
provoke a more thorough explanation. [ Snip! ]
Thank you for the explanation and research!
YW :-) shove autotools.eclass (and supporting) in there too, including
multiprocessing which had a simply painful attempt at cleverness.
I mentioned it in #gentoo-embedded when i saw it, so hopefully it'll
be corrected soon. (bashpid() function: if you can't see why it's
painfully embarrassing, /join #bash and ask.)
Tangental to this, mgorny wrote a little tool yesterday that might
work well as an alternative to crossdev for multilib systems. It
simply wraps all the native toolchain calls with proper -m and
provides the new CTARGETs.
If anybody wants to take a look, this is the link he posted on -dev :
dead url
Whether or not this suits everyone's needs for an i686 crossdev on
amd64 systems, i don't know. Thoughts?
It's more layer upon layer, I'm afraid. Though that file's gone from
the repo, so I imagine it's already made its way to join the rest of
the misguided hackery that is multilib. Still, it's good that his
bash has come on, though he's still too tricksy for his own good;
likely trying to emulate Frysinger, another one who needs a nice
lie-down sometimes, instead of banging out more. Idiot house-styles
will do that to you, as will C++.
I don't know why we can't just mask cross-*/whatever in the multilib
profile, instead of more talk of masking crossdev with a heavy
heart.
Nor do know if that's been done already, as I just found that the
profiles directory Changelog stopped in 2013, for some reason, and
I don't have time to chase the files right now.
Sorry for delay, been away and then busy. I was hoping to read
something more than mask crossdev yet again, when I got back.
Regards,
igli.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: package.mask vs ~arch
On Sun, Jun 29, 2014 at 11:01:53PM -0500, William Hubbs wrote: On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote: A package that hasn't been tested AT ALL doesn't belong in ~arch. Suppose the maintainer is unable to test some aspect of the package, or any aspect of the package? Do we want it to break completely for ~arch? In that event, nobody will run ~arch for that package, and then it still isn't getting tested. I'm not saying that we should just randomly throw something into ~arch without testing it, but ~arch users are running ~arch with the understanding that their systems will break from time to time and they are expected to be able to deal with it when/if it happens. ~arch is not a second stable branch. Nor is it a dumping ground for something you can't be bothered to overlay. I agree that masking for testing is like having a 3rd branch, but I'm not convinced that this is a bad thing. ~arch should be for packages that have received rudimentary testing and which are ready for testing by a larger population. Masking should be used for packages that haven't received rudimentary testing - they might not have been tested at all. The concern with this argument is the definition of rudimentary testing is subjective, especially when a package supports many possible configurations. Well it can never be fresh from upstream, even if that upstream is a Gentoo developer. eudev is more of a sanity filter, and doesn't claim to be upstream. If anything we want more constraints when a Gentoo dev is lead on a project, as there are even less dykes in the way. I think some packages need wide testing before they go stable, and that is where ~arch can help out. IOW some packages don't need wide testing, which by your yardstick, is what anyone with experience/common-sense would call a beta release. In particular, I would argue that for system-critical packages, users should be very careful about running ~arch unless they know what the fallout can be. Yes, and so should Gentoo, when faced with developers who think themselves exceptions to the rules everyone else should live by. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: About current ppc/ppc64 status
On 07/26/14 19:33, Michael Palimaka wrote: On 07/27/2014 03:19 AM, William Hubbs wrote: If an arch team isn't going to honor a stable request, shouldn't they remove themselves from it and say so? Also, if an arch team does that, does that mean we don't have to file stable requests for that arch on future versions of the package? When armin did stabilisation for minor archs in the past, he took the opportunity to evaluate whether it was still useful to have the package stable. In many cases for small random packages, stable keywords were dropped to reduce future workload. I always thought it was a pretty good strategy. Indeed! The thing was that a lot of the packages were keyworded and marked stable back in the day where the arch was more popular. But almost all arches except amd64/x86/arm are getting less and less popular: alpha: no new hardware in more than 8+ years hppa: being phased out IIRC, and no new workstations(ie, graphics/sound) in 5+ years ia64: no new workstations in 10 years, new servers are expensive ppc*: new workstations are expensive sparc: no new workstations in 7+ years, new servers expensive One of the reasons they are being killed, IMHO, its that the power consumption isn't worth, and an amd64 machine is pretty much more powerful, has more cores, and cheaper and has a lot less power consumption. My Sun Blade 1000 (workstation) uses 225W idling, my amd64 workstation uses 100W at full power or so. And the amd64 has way more cores and more performance. And let's not talk about the heat... Besides there's software like firefox and gnome3 that doesn't work in sparc due to unaligned accesses. Debian announced some months ago that they're dropping sparc support as well. Right now debian doesn't support, officially, alpha, hppa and sparc. Obviously ppc* has a lot of work because its the most keyworded arch behind amd64 and x86.
[gentoo-dev] Re: Avoiding rebuilds
On Mon, Jul 28, 2014 at 05:49:07AM +, Martin Vaeth wrote:
hasufell hasuf...@gentoo.org wrote:
Ulrich Mueller:
I wonder if it wouldn't be saner to leave our revision syntax
untouched.
As already mentioned, -r1.1 is only one of several possible ways
how to achieve the same aim; I am not speaking in favour for a
particular method.
Sure. As dolsen prefix is using it, even if this weren't better done
as metadata.
The -r1.1 method has the advantage of being simple and transparent
to the user and developer. Other approaches have other advantages:
Instead, one could introduce a variable INSTALL_VERSION that would
(It would have to be a variable stored in the metadata/ cache
and thus also would only work with a new API, but these are only
technical details.)
Agreed again, there's far too much conflabation of EAPI vs impl round here.
Not helped by the obfuscatory troll you've had the mispleasure to encounter.
Think of it as an initiation.. ;-)
default to ${PVR} but could be set to the version of a previous ebuild
instead. The PM could compare it against INSTALL_VERSION in the VDB
and skip build and installation if versions match.
It should be a list and have empty default (*never* including the
version itself), but these are also technical details.
This solution would have the advantage that you could specify
*full* versions and thus have even more fine-grained control when
recompilations are necessary. One could also allow specify version
ranges, slots, overlays, etc., perhaps even make the behaviour
dependent of USE-flags, as you already mentioned, all
similarl to current DEPEND syntax.
The disadvantage is that it is slightly more work than -r1.1,
less transparent, and easily overlooked to remove for a version bump,
causing issues like these:
It will probably also cause confusion for comaintainers and
collaborators, especially when INSTALL_VERSION points to a version that
has already been removed.
So use another name that can't be confused. Perhaps REPLACES_VERSION, or
w/e the primadonna will allow, since we're still feeding him goats..
Perhaps doubt he'll want to pluralise it, in that tedious nu-skool way
of his. More likely he'll just use anything we discuss as an excuse
for more FUD.
Regards,
steveL
PS: Now you know just why..
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: About current ppc/ppc64 status
On 08/01/2014 04:52, Raúl Porcel wrote: On 07/26/14 19:33, Michael Palimaka wrote: On 07/27/2014 03:19 AM, William Hubbs wrote: If an arch team isn't going to honor a stable request, shouldn't they remove themselves from it and say so? Also, if an arch team does that, does that mean we don't have to file stable requests for that arch on future versions of the package? When armin did stabilisation for minor archs in the past, he took the opportunity to evaluate whether it was still useful to have the package stable. In many cases for small random packages, stable keywords were dropped to reduce future workload. I always thought it was a pretty good strategy. Indeed! The thing was that a lot of the packages were keyworded and marked stable back in the day where the arch was more popular. But almost all arches except amd64/x86/arm are getting less and less popular: alpha: no new hardware in more than 8+ years hppa: being phased out IIRC, and no new workstations(ie, graphics/sound) in 5+ years ia64: no new workstations in 10 years, new servers are expensive ppc*: new workstations are expensive sparc: no new workstations in 7+ years, new servers expensive Who says they have to be new? Sometimes, the fun is in the old hardware of yore. I found out last week that sparc32 is still quasi-alive, though it doesn't appear to have any mainstream kernel maintainers. ia64, go search on eBay for old SGI Altix/Prism gear. There's a metric ton of Altix units being offloaded lately. There was one listing a few weeks ago that had 10-20 Altix 350 servers, dual or quad CPU, for ~$90 per server. Even saw an SGI Prism a few days ago (which is just an ia64 variant of the Tezro). One of the reasons they are being killed, IMHO, its that the power consumption isn't worth, and an amd64 machine is pretty much more powerful, has more cores, and cheaper and has a lot less power consumption. This is always a concern. I used to run equipment 24/7, but that took chunks out of my electric bill each month. Now, I sleep both of my Intel systems and power down the SGI machines when they're not in use. I eventually need to test out hibernation on the SGIs and see if that can be of any use. Ctrl+Z in the middle of a compile, then hibernate...in theory, I should be able to resume and then 'fg' the compile back into action. My Sun Blade 1000 (workstation) uses 225W idling, my amd64 workstation uses 100W at full power or so. And the amd64 has way more cores and more performance. And let's not talk about the heat... SGI O2, 1x CPU, 512MB RAM, 2x HDDs - ~80W SGI Octane, 1x CPU, 2GB RAM, 3x HDDs - ~303-330W SGI Onyx2, 4x CPUs, 8GB RAM, 5 HDDs - ~720W I ran some very quick calculations on running those three systems full time, 24/7 for a month, along with my two Intel Linux systems (~160W and ~140W), about ~$0.10/kWh (distribution charge only, did not factor in transmission rates nor taxes), and it should only add an extra ~$120 to my bill per month, which isn't that bad (but then again, I am serviced by a co-op that has low rates). So running them less often should be easily manageable. Probably moreso in winter, as rates are bit lower then (gas isn't, though, but SGIs make great space heaters). Besides there's software like firefox and gnome3 that doesn't work in sparc due to unaligned accesses. Pft, if people want those shinies, run them on a standard PC. If the only point of having an alternate arch is so you can surf the web...then I don't see much of a point. The direction that most of the large projects are going in is not conducive to old equipment anyways. There is, however, always going to be the smaller projects that might be tickled pink on having their software run on old hardware. Like maybe someone taking fvwm and tailoring it to look like IRIX's 4dwm. Something I've thought about if I ever get bored enough, and can fix all the other bugs I keep running into on these systems. Debian announced some months ago that they're dropping sparc support as well. Right now debian doesn't support, officially, alpha, hppa and sparc. Their loss :) -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
[gentoo-dev] Re: About current ppc/ppc64 status
Raúl Porcel posted on Fri, 01 Aug 2014 10:52:21 +0200 as excerpted: But almost all arches except amd64/x86/arm are getting less and less popular: alpha: no new hardware in more than 8+ years hppa: being phased out IIRC, and no new workstations (ie, graphics/sound) in 5+ years ia64: no new workstations in 10 years, new servers are expensive ppc*: new workstations are expensive sparc: no new workstations in 7+ years, new servers expensive One of the reasons they are being killed, IMHO, its that the power consumption isn't worth, and an amd64 machine is pretty much more powerful, has more cores, and cheaper and has a lot less power consumption. While to nowhere near the same degree, I'd suggest x86 (32-bit) is getting less popular now too, at least for gentoo with our focus on end- user software building. It'll certainly be awhile before it's in the minor-arch camp, but amd64 definitely has the mainline focus now and if x86 installs are keeping up with retirements I'd be very surprised. Amd64 is probably maintaining but I doubt it's increasing much. In terms of usage, tho for different reasons I guess arm is about where amd64 was when I switched to it in 2003, and to gentoo a few months later in early 2004 -- in gentoo they could be challenging x86 for #2 in a few years tho I'm not ready to predict they'll challenge amd64 any time soon. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Meeting of the ppc/ppc64 teams: Monday Aug 4, 2014 @20:00 UTC
Hi everyone, I'm email gentoo-dev@ because I'm trying to hit up as many devs as possible. Hopefully you've seen the recent discussions about what to do with ppc/ppc64 given the low manpower. Let's get interested people meeting in #gentoo-powerpc on Monday Aug 4, 2014 @20:00 UTC. If there are no objections, I'll chair the first meeting so here's the agenda so far: 1. Let's reconstitute the team and elect a lead. 2. How should we address the low manpower issue. At least two solutions have been proposed so far: a. Drop of many stable keywords to ~arch while retaining a core of stable packages b. Skip stabilization requests and let the KEYWORDS revert from stable to ~ by attrition. There may be other approaches. Both 2a and 2b have advantages/disadvantages and their technical problems. Anything else? -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] Re: crossdev and multilib interference
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/08/14 05:05 AM, Steven J. Long wrote:
On Fri, Jun 20, 2014, Ian Stakenvicius wrote:
On 19/06/14 05:20 PM, Steven J. Long wrote:
Well I've spent far too long at crossdev code, only to see this
and realise you can simply hard-mask:
cross-i686-pc-linux-gnu/{binutils,gcc,glibc,pkg-config} in the
amd64 multilib profile, unless I'm missing something. You'd be
hard-pushed to install a clashing crossdev with such a mask,
afaict.
If you do want to change crossdev[1], afaict you're looking at
interaction between toolchain.eclass (and toolchain-binutils,
and likely -funcs), crossdev and gcc-config. I could well be
wrong, as ever. This is just my preliminary understanding, and
maybe it'll provoke a more thorough explanation. [ Snip! ]
Thank you for the explanation and research!
YW :-) shove autotools.eclass (and supporting) in there too,
including multiprocessing which had a simply painful attempt at
cleverness. I mentioned it in #gentoo-embedded when i saw it, so
hopefully it'll be corrected soon. (bashpid() function: if you
can't see why it's painfully embarrassing, /join #bash and ask.)
Tangental to this, mgorny wrote a little tool yesterday that
might work well as an alternative to crossdev for multilib
systems. It simply wraps all the native toolchain calls with
proper -m and provides the new CTARGETs.
If anybody wants to take a look, this is the link he posted on
-dev :
dead url
Whether or not this suits everyone's needs for an i686 crossdev
on amd64 systems, i don't know. Thoughts?
It's more layer upon layer, I'm afraid. Though that file's gone
from the repo, so I imagine it's already made its way to join the
rest of the misguided hackery that is multilib. Still, it's good
that his bash has come on, though he's still too tricksy for his
own good; likely trying to emulate Frysinger, another one who needs
a nice lie-down sometimes, instead of banging out more. Idiot
house-styles will do that to you, as will C++.
I don't know why we can't just mask cross-*/whatever in the
multilib profile, instead of more talk of masking crossdev with a
heavy heart.
Nor do know if that's been done already, as I just found that the
profiles directory Changelog stopped in 2013, for some reason, and
I don't have time to chase the files right now.
Sorry for delay, been away and then busy. I was hoping to read
something more than mask crossdev yet again, when I got back.
Regards, igli.
It's a package in the tree now, actually --
sys-devel/multilib-gcc-wrapper ; it wraps the native toolchain
appropriately for the different ABI's that this toolchain supports, so
that ie an i686-*-gcc call is implemented properly via the native gcc
instead of a crossdev one. Note, it *also* works on multilib
crossdev, too! I have a ppc crossdev installed on my amd64 host box
and multilib-gcc-wrapper allows it to build for both ppc32 and ppc64
ABIs just fine (presumably; i don't have a ppc32 or ppc64 native
system to actually do runtime tests).
Back to the comment on masking -- would a cross-emerge (which i think
uses the target's profile, right?) end up p.masking its own toolchain?
If it did, would that actually break anything (i'm thinking no since
it's the crossdev that manages toolchain updates for the target rather
than cross-emerge)?? I agree that masks should be minimized, at most
masking the conflicting cross-* packages in a profile. However if
this causes issues within cross-emerge too, then perhaps adjusting the
crossdev tool to warn or error would suffice when a target that will
conflict with the native toolchain is requested.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iF4EAREIAAYFAlPbpeAACgkQ2ugaI38ACPCGRwD+JnA2ACNizXn9ZYG0kiaoitwO
wqHqahuceDxeo8z+Ps4A/158v8pElxPFZ4oWgHfVbZ43eiJm/N65Zay1x3U/vo3w
=m7AR
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: package.mask vs ~arch
On Fri, Aug 01, 2014 at 10:13:33AM +0100, Steven J. Long wrote: On Sun, Jun 29, 2014 at 11:01:53PM -0500, William Hubbs wrote: On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote: A package that hasn't been tested AT ALL doesn't belong in ~arch. Suppose the maintainer is unable to test some aspect of the package, or any aspect of the package? Do we want it to break completely for ~arch? In that event, nobody will run ~arch for that package, and then it still isn't getting tested. I'm not saying that we should just randomly throw something into ~arch without testing it, but ~arch users are running ~arch with the understanding that their systems will break from time to time and they are expected to be able to deal with it when/if it happens. ~arch is not a second stable branch. Nor is it a dumping ground for something you can't be bothered to overlay. I can see why teams like gnome, kde, etc choose to use overlays. They have many packages which need to be kept in sync for every release. For single packages though, an overlay is overkill. Also, overlays are purely optional; there is no Gentoo policy requiring their use. In fact, overlays are considered unsupported. If you don't know that something is going to break, it can go straight to ~arch. If you know that something will cause breakage, sure, it can go to package.mask. Or, if a bug that causes many systems to break is found in a package, the package should go to package.mask until the bug is fixed. I agree that masking for testing is like having a 3rd branch, but I'm not convinced that this is a bad thing. ~arch should be for packages that have received rudimentary testing and which are ready for testing by a larger population. Masking should be used for packages that haven't received rudimentary testing - they might not have been tested at all. The concern with this argument is the definition of rudimentary testing is subjective, especially when a package supports many possible configurations. Well it can never be fresh from upstream, even if that upstream is a Gentoo developer. What does this mean? We drop packages that are fresh from upstream into ~arch all the time. eudev is more of a sanity filter, and doesn't claim to be upstream. Eudev is a fork, so it is its own upstream. Also, it is used by some distros outside of Gentoo. If anything we want more constraints when a Gentoo dev is lead on a project, as there are even less dykes in the way. Adding more constraints to software that has Gentoo devs as the upstream authors would be a policy I couldn't support. That is a form of discrimination against our own devs. William signature.asc Description: Digital signature
[gentoo-dev] Re: Re: crossdev and multilib interference
On Fri, Aug 01, 2014 at 10:36AM, Ian Stakenvicius wrote: On 01/08/14 05:05 AM, Steven J. Long wrote: I don't know why we can't just mask cross-*/whatever in the multilib profile, instead of more talk of masking crossdev with a heavy heart. Nor do know if that's been done already, as I just found that the profiles directory Changelog stopped in 2013, for some reason, and I don't have time to chase the files right now. Sorry for delay, been away and then busy. I was hoping to read something more than mask crossdev yet again, when I got back. Back to the comment on masking -- would a cross-emerge (which i think uses the target's profile, right?) end up p.masking its own toolchain? No. The cross-* part is an overlay on CBUILD (ie the machine building the software; for a native build this is the same as CHOST in make.conf.) I agree that masks should be minimized, at most masking the conflicting cross-* packages in a profile. However if this causes issues within cross-emerge too, then perhaps adjusting the crossdev tool to warn or error would suffice when a target that will conflict with the native toolchain is requested. Well that should happen too: it's a trivial patch, which again has already been discussed in #-embedded. Either vapier gets on and does it now he's back, or someone else will, for an arch they care about. I can't see him caring if it's correct; and after all the mask on the overlay itself (which is on CBUILD, remember) is only possible due to the separation inherent in the crossdev design. Nowadays people like to call that belt'n'braces or something. When I learnt to code it was called common-sense. Discussing it wouldn't even arise: it goes without saying. Regards, igli. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
[gentoo-dev] Re: Avoiding rebuilds
Steven J. Long sl...@rathaus.eclipse.co.uk wrote: It will probably also cause confusion for comaintainers and collaborators, especially when INSTALL_VERSION points to a version that has already been removed. So use another name that can't be confused. Perhaps there is a misunderstanding: I did not understand that the confusion is caused by the name, but by the lack of information about its entries: For instance, if you bump a version, you must never forget to check whether this variable needs to be updated. Moreover, if you want to update that variable, you should understand precisely why which version is listed here in order to decide whether a recompile from that version might be needed with the current bump or not. This decision is not necessarily easy if the corresponding referred ebuilds are already in the CVS attic. Of course, if in doubt, it is a safe strategy to always remove that variable (it can only cause redundant compilation, while it can be fatal if you leave a version falsely). Therefore, an automatism to forget this variable automatically if not changed would be preferrable, but one would need a mechanism for this (I have only some strange ideas for such a mechanisms: One could encode the current ebuild version into the name of that variable; or one could require that the current version is the first entry in this variable [although, semanatically, it is ignored and just serves as a proof that the ebuild maintainer checked that variable]).
[gentoo-dev] PMS (was: don't rely on dynamic deps)
Ulrich Mueller u...@gentoo.org wrote: On Sat, 26 Jul 2014, Martin Vaeth wrote: Quite the opposite, PMS claims that one cannot rely on anything stored in /var/db Where does it say so? Appendix B: Unspecified Items The following items are not specified by this document, and must not be relied upon by ebuilds. [...] The VDB (/var/db/pkg) [...] This is bugging me for quite a while already, because I had to try and to rely on undocumented behaviour for all features of eix which access /var/db/pkg. It also is one of the reasons why it might be dangerous if you use another PM even only for testing purposes: In theory, it might even be possible that a package installed by one PM is not recognized by the other. I guess that this is not a big problem in practice, but in fine points like the discussed prerm perhaps some problems might arise through mixing.
Re: [gentoo-dev] Meeting of the ppc/ppc64 teams: Monday Aug 4, 2014 @20:00 UTC
On Fri, Aug 01, 2014 at 09:37:10AM -0400, Anthony G. Basile wrote:
Hi everyone,
I'm email gentoo-dev@ because I'm trying to hit up as many devs as
possible. Hopefully you've seen the recent discussions about what to do
with ppc/ppc64 given the low manpower. Let's get interested people
meeting in #gentoo-powerpc on Monday Aug 4, 2014 @20:00 UTC. If there
are no objections, I'll chair the first meeting so here's the agenda so far:
1. Let's reconstitute the team and elect a lead.
2. How should we address the low manpower issue. At least two solutions
have been proposed so far:
a. Drop of many stable keywords to ~arch while retaining a core of
stable packages
b. Skip stabilization requests and let the KEYWORDS revert from
stable to ~ by attrition.
There may be other approaches. Both 2a and 2b have
advantages/disadvantages and their technical problems.
Anything else?
3. Supported hardare
We might want to reduce the number of systems/profiles we support. For
example, we could drop ppc32/32bit userland and just support
ppc64/{32|64}bit userland.
Here is list from the ppc handbook:
a) Apple NewWorld Machines: Power/PowerPC microprocessors (G3, G4, G5)
such as iMac, eMac, iBook PowerBook, Xserver, PowerMac
b) Apple OldWorld machines: Apple Machines with an Open Firmware
revision less than 3, such as the Beige G3s, PCI PowerMacs and PCI
PowerBooks. PCI-based Apple Clones should also be supported.
c) Genesi: Pegasos I/II, Open Desktop Workstation, Efika
d) IBM: RS/6000, iSeries, pSeries
4. Misc: List what needs to be done?
a) documentation: wiki, handbook, etc
b) ??
Thanks,
--
Jack Morgan
Pub 4096R/761D8E0A 2010-09-13 Jack Morgan jmor...@gentoo.org
Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A
signature.asc
Description: Digital signature
Re: [gentoo-dev] PMS
On Fri, 1 Aug 2014, Martin Vaeth wrote: Ulrich Mueller u...@gentoo.org wrote: On Sat, 26 Jul 2014, Martin Vaeth wrote: Quite the opposite, PMS claims that one cannot rely on anything stored in /var/db Where does it say so? Appendix B: Unspecified Items The following items are not specified by this document, and must not be relied upon by ebuilds. [...] The VDB (/var/db/pkg) [...] This says that ebuilds must not access the VDB. It says nothing about the package manager doing so. Ulrich pgpcHCAFZ36ue.pgp Description: PGP signature
[gentoo-portage-dev] [PATCH] Offer to read news while calcing deps (bug 517310)
Signed-off-by: Alexander Berntsen berna...@gentoo.org --- I don't have time for any more playing with this. Please test it, and ACK it if it is OK. I will merge it when I get back if it's OK. :-] pym/_emerge/actions.py | 10 -- pym/_emerge/post_emerge.py | 5 - 2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/pym/_emerge/actions.py b/pym/_emerge/actions.py index b935139..45f9167 100644 --- a/pym/_emerge/actions.py +++ b/pym/_emerge/actions.py @@ -4058,8 +4058,14 @@ def run_action(emerge_config): # GLEP 42 says to display news *after* an emerge --pretend if --pretend not in emerge_config.opts: - display_news_notification( - emerge_config.target_config, emerge_config.opts) + uq = UserQuery(emerge_config.opts) + if display_news_notification(emerge_config.target_config, + emerge_config.opts) \ + and --ask in emerge_config.opts \ + and uq.query(Would you like to read the news items while \ + calculating dependencies?, + '--ask-enter-invalid' in emerge_config.opts) == Yes: + subprocess.call(['eselect', 'news', 'read']) retval = action_build(emerge_config.target_config.settings, emerge_config.trees, emerge_config.target_config.mtimedb, emerge_config.opts, emerge_config.action, diff --git a/pym/_emerge/post_emerge.py b/pym/_emerge/post_emerge.py index d5f1ba5..0cb533c 100644 --- a/pym/_emerge/post_emerge.py +++ b/pym/_emerge/post_emerge.py @@ -37,11 +37,14 @@ def clean_logs(settings): def display_news_notification(root_config, myopts): if news not in root_config.settings.features: - return + return False portdb = root_config.trees[porttree].dbapi vardb = root_config.trees[vartree].dbapi news_counts = count_unread_news(portdb, vardb) + if all(v == 0 for v in news_counts.values()): + return False display_news_notifications(news_counts) + return True def show_depclean_suggestion(): out = portage.output.EOutput() -- 1.8.5.5
[gentoo-portage-dev] New release: 2.2.11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Friends, Portage 2.2.11 is now out. Brian is uploading the tarball and bumping the ebuild right now. Release notes: - Remove some broken old style virtual code - Bug # 505428 RO only filesystem check - Bug # 506186 TaskSequence starting bug. - Sort repoman check output - Remove obsolete repoman eclass checks - Bug # 505944 Improve mismatch checking - Bug # 488820 fix @security crash - Bug # 438976 Add DESCRIPTION.punctuation check to repoman - Add ruby18 warning for deprecated ruby target to repoman - Add Python version to Portage version line - Prevent rebuild code from performing unwanted repository changes - Include ::repository more consistently in output - Make the slot conflict handler output more debug information - Bug # 487074 Don't split suggested commands when printing them - Handle 'mkdir -p /etc/portage/make.profile/packages' gracefully -- i.e. produce an error instead of crashing with a traceback - Implement --alert - Bug # 516428 Make repoman warn if non-virtuals depend on perl-core - Prefer install-xattr to install.py as a wrapper to coreutils' /usr/bin/install to preserve file system extended attribute. I am going on a vacation. Due to all the bikeshedding over dynamic dependencies: I'm not taking my laptop! Happy hacking meanwhile, and I'll see you in a week. - -- Alexander berna...@gentoo.org https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlPb86wACgkQRtClrXBQc7WyxgD6AtEFL1nb8Y72JuQJWGfOc1/1 nsVfWY/ms1GfObK+eSUA/jYn+tUullVEglFhFZmRUt9d0fhGBxApsPBTUrcSuzfE =JaHZ -END PGP SIGNATURE-
