Re: [gentoo-dev] Baselayout 2 stabilisation todo
Mike Auty wrote: Roy Marples wrote: Attached is the new conf.d/net sample. Sorry, I missed those. Did lists.g.o remove them, or were they not attached? As such, a side project I've started is a new ifconfig tool [1] to handle everything from vlans, to bridging, to bonding, to wireless (up to WEP) with a similar syntax to the BSD ifconfig. Also [1]'s missing, and I couldn't find it at http://roy.marples.name/. Where should I be looking? This decision is heavily influenced by NetBSD (disclaimer - I'm now a NetBSD dev). Congrats on becoming a NetBSD dev! 5:) Gah, posting just before bed! Anyway, attached and [1] was just a blog entry by me, not much more content than here. There's no project page as yet for ifconfig as it's display only right now. Thanks Roy [1] http://roy.marples.name/projects/self/blog/2009/04/19_ifconfig
Re: [gentoo-dev] rfc: Accessibility on our release media
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009.05.24 02:44, William Hubbs wrote: [snip] Random reply to thread William Hubbs gentoo accessibility team lead willi...@gentoo.org Put all the downloads for a minimal gentoo install into dial up context. You need the minimal CD, the stage 3, the portage snapshot, a bootloader and a kernel. An extra 20Mb in that total size is trivial. Having done a few remote installs for blind users dropping into #gentoo, I understand the frustration that lack of accessibility causes. Please add accessibility to Gentoo install media and help our users to help themselves. - -- Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoZIjgACgkQTE4/y7nJvat3RACfQXcsh5oFKrbijkJr6aajfY99 2ToAoKZEUo8Utfq3kYgEK8YFQL9ZzQZ2 =AzOd -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: Accessibility on our release media
Roy Bamford wrote: On 2009.05.24 02:44, William Hubbs wrote: [snip] Random reply to thread William Hubbs gentoo accessibility team lead willi...@gentoo.org Put all the downloads for a minimal gentoo install into dial up context. You need the minimal CD, the stage 3, the portage snapshot, a bootloader and a kernel. An extra 20Mb in that total size is trivial. Having done a few remote installs for blind users dropping into #gentoo, I understand the frustration that lack of accessibility causes. Please add accessibility to Gentoo install media and help our users to help themselves. I haven't heard anyone say they are against having this yet. The size is being discussed but it is not blocking it from being added to the CD. I'm on dial-up and the time is not trivial to me but I still think it is worth having the software on the CD for people that can't see the screen. I'm evening thinking a person could install Gentoo with no monitor. Like maybe a server or something. Dale :-) :-)
[gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
Hi there, app-admin/equo (sabayon overlay -- Entropy Framework client) supports the postfix @repository to let users force the installation of a package from a specific repository. Users of multiple repositories seem to appreciate the freedom that is brought with this small-but-effective(TM) feature. So what about doing the same in Portage? Rationale: User should be able to force the installation of atoms from specific overlays without worrying too much if others or the main tree feature a greater release. Feature-testing overlay maintainers can make sure that packages are pulled in from their sources, which could potentially contain reworked/improved/critically-changed ebuilds. Adding @overlay atoms/deps postfix support could really make life easier, especially because forcing specific atoms in *DEPEND hoping that these will be always pulled in from the same overlay is not something reliable, as you already know. Examples: app-foo/f...@overlay app-foo/foo:2...@overlay foo:2...@overlay f...@overlay Comments are welcome, flames are not. -- Fabio Erculiani signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On Sun, 24 May 2009 19:04:08 +0200 (CEST) lx...@sabayonlinux.org wrote: app-admin/equo (sabayon overlay -- Entropy Framework client) supports the postfix @repository to let users force the installation of a package from a specific repository. @ is used by Portage for sets. Paludis has been using ::repo for repo dependencies for years. Why not go with the established syntax? Users of multiple repositories seem to appreciate the freedom that is brought with this small-but-effective(TM) feature. Note that Portage doesn't support multiple repositories, so this one's probably not very straight-forward... It supports overlays, which means only one thing is ultimately visible for a c/p-v. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On Sun, May 24, 2009 at 10:34 PM, lx...@sabayonlinux.org wrote: Adding @overlay atoms/deps postfix support could really make life easier, especially because forcing specific atoms in *DEPEND hoping that these will be always pulled in from the same overlay is not something reliable, as you already know. Examples: app-foo/f...@overlay app-foo/foo:2...@overlay foo:2...@overlay f...@overlay Comments are welcome, flames are not. Won't this just lead to dependency hell? With horrible dependencies between different overlays? The current system of overlays being restrictive is (IMO) beneficial in the long-term because it forces people to move stuff to the main tree instead of going the lazy way and putting inter-overlay dependencies. If the concept of overlay is taken as feature overlays, then dependencies should not go beyond the main tree + the overlay itself. -- ~Nirbheek Chauhan
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On Sun, 24 May 2009 22:50:45 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Won't this just lead to dependency hell? With horrible dependencies between different overlays? It's primarily a user feature. It's not a good way of solving most inter-repository dependency issues. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On Sun, May 24, 2009 at 10:58 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 24 May 2009 22:50:45 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Won't this just lead to dependency hell? With horrible dependencies between different overlays? It's primarily a user feature. It's not a good way of solving most inter-repository dependency issues. If that's the case (usage being command-line use), then I'm all for it. But not in *DEPEND. -- ~Nirbheek Chauhan
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
Nirbheek Chauhan wrote: On Sun, May 24, 2009 at 10:58 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 24 May 2009 22:50:45 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Won't this just lead to dependency hell? With horrible dependencies between different overlays? It's primarily a user feature. It's not a good way of solving most inter-repository dependency issues. If that's the case (usage being command-line use), then I'm all for it. But not in *DEPEND. I'm also very much for it, especially for use in /etc/portage, to be able to mask/unmask a version from a specific overlay. -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
On Sun, May 24, 2009 at 7:03 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 24 May 2009 19:04:08 +0200 (CEST) lx...@sabayonlinux.org wrote: app-admin/equo (sabayon overlay -- Entropy Framework client) supports the postfix @repository to let users force the installation of a package from a specific repository. @ is used by Portage for sets. Paludis has been using ::repo for repo dependencies for years. Why not go with the established syntax? I wrote postfix not prefix. Sets use @ prefix. Regarding your why, why not going through GLEP and gentoo-dev acceptance ;) ? Users of multiple repositories seem to appreciate the freedom that is brought with this small-but-effective(TM) feature. Note that Portage doesn't support multiple repositories, so this one's probably not very straight-forward... It supports overlays, which means only one thing is ultimately visible for a c/p-v. I know. -- Ciaran McCreesh I am wondering if enabling @overlay postfix support could be just restricted to command line arguments, at least for the beginning. -- Fabio Erculiani signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC:sys-apps/portage @overlay atoms postfix support
Am Sonntag, den 24.05.2009, 20:04 +0200 schrieb lx...@sabayonlinux.org: On Sun, May 24, 2009 at 7:03 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 24 May 2009 19:04:08 +0200 (CEST) lx...@sabayonlinux.org wrote: app-admin/equo (sabayon overlay -- Entropy Framework client) supports the postfix @repository to let users force the installation of a package from a specific repository. @ is used by Portage for sets. Paludis has been using ::repo for repo dependencies for years. Why not go with the established syntax? I wrote postfix not prefix. Sets use @ prefix. Regarding your why, why not going through GLEP and gentoo-dev acceptance ;) ? Users of multiple repositories seem to appreciate the freedom that is brought with this small-but-effective(TM) feature. Note that Portage doesn't support multiple repositories, so this one's probably not very straight-forward... It supports overlays, which means only one thing is ultimately visible for a c/p-v. I know. -- Ciaran McCreesh I am wondering if enabling @overlay postfix support could be just restricted to command line arguments, at least for the beginning. And then it's a pm thing. So the person you want to talk about it is zmedico. -- Tiziano Müller Gentoo Linux Developer, Council Member Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[gentoo-dev] Re: Re: Re: The fallacies of GLEP55
David Leverton wrote: On Friday 15 May 2009 21:06:13 Steven J Long wrote: In practical terms, this is a useless proposal. It rightly got trashed last year. No, it did not get trashed, despite some people's attempts to make their side sound more popular than it really is. Yes there's a lot of that about. Some people like the idea, some don't, and people have put forward various arguments in both directions. Well that adds a lot. Suffice to say that some people not only dislike the idea but actually think it's a massively retrograde step, going as it does against basic Software Engineering principles some of us have seen the reason for at the coalface. (You know, where there are real consequences to getting things wrong, that will affect your real-life, your home and your family.) If it were really as widely hated as you claim (presumably with the implication that the people who still support it are horrible and evil for even thinking about it) Hmm way to go putting thoughts in my head that aren't there. I realise you're very good at couching your assertions in language that can later be denied, but that only really works in this situation. Try it in the workplace and see how far you get. then it wouldn't still be under discussion. Or alternatively, some people just can't take 'no' for an answer, and conceding even one flaw is too much for someone's ego, especially in the conduct of what appears to be a concerted campaign to get Gentoo to admit they were wrong to take whatever action they took so many years ago. (Only not in so many words. Apparently, ceding control of the direction of all future innovation will suffice to heal the wound.) -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
[gentoo-dev] Re: Re: Re: The fallacies of GLEP55
Ciaran McCreesh wrote: On Fri, 15 May 2009 21:06:13 +0100 Steven J Long wrote: Before an ebuild has had its metadata generated, its EAPI is unknown. At this point, the package manager assumes EAPI 0. With the format restriction, that everyone last year seemed happy with, apart from the few pushing GLEP-55, this isn't an issue. The format restriction hasn't been agreed upon, By you. (oh, and your gang.) You're right though, it hasn't been spammed to the list on more occasions than anyone cares to remember, nor has it been pushed up to the Council to vote on, when someone can't convince the rest of the developer community. It just works. and doesn't solve the whole problem anyway. Only we're not allowed to hear what problem you _think_ exists. You just resort to the Emperor's New Clothes defence. (I can't explain it, as the fact you don't agree with me, clearly means you're far too stupid to explain it to.) Sorry but those clothes look like rags to me. Shiny you say? Explain it then, as they /still/ look like rags. Or stop wasting everybody's time. Pick one. If you have a use-case that actually requires more in a version specifier for upstream software, please present it and explain how it cannot be represented with the above. Go and look at all the ebuilds using MY_PV style hacks. Group these into necessary because upstream are being silly and we're only doing this because of some utterly arbitrary rules imposed in the early days of Gentoo. Most are in the second camp. Please elucidate the use-case, and how the versions cannot be represented within Gentoo, or within the expanded def'n[2] as you were asked to do. If you're concerned about stupid BASH, perhaps you could direct your energy towards better BASH scripting, and not relying on an eclass to do what #bash beginners learn in their first two weeks. Learning the craft is part of the process. I realise openly sharing knowledge makes it harder for you to hoard it. Deal with it, or don't work in Free software. As for utterly arbitrary some of the syntax you've proposed is exactly that. Even worse, it's completely cack-handed. That'd be fine if you didn't also insist that everything you dream up is perfectly worked-out and thought-through from the beginning[1]. The combination is quite dangerous, and were this a professional situation you'd have been out on your ear a long time ago. Not storming back after being 'fired' and emailing the whole company with your rants for the next 3 years. In passing, I must express bewildered amusement at the idea of a format with an unlimited amount of extensions. Not what's being proposed. We're proposing giving each format its own file extension. No, you're trying to hijack .ebuild. Even cat-foo/blah-version--EAPI.ebuild would be better than this nonsense. It'd *still* be a bad idea for all the reasons lavajoe (iirc) outlined way back when. I suggest you re-read his post from a long time ago. If you want to do a radically new format, go ahead; no-one's stopping you or holding your work back in any way. The same cannot be said for your continued antics. Oh yeah, .exheres hasn't quite got the same cachet as .ebuild. No satisfaction in it, unlike getting Gentoo to 'submit'. I still haven't seen a version that cannot be handled within the Gentoo schema (and I note you were remarkably silent on suggestions that were put to you[2], as you always are if they didn't come from paludis.) If you're arguing no human input should be required, I think you have a misunderstanding of the user-base. Some of us prefer to know that a human has both tried the ebuild out, and gone through repoman. And that that person takes pride in their name on the commit, and stands by the principle of you broke it, you fix it. It's called a distribution, not ciara's collection of stuff scraped from a webservice. [1] 'If it is unwise to trust other people's claims for one true way, it's even more foolish to believe them about your own designs.' http://www.catb.org/~esr/writings/taoup/html/ch01s06.html#id2879078 [You seem not to have read this site _at all_. Correct that before posting again.] [2] Let's just use a prefix instead of a suffix to indicate vcs, keep branch and upstream for dep specification, not filename, to allow inter-repo dependency for overlays for the few cases where it's actually needed, and add debian-style epochs to guarantee future expansion. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: Re: Re: The fallacies of GLEP55
On Sunday 24 May 2009 21:40:57 Steven J Long wrote: Hmm way to go putting thoughts in my head that aren't there. Yes, that sums you up quite nicely.
[gentoo-dev] Speech on the Gentoo Linux LiveCD
Hello, I would strongly recommend adding Speakup access into the Gentoo installation media, probably with software speech, as hardware speech is becoming quite outdated. Feel free to email me if you folks want offf-list to discuss some of this. Regards, --Keith
Re: [gentoo-dev] Re: [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
On Sunday 24 May 2009 22:43:52 Ciaran McCreesh wrote: Here, this sums up what's wrong with most of your cockamamy ideas (as attractive, and oh so right, as they may seem to you now): http://www.catb.org/~esr/writings/taoup/html/ch01s07.html To paraphrase you: Go and read it and don't come back til you've actually understood the concepts. Sorry, you don't get to post that kind of response until you start being right. In light of you being wrong (see above), please apologise and retract your remarks. Ciaran, this mailinglist is not your personal playground. As you obviously can't even be bothered to reflect on other peoples statements without reflex-posting something unrelated I must ask you to stop spamming us. It's just not funny anymore. Okay, yes, Mr. Long was quite rude there (trying to fight fire with fire I guess). But in this case you're discussing rather subjective things again (how often is it the case that you don't have a cache?) that might not even be a problem. And, as you consistently don't read any arguments that might interfere with how you want reality to be, sometimes people use harsher language in the hope of making you read (and maybe even understand) their argument. Now please stop playing the drama queen, stop spamming (yes, replying to every mail is spamming) and maybe we can return to a technical discussion, as this mailinglist was originally intended (or so I hope). Thanks in advance, your friendly neighborhood kitten.
[gentoo-dev] Re: [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
2009-05-17 18:20:21 Arfrever Frehtes Taifersar Arahesis napisał(a): I would like to suggest to include possibility of using of features of bash-4.0 (and older versions) in local scope of EAPI=3 ebuilds. I know that it's slightly late, but this change is very easy to implement (adjusting RDEPEND of new versions of package managers and updating PMS). Zac Medico doesn't have objections to this proposition, so I hope that Council will approve it. From #gentoo-portage: [22:40:11] Arfrever zmedico: What is your opinion about allowing bash-4.0 features in EAPI=3? ... [22:55:03] zmedico Arfrever: that's fine with me ... [22:56:15] Arfrever zmedico: Could you respond to the thread on gentoo-dev mailing list about it? ... [22:56:59] tanderson I'd not mind seeing bash 4 in eapi 3; and I don't buy ciaran's argument that it'll open the door for all the other latecomers [22:57:20] igli takes out life-insurance on tanderson ;p [22:57:22] zmedico Arfrever: can you just respond for me and say zac says it's okay with him? :) [22:58:52] zmedico is migrating his thunderbird pop setup to use all imap and filters in gmial [22:58:55] zmedico *gmail [22:59:08] tanderson igli: disagreeing technically isn't something that can get you killed! You're notplaying the odds well my friend [22:59:23] Arfrever zmedico: OK. [22:59:34] zmedico Arfrever: thanks a lot :) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
On Sun, 24 May 2009 23:16:13 +0200 Patrick Lauer patr...@gentoo.org wrote: Okay, yes, Mr. Long was quite rude there (trying to fight fire with fire I guess). But in this case you're discussing rather subjective things again (how often is it the case that you don't have a cache?) that might not even be a problem. This is not in the least bit subjective. You don't have cache: * for any overlays you use * often enough for the main tree that we get people asking about it in #paludis, since Paludis warns if it encounters stale cache files. We know full well that this is a real problem. Stop pretending that it isn't. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Allow bash-4.0 features in EAPI=3 ebuilds
On Sunday 24 May 2009 23:22:21 Ciaran McCreesh wrote: On Sun, 24 May 2009 23:16:13 +0200 Patrick Lauer patr...@gentoo.org wrote: Okay, yes, Mr. Long was quite rude there (trying to fight fire with fire I guess). But in this case you're discussing rather subjective things again (how often is it the case that you don't have a cache?) that might not even be a problem. This is not in the least bit subjective. You don't have cache: * for any overlays you use Only partially correct (but you knew that already, so I won't bother repeating it) And with overlays you have _no_ guarantees anyway. Plus portage spews a nice warning if you play around with eclasses, which many users parse as an error. So that's not an issue anyway ... overlays are unsupported territory where the only assumption you can make is that things might not work (but surprisingly often they do) * often enough for the main tree that we get people asking about it in #paludis, since Paludis warns if it encounters stale cache files. Haven't seen that with portage (well duh), and if it really is a problem maybe we should ask grobian how he made the prefix rsync checkout consistent. Y'know, if it is a problem fix the problem. We know full well that this is a real problem. Stop pretending that it isn't. Well, we don't. Hmm, who is we in this context? Would be much nicer if we stopped using the pluralis majestatis to make us look more important. Anyways, if it is a problem it's mostly an issue of the cache generation, which is trivially fixed, or it's not a problem, in which case it is fixed already. Or it is an issue for everyone doing unsupported things, in which case ... it is not an issue. Because it's unsupported. So what was our point again? Anyways, this is going round and round in circles until someone gets dizzy and throws up. Not the best way to discuss, and I'm getting really bored with it.
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2009-05-24 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2009-05-24 23h59 UTC. Removals: sys-fs/lvm-user 2009-05-19 03:06:39 cardoe profiles/default-linux/ppc 2009-05-20 17:22:03 ranger media-plugins/eq-audacious 2009-05-22 01:02:23 ssuominen media-sound/lastfm-ripper 2009-05-22 01:05:52 ssuominen media-sound/rat 2009-05-22 01:05:53 ssuominen media-sound/wavesurfer 2009-05-22 01:05:53 ssuominen net-news/charm 2009-05-24 04:04:41 neurogeek lxde-base/lxsession-lite2009-05-24 21:31:50 yngwin Additions: dev-java/glassfish-jms-api 2009-05-18 19:36:13 betelgeuse java-virtuals/jms 2009-05-18 19:38:05 betelgeuse dev-util/kelbt 2009-05-19 19:45:20 flameeyes sci-electronics/geda-docs 2009-05-20 01:57:06 calchan sci-electronics/geda-examples 2009-05-20 02:01:58 calchan sci-electronics/geda-symbols2009-05-20 02:06:54 calchan sci-electronics/geda-gattrib2009-05-20 02:08:39 calchan sci-electronics/geda-gnetlist 2009-05-20 02:12:35 calchan sci-electronics/geda-gschem 2009-05-20 02:15:06 calchan sci-electronics/geda-gsymcheck 2009-05-20 02:18:27 calchan sci-electronics/geda-utils 2009-05-20 02:20:34 calchan x11-misc/touchfreeze2009-05-21 12:40:04 hwoarang x11-themes/murrine-themes 2009-05-21 20:09:00 nirbheek dev-java/pdf-renderer 2009-05-22 22:19:27 betelgeuse net-misc/jrdesktop 2009-05-22 22:33:17 ali_bush kde-base/krossjava 2009-05-23 07:07:47 ali_bush dev-java/constantine2009-05-23 07:38:01 caster dev-java/jcodings 2009-05-23 07:39:00 caster dev-java/jna2009-05-23 07:41:07 caster dev-java/jna-posix 2009-05-23 07:41:59 caster dev-java/joni 2009-05-23 07:43:13 caster dev-java/jffi 2009-05-23 07:44:07 caster dev-ruby/jruby-openssl 2009-05-23 07:44:48 caster dev-java/glassfish-connector-api2009-05-23 08:23:10 betelgeuse dev-java/absolutelayout 2009-05-24 03:06:48 ali_bush net-misc/charm 2009-05-24 03:57:37 neurogeek lxde-base/lxsession 2009-05-24 20:27:16 yngwin lxde-base/menu-cache2009-05-24 22:13:54 yngwin lxde-base/lxmenu-data 2009-05-24 22:27:57 yngwin -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: sys-fs/lvm-user,removed,cardoe,2009-05-19 03:06:39 profiles/default-linux/ppc,removed,ranger,2009-05-20 17:22:03 media-plugins/eq-audacious,removed,ssuominen,2009-05-22 01:02:23 media-sound/lastfm-ripper,removed,ssuominen,2009-05-22 01:05:52 media-sound/rat,removed,ssuominen,2009-05-22 01:05:53 media-sound/wavesurfer,removed,ssuominen,2009-05-22 01:05:53 net-news/charm,removed,neurogeek,2009-05-24 04:04:41 lxde-base/lxsession-lite,removed,yngwin,2009-05-24 21:31:50 Added Packages: dev-java/glassfish-jms-api,added,betelgeuse,2009-05-18 19:36:13 java-virtuals/jms,added,betelgeuse,2009-05-18 19:38:05 dev-util/kelbt,added,flameeyes,2009-05-19 19:45:20 sci-electronics/geda-docs,added,calchan,2009-05-20 01:57:06 sci-electronics/geda-examples,added,calchan,2009-05-20 02:01:58 sci-electronics/geda-symbols,added,calchan,2009-05-20 02:06:54 sci-electronics/geda-gattrib,added,calchan,2009-05-20 02:08:39 sci-electronics/geda-gnetlist,added,calchan,2009-05-20 02:12:35 sci-electronics/geda-gschem,added,calchan,2009-05-20 02:15:06 sci-electronics/geda-gsymcheck,added,calchan,2009-05-20 02:18:27 sci-electronics/geda-utils,added,calchan,2009-05-20 02:20:34 x11-misc/touchfreeze,added,hwoarang,2009-05-21 12:40:04 x11-themes/murrine-themes,added,nirbheek,2009-05-21 20:09:00 dev-java/pdf-renderer,added,betelgeuse,2009-05-22 22:19:27 net-misc/jrdesktop,added,ali_bush,2009-05-22 22:33:17 kde-base/krossjava,added,ali_bush,2009-05-23 07:07:47 dev-java/constantine,added,caster,2009-05-23 07:38:01 dev-java/jcodings,added,caster,2009-05-23 07:39:00 dev-java/jna,added,caster,2009-05-23 07:41:07 dev-java/jna-posix,added,caster,2009-05-23 07:41:59 dev-java/joni,added,caster,2009-05-23 07:43:13 dev-java/jffi,added,caster,2009-05-23 07:44:07 dev-ruby/jruby-openssl,added,caster,2009-05-23 07:44:48 dev-java/glassfish-connector-api,added,betelgeuse,2009-05-23 08:23:10 dev-java/absolutelayout,added,ali_bush,2009-05-24 03:06:48 net-misc/charm,added,neurogeek,2009-05-24 03:57:37
[gentoo-dev] Has anyone tried to use Linux Unified Kernel ?
These gyus ( http://linux.insigma.com.cn/en/index.php ) are working on support for running Windows binaries in Linux kernel. It works by supporting Win syscalls directly in kernel or ( for unsupported ones ) by redirecting them to patched Wine server. Authors say that end effect is much less speed loss. Their previous versions were too limited and since they were written as a patch against vanilla-2.6.23, I had no luck trying them on anything newer. But latest version 0.24 is reportedly much closer to real deal. I could apply majority of the patches to gentoo-sources-2.6.29-r4 and I'm curious whether anyone here tried to fiddle with LUK and could post here final gentoo-ready version. Unfortunately, this version still doesn't support ext4, but this should come soon...
