[gentoo-dev] GLEP 42?
Hi, Whatever happened to the work to implement GLEP 42? Is there anyone actively working on this atm? Best regards, Stu -- -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://blog.stuartherbert.com/ GnuPG key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42?
On Wed, 11 Oct 2006 13:59:59 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | Whatever happened to the work to implement GLEP 42? Is there anyone | actively working on this atm? There's a full implementation in Paludis. I believe Christel was working on backporting it to the legacy package manager. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
[gentoo-dev] a new TLP to unify programming langiages?
Hi gang. As I looked for a place where to put some documentation naturally falling in a project domain for Ada, I realized that we have TLPs for many individual (programming) languages. First I though to ping some people on irc, but, as I went down the page the noticed number became nontrivial, so I decided to throw an email here instead. Basically the idea is that a TLP for an individual language is way too much - most of them do not have subprojects anyway. Therefore lets try to organize it a bit better? At least documentation-wise. We will have to see whether there will be any additional correllation further on (and indeed there might be, for example for the different gcc-backends), but even if not I think it is better to keep the main projects page more structured. What I propose is to create a TLP page for Gentoo Programming Resources (or pick your name) and move all the individual languages into the subdirs of it. Any opinions? If I get any yay's or no nays I'll create a bug about it and then we can finalize the layout there.. (I just like to keep the trace of what is being done and the related discussions). The principal list of individual TLPs (as they stand now) is below: Common Lisp eselect java perl php python Ada -- to be added George PS This is the top level project listing page I am talking about: http://www.gentoo.org/proj/en/ PPS We could add principal divisions there, like Languages Tools whatever_else and organize it even more, but this is a matter of discussion and we do not need to do it right away. I think the creation of a common TLP and relocation would suffice for a start. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Alon Bar-Lev (alonbl)
Eldad Zack wrote: Christian Heim wrote: Its my pleasure to introduce to you Alon alonbl Bar-Lev, the latest addition joining to help out with the crypto herd. He hails from Israel (hrm, they don't have cities down there ?). So far it looks like Alon is completely constrained to his computer, he doesn't have any other hobbies nor life. Oh, great, I'm not alone here anymore :) Welcome! And soon there will be three of us - I'm moving to Israel some time next year ;-) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Missing: Universal-CD - Gentoo discriminates shell and networkless users
Chris Gianelloni [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 10 Oct 2006 12:24:21 -0400: There's a difference between support and ability. You will retain the ability to install on i686 machines. We just don't want to support it. This means we aren't going to be pushing out lots of new media for them. I have a set of legacy media that I plan on pushing out. It is all built with the 2006.1 snapshot. The media is an installcd, a stage set (stage1/2/3) for x86 compiled against the no-nptl profile, a stage set for i586 compiled against the 2006.1 profile, and a stage set for i586 compiled against the no-nptl profile. I don't plan on upgrading these until we switch over to the new multiple-inheritance profiles, at which point, I'll likely build a set of stages again for legacy hardware. The stages won't be supported, but they'll be available. That's exactly the sort of thing I had in mind. Not supported means lower priority or even roll your-own install media (or simply bootstrap Gentoo from some other distribution), and that it's considered acceptable to close bugs (at Gentoo package maintainer prerogative, of course) related to 586 or lower as WONTFIX, NOTABUG, or NEEDINFO (in this case, a patch, no patch, no fix, patch, happy to). As was pointed out by someone from embedded recently, due to its flexibility, people install Gentoo based systems on all sorts of stuff, as long as there's a GCC or the like and a kernel that supports it (not said but what I read into it). Older x86 would be no exception, and might in fact continue to be supported to some extent thru embedded (if they want to take it on, of course). In fact, from what I've read, pentium class x86 is quite a popular solution for certain embedded applications, so that would be a rather logical way to go. -- 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@gentoo.org mailing list
[gentoo-dev] Re: Missing: Universal-CD - Gentoo discriminates shell and networkless users
Paul de Vrieze [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 10 Oct 2006 16:46:05 +0200: A couple of years ago (when we were still using gcc-2.95 I used to run gentoo on my server machine which was a pentium-60 (with fdiv bug). While it took a while to compile the bigger packages it was certainly workable. I did it because I didn't have a better machine, not to be able to say I did it. Well yes, except that I'd guess that was a bit more than a couple of years ago (I've been on Gentoo since 2004.0/2004.1, and IIRC it was gcc-3.3 then, so 2.95 would have been what, at least three years ago??). That means the archs are a third(-ish) of a decade further out of date than they were then. That's a significant amount of time in computer terms. Anyway, not supported doesn't mean can't do it. As I suggested in a different reply, it could and would likely still be done, just as Gentoo based systems are run on all sorts of stuff according to embedded, and in fact they may choose to continue some support, as I believe pentium-class embedded is quite popular. Not supported just means less frequent install media or bootstrapping from other distributions instead of Gentoo install media, and that bugs can be closed if desired and appropriate, based on that alone. -- 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@gentoo.org mailing list
Re: [gentoo-dev] Re: Missing: Universal-CD - Gentoo discriminates shell and networkless users
I fear the idea that valid bugs may be closed do to a -march=i586. release media should not have to be tuned to i386. perhaps thes older machines shouldn't be a priority, but that doesn't mean they should become completely unsupported. if a general move to i686 is desired perhaps the archs should split x86 and i686 or some such. and applications that are unable to be supported on i686 be removed from the x86 tree. On 10/11/06, Duncan [EMAIL PROTECTED] wrote: Paul de Vrieze [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 10 Oct 2006 16:46:05 +0200: A couple of years ago (when we were still using gcc-2.95 I used to run gentoo on my server machine which was a pentium-60 (with fdiv bug). While it took a while to compile the bigger packages it was certainly workable. I did it because I didn't have a better machine, not to be able to say I did it. Well yes, except that I'd guess that was a bit more than a couple of years ago (I've been on Gentoo since 2004.0/2004.1, and IIRC it was gcc-3.3 then, so 2.95 would have been what, at least three years ago??). That means the archs are a third(-ish) of a decade further out of date than they were then. That's a significant amount of time in computer terms. Anyway, not supported doesn't mean can't do it. As I suggested in a different reply, it could and would likely still be done, just as Gentoo based systems are run on all sorts of stuff according to embedded, and in fact they may choose to continue some support, as I believe pentium-class embedded is quite popular. Not supported just means less frequent install media or bootstrapping from other distributions instead of Gentoo install media, and that bugs can be closed if desired and appropriate, based on that alone. -- 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@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] a new TLP to unify programming langiages?
On Wed, 2006-10-11 at 17:24 +0200, George Shapovalov wrote: Hi gang. As I looked for a place where to put some documentation naturally falling in a project domain for Ada, I realized that we have TLPs for many individual (programming) languages. First I though to ping some people on irc, but, as I went down the page the noticed number became nontrivial, so I decided to throw an email here instead. Basically the idea is that a TLP for an individual language is way too much - most of them do not have subprojects anyway. Therefore lets try to organize it a bit better? At least documentation-wise. We will have to see whether there will be any additional correllation further on (and indeed there might be, for example for the different gcc-backends), but even if not I think it is better to keep the main projects page more structured. What I propose is to create a TLP page for Gentoo Programming Resources (or pick your name) and move all the individual languages into the subdirs of it. Any opinions? If I get any yay's or no nays I'll create a bug about it and then we can finalize the layout there.. (I just like to keep the trace of what is being done and the related discussions). I'd certainly say 'yay' for the Haskell team. We'd be quite happy to be a sub-project of some prog lang TLP. -- Duncan Coutts : Gentoo Developer (Haskell team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stuart Herbert wrote:
Whatever happened to the work to implement GLEP 42? Is there anyone
actively working on this atm?
It's been on my todo list, but I haven't gotten around to it yet due
to other portage work that's kept me extremely busy. I hope to get
GLEP 42 implemented soon though.
On the bright side, portage-2.1.2 [1] has made recent progress on
quite a few important and long standing bugs. Here are descriptions
of some of the recent changes:
* Profiles support multiple inheritance.
* CONFIG_PROTECT and CONFIG_PROTECT_MASK both support files (not
just directories).
* Collision protection handles symlinks properly.
* Dependencies can be satisfied by installed packages that do not
have matching ebuilds in the portage tree or overlay.
* Emerge automatically ignores blockers that are made irrelevant by
an upgrade.
* Emerge builds a complete dependency graph in order to ensure
correct merge order and detection of circular dependencies.
* The world and system sets allow automatic update of all installed
slots.
* DEPEND atoms support SLOT dependencies of the form
${CATEGORY}/${PN}:${SLOT}.
Zac
[1] http://bugs.gentoo.org/show_bug.cgi?id=147007
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFLSvG/ejvha5XGaMRArOGAKDNpWrM6t6yOI2UWpzdSMNZI5aDCQCeOGGr
2WPgtPacSdHZFWPzib/H4v8=
=n+s3
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42?
Zac Medico wrote:
* DEPEND atoms support SLOT dependencies of the form
${CATEGORY}/${PN}:${SLOT}.
No way, it happened!!
So when can we start actually using this feature?
Thanks,
Donnie
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] GLEP 42?
On Oct 11, 2006, at 12:37 PM, Zac Medico wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stuart Herbert wrote:
Whatever happened to the work to implement GLEP 42? Is there anyone
actively working on this atm?
It's been on my todo list, but I haven't gotten around to it yet due
to other portage work that's kept me extremely busy. I hope to get
GLEP 42 implemented soon though.
On the bright side, portage-2.1.2 [1] has made recent progress on
quite a few important and long standing bugs. Here are descriptions
of some of the recent changes:
* Profiles support multiple inheritance.
* CONFIG_PROTECT and CONFIG_PROTECT_MASK both support files (not
just directories).
* Collision protection handles symlinks properly.
* Dependencies can be satisfied by installed packages that do not
have matching ebuilds in the portage tree or overlay.
* Emerge automatically ignores blockers that are made irrelevant by
an upgrade.
* Emerge builds a complete dependency graph in order to ensure
correct merge order and detection of circular dependencies.
* The world and system sets allow automatic update of all installed
slots.
* DEPEND atoms support SLOT dependencies of the form
${CATEGORY}/${PN}:${SLOT}.
I thought we were eventually going to use that format to specify deps
with specific USE set.
--Iggy
Zac
[1] http://bugs.gentoo.org/show_bug.cgi?id=147007
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFLSvG/ejvha5XGaMRArOGAKDNpWrM6t6yOI2UWpzdSMNZI5aDCQCeOGGr
2WPgtPacSdHZFWPzib/H4v8=
=n+s3
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Donnie Berkholz wrote:
Zac Medico wrote:
* DEPEND atoms support SLOT dependencies of the form
${CATEGORY}/${PN}:${SLOT}.
No way, it happened!!
So when can we start actually using this feature?
We can either wait until several months after the feature is
available in release media, or else do an EAPI bump (whichever comes
sooner). Ideally, an EAPI bump will include a number of major
changes. Other features that I think we should consider for an EAPI
bump are:
1) Grouping of package atom restrictions [1].
2) Default USE flags at the ebuild and/or profile level [2].
3) Ebuild helpers as functions that die automatically [3].
4) Elimination of the implicit RDEPEND feature [4].
The first EAPI bump should probably be proposed as a GLEP and should
include features that have been proposed/implemented as part of
other GLEPs.
Zac
[1] http://bugs.gentoo.org/show_bug.cgi?id=4315
[2] http://bugs.gentoo.org/show_bug.cgi?id=61732
[3] http://bugs.gentoo.org/show_bug.cgi?id=138792
[4] http://bugs.gentoo.org/show_bug.cgi?id=135945
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFLT11/ejvha5XGaMRAu/EAKCh5pX5yM7OHF7uHo8e6EzSV2QzRgCeJFyg
fe6FbBk+YGLajtn+puYG8H8=
=Mp3N
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42?
Am Mittwoch, 11. Oktober 2006 20:36 schrieb Brian Jackson:
On Oct 11, 2006, at 12:37 PM, Zac Medico wrote:
encies.
* The world and system sets allow automatic update of all installed
slots.
* DEPEND atoms support SLOT dependencies of the form
${CATEGORY}/${PN}:${SLOT}.
Yay!
I thought we were eventually going to use that format to specify deps
with specific USE set.
Nope, that was ${CATEGORY}/${PN}[foo].
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42?
On Wed, 11 Oct 2006 13:36:16 -0500 Brian Jackson [EMAIL PROTECTED]
wrote:
| ${CATEGORY}/${PN}:${SLOT}.
|
| I thought we were eventually going to use that format to specify
| deps with specific USE set.
That's [use].
--
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Missing: Universal-CD - Gentoo discriminates shell and networkless users
On Wed, 2006-10-11 at 12:18 -0400, Caleb Cushing wrote: I fear the idea that valid bugs may be closed do to a -march=i586. If they're a bug dealing with an issue only present on i686, then yes, they likely would be, at least for release media, unless you also provide a patch. This is what being unsupported means. Now, if you give me a patch for some bug that only affects i686, I'll apply it, provided it doesn't break = i686, but I simply don't have the time to support i686 with the release media anymore. By the way, the stage1 tarball and Minimal InstallCD are both built as i386 and will remain that way for the foreseeable future. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42?
On Wed, 2006-10-11 at 19:44 +0100, Ciaran McCreesh wrote:
On Wed, 11 Oct 2006 13:36:16 -0500 Brian Jackson [EMAIL PROTECTED]
wrote:
| ${CATEGORY}/${PN}:${SLOT}.
|
| I thought we were eventually going to use that format to specify
| deps with specific USE set.
That's [use].
I assume it is really [list of use] right?
--
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 42?
On Wed, 11 Oct 2006 15:30:03 -0400 Chris Gianelloni
[EMAIL PROTECTED] wrote:
| On Wed, 2006-10-11 at 19:44 +0100, Ciaran McCreesh wrote:
| On Wed, 11 Oct 2006 13:36:16 -0500 Brian Jackson [EMAIL PROTECTED]
| wrote:
| | ${CATEGORY}/${PN}:${SLOT}.
| |
| | I thought we were eventually going to use that format to specify
| | deps with specific USE set.
|
| That's [use].
|
| I assume it is really [list of use] right?
I think cat/pkg:slot[foo][-bar][baz] or opcat/pkg-ver:slot[foo][-bar]
was what was decided upon. That's how paludis does it, but it's easy
enough to tweak if people prefer something else...
--
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13
signature.asc
Description: PGP signature
[gentoo-dev] Re: GLEP 42?
On Wed, 11 Oct 2006, Ciaran McCreesh wrote:
On Wed, 11 Oct 2006 15:30:03 -0400 Chris Gianelloni
[EMAIL PROTECTED] wrote:
| On Wed, 2006-10-11 at 19:44 +0100, Ciaran McCreesh wrote:
| On Wed, 11 Oct 2006 13:36:16 -0500 Brian Jackson [EMAIL PROTECTED]
| wrote:
| | ${CATEGORY}/${PN}:${SLOT}.
| |
| | I thought we were eventually going to use that format to specify
| | deps with specific USE set.
|
| That's [use].
|
| I assume it is really [list of use] right?
I think cat/pkg:slot[foo][-bar][baz] or opcat/pkg-ver:slot[foo][-bar]
was what was decided upon. That's how paludis does it, but it's easy
enough to tweak if people prefer something else...
What's the point of all the square brackets? Is there some benefit over
just [foo -bar baz]?
Michael Sterrett
-Mr. Bones.-
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42?
On Wed, Oct 11, 2006 at 03:52:08PM -0400, Michael Sterrett -Mr. Bones.- wrote:
On Wed, 11 Oct 2006, Ciaran McCreesh wrote:
On Wed, 11 Oct 2006 15:30:03 -0400 Chris Gianelloni
[EMAIL PROTECTED] wrote:
| On Wed, 2006-10-11 at 19:44 +0100, Ciaran McCreesh wrote:
| On Wed, 11 Oct 2006 13:36:16 -0500 Brian Jackson [EMAIL PROTECTED]
| wrote:
| | ${CATEGORY}/${PN}:${SLOT}.
| |
| | I thought we were eventually going to use that format to specify
| | deps with specific USE set.
|
| That's [use].
|
| I assume it is really [list of use] right?
I think cat/pkg:slot[foo][-bar][baz] or opcat/pkg-ver:slot[foo][-bar]
was what was decided upon. That's how paludis does it, but it's easy
enough to tweak if people prefer something else...
What's the point of all the square brackets? Is there some benefit over
just [foo -bar baz]?
Been awhile, but the original syntax being pushed was
cat/pkg:slot1,slot2
cat/pkg[use1_on,-use2_off,-use3_on]
Somewhat prefer the spaces in use rather then commas personally also,
but implemented the syntax I recalled.
~harring
pgpd1lNRcLWeM.pgp
Description: PGP signature
Re: [gentoo-dev] Re: GLEP 42?
On Wed, 11 Oct 2006 15:52:08 -0400 (EDT) Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] wrote: | What's the point of all the square brackets? Is there some benefit | over just [foo -bar baz]? Spaces in dep atoms would be highly evil, since it'd mean they were no longer simply space delimited. Commas [foo,-bar,baz] would be fine... -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
[gentoo-dev] Re: Re: GLEP 42?
On Wed, 11 Oct 2006, Ciaran McCreesh wrote: On Wed, 11 Oct 2006 15:52:08 -0400 (EDT) Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] wrote: | What's the point of all the square brackets? Is there some benefit | over just [foo -bar baz]? Spaces in dep atoms would be highly evil, since it'd mean they were no longer simply space delimited. Commas [foo,-bar,baz] would be fine... I could live with [foo,-bar,baz]. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42?
Hi Zac, This is all good news. On 10/11/06, Zac Medico [EMAIL PROTECTED] wrote: 2) Default USE flags at the ebuild and/or profile level [2]. This one would be very very useful for Seeds, if we can set per-ebuild USE flags at the profile level. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42?
On 10/11/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: Spaces in dep atoms would be highly evil, since it'd mean they were no longer simply space delimited. Commas [foo,-bar,baz] would be fine... Write a better parser then :P We use space-delimited USE flags everywhere else. It would make a lot of sense to keep it consistent here. Best regards, Stu -- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] a new TLP to unify programming langiages?
Hi George, On 10/11/06, George Shapovalov [EMAIL PROTECTED] wrote: Hi gang. As I looked for a place where to put some documentation naturally falling in a project domain for Ada, I realized that we have TLPs for many individual (programming) languages. First I though to ping some people on irc, but, as I went down the page the noticed number became nontrivial, so I decided to throw an email here instead. We don't need a management hierarchy just to bring some structure to the docs on the website.I don't see any benefit in creating a TLP for programming languages. If we were to move programming languages around, for example, I'd want to bring PHP and Ruby under webapps, as that's a more natural fit than a 'programming languages' category. (And no, I'm not pushing for PHP and Ruby to move at all). Best regards, Stu -- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42?
On Wed, 11 Oct 2006 22:08:31 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | On 10/11/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: | Spaces in dep atoms would be highly evil, since it'd mean they were | no longer simply space delimited. Commas [foo,-bar,baz] would be | fine... | | Write a better parser then :P Not an issue for me. It's an issue for random people writing scripts, for people using command line things and for people who don't want to use a full parser framework for some quick hack. There's no need to make things harder for random developers here. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ as-needed is broken : http://ciaranm.org/show_post.pl?post_id=13 signature.asc Description: PGP signature
Re: [gentoo-dev] Livecd, python, pyopengl and broken gtk installer
Dominique Michel wrote: It seam at it is a big problem with the livecd. From the forum: QUOTE: The problem is you can't use the GTK installer due to this problem. It crashes out and leaves you with no option but to wash, rinse, repeat, re-crash. By saying they won't fix the bug the developers have decided to make the graphical installer a waste of effort. In my case I went in and installed the old fashoned way (never HAVE gotten that graphical POS to work), but for anyone who is trying out Gentoo and hasn't done this a few hundred times before they're out of luck. Bad for them, bad for the community, bad for Gentoo, bad for Linux. Do these guys work in Redmond now? ENDQUOTE http://forums.gentoo.org/viewtopic-t-477582-start-25.html From bugzilla: QUOTE: And we still won't and can't fix it. All the livecd stuff is just a snapshot of portage tree in a given moment. There's been one use flag, changed meanwhile - emerge --sync, re-emerge python and stop ranting here. ENDQUOTE http://bugs.gentoo.org/show_bug.cgi?id=147809 I have done a search on bugzilla, and it is other bug report where problems with the livecd have been fixed, so I just don't understand why this one want be fixed, and I am just too tired to argue on it. It say all time the same thing, do a sync and re emerge python. With the livecd?... So here is the problem: the livecd gtk installer is broken and it must be fixed. But no one seam to be willing to do so. So, when I read such comments on the forum, I think at it will be better to remove this livecd from the servers. It is better to have no publicity as a bad publicity. The gtk installer is NOT broken. Have you tried to install without the tk/tcl/tcltk use flag? Personally, I installed with the default flags set, in fact, I told it networkless install and was up and running in about 40 minutes (366MHz) - The installer works, but not every single USE flag combination can be tested. You can *always* change a flag after you have the system installed. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 42?
On Wed, 11 Oct 2006 22:08:31 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: We use space-delimited USE flags everywhere else. It would make a lot of sense to keep it consistent here. We also use space-delimited depend atoms everywhere else. It makes no sense to break that when a comma works equally well. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Alon Bar-Lev (alonbl)
On Wed, 2006-10-11 at 08:35 -0700, Ilya A. Volynets-Evenbakh wrote: Eldad Zack wrote: Christian Heim wrote: Its my pleasure to introduce to you Alon alonbl Bar-Lev, the latest addition joining to help out with the crypto herd. He hails from Israel (hrm, they don't have cities down there ?). So far it looks like Alon is completely constrained to his computer, he doesn't have any other hobbies nor life. Oh, great, I'm not alone here anymore :) Welcome! And soon there will be three of us - I'm moving to Israel some time next year ;-) yuval too. -- -o()o-- Michael Cummings |#gentoo-dev, #gentoo-perl Gentoo Perl Dev|on irc.freenode.net Gentoo/SPARC Gentoo/AMD64 GPG: 0543 6FA3 5F82 3A76 3BF7 8323 AB5C ED4E 9E7F 4E2E -o()o-- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] a new TLP to unify programming langiages?
George Shapovalov [EMAIL PROTECTED] writes: [...] What I propose is to create a TLP page for Gentoo Programming Resources (or pick your name) and move all the individual languages into the subdirs of it. Any opinions? If I get any yay's or no nays I'll create a bug about it and then we can finalize the layout there.. I think this proposal is OK even it is just to organize the top level listing a bit better. It seems like a real mix right now -- Council next to Common Lisp, PR next to Python and so on etc. (I just like to keep the trace of what is being done and the related discussions). The principal list of individual TLPs (as they stand now) is below: Common Lisp eselect java perl php python Ada -- to be added I'm surprised to see you've listed eselect in there. Isn't that more of a system tool? PPS We could add principal divisions there, like Languages Tools whatever_else I think this would be too deep a hierarchy. -- Matthew Kennedy Gentoo Linux Developer (Public Key 0x401903E0) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Max parallelization setting
Brian Harring ha scritto:
On Tue, Oct 10, 2006 at 05:27:07PM +0200, Marius Mauch wrote:
On Tue, 10 Oct 2006 00:04:57 -0700
Brian Harring [EMAIL PROTECTED] wrote:
I might be daft (likely), but why not just introduce a var indicating
max parallelization instead? Tweak portage to push that setting into
MAKEOPTS=${MAKEOPTS+${MAKEOPTS} } -j${PARALLELIZATION}.
Might sound daft, but -j is hardcoded parallelization; if you're
trying to run 3 build processes, the original var of -j isn't all
that useful, nor will the hardcoded -j# var set for 3 package build
processes be useful if you're doing a single build.
Depending on number of seperate package build processes possible, the
# of build processes allocated per build process needs to vary
(essentially).
Seems useful as *alternative* to the low level vars, but shouldn't
replace them (so if the low level vars are set they override the global
setting).
Well.. heres the failing.
Say I've got a 32x system; I screw up and have -j32 in my makeopts,
and PARALLELIZATION=32.
Now either the pkg manager needs to understand MAKEOPTS (beyond just
adding a simple string to it), and check for -j*, or it's going to
wind up allowing 32 seperate build jobs, each with -j32.
Personally, I *really* would love to see that loadavg (that would be
one nifty screenshot).
Allowing MAKEOPTS to override the alloted build slices the manager
hands it totally defeats the purpose of moving the parallelization
factor into a seperate var; the intention is to give the manager a
max, and allow it to allocate as it needs depending on the # of build
jobs that can be ran at that point.
Theres no point in doing this if the hole it's trying to plug is
explicitly allowed; at best you wind up with two different vars you
have to keep in sync, at worst, you wind up with the 32*32 exapmle
from above.
Response of course is don't have -j* in your MAKEOPTS; well dar,
thus why allow it? ;)
~harring
Not going deep, sincerly I've read too few form the bug and the thread but:
I'm lucky and I have a cluster of 32 boxes with distcc each with 32
processors.
In such a eco-system the ebuild work is not parallelizable in the
cluster but the compiler work is, those are very different things.
please keep this in account ;)
rgds,
Francesco R.
--
gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] Feature request: --history
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I was doing my usual tests the other day when I noticed that I needed history information upon performed emerges, together with what variables were being used and the success state. I know that the log files are there, however I thought that it wouldn't be a bad idea to have an 'emerge --history' command that could show up all this kind of information. I already know that genlop parses the file, but it's missing the USE flags as well. It would be great if at least the header of 'emerge - --info' with gcc version, etc. was shown as well. I would like to know whether you consider that such request is viable or not and if it is worth the effort of being implemented and . Sorry if I missed anything :) - -- Ioannis Aslanidis (deathwing00) Gentoo KDE Herd Member Gentoo Forums Global Moderator GPG Key ID: 0xB9B11F4E GPG Key Fingerprint: 8295 0925 A183 52F2 5A40 4319 CDB9 7DAA B9B1 1F4E http://dev.gentoo.org/~deathwing00 -BEGIN PGP SIGNATURE- iD8DBQFFLNh3zbl9qrmxH04RCh9fAJ9KfNVFu0eKS4uWBG9TG6rX6dGotQCbB0S+ 4nVsGjq33Z01hiIsBq9jqbk= =lJZH -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] GLEP 14?
What's the current status of GLEP 14? This wiki page on glsa-check (which seems to have been more or less unchanged for a very long time) has a roadmap: http://gentoo-wiki.com/Glsa-check The implementation will take place in the following order: 1. distribute GLSAs in the portage tree (completed) 2. release a beta version of the GLSA handling code in gentoolkit (in progress) 3. move dependency handling code from emerge to portage.py 4. add glsa.py to portage 5. integrate functions from glsa-check in emerge and equery Note: This list might be expanded in the future So, is there some work that needs to be done on portage before step 3 happens -- i.e. is now the wrong time to be doing that work? Or is it just lack of somebody to do it? John -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] GLEP 14?
John J Lee wrote: So, is there some work that needs to be done on portage before step 3 happens -- i.e. is now the wrong time to be doing that work? Or is it just lack of somebody to do it? In short: No, yes, yes. What really is needed is sets support in portage. See bug 144480 for that. [1] http://bugs.gentoo.org/show_bug.cgi?id=144480 -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-portage-dev@gentoo.org mailing list
