Paul de Vrieze wrote:
WXS is W3C Xml Schema, so yes. The problem though is that the DTD and the
schema must be compatible on some level.
Paul
This is not really a problem because you can validate xml files against
both a DTD and a schema. When you are making the schema you just make
Hi,
our documentation [1] lists syslog-ng as the default system logger
while current profiles uses metalog (except embedded, default-macos/ppc,
default-darwin and sparc32). What should be changed, Handbook or profiles?
[1] http://www.gentoo.org/doc/en/handbook/hb-install-tools.xml
TIA,
-jkt
--
On Tue, Sep 27, 2005 at 10:31:04AM +0200, Jan Kundrát wrote:
our documentation [1] lists syslog-ng as the default system logger
while current profiles uses metalog (except embedded, default-macos/ppc,
default-darwin and sparc32). What should be changed, Handbook or profiles?
I think we should
Hello all,
To shove under the rug:
Bug 62001: Have portage QA checks consider USE_EXPAND
Bug 70648: QA warnings about USE_EXPAND-derived use variables
Bug 101998: Portage shouldn't warn on missing IUSE for USE_EXPAND
To not shove under the rug:
Bug 23826: Give more visibility to ebuilds
On Tuesday 27 September 2005 11:23, Jason Stubbs wrote:
So what needs to be done to fix it? Well, what is the purpose of
USE_EXPAND? Put simply, it is to allow the user to select one or more
features of a package from a list of choices. How is this different to USE
flags? The choices all
On Tuesday 27 September 2005 18:38, Diego 'Flameeyes' Pettenò wrote:
On Tuesday 27 September 2005 11:23, Jason Stubbs wrote:
So what needs to be done to fix it? Well, what is the purpose of
USE_EXPAND? Put simply, it is to allow the user to select one or more
features of a package from a
On Tuesday 27 September 2005 10:39, Henrik Brix Andersen wrote:
On Tue, Sep 27, 2005 at 10:31:04AM +0200, Jan Kundrát wrote:
our documentation [1] lists syslog-ng as the default system logger
while current profiles uses metalog (except embedded, default-macos/ppc,
default-darwin and
On Tue, 27 Sep 2005 18:23:25 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
Bug 23826: Give more visibility to ebuilds variables (ALSA_CARDS,
etc.)
Just to make it clear if it wasn't: although some comments made
it derive toward USE_EXPANDed vars, the above bug was at the
begining about
On Tue, 2005-09-27 at 10:39 +0200, Henrik Brix Andersen wrote:
On Tue, Sep 27, 2005 at 10:31:04AM +0200, Jan Kundrát wrote:
our documentation [1] lists syslog-ng as the default system logger
while current profiles uses metalog (except embedded, default-macos/ppc,
default-darwin and
On Tuesday 27 September 2005 19:54, Thomas de Grenier de Latour wrote:
On Tue, 27 Sep 2005 18:23:25 +0900
Jason Stubbs [EMAIL PROTECTED] wrote:
Bug 23826: Give more visibility to ebuilds variables (ALSA_CARDS,
etc.)
So i don't think this bug is really relevant in this discussion.
It has
On Tue, 2005-09-27 at 19:12 +0900, Jason Stubbs wrote:
On Tuesday 27 September 2005 18:38, Diego 'Flameeyes' Pettenò wrote:
On Tuesday 27 September 2005 11:23, Jason Stubbs wrote:
So what needs to be done to fix it? Well, what is the purpose of
USE_EXPAND? Put simply, it is to allow the
Before you reply to this.. Can you enlighten me on what the solution to the
problem is that you are heading toward? I'm having trouble seeing what your
real point is.
On Tuesday 27 September 2005 19:41, Diego 'Flameeyes' Pettenò wrote:
On Tuesday 27 September 2005 12:12, Jason Stubbs wrote:
On Tue, 27 Sep 2005 08:35:43 -0400
Chris Gianelloni [EMAIL PROTECTED] wrote:
Unfortunately, even trying to add -linguas_fr to package.use,
still results in the French language pack being installed over
the English.
This reminds me bug #104573: it was the same problem where some
LINGUAS=fr
On Tuesday 27 September 2005 14:51, Jason Stubbs wrote:
Variables are _not_ fine. I would think it should be clear to everybody by
now that ebuilds can not pick random things from the computer they are
installing on to define how they will build.
If variables are not fine, so can't be find
On Tue, 2005-09-27 at 15:07 +0200, Thomas de Grenier de Latour wrote:
On Tue, 27 Sep 2005 08:35:43 -0400
Chris Gianelloni [EMAIL PROTECTED] wrote:
Unfortunately, even trying to add -linguas_fr to package.use,
still results in the French language pack being installed over
the English.
On Tuesday 27 September 2005 21:35, Chris Gianelloni wrote:
On Tue, 2005-09-27 at 18:23 +0900, Jason Stubbs wrote:
1) What to do if nothing is set?
2) What to do if an invalid value is set?
Install everything. If everything cannot be installed, due to
incompatibilities, then die.
This
On Tuesday 27 September 2005 22:44, Diego 'Flameeyes' Pettenò wrote:
On Tuesday 27 September 2005 14:51, Jason Stubbs wrote:
Variables are _not_ fine. I would think it should be clear to everybody
by now that ebuilds can not pick random things from the computer they are
installing on to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Gianelloni wrote:
| On Tue, 2005-09-27 at 19:12 +0900, Jason Stubbs wrote:
|Which leads me to the one thing I didn't say but feel strongest
about.. What
|is the real point of USE_EXPAND? What can/does it do that USE flags do
not?
|
|
| As far
Diego 'Flameeyes' Pettenò posted
[EMAIL PROTECTED], excerpted below,
on Tue, 27 Sep 2005 12:41:50 +0200:
Saying for example that kdelibs uses kernel_linux can make people think that
kdelibs works ONLY for Linux kernel, while that's not true at all.
I see your point on most of your post, but
On Tue, Sep 27, 2005 at 09:07:00AM -0500, Kito wrote:
[Portage devs please don't throw rocks at me]
All out of rocks :/
My impression of the userland, elibc, and kernel use expanded vars is
it was a quick way to sidestep some of the issues with GLEP22... it
would seem the full keywords
On Tue, Sep 27, 2005 at 08:27:34AM -0400, Chris Gianelloni wrote:
On Tue, 2005-09-27 at 10:39 +0200, Henrik Brix Andersen wrote:
On Tue, Sep 27, 2005 at 10:31:04AM +0200, Jan Kundr??t wrote:
our documentation [1] lists syslog-ng as the default system logger
while current profiles uses
On Tue, 2005-09-27 at 11:57 -0500, Brian Harring wrote:
Basically... why?
I'm neither advocating being different to be different, nor following
others so howtos about their stuff fit to ours. I'm after
the underlying reasons why general users should be using syslog-ng over
metalog in
On Tuesday 27 September 2005 01:29 pm, Chris Gianelloni wrote:
On Tue, 2005-09-27 at 11:57 -0500, Brian Harring wrote:
Basically... why?
I'm neither advocating being different to be different, nor following
others so howtos about their stuff fit to ours. I'm after
the underlying
On Tue, 27 Sep 2005 13:47:49 -0400 Mike Frysinger [EMAIL PROTECTED]
wrote:
| because someone changed it doesnt mean it should have been changed
Ok, for those who don't remember...
In the good old days, syslog-ng was the default. Then, for one of the
releases, the x86 team accidentally included
On Tue, Sep 27, 2005 at 01:47:49PM -0400, Mike Frysinger wrote:
On Tuesday 27 September 2005 01:29 pm, Chris Gianelloni wrote:
On Tue, 2005-09-27 at 11:57 -0500, Brian Harring wrote:
I'd rather see reasons listed as to why syslog-ng is a superior
default for users who (most likely) don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
| Ok, for those who don't remember...
|
| In the good old days, syslog-ng was the default. Then, for one of the
| releases, the x86 team accidentally included metalog instead of
| syslog-ng on the distfiles CD, so the default
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Harring wrote:
| Re: it being a temporary change that should be undone, it's been
| around long enough I won't call it 'temporary' at this point.
Oh, so if we screwed up a year ago, we shouldn't fix it. If you won't
call that temporary, I
Mike Frysinger wrote:
On Tuesday 27 September 2005 02:59 pm, Donnie Berkholz wrote:
Ciaran McCreesh wrote:
| Ok, for those who don't remember...
|
| In the good old days, syslog-ng was the default. Then, for one of the
| releases, the x86 team accidentally included metalog instead of
|
On Wednesday 28 September 2005 00:35, Donnie Berkholz wrote:
What I have done in my ebuilds using USE_EXPAND is add extra IUSE-like
variables, for example:
IUSE_VIDEO_CARDS=radeon sis mga
IUSE_INPUT_DEVICES=synaptics wacom
for `use video_cards_sis` etc..
This would allow for possible QA
On Wednesday 28 September 2005 10:23, Jason Stubbs wrote:
On Wednesday 28 September 2005 00:35, Donnie Berkholz wrote:
What I have done in my ebuilds using USE_EXPAND is add extra IUSE-like
variables, for example:
IUSE_VIDEO_CARDS=radeon sis mga
IUSE_INPUT_DEVICES=synaptics wacom
Mike Frysinger wrote:
On Monday 26 September 2005 12:01 am, Andrew Muraco wrote:
1) would ?arch become the old ~arch, if it was implemented?
2) would people actually try to run a full ?arch system?
3) #2, would it be possible without breakage?
if we went with a testing mask it'd mean that
On Wednesday 28 September 2005 00:35, Donnie Berkholz wrote:
IUSE_VIDEO_CARDS=radeon sis mga
IUSE_INPUT_DEVICES=synaptics wacom
So, my patch (even though it works) puts these flags into an IUSE_EXPAND
variable and would require an upgrade on the CVS server to get correct cache
generation for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jason Stubbs wrote:
| What are the exact reasons for not wanting to put the expanded flags
directly
| into IUSE? If it's just a matter of the horrid display existing tools
would
| give, the functionality can go in and IUSE updated after the
Hola all.
The short version of it is that there is no good reason to be using
has_version/portageq in the global scope; it's slow, it's not allowed,
and any attempts to change metadata via it screw up the build plan.
It's really a no go... so next version of portage will trigger an
Mark Loeser halcy0n at gentoo.org writes:
Well, the x86 team has now chosen some leads so we can start getting
everything together as a team. For our leads, we have chosen to have a
committee of 4 of us: halcy0n, solar, azarah, and wolf32o2. We each
felt that we didn't have the time or
Removes any atoms that are satisfied by package.provided in emerge's getlist()
function.
diff -uNr 2.0/bin/emerge 2.0-patched/bin/emerge
--- 2.0/bin/emerge 2005-09-27 13:16:09.0 +0900
+++ 2.0-patched/bin/emerge 2005-09-27 15:00:23.0 +0900
@@ -861,6 +861,16 @@
continue
This patch is by swegener. It allows one to specify atoms after `emerge info`
that will be matched to installed packages. Any installed packages found that
have settings differing to the current settings will have those settings
printed out along with the global info.
diff -u -r1.345.2.37
This patch has two parts. The first adds information to show what package
brought in the offending atom. The second part clarifies that the problem
with ebuild foo is talking about the world/system/cli package rather than
the actual package requiring the unsatisfiable atom.
diff -u -r1.345.2.37
Subject says it all...
diff -uNr 2.0/bin/emerge 2.0-patched/bin/emerge
--- 2.0/bin/emerge 2005-09-27 13:16:09.0 +0900
+++ 2.0-patched/bin/emerge 2005-09-27 15:18:53.0 +0900
@@ -3173,7 +3173,7 @@
if x[3]!=nomerge:
mergecount+=1
#check for blocking dependencies
-
While not harmful, there was one issue with the previous patch; the parent of
the blocking package would be fetched as well. This would usually mean that
one of the packages being merged would be fetched twice. This patch fixes
that.
diff -uNr 2.0/bin/emerge 2.0-patched/bin/emerge
---
Kill 'em all!
(Original patch by solar)
diff -uNr 2.0/pym/portage.py 2.0-patched/pym/portage.py
--- 2.0/pym/portage.py 2005-09-26 11:48:15.0 +0900
+++ 2.0-patched/pym/portage.py 2005-09-27 16:06:21.0 +0900
@@ -1864,7 +1864,7 @@
fetched=0
else:
for x_key
On Wednesday 28 September 2005 12:15, Marius Mauch wrote:
Jason Stubbs wrote:
Kill 'em all!
(Original patch by solar)
Hmm, I actually liked them.
Even now that FEATURES=strict is default and every package results in a
screenful of everything's alright, mate ;-) ?
--
42 matches
Mail list logo
