Re: [gentoo-dev] architectures which support Java
On Thursday 20 July 2006 21:17, Joshua Nichols wrote: Could I get notice of whether or not your architecture is supporting Java? On PPC64 we have support for java in theory. In IBM JDK version 1.4 the Java JIT compiler is broken, so pretty much everything is broken - except things that are just run and not compiled.. (you have to export JAVA_COMPILER=none) Version 1.5 on the other side does work pretty good. So add PPC64 to the list of supported arches once 1.5 is stable ;-) Regards, Markus pgpHDwGD6wTTh.pgp Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On 7/19/06, Kevin F. Quinn [EMAIL PROTECTED] wrote: In my opinion moving packages from one category to another just causes unnecessary disruption to the tree - all relevant dependencies throughout the tree have to be altered, putting current installations out-of-date with respect to it. Some other folk hold a different opinion. It's both perfectly natural and desirable for packages to migrate out of -misc type categories into more targetted categories over time. We've done it in the past, and it's something we need to be able to continue to do in the future. It helps folks look for things when they don't know the name of what they're looking for, and it stops -misc type categories from becoming dumping grounds. The key issue is that categories are semantically inadequate. Do you have any evidence to show that this is a widely-held opinion? Have you done any research amongst the wider user community to find out how they view categories? Deciding which category a package fits into is subjective, frequently a package fits into many categories yet the category system insists that a package belong to one and only one category. All classification systems are subjective, imperfect, and prone to change over time. Portage's is no worse than any other in this respect. (What is worse is the way Portage copes with change ... I agree with Mike here, we should be fixing our tools, rather than being artificially restricted by them). Usually these big package moves occur when people want to align herds with categories, which is a waste of time - also it's daft as packages can sensibly belong to more than one herd. Unfortunately we see a lot of it in the tree. You think it's daft, but that's just one perspective. What would you prefer? A tree where packages never ever move category? Christ, if we followed that dogma, then categories really would be useless, because we'd have far too many packages filed in the wrong place, or in general catchall -misc type categories. I think it's more important that the tree can be flexible, and can change structure over time. This week it's packages that have voip functionality that are being moved to net-voip. In six months time it'll be someone else wanting to move all packages with IM functionality into net-im. In herd-speak, these packages could easily belong to both the voip and im herds, should such exist; those providing c++ libraries could also belong to the cpp herd. This is useful, as the maintainers of those herds can each deal with issues in their field. It doesn't matter which category it's in. It seems a bit odd that a language herd like cpp (using your own example) would maintain a package just because the package itself is written in cpp, irrespective of what the package actually does. For example, the PHP herd is focused on packages that provide the PHP language and it's supporting infrastructure ... not on applications that are written in PHP. Those are left to other herds, who are more expert in the problems that those applications solve. The only concrete thing categories give us is the ability to have two packages with the same upstream name without having to mangle the upstream name. Not true. They provide us with an organisational ability too, whether its grouping packages to ensure people don't dump stuff in the tree (dev-perl being the classic example here), grouping packages by origin (gnome-*) or by common purpose (sys-fs). If a user needs something, but doesn't know which package they want, they can look inside the relevant category, and see what their choices are. In fact, categories do not give us the complete ability to have two packages with the same upstream name in the tree ... because binary packages do not support category names at all. Unfortunately the category system is deeply embedded in portage and the tree, so changing that system is simply not going to happen, which is why I've stopped whinging about the semantic inadequacy of the system. Instead of whinging about why the existing categories are bad, why not instead put forward an alternative (preferably with code, but a clear and consistently argued position would be a start) for something better? Otherwise, you *are* going to be ignored ... and with good reason. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Fri, Jul 21, 2006 at 08:44:35AM +0100, Stuart Herbert wrote: In fact, categories do not give us the complete ability to have two packages with the same upstream name in the tree ... because binary packages do not support category names at all. B. They do actually- the bintree *repository* format flattens the namespace, thus screwing the ability to use category as part of the key for lookup. That said, the binpkgs themselves still carry their original category. Fixing the namespace flattening is easy for bintrees- problem is it'll screw over remote binhost implementation, which relies on remote listdir (essentially) of the All directory to figure out what's available. Personally I'd be inclined to give existing remote bintree implementation the boot (ugly code, slow due to it's design), but others will bitch. Unfortunately the category system is deeply embedded in portage and the tree, so changing that system is simply not going to happen, which is why I've stopped whinging about the semantic inadequacy of the system. Instead of whinging about why the existing categories are bad, why not instead put forward an alternative (preferably with code, but a clear and consistently argued position would be a start) for something better? Otherwise, you *are* going to be ignored ... and with good reason. Just so we're clear, I probably will wedgie anyone who suggests trying to extend the existing tree format with N categories per pkg- sounds nice on paper, but it makes lookup a serious pita- sys-apps/portage, we'll pretend it's actually located in sys-apps, and it's also in category 'pkg-managers'. An atom states 'pkg-managers/portage'; how does a pkg manager do a lookup for it? Has to walk the entire tree... so if N category per pkg is going to be proposed, need to preserve the fast lookup that's there now. ~harring pgpTR3jYhLxtZ.pgp Description: PGP signature
Re: [gentoo-dev] architectures which support Java
Joshua Nichols wrote:
Doesn't support:
alpha
Alpha has compaq-{jdk,jre} which requires nast hacks with glibc and
doesn't work - details are in virtual/{jdk,jre} bugs.
--
Krzysiek Pawlik nelchael at gentoo.org key id: 0xBC51
desktop-misc, desktop-dock, desktop-wm, x86, java, apache...
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] architectures which support Java
On Fri, 21 Jul 2006 10:10:42 +0200
Krzysiek Pawlik [EMAIL PROTECTED] wrote:
Joshua Nichols wrote:
Doesn't support:
alpha
Alpha has compaq-{jdk,jre} which requires nast hacks with glibc and
doesn't work - details are in virtual/{jdk,jre} bugs.
compaq-{jdk,jre} were masked by YosWinK on July 7th. The latest version
was 1.3, upstream is dead, the packages are binary only, and they were
compiled against an older version of glibc. LD_PRELOAD Hacks Bug:
http://bugs.gentoo.org/84306
The alpha team is actively seeking a replacement. So far SableVM and
kaffe look the most promising. SableVM's sdk (not in the tree yet)
works for basic things, but doesn't compile ant-core because it is
missing tools.jar. kaffe doesn't pass all of the tests for 'make check'
but improvements are being made. kaffe also has a JIT for alpha, but it
is currently broken. We'll continue to work on the issue, but right now
Gentoo/alpha doesn't support Java.
-Thomas
pgpQxCRfFL8wj.pgp
Description: PGP signature
Re: [gentoo-dev] New category: net-voip
On Wed, 19 Jul 2006 11:10:51 -0400 Ned Ludd [EMAIL PROTECTED] wrote: | Every single year quarter after quarter the more updates | that happen the slower portage is becoming. | Care to solve that? This is a minute amount of time in comparison to anything significant. If you care about Portage speed, you'd be far better off reducing the number of packages that users have installed and reducing the number of packages in the tree. | My fix would be to remove the ability to do package moves | from portage all together. Which makes me rather glad that you're not fixing anything... | |i dont think this sort of thing should hold up tree | shuffles ... | | Well it should. | | package.keywords package.use package.mask etc.. | | Where is the stability and consistency when we end up | forcing people to update /etc/portage files... Erm... Portage updates these automatically. -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Fri, 21 Jul 2006 01:05:20 -0700 Brian Harring [EMAIL PROTECTED] wrote: | Just so we're clear, I probably will wedgie anyone who suggests | trying to extend the existing tree format with N categories per pkg- | sounds nice on paper, but it makes lookup a serious pita- | sys-apps/portage, we'll pretend it's actually located in sys-apps, | and it's also in category 'pkg-managers'. An atom states | 'pkg-managers/portage'; how does a pkg manager do a lookup for it? If you're looking to preserve linear / log-linear lookup times, you do it by having two types of object: 'real' packages and package aliases. I tried implementing it a while back for Paludis just to see if it'd be of any use. There're a few cases where it might be neat but there's no way it's worth trying to get Portage to do such a thing... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On 7/6/06, Patrick Lauer [EMAIL PROTECTED] wrote: So here's my nominations: Flameeyes brix lu_zero kosmikus Stuart jakub marienz patrick Thanks, but I don't accept. I'm planning on leaving Gentoo. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] architectures which support Java
Hi Mike, On 7/21/06, Mike Frysinger [EMAIL PROTECTED] wrote: in Gentoo or in general ? in general, kaffe should support pretty much all our arches, but in Gentoo, i dont have time to get it working for: Last time I checked, kaffe didn't provide a libjvm, which is used for embedding Java in other applications (such as PHP). Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Einput eclass
Brian, I was looking through /usr/bin/emerge and lines 3477-3481 seemed to best fit what displayConfirmPrompt is trying to supplement. The check on line 3477 is against a No returned from userPrompt(), and then a system exit code is issued by caller (line 3481). Was unable to find any other instance of the function being called issuing a system code in the emerge code, could you please point me in the direction you wanted me to go with this? On 7/20/06, Brian Harring [EMAIL PROTECTED] wrote: Examples of converted ebuilds would be wise prior to plopping it into the tree imo- fex, displayConfirmPrompt looks like it should be reliant on exit codes rather then mangling a global var to indicate the outcome; that would shift it more towards get confirmation rather then display. Thank you for the kudos Doug. On 7/20/06, Doug Goldstein [EMAIL PROTECTED] wrote: John, I think you've done a really great job with this. Very creative and good initiative. You're hired. Someone get him his developer badge.. Regards, John Open source, you don't pay back, you pay forward. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: making the firefox USE flag a global one
Simon Stelling wrote: Hi all, I just noticed that the USE flag 'firefox' is a local one. I think it should be global, though: If this happens, could you also close https://bugs.gentoo.org/show_bug.cgi?id=96473 :) --de. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] architectures which support Java
I wouldn't know the first thing to do with Java, but jrocket-jdk-bin has support for 1.4 and 1.5 on ia64. Aron -- gentoo-dev@gentoo.org mailing list
