Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

2010-08-14 Thread Harald van Dijk
On Sat, Aug 14, 2010 at 06:26:12PM +0200, Thilo Bangert wrote:
  So you want me to force everyone to update the package just to respect
  the LDFLAGS.
 
 yes. IIRC it has been stated on this list before, that a change which 
 changes the resulting binary always needs to be done in a revbump. 

If that's true, that doesn't make sense. Take one extreme case: let's
say libgcj, part of gcc, has a problem with LDFLAGS, and you fixed it.
But the majority of people using gcc don't even turn on java support,
those that do have a working libgcj already, and gcc can easily take
hours to build. Should you revbump?

There are always exceptions. Maybe you don't consider LDFLAGS support
in general one of those exceptions, but clearly some others do. You
can't just tell them there are no exceptions when there are, you need
to explain why this isn't a valid reason to make an exception.
My impression, too, is that few people care enough about LDFLAGS support
to want to rebuild packages for it, so I would not have bumped either,
but I'm willing to be convinced I'm wrong.



Re: [gentoo-dev] Locale check in python_pkg_setup()

2010-08-02 Thread Harald van Dijk
On Mon, Aug 02, 2010 at 11:02:20PM +0200, Arfrever Frehtes Taifersar Arahesis 
wrote:
 It would have to be parsed using e.g. grep and sed. It's easier to call 
 Python in this case.

It's even easier not to.

 The call to Python is sufficiently fast:
 
 $ time python -c 'import os; print(os.environ.get(LC_ALL, 
 os.environ.get(LC_CTYPE, os.environ.get(LANG, POSIX'  /dev/null
 
 real0m0.062s
 user0m0.051s
 sys 0m0.011s

Let's compare. On my system:

time python -c 'import os; print(os.environ.get(LC_ALL, 
os.environ.get(LC_CTYPE, os.environ.get(LANG, POSIX'
en_GB.UTF-8

real0m0.020s
user0m0.016s
sys 0m0.004s

time sh -c 'echo ${LC_ALL:-${LC_CTYPE:-${LANG:-POSIX}}}'
en_GB.UTF-8

real0m0.001s
user0m0.000s
sys 0m0.000s

And that's after several runs for both, so it's not caused by the
initial load of python, which wasn't in memory yet.

Yes, 0.019s is very little, but in this case I see absolutely no benefit
whatsoever in calling python. Plus sh has the advantage of actually
working when LC_ALL is exported as  (which in LC_* means the same as
having it unset)...

But why exactly are you concerned about LC_* being defined but not
exported anyway? You're checking from an ebuild; locales are going to
get inherited from portage or profile.env anyway, so you can just
assume that if they _are_ set, they're exported. The only way they might
not be is if the user is messing with the locale from the bashrc, and if
the user's doing that, the user really needs to fix the bashrc and
export the vars anyway.

None of this changes the fact that locale checks warns about bugs in packages,
not bugs in the user's configuration.



Re: [gentoo-dev] Locale check in python_pkg_setup()

2010-07-30 Thread Harald van Dijk
On Fri, Jul 30, 2010 at 01:16:18AM +0200, Arfrever Frehtes Taifersar Arahesis 
wrote:
 We received too many invalid bugs caused by unsupported locales. 
 python_pkg_setup() needs to check
 locale and print error (using eerror(), without die()), when unsupported 
 locale has been detected.

I'm strongly with Brian on this. You receive too many valid bug reports
caused by a broken package.  python_pkg_setup needs to do nothing. You
need to fix the bugs, or if fixing them is too much of an issue, work
around them in the ebuild. Keep in mind that having no locale explicitly
selected is the default for a Gentoo installation, and that the docs do
not (and should not) say anywhere that non-UTF-8 locales are unsupported.
In fact, quoting from
  http://www.gentoo.org/doc/en/guide-localization.xml:

It's also possible, and pretty common especially in a more traditional
 UNIX environment, to leave the global settings unchanged, i.e. in the
 C locale. Users can still specify their preferred locale in their own
 shell RC file:



Re: [gentoo-dev] Minor changes in python.eclass and distutils.eclass

2010-07-05 Thread Harald van Dijk
On Mon, Jul 05, 2010 at 07:01:27PM +0200, Arfrever Frehtes Taifersar Arahesis 
wrote:
 2010-07-05 18:36:09 Tomáš Chvátal napisał(a):
  Dne 5.7.2010 18:34, Arfrever Frehtes Taifersar Arahesis napsal(a):
   python.eclass uses colors for build time outputting, which doesn't 
   communicate anything for users.
  
  +   echo  ${_RED}*${_NORMAL} ${_RED}Deprecation Warning: NEED_PYTHON
  variable is deprecated and will be banned on 2010-10-01.${_NORMAL}
  +   echo  ${_RED}*${_NORMAL} ${_RED}Use PYTHON_DEPEND variable instead of
  NEED_PYTHON variable.${_NORMAL}
  +   echo  ${_RED}*${_NORMAL} ${_RED}The ebuild needs to be fixed. Please
  report a bug, if it has not been already reported.${_NORMAL}
  
  The above is build outputting since when?
 
 The colored, non-logged output in deprecation warnings is used as exception 
 to increase
 the chance that ebuild maintainers will be notified earlier about the 
 necessity of changes
 in given ebuilds.

einfo/ewarn/eerror output is repeated by default when emerge exits. By
not using einfo/ewarn/eerror, you are making it less likely that others
will be reading your deprecation notices.



Re: [gentoo-dev] Minor changes in python.eclass and distutils.eclass

2010-07-05 Thread Harald van Dijk
On Mon, Jul 05, 2010 at 07:38:32PM +0200, Harald van Dijk wrote:
 On Mon, Jul 05, 2010 at 07:01:27PM +0200, Arfrever Frehtes Taifersar Arahesis 
 wrote:
  2010-07-05 18:36:09 Tomáš Chvátal napisał(a):
   Dne 5.7.2010 18:34, Arfrever Frehtes Taifersar Arahesis napsal(a):
python.eclass uses colors for build time outputting, which doesn't 
communicate anything for users.
   
   + echo  ${_RED}*${_NORMAL} ${_RED}Deprecation Warning: NEED_PYTHON
   variable is deprecated and will be banned on 2010-10-01.${_NORMAL}
   + echo  ${_RED}*${_NORMAL} ${_RED}Use PYTHON_DEPEND variable instead of
   NEED_PYTHON variable.${_NORMAL}
   + echo  ${_RED}*${_NORMAL} ${_RED}The ebuild needs to be fixed. Please
   report a bug, if it has not been already reported.${_NORMAL}
   
   The above is build outputting since when?
  
  The colored, non-logged output in deprecation warnings is used as exception 
  to increase
  the chance that ebuild maintainers will be notified earlier about the 
  necessity of changes
  in given ebuilds.
 
 einfo/ewarn/eerror output is repeated by default when emerge exits. By
 not using einfo/ewarn/eerror, you are making it less likely that others
 will be reading your deprecation notices.

Ugh. I see that you're using einfo already and suppressing its output.
In that case, my objection doesn't apply, but it's still nasty.



Re: [gentoo-dev] Re: FYI: Rules for distro-friendly packages

2010-06-27 Thread Harald van Dijk
On Sun, Jun 27, 2010 at 02:56:33PM +0300, Nikos Chantziaras wrote:
 On 06/27/2010 01:47 PM, Enrico Weigelt wrote:
  * Nikos Chantziarasrea...@arcor.de  schrieb:
 
  Did it actually occur to anyone that warnings are not errors?  You can
  have them for correct code.  A warning means you might want to look at
  the code to check whether there's some real error there.  It doesn't
  mean the code is broken.
 
  In my personal experience, most times a warning comes it, the
  code *is* broken (but *might* work in most situations).
 
 That's the key to it: most times.  Granted, without -Wall (or any other 
 options that tweaks the default warning level) we can be very sure that 
 the warning is the result of a mistake by the developer.  But with 
 -Wall, many warnings are totally not interesting (unused parameter) 
 and some even try to outsmart the programmer even though he/she knows 
 better (taking address of variable declared register).  In that last 
 example, fixing it would even be wrong when you consider the optimizer 
 and the fuzzy meaning of register which the compiler is totally free 
 to ignore.

The compiler is not totally free to ignore the register keyword. Both
the C and the C++ standards require that the compiler complain when
taking the address of a register variable. Other compilers will issue a
hard error for it. Fixing the code to not declare the variable as
register would be the correct thing to do.

Make sure you *understand* warnings, and then you can decide whether to
fix the code, if there is anything to fix, or to ignore.



Re: [gentoo-dev] Re: FYI: Rules for distro-friendly packages

2010-06-27 Thread Harald van Dijk
On Sun, Jun 27, 2010 at 05:46:28PM +0300, Nikos Chantziaras wrote:
 On 06/27/2010 03:23 PM, Harald van Dijk wrote:
  The compiler is not totally free to ignore the register keyword.
  Both the C and the C++ standards require that the compiler complain
  when taking the address of a register variable. Other compilers will
  issue a hard error for it. Fixing the code to not declare the
  variable as register would be the correct thing to do.
 
 No, it would not be the correct thing to do, because of the following. 
 (This is part of a discussion between me and someone quite smarter than 
 me, who explained the issue in detail.)

 [snip]

That explanation seems to be written by someone who does not know that
taking the address of a register variable is simply not allowed.

 OK, long read, but the the conclusion is that fixing the code to not 
 declare the variable as register would be the correct thing to do it 
 *not* the correct thing to do.  The correct thing to do is to ignore the 
 warning, which is not possible if warnings are turned into errors.

And which is not possible if the warning is a hard error in the first place.

 You also mentioned that other compilers will issue a hard error for 
 it.  That sounds rather strange, and I wonder which compilers that 
 might be; someone should file a bug report against them ;)

Well, let's start with gcc; that's quite an important one for Gentoo...



Re: [gentoo-dev] lastrite: www-client/kazehakase

2010-06-26 Thread Harald van Dijk
On Sat, Jun 26, 2010 at 11:35:29AM +0300, Samuli Suominen wrote:
 nothing usable left in tree.
 
 # Samuli Suominen ssuomi...@gentoo.org (26 Jun 2010)
 # Masked for QA
 #
 # Fails to compile with stable xulrunner, see bug 317275
 # Fails to compile with GTK+-2.20, see bug 325661
 # Ignores LDFLAGS, see bug 268491
 # Current stable is using vulnerable xulrunner, see bug 324953
 #
 # Removal in 30 days
 www-client/kazehakase

In case anyone is interested in picking this up, I've attached the
patches from upstream for xulrunner and gtk+ to their bugs. With those,
it's at least possible to get kazehakase to build, run, and display web
pages.



Re: [gentoo-dev] LINGUAS handling

2010-06-09 Thread Harald van Dijk
On Wed, Jun 09, 2010 at 11:38:03AM +0400, Peter Volkov wrote:
 1. Do we want all packages to support LINGUAS if possible? It is
 possible to leave gettext based package without LINGUAS and everything
 will just work, but I think that it's good idea to make supported
 languages visible to user through linguas_lang flags.

I agree, but I'd like to point out this would be a visible change in
default behaviour: the default would change from install everything to
install nothing. For gettext-based packages, install everything is a
sane default, in my opinion.

 2. How should we handle case of unset LINGUAS in ebuild? Should we mimic
 gettext and install all supported languages, using code like
 
 LINGUAS=${LINGUAS-%UNSET%}
 if test %UNSET% == $LINGUAS; then
   # install all supported languages
 fi

Firstly, don't use == with test. It's not portable. The bash built-in
test supports ==. Other test implementations don't, such as the one from
GNU coreutils, and the built-in test in other shells, don't. If you use
test in a context where you're absolutely sure the built-in version will
be used, and the executing shell is bash, then I suppose you can use ==,
but at that point you're better off using [[ ]] anyway.

That said, to test if a variable is set, use ${VAR+set} over
${VAR-unset}. ${VAR-unset} evaluates to unset if VAR is unset, and if
VAR is set to the string unset. I suppose that's why you used %UNSET%,
to reduce the possibility of accidents. You can reduce it to 0, using
for example

if [[ -z ${LINGUAS+set} ]]; then
  # LINGUAS is unset
fi

 ? If yes, it's easy to write such code and put in eclass. If no, how do
 we live with inconsistency that some packages will install all languages
 some, will install nothing (document in handbook and add portage warning
 in case LINGUAS is unset?)?

Unfortunately, consistency either way is bad. Making unset LINGUAS
install nothing changes gettext's design, when the whole idea behind
LINGUAS was to mimic gettext's design. Making unset LINGUAS install
everything causes massive disk space requirements for the default
settings for some packages such as openoffice. In my opinion, either of
those would be worse than having LINGUAS behave inconsistently.

 3. What is the purpose of strip-linguas function (mentioned in
 devmanual)? It's clear what it does but I have no ideas why. Probably
 similar code could be used in QA function that will gather supported
 languages from po directories and warn maintainer that it's time to
 update linguas_lang in IUSE (and probably later it could be expanded
 to support qt packages too).

It's used for some packages that fail to build with certain LINGUAS
values. If I recall correctly, binutils had a bug where putting en_GB in
your LINGUAS made the build fail, for example. binutils doesn't support
en_GB anyway, so it gets filtered out,



Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*

2010-06-05 Thread Harald van Dijk
On Sat, Jun 05, 2010 at 05:49:08PM +0200, Thomas Sachau wrote:
 If any package does inherit python or distutils eclass, then those eclasses 
 do pull in
 dev-lang/python, which is unversioned, so it will always pull in the latest 
 version, in this case
 python-3*. You could change this, so it allows any major installed slot to 
 satisfy the python
 dependency.

A dependency on dev-lang/python *is* satisfied by any slot, any version. You've
been told so already, if I recall correctly.



Re: [gentoo-dev] Actions of python team, especially Arfrever wrt python eclass and python-3*

2010-06-05 Thread Harald van Dijk
On Sun, Jun 06, 2010 at 01:03:48AM +0200, Thomas Sachau wrote:
 Am 05.06.2010 20:31, schrieb Harald van Dijk:
  On Sat, Jun 05, 2010 at 05:49:08PM +0200, Thomas Sachau wrote:
  If any package does inherit python or distutils eclass, then those 
  eclasses do pull in
  dev-lang/python, which is unversioned, so it will always pull in the 
  latest version, in this case
  python-3*. You could change this, so it allows any major installed slot to 
  satisfy the python
  dependency.
  
  A dependency on dev-lang/python *is* satisfied by any slot, any version. 
  You've
  been told so already, if I recall correctly.
 
 Every slot and every version *should* satisfy a dev-lang/python dependency, 
 but currently such
 unspecified version dependency does automaticly pull in the latest 
 version/slot, which in case of
 python does mean python-3*, even when you have e.g. python:2.6 installed.

Fine, I'll be as explicit as possible: not quite. I have a Python 3-free 
system. I created
a dummy ebuild that does nothing but pull in unversioned python. Let's
see how it behaves.

$ emerge -pv python

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  NS   ] dev-lang/python-3.1.2-r3 [2.6.5-r2] USE=gdbm ipv6 ncurses 
readline sqlite ssl threads tk (wide-unicode) xml -build -doc -examples 
-wininst ELIBC=(-uclibc) 9,558 kB

$ cat test-2.0.ebuild 
KEYWORDS=~amd64
SLOT=0
DEPEND=dev-lang/python

$ emerge -pv test

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N] test/test-2.0  0 kB [1]

Total: 1 package (1 new), Size of downloads: 0 kB
Portage tree and overlays:
 [0] /usr/portage
 [1] /etc/portage/overlay

Note how python 3 is *not* pulled in, despite an unversioned dependency on 
dev-lang/python.
You only get that if you tell portage to try and update dependencies as
well, and yes, if you do that, it's only fair that it attempts to update python.



Re: [gentoo-dev] bug wrangler queue is large...

2010-05-25 Thread Harald van Dijk
On Tue, May 25, 2010 at 03:33:33PM -0400, Mike Frysinger wrote:
 On Tuesday 25 May 2010 14:46:01 Matti Bickel wrote:
  I wrangle bugs when there's a need and I'd
  like to hear what maintainers want to see on a bug assigned to them.
  If info is missing I usually ask for it and assign the bug anyway. If
  that's not wanted, let me know.
 
 i dont feel like this should go to the maintainer yet.  if a report is 
 missing 
 something that the maintainer needs, it isnt ready for them to look at.  so 
 wranglers ask for it, leave it assigned to bug-wranglers, and close as 
 NEEDINFO.  when (if) things become available, it can then be re-opened and 
 moved to the maintainer.

No, don't close as NEEDINFO, mark as ASSIGNED. NEEDINFO bugs cannot be
reopened by other users, even if they provide the requested information.
NEEDINFO bugs are also easily forgotten about when the reporter forgets
to reopen the bug him/herself. Plus, it's in the docs anyway.

Do not assume that the reporter ought to know how to report bugs. An
 omitted `emerge --info' does not call for a public flogging, it simply
 calls for the missing `emerge --info'. Even experienced reporters make
 mistakes, so simply request the information, mark the bug as ASSIGNED
 and wait for the information you requested.

  http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml



Re: [gentoo-dev] bug wrangler queue is large...

2010-05-25 Thread Harald van Dijk
On Tue, May 25, 2010 at 04:25:20PM -0400, Mike Frysinger wrote:
 and people on the wrangler alias see that traffic, so the state doesnt 
 matter.  
 but i guess you're trying to cater to people who only scan the assigned list 
 rather than watching the e-mails sent to it.

Yes, people like myself who don't normally wrangle bugs but try to help out
occasionally. I'm not really interested in receiving all bug wrangler
e-mails.



Re: [gentoo-dev] perl eclass review - EAPI=3 + new helper eclass

2010-04-19 Thread Harald van Dijk
On Mon, Apr 19, 2010 at 04:58:57PM -0400, James Cloos wrote:
  CM == Ciaran McCreesh ciaran.mccre...@googlemail.com writes:
 
 CM There's no need to offer the user the choice to do something that is
 CM always broken. Your car doesn't have a connect the exhaust fumes to
 CM the air conditioning intake button.
 
 Overriding portage's eclasses with one's own is not always broken;
 your analogy is not at all on point.

Overriding portage's eclasses with your own is already possible. You're
asking to override portage's eclasses, without letting portage handle
the fact that you are overriding eclasses. And that is a bad idea. You
haven't commented, at least not in this thread that I have seen, on
how to handle metadata changes as a result of eclass changes.

Let's say this is in the tree:

foo.eclass:
DEPEND=dev-lang/python:2.6

bar-1.ebuild:
inherit foo

Let's say this is in your overlay:

foo.eclass:
DEPEND=|| ( dev-lang/python:3.1 dev-lang/python:2.6 )

Now you install bar. How should portage know that it must regenerate the
metadata cache, to see that it doesn't need to install python 2.6 if you
already have 3.1?



Re: [gentoo-dev] Non-free software in Gentoo

2010-01-06 Thread Harald van Dijk
On Wed, Jan 06, 2010 at 10:57:01AM -0800, Greg KH wrote:
 On Tue, Jan 05, 2010 at 11:55:49PM -0500, Vincent Launchbury wrote:
  Greg KH wrote:
   And note, _I_ placed those images in the kernel image, after consulting
   lawyers about this issue, so it's not like I don't know what I am
   talking about here.
  
  I'm not questioning whether it's legal to distribute non-free firmware
  alongside the GPL. I'm merely saying that the firmware _is_ non-free,
  which should be reflected by the ebuild licenses.
 
 So you are saying that the license for the kernel should show the
 license for all of the different firmware files as well?

If all the different firmware files get installed, then yes.

 That would get
 pretty unusable, and keep the kernel from being able to be installed on
 anyone's machine that didn't want such licenses, right?
 
 Also note that the license of the firmware files do not matter to almost
 everyone using the kernel, as almost no one uses those files anymore,
 the ones in the linux-firmware package should be used instead.

Right, which is why at the same time it would be useful to have an
option to not install those files. There's no problem with USE
conditionals in LICENSE; LICENSE=GPL-2 firmware? ( freedist ) or
expanded further would be fine, and simply nuke those files on install
with USE=-firmware.

 So as we are a source-based distro, if you object to those firmware
 licenses, just don't build them in your kernel builds.  But to expect to
 list all of them as the license for the whole kernel package, that's not
 a workable solution as far as I can see.

The kernel sources are unusual in that they install the sources, and the
user is responsible for configuration and compilation. For anything
built from an ebuild, the license of unused parts of the source code
shouldn't matter, but here all of the source files of the kernel get
installed.

   So it's a pointless effort.
  
  To you maybe, but it's important to some. Note that updating the
  licenses would only affect those with strict ACCEPT_LICENSE settings
  anyway. I don't understand why you'd oppose the change.
 
 So you want anyone with such strict settings to not be able to install
 the kernel package at all?  If so, what kernel do you want them to be
 able to use?  :)

The GPL-2 licensed parts of all the kernel packages -- so probably
everything that matters -- could be installed with
ACCEPT_LICENSE=GPL-2 with my above suggestion.



Re: [gentoo-dev] Re: [RFC] base.eclass

2010-01-03 Thread Harald van Dijk
On Sun, Jan 03, 2010 at 02:56:01AM +0100, Tomáš Chvátal wrote:
 Dne 3.1.2010 01:56, Mark Bateman napsal(a):
  There seems to be alot of unquoted variables
  
  65 base_src_util $@
 This is not problem

Only because you can be sure there will be exactly one word in the
result, which will not be split. In general, $@ should be quoted, and it
would be a good idea to either do it here too even though it's not
strictly necessary, or make the intent clearer and just write

  base_src_util $1

  90 case $1 in
 Yarp this is problem and fixed

That's not a problem. A case expression is another example where quoting
is unnecessary; there won't be any word splitting on $1 anyway.

  95 [[ ! -z ${A} ]]  unpack ${A}
 ${A} is not used quoted :]

Right, that doesn't need quoting, and it would even be okay to drop the
unnecessary quotes in [[.



Re: [gentoo-dev] Re: [RFC] base.eclass

2010-01-03 Thread Harald van Dijk
On Sun, Jan 03, 2010 at 11:28:27AM +0100, Ulrich Mueller wrote:
  On Sun, 3 Jan 2010, Harald van Dijk wrote:
 
   65 base_src_util $@
  This is not problem
 
  Only because you can be sure there will be exactly one word in the
  result, which will not be split. In general, $@ should be quoted, and it
  would be a good idea to either do it here too even though it's not
  strictly necessary, or make the intent clearer and just write
 
base_src_util $1
 
 I think this would not be correct. Note the while loop over parameters
 in base_src_util.

You're right. I'm so used to src_unpack normally not having any arguments
that I didn't stop to think base_src_unpack could easily be called
explicitly, with as many parameters as you'd like. Checking shows this
is not done in the tree (never more than one parameter, and usually
zero), but that's no reason to drop it. :)

 So it should be $@ (with quotes).

That'd be better, but my point still stands: the arguments to
base_src_unpack won't ever contain anything that can be expanded, so quoting
isn't strictly necessary, just a good idea.

Not that I'm against the quoting, of course.



Re: [gentoo-dev] Non-free software in Gentoo

2009-12-30 Thread Harald van Dijk
On Wed, Dec 30, 2009 at 08:51:18PM -0800, Greg KH wrote:
 On Wed, Dec 30, 2009 at 06:43:47AM -0500, Richard Freeman wrote:
  On 12/29/2009 07:52 PM, Greg KH wrote:
  No, the readme/copying is correct, it covers all of the code that runs
  on the processor as one body of work.  Firmware blobs are different in
  that they do not run in the same processor, and can be of a different
  license.
 
 
  Yes, but they don't cover everything in the tarball.  If I want to copy the 
  tarball, then I need to comply with the distribution license of the 
  tarball.  That license isn't clearly advertised.  It is a mix of a number 
  of licenses from GPL v2 to allowed-to-copy-without-modifications.
 
 No, you can copy that tarball just fine, and when you _distribute_ it,
 the GPLv2 applies to it.

Then I can distribute modified versions of the tarball, with altered
firmware, in direct violation of the license granted for that firmware,
just because it's allowed by the GPL? Seriously, you're saying the
license of the firmware doesn't matter.

  The processor that the software runs on is fairly irrelevant.
 
 Not true at all, why would you think that?  Since when does a license
 cross a processor boundry?

When I copy the Linux kernel sources, all files are copied by a single
processor. This isn't about running the kernel.

  In any case, I'm sure the kernel team will update the ebuild license string 
  appropriately - this is more of a debate for the LKML.  I just don't think 
  that they've done a good job with it.  Others are welcome to hold differing 
  opinions.  :)
 
 You don't think the gentoo kernel team (of which I think I'm the
 longest-term member), or the Linux kernel developers (of which I am the
 actual person who put those images in the kernel back in the late
 1990's after consulting many lawers, and Linus, on the issue) are doing
 a good job with this?

Please stop avoiding the issue. No one is saying the firmware is in
conflict with the GPL, or that distribution of the kernel is illegal.
The way it's distributed is fine. It's just not reflected properly in
Gentoo.



Re: [gentoo-dev] Preparing profiles for EAPI 3 IUSE strictness

2009-07-10 Thread Harald van Dijk
On Wed, Jul 08, 2009 at 05:02:10AM +0200, Arfrever Frehtes Taifersar Arahesis 
wrote:
 2009-07-07 01:01:11 Ciaran McCreesh napisał(a):
  ...
  IUSE_IMPLICIT=build debug
  
  Are people wanting to make those implicit?
 
 IMHO they shouldn't be implicit.

Agreed. They shouldn't be implicit, if only because you really want
emerge --newuse (or equivalent) to pick up on changes in USE=build or
USE=debug. Also, are USE dependencies possible with implicit IUSE? If
not, things like DEPEND=dev-lang/python[-build] would have to be
changed even though they're probably a good idea.



Re: [gentoo-dev] LC_ALL=C Set by default for portage

2009-03-08 Thread Harald van Dijk
On Sun, Mar 08, 2009 at 09:20:14PM +0100, Tomáš Chvátal wrote:
 Hi,
 lately i see that in our bugzilla most of the build reports are reported with 
 localized build logs which we dont understand. This leads to us asking the 
 user to run the emerge once more with LC_ALL=C.
 
 Wont it be nice to have this variable set by default in portage so users 
 reporting bugs report in English?

I can't speak for others, but I'd like to find and fix bugs with strange
locales, at least for the packages I maintain. If portage were to force
LC_ALL=C on me, I'd have a very hard time doing so.



Re: [gentoo-dev] LC_ALL=C Set by default for portage

2009-03-08 Thread Harald van Dijk
On Sun, Mar 08, 2009 at 09:27:20PM +0100, Alexis Ballier wrote:
 Moreover this would automagically solve the [a-z]  friends regexp
 failures; though that's still good QA to fix them but we wouldn't
 encounter them anymore.

We would encounter them when using the programs outside of portage, but
not when running the testsuite (if available) from within portage. It
would succeed in working around compile-time only bugs, but it would be
a major pain for locale bugs that can also cause problems at run time.



[gentoo-dev] Re: [gentoo-dev-announce] Last rites: app-editors/ted

2008-09-14 Thread Harald van Dijk
On Fri, Sep 12, 2008 at 10:17:12PM -0500, Jeremy Olexa wrote:
 # Jeremy Olexa [EMAIL PROTECTED] (13 Sep 2008)
 # Masked for removal in 60 days. Multiple issues, broke for some people. 
 Needs
 # maintainer. automagic deps. See bug #154997
 app-editors/ted

I've fixed the build and marked myself as maintainer; I don't want to
see this gone just yet.



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-util/eclipse-sdk: eclipse-sdk-3.2.1-r2.ebuild ChangeLog eclipse-sdk-3.3.1.1.ebuild

2008-01-23 Thread Harald van Dijk
On Wed, Jan 23, 2008 at 05:31:13PM -0500, Mike Frysinger wrote:
 On Wednesday 23 January 2008, Steve Long wrote:
  Or even: find blah -exec sed 'blah blah' +
 
 we specifically discourage `find -exec` in favor of `find -print0 | xargs -0` 
 because it sucks.

In what way? I'm not aware of any problems with find -exec ... {} + that
are handled any better by find -print0 | xargs -0. It's too bad that you
can only add {} + at the very end of the command, but that's just as
much a problem with xargs -0.

Your reply didn't make it clear, but you're aware of the difference
between -exec {} ; and -exec {} +, right? The former executes a single
command for every file, while the latter builds one long argument list
when possible, the same way xargs does.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-wm/sawfish: ChangeLog sawfish-1.3.2.ebuild sawfish-1.3_p20050816-r1.ebuild sawfish-1.3_p20060816.ebuild sawfish-1.3.20040120.ebuild sawfi

2008-01-22 Thread Harald van Dijk
On Tue, Jan 22, 2008 at 11:21:26PM -0500, Mike Frysinger wrote:
 On Tuesday 22 January 2008, Donnie Berkholz wrote:
  On 20:58 Tue 22 Jan , Harald van Dijk (truedfx) wrote:
 WANT_AUTOCONF=latest
 WANT_AUTOMAKE=latest
 
 redundant, please drop

Done.

 eaclocal || die
 eautoconf || die
 
 these things call die themselves ...
 an reason you're using these instead of 
 eautoreconf ?  aclocal/autoconf changes often imply having to regenerate 
 Makefile.in ...

sawfish doesn't use automake (except for aclocal), and eautoreconf used
to force automake. As it no longer has that problem, I've switched to
eautoreconf.

Thanks for the comments.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] rgb file specification

2008-01-19 Thread Harald van Dijk
On Sat, Jan 19, 2008 at 05:43:18PM +, Ferris McCormick wrote:
 This is random musing based based on perhaps my own problems.
   I need a local color.file to see well what I have going on, and
 current xorg ignores that.  Thus, at every build, there is in
 oscolor.c a constant I must change from 1 to 0.

While I don't have any need for your specific change, I do have the same
problem with some other unrelated patches for unrelated packages. Instead
of manually changing the code for every version bump, you can set up your
bashrc to define a post_src_unpack function, which checks if
${CATEGORY}/${PN} == x11-base/xorg-server, and if so, applies the patch.
solar's old bashrc which does this is still found at
http://dev.gentoo.org/~solar/bashrc, and I've put up the function as
I'm using it at http://dev.gentoo.org/~truedfx/bashrc.
-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Re: Watch out for license changes to GPL-3.

2007-07-12 Thread Harald van Dijk
On Thu, Jul 12, 2007 at 11:16:46PM +0300, Petteri Räty wrote:
 Ciaran McCreesh kirjoitti:
  
  As I understand it, merely using an eclass doesn't force GPL-2 on an
  ebuild because there's no linkage involved.
  
 
 This argument would make it possible to write apps using GPL-2 python
 libraries in !GPL-2 licenses

Correct, it does, just like it permits C applications with
GPL-incompatible licenses to link with GPL libraries, so long as this
linking is done by the end user and the application is not distributed
in its linked form. See for example the NVidia kernel module, or for a
somewhat different but similar example, cdrtools.
-- 
[EMAIL PROTECTED] mailing list



[gentoo-dev] Re: Watch out for license changes to GPL-3.

2007-07-12 Thread Harald van Dijk
 Correct, it does, just like it permits C applications with
 GPL-incompatible licenses to link with GPL libraries, so long as this
 linking is done by the end user and the application is not distributed
 in its linked form. See for example the NVidia kernel module, or for a
 somewhat different but similar example, cdrtools.
 
 Not true:
 
 cdrecord and all-1 programs in cdrtrools are 100% CDDL.
 
 mkisofs is a GPL project that links to non-GPL libraries.
 This is something that is no problem with the GPLv2 as long as the
 libraries are not derived from or written for GPL code.
 
 As the libraries mkisofs links with are older than mkisofs or at 
 least written independently and usage neutral, there is no problem 
 even with binaray redistribution of mkisofs.

http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

Neither the FSF nor you hold the copyright to mkisofs, but still, I'll
take the FSF's own interpretation over yours. If others believe you're
right, that's their choice.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: Watch out for license changes to GPL-3.

2007-07-12 Thread Harald van Dijk
On Fri, Jul 13, 2007 at 07:04:20AM +0200, Harald van Dijk wrote:
  Correct, it does, just like it permits C applications with
  GPL-incompatible licenses to link with GPL libraries, so long as this
  linking is done by the end user and the application is not distributed
  in its linked form. See for example the NVidia kernel module, or for a
  somewhat different but similar example, cdrtools.
  
  Not true:
  
  cdrecord and all-1 programs in cdrtrools are 100% CDDL.
  
  mkisofs is a GPL project that links to non-GPL libraries.
  This is something that is no problem with the GPLv2 as long as the
  libraries are not derived from or written for GPL code.
  
  As the libraries mkisofs links with are older than mkisofs or at 
  least written independently and usage neutral, there is no problem 
  even with binaray redistribution of mkisofs.
 
 http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs
 
 Neither the FSF nor you hold the copyright to mkisofs, but still, I'll
 take the FSF's own interpretation over yours. If others believe you're
 right, that's their choice.

Besides, as I recall, the decision for cdrkit was based on a
disagreement over the build system license, not the license of
libraries. Sorry, that's what I should've said, and that's all I
should've said; the rest is not relevant here.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Watch out for license changes to GPL-3.

2007-07-08 Thread Harald van Dijk
On Sun, Jul 08, 2007 at 03:50:56PM +0100, Ciaran McCreesh wrote:
 On Sun, 8 Jul 2007 16:46:57 +0200
 Dominique Michel [EMAIL PROTECTED] wrote:
  With the original statement GPL-2 alone, you have to take contact
  and get an authorisation to move from each single programmer that
  contributed code into the project.
 
 No, you have to get permission of the copyright holders. Which, in this
 case, is the Foundation.

Could you back that up, please? I was looking for something to confirm or
deny this myself, but didn't find anything.

I did, however, find
  http://dev.gentoo.org/~swift/blog/articles/20050506-foundation/

Quoting:
  Note that the Foundation would never change the license used for the
   code or documentation, if that could be set in stone that would be
   even better.

Is this still relevant?
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Watch out for license changes to GPL-3.

2007-07-08 Thread Harald van Dijk
On Sun, Jul 08, 2007 at 08:52:30PM +0200, Wulf C. Krueger wrote:
 On Sunday, 08. July 2007 20:15:31 Harald van Dijk wrote:
   No, you have to get permission of the copyright holders. Which, in
   this case, is the Foundation.
  Could you back that up, please? I was looking for something to confirm
  or deny this myself, but didn't find anything.
 
 It's in the copyright notice of every single ebuild:
 
 # Copyright 1999-2007 Gentoo Foundation
 
 Thus, the copyright owner/holder is the Gentoo Foundation.

If I write an ebuild today, why does it not say Copyright 2007? It's
because the copyright notice applies to skel.ebuild and/or the tree as a
whole. Whether it also applies to the individual contributions is what
I'm curious about.

 The Foundation 
 can therefore decide to change the licence.

If the Foundation is the copyright holder, then agreed, it can.

Note that the Foundation would never change the license used for the
 code or documentation, if that could be set in stone that would be
 even better.
  Is this still relevant?
 
 Hopefully not as it is, stated as simple as that, not very wise. 
 
 It's probably *meant* to say that the Foundation will never switch to a 
 closed-source model but it shouldn't rule out switching to GPL-3 should 
 that turn out to be desirable.

If you can give a clear way to separate licenses which should be
allowable, from those which should not, then please share. Would it mean
that the Foundation might change to the CDDL, for example? If not, why
not?
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Watch out for license changes to GPL-3.

2007-07-08 Thread Harald van Dijk
On Sun, Jul 08, 2007 at 09:42:49PM +0200, Wulf C. Krueger wrote:
 On Sunday, 08. July 2007 21:12:38 Harald van Dijk wrote:
   # Copyright 1999-2007 Gentoo Foundation
   Thus, the copyright owner/holder is the Gentoo Foundation.
  If I write an ebuild today, why does it not say Copyright 2007? 
 
 Probably because different legal systems require different formats of the 
 copyright notice. Over here, copyright 2007 would be fully sufficient.

If the copyright notice doesn't apply at least in part to skel.ebuild
and/or the whole tree, it's not possible for Copyright 1999-2007 to be
required anywhere.

  It's because the copyright notice applies to skel.ebuild and/or the 
  tree as a whole. Whether it also applies to the individual 
  contributions is what I'm curious about.
 
 TTBOMK, it applies to each and every individual ebuild. The tree itself 
 doesn't seem to have a separate copyright notice and I see no need for it 
 either.

As I recall from previous discussions, the tree as a whole is
copyrighted, essentially because it is not clear whether the majority of
ebuilds are copyrightable by themselves.

 As for contributions without a clear copyright notice, it would, IMHO, be 
 best to make sure (e. g. by adding some legal blah to Bugzilla) they're 
 original works to be licenced under (currently) the GPL-2 or derived from 
 a product with a compatible licence by the contributor.

If the Foundation needs the right to relicense code, this should also be
made clear (e.g. in the legal blah that would be added to Bugzilla).

  If you can give a clear way to separate licenses which should be
  allowable, from those which should not, then please share. 
 
 Sorry, that's both beyond my legal knowledge and my sphere of interest. :)
 
 I think we all agree that ebuilds should be released under an open source 
 licence. That's good enough for me. :-)

I can agree with that. What I care about is the right to decide on the
license for code that is entirely written by myself. I don't really care
how the tree is licensed.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] glibc-2.6 / gcc-4.2 going into ~arch

2007-07-06 Thread Harald van Dijk
On Fri, Jul 06, 2007 at 12:08:20AM -0400, Mike Frysinger wrote:
 get your waaait dont do it votes in now, i plan on pushing:
 glibc-2.6 ~amd64 ~ppc ~ppc64 ~x86
 gcc-4.2.0 ~amd64 ~x86
 in the next day or so

Why 4.2.0 rather than 4.2.1 RC1? Are there problems with the RC, or are
all important patches since 4.2.0 added by the ebuild already?
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Nero-3.0.0.0 license needs RESTRICT=fetch ?

2007-07-06 Thread Harald van Dijk
On Fri, Jul 06, 2007 at 03:09:23PM +0300, Samuli Suominen wrote:
 Missed something before.. But after reading this it leads me to
 conclusion nero-3.0.0.0 needs RESTRICT=fetch? Would someone be kind
 enough to take a look for me to get a second opinion as it might be out
 of context / I'm overlooking something. Now, it's RESTRICT=mirror.

It doesn't need RESTRICT=fetch; there is no assumption that you agree to
the license just by downloading the software. Installing it, however,
does apparently require acceptance of the license, so eutils.eclass's
check_license function should probably be used.

 Also, I failed to see such ACCEPT button in their homepage.. but I see
 one after starting it(!).
 
 ${PORTDIR/licenses/Nero
 
 snip
 
 B.BY INSTALLING THE DOWNLOADED SOFTWARE, YOU ARE AGREEING TO BE BOUND
 BY THE TER MS OF THIS AGREEMENT BY MEANS OF CLICKING THE “ACCEPT”
 BUTTON ON THE WEBSITE. IF YOU DO NOT AGREE TO THE TERMS OF THIS
 AGREEMENT, PROMPTLY UNINSTALL AND DELETE THE SOFTWARE AND ALL THE
 ACCOMPANYING ITEMS (INCLUDING DOCUMENTATION OR MANUALS).
 
 /snip
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Nero-3.0.0.0 license needs RESTRICT=fetch ?

2007-07-06 Thread Harald van Dijk
On Fri, Jul 06, 2007 at 07:40:47PM +0200, Jakub Moc wrote:
 Mike Frysinger napsal(a):
  On Friday 06 July 2007, Jakub Moc wrote:
  Harald van Dijk napsal(a):
  so eutils.eclass's check_license function should probably be used.
  Broken until Bug 17367 is implemented.
  
  the same exact thing could be said for everything using `built_with_use`
 
 This check in this particular ebuild won't add anything useful; will
 just bug users redundantly to accept a license which they'll have to
 accept once again on the first run. Kinda miss the point here.

And what if they decide they don't accept the license on the first run?
They'll already have installed the software, which requires acceptance
of the license. Please don't ignore silly license requirements just
because it's convenient.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Nero-3.0.0.0 license needs RESTRICT=fetch ?

2007-07-06 Thread Harald van Dijk
On Fri, Jul 06, 2007 at 08:08:13PM +0200, Torsten Rehn wrote:
 On Friday 06 July 2007 19:56, Harald van Dijk wrote:
  And what if they decide they don't accept the license on the first run?
  They'll already have installed the software, which requires acceptance
  of the license.
 
 No violation here: [...] IF YOU DO NOT AGREE TO THE TERMS OF THIS
 AGREEMENT, PROMPTLY UNINSTALL AND DELETE THE SOFTWARE [...]

That only means uninstalling and deleting the software means you won't
be in further violation of the license, I believe, but I would not be
entirely surprised if your interpretation turns out correct.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] irregular metdata.xml check

2007-06-11 Thread Harald van Dijk
On Mon, Jun 11, 2007 at 01:41:30AM +0200, Thilo Bangert wrote:
 Herds with no email
 ===
 
 As robbat2 points out, in order to allow for automatic bug assignment all 
 herds need to have an email address. The following herds do not have an 
 email address specified in herds.xml.
 
 herd without email: lang-misc

Fixed now.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [PMS] Version Naming Clarification

2007-06-07 Thread Harald van Dijk
On Thu, Jun 07, 2007 at 09:31:44PM +0100, Stephen Bennett wrote:
 On Thu, 7 Jun 2007 19:42:45 +0200
 Marius Mauch [EMAIL PROTECTED] wrote:
 
  Thing is: if you see sys-fs/ntfs-3g, is that an atom or a CPV? You
  don't know unless you actually check the tree.
 
 Is there any place in the tree where a dep atom and a CPV are both
 accepted?

An ebuild's PROVIDE list.

 Should there be?

Probably not.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [PMS] Version Naming Clarification

2007-06-07 Thread Harald van Dijk
On Thu, Jun 07, 2007 at 09:40:20PM +0100, Ciaran McCreesh wrote:
 On Thu, 7 Jun 2007 22:33:21 +0200
 Harald van Dijk [EMAIL PROTECTED] wrote:
  An ebuild's PROVIDE list.
 
 Nnnnope. Not legal.

The question was Is there any place in the tree where a dep atom and a
CPV are both accepted? Look at the last word.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Living in a bubble [gentoo-proctor] Warning^2

2007-06-05 Thread Harald van Dijk
On Tue, Jun 05, 2007 at 11:13:25PM +0200, Wernfried Haas wrote:
 On Tue, Jun 05, 2007 at 09:44:23PM +0100, Roy Bamford wrote:
  Please step back, take a deep breath and avoid posting to this thread 
  for 24 hours.
 
 Folks, while we're cutting some slack to the people replying
 somewhere else in the thread because they may not have gotten the mail
 by Roy yet (and that time frame should be over any time now, too),
 replying to this mail clearly shows you are not following our call to
 do so.
 
 So far we have temporarily suspended both ciaran's and geoman's account
 from posting and encourage everyone to do as Roy initially suggested.

Please also suspend your own account. You're clearly replying to Roy's
message. It doesn't matter that you're not contributing to the original
discussion, because after Roy's message, neither did Ciaran. Feel free
to suspend my account as well.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Eigen and GPL-2 exception - is a new licence required?

2007-05-12 Thread Harald van Dijk
On Sat, May 12, 2007 at 02:27:20PM +0200, Carsten Lohrke wrote:
 No. LICENSE=GPL-2 some-exception suffices.

No, that means something completely different. It means that you should
install the software only if you find both the GPL-2 and the exception
acceptable, rather than if you find the combination of the GPL-2 with
the exception acceptable.

A new license should be added. See the GMGPL and
GPL-2-with-linking-exception licenses for an example (especially GMGPL).
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Eigen and GPL-2 exception - is a new licence required?

2007-05-12 Thread Harald van Dijk
On Sat, May 12, 2007 at 03:13:02PM +0200, Carsten Lohrke wrote:
 On Samstag, 12. Mai 2007, Harald van Dijk wrote:
  On Sat, May 12, 2007 at 02:27:20PM +0200, Carsten Lohrke wrote:
   No. LICENSE=GPL-2 some-exception suffices.
 
  No, that means something completely different. It means that you should
  install the software only if you find both the GPL-2 and the exception
  acceptable, rather than if you find the combination of the GPL-2 with
  the exception acceptable.
 
 And that's why it's not different. Such exceptions usually don't stand for 
 themselves, but relate to the license they're bound to. Can be matter of the 
 wording, though. 

Do you need to accept the unmodified GPL-2 for software licensed under
the GPL-2 plus exception? No? Then GPL-2 does not belong in LICENSE,
unless in a || group.

 I consider it quite stupid adding extra licenses for such exceptions.

A generic license could be used, which points to the packages for the
exact license.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Eigen and GPL-2 exception - is a new licence required?

2007-05-12 Thread Harald van Dijk
On Sat, May 12, 2007 at 04:21:52PM +0200, Carsten Lohrke wrote:
 On Samstag, 12. Mai 2007, Harald van Dijk wrote:
  Do you need to accept the unmodified GPL-2 for software licensed under
  the GPL-2 plus exception? No? Then GPL-2 does not belong in LICENSE,
  unless in a || group.
 
 Of course you accept the GPL plus the added exception. Just because an 
 exception exists, it does not become a completely different license.

Of course you accept the GPL plus the added exception, *if* you accept
the GPL. If you don't accept the GPL, however, you can still
legitimately accept the GPL with the exception.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] It seems our ChangeLogs are quite borked

2007-03-24 Thread Harald van Dijk
On Sat, Mar 24, 2007 at 12:29:06AM +0200, Petteri Räty wrote:
 I got annoyed enough about emerge -pl not working when people don't use
 echangelog like:
 
 # $Header: /var/cvsroot/gentoo-x86/x11-libs/libXinerama/ChangeLog,v 1.27
 2007/03/22 02:18:21 joshuabaergen Exp $
 
   22 Mar 2007; Joshua Baergen [EMAIL PROTECTED]
   +libXinerama-1.0.2.ebuild:
   Version bump.  Includes new documentation and some small code tweaks.
 
 
 Because it's missing *libXinerama-1.0.2 (22 Mar 2007)  emerge -pl does
 not work. This lead me to write the code to detect these cases:
 
 https://bugs.gentoo.org/show_bug.cgi?id=171962
 
 You can find the results here:
 http://dev.gentoo.org/~betelgeuse/changelogs_with_bad_new_revision_entries.txt
 
 Most of these probably probably date back to time before echangelog but
 feel free to fix your packages any way :)

It complains about the fpc changelog, for 2.0.0-r1, but it seems okay to me:

[...]
  17 Dec 2005; Carsten Lohrke [EMAIL PROTECTED] +fpc-2.0.0-r1.ebuild:
  restore ebuild for dev-lang/lazarus

*fpc-2.0.2 (17 Dec 2005)

  17 Dec 2005; Carsten Lohrke [EMAIL PROTECTED]
  -fpc-1.9.5_pre20040820.ebuild, -fpc-2.0.0_rc2.ebuild, -fpc-2.0.0.ebuild,
  -fpc-2.0.0-r1.ebuild, +fpc-2.0.2.ebuild:
  version bump

  14 Oct 2005; Gustavo Zacarias [EMAIL PROTECTED] fpc-2.0.0-r1.ebuild:
  Added sparc support and keyworded accordingly

  15 Sep 2005; Marcelo Goes [EMAIL PROTECTED]
  fpc-1.9.5_pre20040820.ebuild:
  Add app-arch/unzip to DEPEND for bug 69831.

  24 Jul 2005; Herbie Hopkins [EMAIL PROTECTED] fpc-2.0.0-r1.ebuild:
  Added amd64 support thanks to Matthias Jansen.

*fpc-2.0.0-r1 (03 Jul 2005)
[...]

Or should the *fpc-2.0.0-r1 line be repeated?

Also, would it be possible to sort the packages in some way?


pgphE8QDONytz.pgp
Description: PGP signature


Re: [gentoo-dev] RFC Package name additions

2007-03-17 Thread Harald van Dijk
On Fri, Mar 16, 2007 at 09:24:33PM -0400, Mike Frysinger wrote:
 On Friday 16 March 2007, Miroslav Šulc (fordfrog) wrote:
  Just a note to this. I'm co-maintainer of netbeans ebuild. Netbeans does
  milestone releases. These are pretty stable and usable since milestone 7
  of netbeans 6.0 with many new features that make sense to use the
  milestone releases. I have to name the ebuilds netbeans-6.0_alpha7 etc.
  though I was assured by mkt guy from Sun it is not yet alpha quality. It
  would be fair to the upstream and to users to not use _alpha because it
  is not alpha but there's no appropriate choice available.
 
 i would use _p# over _alpha#

6.0_p7 is considered a higher version than 6.0, right? That will probably
cause problems in the future. _pre# may be a good choice, though.


pgpAEes51I0pb.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Little respect towards Daniel please

2007-03-05 Thread Harald van Dijk
On Mon, Mar 05, 2007 at 03:25:31PM +, Steve Long wrote:
 Ioannis Aslanidis wrote:
 
  Maybe if Ciaran recognized his past faults, begged pardon and promised
  to be kinder from now and on, everything would be easier for everyone,
  everything would calm down.
  
 I share your dream ;)
 
  Ciaran McCreesh wrote:
  On Sun, 04 Mar 2007 14:15:36 -0500 William L. Thomson Jr.
  [EMAIL PROTECTED] wrote:
  So I we can cut him some slack, and we should all have some level of
  respect, at least in public, towards the father, creator, and founder
  of Gentoo.
  
  What kind of response do you think anyone else would have received had
  they started repeatedly attacking a project when they didn't even know
  what that project was, repeatedly tried to interfere with the
  management of a project when they don't know who is involved with or
  managing said project, repeatedly posted all kinds of outright lies
  after having been told that something was untrue and repeatedly resorted
  to ad hominem attacks in a technical discussion?
  
 Bloody hell where did all that come from? Am I missing something, cos I
 certainly haven't seen that on the dev m-l. Maybe it's a core/ irc thing,
 but afaic in the public domain drobbins hasn't done the above.

drobbins has repeatedly claimed that PMS is not a Gentoo project, that
Ciaran is leading PMS, that Ciaran's involvement with PMS requires
developer status, that Gentoo projects require Gentoo copyright, and
more. Having read some of his past and later messages, I don't doubt his
intentions are good, but from this thread alone I initially got the same
impression Ciaran did, except I did not see any actual ad hominem's from
drobbins's side, myself. I did see Ciaran asking drobbins to stop with
them in reply to what he apparently considered one.


pgpCvfkIkMvZj.pgp
Description: PGP signature


Re: [gentoo-dev] Last rites: net-p2p/mnet

2007-02-14 Thread Harald van Dijk
On Wed, Feb 14, 2007 at 08:47:20PM +0100, Raúl Porcel wrote:
 # Raúl Porcel [EMAIL PROTECTED] (14 Feb 2007)
 # Doesn't build, upstream dead, network dead, bug 1666887
 # Pending removal 13 Mar 2007
 net-p2p/mnet

That's bug #166887; mnet may be broken, but it's not the incarnation of
evil. :-)


pgpDZoiG6kCjv.pgp
Description: PGP signature


Re: [gentoo-dev] Network configuration and bash

2007-02-09 Thread Harald van Dijk
On Fri, Feb 09, 2007 at 09:29:04AM +, Roy Marples wrote:
 On Fri, 09 Feb 2007 01:03:04 -0800
 Donnie Berkholz [EMAIL PROTECTED] wrote:
 
  Jakub Moc wrote:
   Mike Frysinger napsal(a):
   On Thursday 08 February 2007, Roy Marples wrote:
   The actual scripts themselves can be re-worked if they need to be
   - this problem only when the arrays are used in config files.
   i guess my point was i think we really need to be consistent
   here ... either arrays are OK for init.d scripts or they're not OK
  
   did you get a chance to see how hard it would be to integrate the
   bash array code ?
   
   sys-apps/855resolution and sys-apps/915resolution use arrays in
   config files, and there's not much way around it ATM if you want to
   replace multiple BIOS modes...
   
   snip
   # to replace more than one mode do something like this
   #replace=(
   # 4d 1280 768 24
   # 5c 1400 1050 16
   #)
  
  How about this?
  
  replace=
  '4d 1280 768 24'
  '5c 1400 1050 16'
  
  
 
 Actually, that may work better than my delimited with ; approach.
 We could then do
 
 eval set -- ${replace}
 for x in $@ ; do
  
 done

That works with your ; approach too, as well as with the
newline-separated approach:

replace=
4d 1280 768 24
5c 1400 1050 16


IFS=';
'
#set -f
set -- ${replace}
#set +f
unset IFS

for x ; do
  
done


pgprrqWQ2pIf0.pgp
Description: PGP signature


Re: [gentoo-dev] Network configuration and bash

2007-02-09 Thread Harald van Dijk
On Fri, Feb 09, 2007 at 11:49:05AM +, Roy Marples wrote:
 On Fri, 9 Feb 2007 12:05:52 +0100
 Harald van Dijk [EMAIL PROTECTED] wrote:
   One issue is that any valid character is allowed in WPAPSK,
   including ;
  
  Good point, but excluding newline, right? I can't try it, but rt2500's
  own settings file format does not allow for newline in WPAPSK.
 
 No it doesn't, but the actual specification for IEEE 802.11 allows ANY
 character in SSID and keys - newlines, tabs, ;, etc.

Okay, thanks for the info. The only easy alternative I can think of is
using printf %b, but IIRC printf is not universally supported yet, so
yeah, eval is probably the only thing that will offer all the needed
options. I still hope you can get some decent sanity checks for it.

 Just because the rt2500 proprietary config doesn't allow it doesn't
 mean we shouldn't either.

Proprietary?


pgp512noaYxaT.pgp
Description: PGP signature


Re: [gentoo-dev] ecompress heads up

2007-01-26 Thread Harald van Dijk
On Fri, Jan 26, 2007 at 03:19:23AM -0500, Mike Frysinger wrote:
 the new version of portage has customizable compression ... this is cool as 
 now people can do bzip/gzip/whatever
 
 the downside is that it breaks with packages that assume everything is 
 compressed with gzip ... so here is a list of common things ebuilds should 
 not be doing:
 doman foo.1.gz
 dosym foo.1.gz /usr/share/man/man1/fooie.1.gz
 dodoc README.gz

I'm asking, hoping for an explicit answer: so if upstream provides
gzip-compressed files, should ebuilds gunzip them, install them, and
then let portage recompress them?
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT

2007-01-12 Thread Harald van Dijk
On Fri, Jan 12, 2007 at 08:00:18AM +, Ciaran McCreesh wrote:
 On Fri, 12 Jan 2007 08:48:37 +0100 Harald van Dijk [EMAIL PROTECTED]
 wrote:
 | On Fri, Jan 12, 2007 at 07:15:53AM +, Ciaran McCreesh wrote:
 |  On Fri, 12 Jan 2007 07:55:00 +0100 Harald van Dijk
 |  [EMAIL PROTECTED] wrote:
 |  | When does upstream get to install arbitrary content on my
 |  | computer? Upstream's build system gets to write stuff to $D, but
 |  | not to $ROOT (malice aside). The move to $ROOT, and anything
 |  | after that, is the ebuild writer's and the package manager's
 |  | responsibility.
 |  
 |  Well that's the point. We're talking malice here,
 | 
 | You're talking malice here. I don't think everyone else is.
 
 Why else would a user want to refuse ebuilds that set userpriv?

As a safeguard against accidental mistakes by upstream.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT

2007-01-12 Thread Harald van Dijk
On Fri, Jan 12, 2007 at 08:30:49AM +, Ciaran McCreesh wrote:
 On Fri, 12 Jan 2007 09:11:11 +0100 Harald van Dijk [EMAIL PROTECTED]
 wrote:
 |  Why else would a user want to refuse ebuilds that set userpriv?
 | 
 | As a safeguard against accidental mistakes by upstream.
 
 But ebuilds setting RESTRICT=userpriv are explicitly saying we can't
 use userpriv not because of an accident but because the build system
 really needs elevated privs. If a user wants to be protected against
 accidental mistakes, they set FEATURES=userpriv and accidental mistakes
 are caught whilst intentional requirements are let through.

Accidental mistakes in packages for which the ebuilds specify
RESTRICT=userpriv are also let through. ACCEPT_RESTRICT=-userpriv (or
whatever) would mean I want to be protected against accidental
mistakes, even if it means I can't install some software.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT

2007-01-12 Thread Harald van Dijk
On Fri, Jan 12, 2007 at 10:11:59AM +, Ciaran McCreesh wrote:
 On Fri, 12 Jan 2007 10:53:02 +0100 Harald van Dijk [EMAIL PROTECTED]
 wrote:
 | ACCEPT_RESTRICT=-userpriv (or whatever) would mean I want to be
 | protected against accidental mistakes, even if it means I can't
 | install some software.
 
 Which is a silly and arbitrary distinction to make, and users should
 not be encouraged to do so.

I don't think anyone was planning on encouraging people to mess with
ACCEPT_RESTRICT if it gets implemented.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT

2007-01-12 Thread Harald van Dijk
On Fri, Jan 12, 2007 at 11:55:44AM +, Ciaran McCreesh wrote:
 On Fri, 12 Jan 2007 12:41:27 +0100 Harald van Dijk [EMAIL PROTECTED]
 wrote:
 | I don't think anyone was planning on encouraging people to mess with
 | ACCEPT_RESTRICT if it gets implemented.
 
 Implementing it *is* encouraging people to mess with it.

Just like people are encouraged to use FEATURES=noauto noclean?
Implementing it is not encouraging people to mess with it.

As for the legitimate use, I won't try to convince you that there are
legitimate uses, but rather, even if it is silly, what does it matter to
you?
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT

2007-01-12 Thread Harald van Dijk
On Fri, Jan 12, 2007 at 12:19:18PM +, Ciaran McCreesh wrote:
 On Fri, 12 Jan 2007 13:04:21 +0100 Harald van Dijk [EMAIL PROTECTED]
 wrote:
 | On Fri, Jan 12, 2007 at 11:55:44AM +, Ciaran McCreesh wrote:
 |  On Fri, 12 Jan 2007 12:41:27 +0100 Harald van Dijk
 |  [EMAIL PROTECTED] wrote:
 |  | I don't think anyone was planning on encouraging people to mess
 |  | with ACCEPT_RESTRICT if it gets implemented.
 |  
 |  Implementing it *is* encouraging people to mess with it.
 | 
 | Just like people are encouraged to use FEATURES=noauto noclean?
 | Implementing it is not encouraging people to mess with it.
 
 FEATURES has legitimate values. The feature as a whole is useful, even
 if some of the options have very restricted target audiences.

So if ACCEPT_* were implemented in a way that lets you write
ACCEPT=keyword:~x86 -license:QPL-1.0 restrict:sandbox
you'd have no problem? After all, ACCEPT as a whole is useful, right?

You can't group all features together in your logic, just because they
share a variable. Please reconsider the point I tried to make.

 | As for the legitimate use, I won't try to convince you that there are
 | legitimate uses, but rather, even if it is silly, what does it matter
 | to you?
 
 It matters in that there's even more time being spent going off on
 completely the wrong track that would be of more use elsewhere.

ACCEPT_RESTRICT is trivial to implement and to maintain, even moreso if
you combine the code for it with that for ACCEPT_LICENSE. More time has
been spent on this thread than would have to be on the code...
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT

2007-01-12 Thread Harald van Dijk
On Fri, Jan 12, 2007 at 12:46:58PM +, Ciaran McCreesh wrote:
 On Fri, 12 Jan 2007 13:30:11 +0100 Harald van Dijk [EMAIL PROTECTED]
 wrote:
 |  FEATURES has legitimate values. The feature as a whole is useful,
 |  even if some of the options have very restricted target audiences.
 | 
 | So if ACCEPT_* were implemented in a way that lets you write
 | ACCEPT=keyword:~x86 -license:QPL-1.0 restrict:sandbox
 | you'd have no problem? After all, ACCEPT as a whole is useful, right?
 
 If ACCEPT were implemented that way, and there were no additional code
 involved in making restrict work in it, then it would be reduced from
 silly misfeature to something that works by fluke but that you
 shouldn't do.

FEATURES=noauto noclean do not work by fluke. I'll ask you a second
time to try to reconsider the point I was making.

 |  | As for the legitimate use, I won't try to convince you that there
 |  | are legitimate uses, but rather, even if it is silly, what does
 |  | it matter to you?
 |  
 |  It matters in that there's even more time being spent going off on
 |  completely the wrong track that would be of more use elsewhere.
 | 
 | ACCEPT_RESTRICT is trivial to implement and to maintain, even moreso
 | if you combine the code for it with that for ACCEPT_LICENSE. More
 | time has been spent on this thread than would have to be on the
 | code...
 
 And what about the time spent arguing with users who start demanding
 that your package stop depping upon some random other package that
 happens to need userpriv turned off?

I'd like to give users a little bit more credit than to ask for
dependencies on required packages to be dropped. (And as for
dependencies on non-required packages, generally speaking, they should
already be optional dependencies, or not dependencies at all.)

 And what about the time spent
 explaining to everyone why fetch can't be used in ACCEPT_RESTRICT to
 get the results they expect

Presumably, the default for ACCEPT_RESTRICT would include all possible
values, so the case to consider is ACCEPT_RESTRICT=-fetch, which I can
only imagine to work in one way.

 and why userpriv and sandbox are not
 dangerous?
 
 Just because a feature *can* be added doesn't mean it *should*, no
 matter how trivial it is.

Correct, that reason by itself is not enough. My reply specifically
addressed your comment, it was not a complete argument /for/
ACCEPT_RESTRICT.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT

2007-01-12 Thread Harald van Dijk
On Fri, Jan 12, 2007 at 05:19:02PM +, Ciaran McCreesh wrote:
 On Fri, 12 Jan 2007 14:05:49 +0100 Harald van Dijk [EMAIL PROTECTED]
 wrote:
 | On Fri, Jan 12, 2007 at 12:46:58PM +, Ciaran McCreesh wrote:
 |  On Fri, 12 Jan 2007 13:30:11 +0100 Harald van Dijk
 |  [EMAIL PROTECTED] wrote:
 |  |  FEATURES has legitimate values. The feature as a whole is
 |  |  useful, even if some of the options have very restricted target
 |  |  audiences.
 |  | 
 |  | So if ACCEPT_* were implemented in a way that lets you write
 |  | ACCEPT=keyword:~x86 -license:QPL-1.0 restrict:sandbox
 |  | you'd have no problem? After all, ACCEPT as a whole is useful,
 |  | right?
 |  
 |  If ACCEPT were implemented that way, and there were no additional
 |  code involved in making restrict work in it, then it would be
 |  reduced from silly misfeature to something that works by fluke
 |  but that you shouldn't do.
 | 
 | FEATURES=noauto noclean do not work by fluke. I'll ask you a second
 | time to try to reconsider the point I was making.
 
 And noauto and noclean do have specific genuine use, so it's not a
 fair comparison.

Again irrelevant to the point, since regardless of whether they have
some small valid use, they should not be recommended to users.

 |  And what about the time spent arguing with users who start demanding
 |  that your package stop depping upon some random other package that
 |  happens to need userpriv turned off?
 | 
 | I'd like to give users a little bit more credit than to ask for
 | dependencies on required packages to be dropped. (And as for
 | dependencies on non-required packages, generally speaking, they should
 | already be optional dependencies, or not dependencies at all.)
 
 Except that Portage doesn't do automatic dependency disabling for
 non-required packages that are masked.

Okay, that's a fair enough point; it's possible to make portage handle
that case nicer, and if ACCEPT_* (it also applies to LICENSE) has to
wait until it does, I won't object.

 |  And what about the time spent
 |  explaining to everyone why fetch can't be used in ACCEPT_RESTRICT to
 |  get the results they expect
 | 
 | Presumably, the default for ACCEPT_RESTRICT would include all possible
 | values, so the case to consider is ACCEPT_RESTRICT=-fetch, which I can
 | only imagine to work in one way.
 
 You miss the point (I explained it elsewhere in the thread). Turning on
 ACCEPT_RESTRICT=fetch will not behave the sane way if a
 fetch-restricted package has had all its ${A} things downloaded. It
 will still show up as masked, which is not desired behaviour.

I'm not sure what you mean.

With ACCEPT_RESTRICT=fetch, portage should behave as it currently does:
be quiet if the sources are available, complain if they're not. If
portage would always complain, yeah, that's bad, but I don't see why it
would do that.

With ACCEPT_RESTRICT=-fetch, you tell it you don't want packages with
RESTRICT=fetch, so portage /should/ complain regardless of whether the
sources are available.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT

2007-01-12 Thread Harald van Dijk
On Fri, Jan 12, 2007 at 07:12:00PM +, Ciaran McCreesh wrote:
 On Fri, 12 Jan 2007 18:42:20 +0100 Harald van Dijk [EMAIL PROTECTED]
 | With ACCEPT_RESTRICT=-fetch, you tell it you don't want packages with
 | RESTRICT=fetch, so portage /should/ complain regardless of whether the
 | sources are available.
 
 Which is my point -- that's a stupid thing to request. A sensible thing
 to request would be mask anything that will require me to fetch
 something manually.

It's not a stupid thing to request to install only packages that allow
you to emerge -e world if / gets corrupted.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT

2007-01-12 Thread Harald van Dijk
On Sat, Jan 13, 2007 at 05:45:31AM +, Ciaran McCreesh wrote:
 On Sat, 13 Jan 2007 02:05:45 +0100 Harald van Dijk [EMAIL PROTECTED]
 wrote:
 | On Fri, Jan 12, 2007 at 07:12:00PM +, Ciaran McCreesh wrote:
 |  On Fri, 12 Jan 2007 18:42:20 +0100 Harald van Dijk
 |  [EMAIL PROTECTED]
 |  | With ACCEPT_RESTRICT=-fetch, you tell it you don't want packages
 |  | with RESTRICT=fetch, so portage /should/ complain regardless of
 |  | whether the sources are available.
 |  
 |  Which is my point -- that's a stupid thing to request. A sensible
 |  thing to request would be mask anything that will require me to
 |  fetch something manually.
 | 
 | It's not a stupid thing to request to install only packages that allow
 | you to emerge -e world if / gets corrupted.
 
 Huh? No, you're grasping at straws here. If / gets corrupted then
 you're screwed.

I have personally had my / corrupted more than once, and I have been
able to re-install everything without a livecd more than once too.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT

2007-01-11 Thread Harald van Dijk
On Fri, Jan 12, 2007 at 07:15:53AM +, Ciaran McCreesh wrote:
 On Fri, 12 Jan 2007 07:55:00 +0100 Harald van Dijk [EMAIL PROTECTED]
 wrote:
 | When does upstream get to install arbitrary content on my computer?
 | Upstream's build system gets to write stuff to $D, but not to $ROOT
 | (malice aside). The move to $ROOT, and anything after that, is the
 | ebuild writer's and the package manager's responsibility.
 
 Well that's the point. We're talking malice here,

You're talking malice here. I don't think everyone else is.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] debug.eclass is dead now

2007-01-05 Thread Harald van Dijk
On Fri, Jan 05, 2007 at 07:19:30AM -0500, Caleb Tennis wrote:
 
  Don't use debug.eclass.
 
 Pardon what may be a stupid question here, but what's the fix/workaround for 
 using
 the debug.eclass ?

Simply stop using it. Drop it from the inherit line, and if your ebuild
has a legitimate use of the debug flag, put that in IUSE. There is no
need to restore the functionality that the eclass provided, since that
didn't belong in ebuilds/eclasses in the first place.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GPL-2 vs GPL-2+

2006-12-22 Thread Harald van Dijk
On Sat, Dec 23, 2006 at 12:10:44AM +0100, Diego 'Flameeyes' Pettenò wrote:
 On Friday 22 December 2006 23:43, Alec Warner wrote:
  Say I approve only GPL-3 packages (cause' I hate patents, and I dislike
  having a working system too!).  This would encompass anything strictly
  GPL-3 and also anything GPL-2+ (which would then be under 3 at my option
  in this case).
 Not really, as GPL-2 does not disallow DRM (_if_ GPL-3 will disallow them), 
 so 
 if there's a software licensed under GPL-2+ that uses DRM, it couldn't be 
 used under GPL-3 terms even at your option.

I believe you're misunderstanding the DRM issue. There is nothing in the
GPL-3 draft that forbids DRM, except insofar as the DRM prevents the user
from exercising his/her GPL-granted rights, and it is not likely that
the final GPL-3 will forbid it. In plain English, as long as you're able
to modify, compile, and run the code, it's fine as far as the GPL is
concerned. And Gentoo being a source-based distro, you can already know
you're able to do all that.

It's also possible that I'm misunderstanding your message, of course. If
I am, would you please clarify?
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] linking with ld or gcc?

2006-12-08 Thread Harald van Dijk
On Fri, Dec 08, 2006 at 06:40:40PM +0100, Andreas Vinsander wrote:
 Harald van Dijk wrote:
  On Sun, Nov 05, 2006 at 06:47:07PM +0300, Peter Volkov (pva) wrote:
  Hello.
 
  Short question: What shall we use to link libraries/programs: gcc or ld?
  Why?
 
  A bit longer story: I have a problem during linking of wepattack on
  amd64 systems. Linking stage issues warning:
 
  $ x86_64-pc-linux-gnu-ld  -o wepattack wepattack.o rc4.o wepfilter.o
  log.o modes.o misc.o verify.o keygen.o -lpcap -lz -lcrypto
  ld: warning: cannot find entry symbol _start; defaulting to
  00400e10
 
  And resulted file is not executable. In google I found the most of
  tutorials/howtos suggest to link with gcc but some programs still use
  LD. From ld man page it's clear that it should link the program but this
  is not working. So what is the right way to do that? Why?
  
  Link using gcc unless your program is a very special case. _start is defined
  in /usr/lib/crt1.o (may be slightly different on amd64), and that as well as
  other object files typically required by every program will be pulled in by
  gcc.
 
 Doing some reading up on the list... thus the late answer.
 
 gnu make provides you with the variables/macros that is usable for
 linking. Look for 'LINK.c' etc in the output of 'make -p -f/dev/null'.
 It might be wise to use them instead of the actual linker since you
 might wanna port your project to some other compiler etc in the future.

With any compiler in a Unix-like environment, and many compilers in
other environments, you can be sure it can be used to link. It's
extremely common existing practice which has even been standardised by
POSIX (`man 3p c99`, but the same was specified for the cc and c89
utilities). Assuming GNU make is used is far more likely to cause
problems when porting to some other platform.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Herds, take your marks...get set...take stuff!

2006-12-01 Thread Harald van Dijk
On Fri, Dec 01, 2006 at 10:48:03AM -0800, James Ausmus wrote:
 On 12/1/06, Philip Webb [EMAIL PROTECTED] wrote:
 061201 Alec Warner wrote:
  If you look at
http://spaceparanoids.org/gentoo/gpnl/qa.php?q=no-herd-maintainer
  you will see a list of packages with NO maintainer and NO herd.
  For users, if you see something you use,
  you may become a proxy-maintainer for it.
 snipe
 Perhaps you should tell users briefly what proxy-maintenance involves.
 
 
 So depending on what exactly is involved with proxy-maintenance, I
 could be interested in taking care of some or (up to) all of the
 following:
 
 dev-lang/fpc-source

This should just go away. It's been replaced by dev-lang/fpc with the
'source' USE flag. I'll see if I can get rid of whatever still needs it
over the weekend, and fpc-source itself after that.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] ACCEPT_LICENSE revisited

2006-11-27 Thread Harald van Dijk
On Mon, Nov 27, 2006 at 05:42:31PM +0100, Marius Mauch wrote:
 On Mon, 27 Nov 2006 10:53:43 -0500
 Mike Frysinger [EMAIL PROTECTED] wrote:
 
  On Monday 27 November 2006 10:48, Marius Mauch wrote:
   Mike Frysinger [EMAIL PROTECTED] wrote:
On Sunday 26 November 2006 18:38, Marius Mauch wrote:
 Mike Frysinger [EMAIL PROTECTED] wrote:
  is there a way in the new GLEP to say never bother me with
  any license bullcrap ?  i made sure the current
  check_license() function respected the idea of * so that i
  can put this in my make.conf: ACCEPT_LICENSES=*
 
 Hmm, you sure about that? I don't see how it's doing that as it
 requires a literal match and globbing is explicitly disabled.

That's because of a relatively recent change (as a result of the bug you
mentioned in the rest of your message):
http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/eutils.eclass?r1=1.254r2=1.255
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: Make 'nls' use flag more generic

2006-11-26 Thread Harald van Dijk
On Sun, Nov 26, 2006 at 03:17:39PM +0100, Diego 'Flameeyes' Pettenò wrote:
 On Sunday 26 November 2006 13:24, Charlie Shepherd wrote:
  The description for the nls use flag is currently 'Adds Native
  Language Support (using gettext - GNU locale utilities)'. However, in
  bug 137297, the kde herd would like to pull in kde-i18n from kde-meta,
 And *how* KDE is using those kde-i18n package? Think about it... Through 
 GETTEXT, INDEED!

It's using gettext? Maybe I'm just clueless (very well possible), but I
was under the impression that KDE had its own internal language
handling.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: Make 'nls' use flag more generic

2006-11-26 Thread Harald van Dijk
On Sun, Nov 26, 2006 at 04:45:59PM +0100, Harald van Dijk wrote:
 On Sun, Nov 26, 2006 at 03:17:39PM +0100, Diego 'Flameeyes' Pettenò wrote:
  On Sunday 26 November 2006 13:24, Charlie Shepherd wrote:
   The description for the nls use flag is currently 'Adds Native
   Language Support (using gettext - GNU locale utilities)'. However, in
   bug 137297, the kde herd would like to pull in kde-i18n from kde-meta,
  And *how* KDE is using those kde-i18n package? Think about it... Through 
  GETTEXT, INDEED!
 
 It's using gettext? Maybe I'm just clueless (very well possible), but I
 was under the impression that KDE had its own internal language
 handling.

Already figured out it really is using gettext, just differently from
other packages. So please ignore my previous mail. :)
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Resolve build time default editor dependency. (was: How get ebuild provider virtual/category.)

2006-11-12 Thread Harald van Dijk
On Sun, Nov 12, 2006 at 04:34:25AM -0500, Mike Frysinger wrote:
 On 11/12/06, Peter Volkov (pva) [EMAIL PROTECTED] wrote:
 The possible solution is to add virtual/editor ebuild
 
 this is a horrible idea
 
 why not modify sudo to not filter the EDITOR env var then there is no
 more problem

Except for a gaping security hole.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Resolve build time default editor dependency. (was: How get ebuild provider virtual/category.)

2006-11-12 Thread Harald van Dijk
On Sun, Nov 12, 2006 at 04:56:33AM -0500, Mike Frysinger wrote:
 On 11/12/06, Harald van Dijk [EMAIL PROTECTED] wrote:
 On Sun, Nov 12, 2006 at 04:34:25AM -0500, Mike Frysinger wrote:
  On 11/12/06, Peter Volkov (pva) [EMAIL PROTECTED] wrote:
  The possible solution is to add virtual/editor ebuild
 
  this is a horrible idea
 
  why not modify sudo to not filter the EDITOR env var then there is no
  more problem
 
 Except for a gaping security hole.
 
 pulling a ciaranm here huh ?  if a guy has access to `sudo`, then
 having a modified environment isnt going to make much difference

sudo can be configured to only allow access to a select few applications.
Allowing arbitrary EDITOR settings completely bypasses this.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Resolve build time default editor dependency.

2006-11-12 Thread Harald van Dijk
On Sun, Nov 12, 2006 at 08:43:55AM -0600, Mike Doty wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Harald van Dijk wrote:
  On Sun, Nov 12, 2006 at 04:56:33AM -0500, Mike Frysinger wrote:
  On 11/12/06, Harald van Dijk [EMAIL PROTECTED] wrote:
  On Sun, Nov 12, 2006 at 04:34:25AM -0500, Mike Frysinger wrote:
  On 11/12/06, Peter Volkov (pva) [EMAIL PROTECTED] wrote:
  The possible solution is to add virtual/editor ebuild
  this is a horrible idea
 
  why not modify sudo to not filter the EDITOR env var then there is no
  more problem
  Except for a gaping security hole.
  pulling a ciaranm here huh ?  if a guy has access to `sudo`, then
  having a modified environment isnt going to make much difference
  
  sudo can be configured to only allow access to a select few applications.
  Allowing arbitrary EDITOR settings completely bypasses this.
 so force EDITOR to something secure (infra uses rvim)

rvim is less insecure than vim, but isn't secure if called as root, nor are
most editors. If you can choose to edit other files than those specified on
the command line, you can edit the boot scripts, and do anything after that.

Anyway, if you have something safe (even if it's only /bin/false), forcing
EDITOR to it would be good, but I do not believe sudo has an option for
this. You can remove variables from the environment, but not add them.
There is a special case for visudo, but that's not handled via the
environment. And if there is no way to force EDITOR to something safe,
unsetting it (the current situation) is the next best thing.

 but really,
 visudo, vipw, crontab these can all be exploited to gain root access
 thus making it silly to try to prevent in these cases.

Obviously you shouldn't allow access to such programs to users that are not
completely trusted. This isn't about such programs. For example, in ufed, I
used to read the PAGER variable (if you believe that is significantly
different, please explain) to display the help. Since sudo clears it, ufed
is usable even when it's not possible to display the help, and ufed can't
do anything other than edit /etc/make.conf, it would be safe to allow it to
run via sudo (emerge --ask should of course be used if ufed can be run, but
that's a separate issue). That's the kind of thing that would no longer be
safe.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] GNOME 1.x and GNOME 1.x dependent package masking

2006-11-09 Thread Harald van Dijk
On Thu, Nov 09, 2006 at 03:23:19AM +, Saleem Abdulrasool wrote:
 Please do NOT reply to this message with a reason why package X should not be
 masked.  If you feel strongly about a package, please port it to GTK+-2 and
 submit patches on a new bug.
 
 x11-wm/sawfish

This should say x11-wm/sawfish-1.3. I am the maintainer of this, and it is
already working with GTK2. You said not to reply here, but if I follow your
advice, I would have to open a new bug and attach /dev/null as a patch. :)
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] baselayout-1.13 going into ~ARCH soon

2006-11-07 Thread Harald van Dijk
On Tue, Nov 07, 2006 at 08:47:18PM +, Roy Marples wrote:
 On Tuesday 07 November 2006 20:32, Drake Wyrm wrote:
  I could be missing something, but:
 
  [[ $'\nwombat' =~ $'wombat' ]]  \
  echo These compare as equal, with or without the leading \n
 
 A working example in bash-3.2 :)
 
 [[ $(/proc/mounts) =~ $'\n'/dev/root\  ]] \
  echo Yay, I matched ^/dev/root 
 
 I challenge you to get an exact match of /dev/root being on the first line 

You mean being first on a line, right?

 using the == operator and/or quoting.
 Remember, /dev/root/foo and /dev/foo /dev/root must not match either.
 
 If you can you get credit in the ChangeLog :)

[[ 
$(/proc/mounts) == *
/dev/root * ]]  echo Yay, I matched ^/dev/root

You can use $'\n' instead of actual newline characters, of course.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Monthly Gentoo Council Reminder for November

2006-11-06 Thread Harald van Dijk
On Mon, Nov 06, 2006 at 05:20:26PM -0500, Mike Frysinger wrote:
 On Monday 06 November 2006 17:09, Alin Nastac wrote:
  I re-stated my case in comment #14
 
 most of your dislike for SPF centers around the idea you dont want to send 
 mail via gentoo.org mail servers ... is this really a problem ?  seems like 
 it's pretty trivial to do so

Sending mail via gentoo.org mail servers is explicitly disallowed (not even
just strongly discouraged) if the dev in question can use his/her ISP's
server.
  http://www.gentoo.org/proj/en/infrastructure/dev-email.xml
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Monthly Gentoo Council Reminder for November

2006-11-06 Thread Harald van Dijk
On Mon, Nov 06, 2006 at 05:11:42PM -0500, Mike Frysinger wrote:
 On Monday 06 November 2006 18:03, Jakub Moc wrote:
  considering that quite a 
  couple of arguments were given against using it
 
 which were a copy and paste of existing websites ... how about for the 
 counterargument i copy and paste url's to pro-spf websites and then we'll 
 have a proper exchange of ideas

Why don't you do that? When some actual pro-SPF arguments are given, at
least there's a real chance to either debunk or accept them.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] linking with ld or gcc?

2006-11-05 Thread Harald van Dijk
On Sun, Nov 05, 2006 at 06:47:07PM +0300, Peter Volkov (pva) wrote:
 Hello.
 
 Short question: What shall we use to link libraries/programs: gcc or ld?
 Why?
 
 A bit longer story: I have a problem during linking of wepattack on
 amd64 systems. Linking stage issues warning:
 
 $ x86_64-pc-linux-gnu-ld  -o wepattack wepattack.o rc4.o wepfilter.o
 log.o modes.o misc.o verify.o keygen.o -lpcap -lz -lcrypto
 ld: warning: cannot find entry symbol _start; defaulting to
 00400e10
 
 And resulted file is not executable. In google I found the most of
 tutorials/howtos suggest to link with gcc but some programs still use
 LD. From ld man page it's clear that it should link the program but this
 is not working. So what is the right way to do that? Why?

Link using gcc unless your program is a very special case. _start is defined
in /usr/lib/crt1.o (may be slightly different on amd64), and that as well as
other object files typically required by every program will be pulled in by
gcc.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Removal request for several desktop-wm packages

2006-10-29 Thread Harald van Dijk
On Sun, Oct 29, 2006 at 07:15:01PM -0800, David Shakaryan wrote:
 The desktop-wm herd is understaffed and has a bunch of dead packages
 lying around which no one wants to maintain. I tried to give a valid
 alternative for all of the packages I want removed. At first glance, it
 seems like all of the following packages also have a dead upstream.
 
 x11-wm/larswm -- alternative: pekwm

While the last release is from over two years ago, it still works
great and has no open bugs. Would you consider keeping it around at
least as long as that remains so?

(I'll comment on the bug later.)
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: license group file format

2006-10-26 Thread Harald van Dijk
On Thu, Oct 26, 2006 at 07:02:36PM +0200, Marius Mauch wrote:
 Ok, as there is currently a lot of work going on for GLEP 23
 (licese based visibility filtering aka ACCEPT_LICENSE) the topic of
 license groups came up, in particular the way how they should be
 (technically) defined.
 
 The simplest way is a line based format
   groupname license1 ... licenseN
 however this doesn't allow for any addition of metadata (for example
 descriptions to explain the purpose of a group), these (if wanted) would
 have to be defined in another file.

A description could be provided in the same file, by allowing comments.

 The alternative would be to use a
 more complex file format, for example so called ini-style
 
 [groupname]
 licenses=license1 license2 ... licenseN
 description=Sample license group
 constains_stupid_licenses=1

Something like contains_stupid_licenses (even in an objective form)
could be handled differently: a STUPID_LICENSES group, so that
ACCEPT_LICENSE can contain @GROUP1 @GROUP2 [EMAIL PROTECTED]. Do you
have an example of metadata other than the description that cannot be
dealt with another way?
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Last rites for XMMS

2006-10-23 Thread Harald van Dijk
On Mon, Oct 23, 2006 at 12:43:52AM +0200, Diego 'Flameeyes' Pettenò wrote:
 So, Luis gave up on this, and now it's time againf or removing xmms from the 
 tree.
 
 I've masked the xmms useflag and the following packages:
[...]
 They'll be removed next month... so that I can have my birthday present from 
 Gentoo... getting rid of xmms finally...

What will be done for IUSE=xmms? Should it stay or go? If it should go,
I assume it should not be now (in case someone wants to step up and
maintain xmms), but if not, when?
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: [gentoo-core] Developer retirement

2006-10-16 Thread Harald van Dijk
On Mon, Oct 16, 2006 at 10:17:00AM -0700, Drake Wyrm wrote:
 Jakub Moc [EMAIL PROTECTED] wrote:
  Stephen Bennett napsal(a):
   Please, try to stay on the right mailing list. It's very annoying
   when you don't...
  
  No matter how hard I try, I always hit the _retarded_ behaviour of the
  _one_ mailing just that just _has_ to be special for _no_ apparent
  reason at all.
 
 Can anybody explain how that one list is different from the others? Are
 the headers being munged differently for gentoo-core?

This list sets Reply-to to direct replies to the list. gentoo-core
doesn't. People who just hit the Reply button in their mail clients end
up replying to the author, rather than to the list.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: [gentoo-core] Developer retirement

2006-10-16 Thread Harald van Dijk
On Mon, Oct 16, 2006 at 11:10:57PM +0200, Andrej Kacian wrote:
 On Mon, 16 Oct 2006 22:10:37 +0200
 Harald van Dijk [EMAIL PROTECTED] wrote:
 
   Can anybody explain how that one list is different from the others? Are
   the headers being munged differently for gentoo-core?  
  
  This list sets Reply-to to direct replies to the list. gentoo-core
  doesn't. People who just hit the Reply button in their mail clients end
  up replying to the author, rather than to the list.
 
 Of course, a well-behaving MUA could just use the address in List-Post header,
 as that's why the header is there.

To clarify (if you disagree, please say so):

It's meant to be used when the user chooses to reply to the list. That
is not necessarily the function of the Reply button. In mutt, and IIRC
in Thunderbird as well, reply is intended to mean reply to author,
and there is a separate reply to list function which works on
gentoo-core and gentoo-dev just the same.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: [gentoo-core] Developer retirement

2006-10-16 Thread Harald van Dijk
On Mon, Oct 16, 2006 at 11:57:55PM +0200, Jakub Moc wrote:
 Harald van Dijk napsal(a):
  It's meant to be used when the user chooses to reply to the list. That
  is not necessarily the function of the Reply button. In mutt, and IIRC
  in Thunderbird as well, reply is intended to mean reply to author,
  and there is a separate reply to list function which works on
  gentoo-core and gentoo-dev just the same.
 
 Well, there's no reply to list function in Thunderbird  [1], and
 there's no such function in a couple more clients.

Sorry, my memory must be failing me. Pretend I didn't mention
Thunderbird as a second example, then. :-)
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: [gentoo-core] Developer retirement

2006-10-16 Thread Harald van Dijk
On Mon, Oct 16, 2006 at 05:45:54PM -0700, Drake Wyrm wrote:
 Harald van D??k [EMAIL PROTECTED] wrote:
  On Mon, Oct 16, 2006 at 10:17:00AM -0700, Drake Wyrm wrote:
   Jakub Moc [EMAIL PROTECTED] wrote:
Stephen Bennett napsal(a):
 Please, try to stay on the right mailing list. It's very
 annoying when you don't...

No matter how hard I try, I always hit the _retarded_ behaviour of
the _one_ mailing just that just _has_ to be special for _no_
apparent reason at all.
   
   Can anybody explain how that one list is different from the others?
   Are the headers being munged differently for gentoo-core?
  
  This list sets Reply-to to direct replies to the list. gentoo-core
  doesn't. People who just hit the Reply button in their mail clients
  end up replying to the author, rather than to the list.
 
 Thank you, that does answer my question, but I'm still confused. I doubt
 that gentoo-dev sent the email to which jakub replied. How, then, did he
 manage to reply to gentoo-dev?

I imagine he hit the Reply button, and when adding the list address
manually, simply picked the wrong list by mistake.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection

2006-09-16 Thread Harald van Dijk
On Fri, Sep 15, 2006 at 07:39:35PM +0100, Ciaran McCreesh wrote:
 On Thu, 14 Sep 2006 08:51:09 +0200 Harald van Dijk [EMAIL PROTECTED]
 wrote:
 | On Mon, Sep 11, 2006 at 11:22:11PM +0100, Ciaran McCreesh wrote:
 |  Comments both on the nature and the specifics of the specification
 |  would be welcomed. In particular, I'd like to know if people think
 |  we're mandating the appropriate degree of specificity and whether
 |  we're providing sufficient generality to avoid overly restricting
 |  innovation.
 | 
 | I think this is overly restrictive, actually. It's a good idea to
 | specify which files and directories will be matched by CONFIG_PROTECT
 | and _MASK, since that's something ebuilds end up using, but it may be
 | better to leave the details on how they will be protected up to the
 | package manager (which can in turn make it configurable for the user).
 | For one example of what a package manager, if configured to do so,
 | should in my opinion be allowed to do: automatically remove unmodified
 | and abandoned configuration files on updates. (This is not the same as
 | setting CONFIG_PROTECT=-*.) For another, a package manager, if
 | configured to do so, should in my opinion be allowed to store the
 | config files on a (possibly local) cvs/svn server in addition to the
 | real filesystem, avoiding ._cfg* files altogether. Specifying how
 | they will be protected prevents things like this.
 
 Hm, the specification doesn't preclude additional functionality. It
 just describes how things should work when normal configuration
 protection is in action.

Sure, the specification does not prohibit package managers from having
behaviour that can be configured to not match what is specified, but
that isn't the point. The point is that if configured as such, it isn't
a Gentoo package manager anymore.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection

2006-09-14 Thread Harald van Dijk
On Mon, Sep 11, 2006 at 11:22:11PM +0100, Ciaran McCreesh wrote:
 Comments both on the nature and the specifics of the specification
 would be welcomed. In particular, I'd like to know if people think
 we're mandating the appropriate degree of specificity and whether we're
 providing sufficient generality to avoid overly restricting innovation.

I think this is overly restrictive, actually. It's a good idea to
specify which files and directories will be matched by CONFIG_PROTECT
and _MASK, since that's something ebuilds end up using, but it may be
better to leave the details on how they will be protected up to the
package manager (which can in turn make it configurable for the user).
For one example of what a package manager, if configured to do so,
should in my opinion be allowed to do: automatically remove unmodified
and abandoned configuration files on updates. (This is not the same as
setting CONFIG_PROTECT=-*.) For another, a package manager, if
configured to do so, should in my opinion be allowed to store the config
files on a (possibly local) cvs/svn server in addition to the real
filesystem, avoiding ._cfg* files altogether. Specifying how they will
be protected prevents things like this.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: AT emerge info cruft attachments on bugs.g.o

2006-08-12 Thread Harald van Dijk
On Sat, Aug 12, 2006 at 01:13:48PM +0200, Simon Stelling wrote:
 Jeroen Roovers wrote:
  On a minor note, I'd also like to see bug reporters use canonical
  package names in bug descriptions, including the category (and
  preferably the specific version, not some =foo-3*!!!one, not to
  mention specifying no version at all). Including the category means
  arch devs won't need to guess/discover which of a few hundred categories
  a package is meant to reside in.
 
 First off, I second that. Second, here's how you still get where you
 want without looking up the category:
 
 $ cd gentoo-x86/*/foo

This works better:

$ cd gentoo-x86/*/foo/

This avoids the case where a file by the same name exists (for
example, in licenses/).

 This of course doesn't work if there are multiple packages with the same
 name in different categories, but if a package maintainer doesn't
 specify the category in such a case, he should be hit anyway ;P
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: AT emerge info cruft attachments on bugs.g.o

2006-08-12 Thread Harald van Dijk
On Sat, Aug 12, 2006 at 02:42:32PM +, Francesco Riosa wrote:
 [...]
 
  $ cd gentoo-x86/*/foo
  
  This works better:
  
  $ cd gentoo-x86/*/foo/
  
  This avoids the case where a file by the same name exists (for
  example, in licenses/).
 
 may be
 $ cd gentoo-x86/*-*/foo/
 ?

Maybe. That avoids virtual/*, which may or may not be a good thing,
depending on your needs. (The only other case where it helps is
uclibc, which is probably already a special enough case that it can
be mostly ignored for this thread.)
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Setting USE_EXPAND defaults in profiles (in some cases)

2006-08-07 Thread Harald van Dijk
On Mon, Aug 07, 2006 at 10:01:12AM +0200, Jakub Moc wrote:
 Zac Medico wrote:
  Donnie Berkholz wrote:
  agaffney suggested this in the first place, and every time I think about
  it, it seems like a better idea. If we set VIDEO_CARDS and INPUT_DEVICES
  in the arch profiles, we get the arch-specific defaults we need without
  the really hugely ugly indecipherable mess in the ebuilds that nobody
  can understand besides Josh_B and me. The very strange corner case this
  doesn't work with is if people manually set VIDEO_CARDS=, then they
  will no longer get the behavior of pulling in everything. But the
  default case will still work great.
  
  As of portage-2.1.1_pre4-r4, VIDEO_CARDS= should now continue to work 
  like 
  before no matter how you've enabled the flags in the profile.
 
  As part of the fix for bug 142125, portage automatically regenerates all of 
  the USE_EXPAND variables to be consistent with the corresponding USE
 flags.
  
  Zac
 
 Well, please don't change the behaviour in every other release, it's
 very confusing and people file bugs about it. And -r4 behaviour is
 incorrect, as it ignores defaults in profiles when you set anything in
 make.conf. -r3 got it correctly so that foo in profiles could be
 overriden with -foo in make.conf, this doesn't work any more in -r4.

That was a bug, not a feature. Older portage versions behave as -r4
does, and -r3's behaviour forces users to set invalid values in
certain cases.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Make FEATURES=test the default

2006-08-05 Thread Harald van Dijk
On Sat, Aug 05, 2006 at 12:04:01PM -0400, Alec Warner wrote:
 Ciaran McCreesh wrote:
 On Sat, 5 Aug 2006 17:35:32 +0200 Kevin F. Quinn
 [EMAIL PROTECTED] wrote:
 | USE=test is a workaround; portage cannot use FEATUREs in 
 dep
 | strings.
 
 Actually, it could, if anyone ever got around to adding 
 FEATURES to
 USE_EXPAND...
 
 
 We would do lots of things; that doesn't mean we should ;)

s/would/could/ ? Anyway, sure, there's plenty of things we could do
that we shouldn't. Forcing a hack by users (USE=test) when a hack by
devs is available is one such thing, in my opinion. Yes, I'm aware
that relevant people think FEATURES in USE_EXPAND is a bad idea, and
I'm not sure I disagree. I think as a temporary workaround until a
clean fix is available, it beats the current situation, though.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Make FEATURES=test the default

2006-08-05 Thread Harald van Dijk
On Sat, Aug 05, 2006 at 02:35:49PM -0400, Mike Frysinger wrote:
 On Saturday 05 August 2006 06:57, Kevin F. Quinn wrote:
  On Sat, 5 Aug 2006 11:49:53 +0200
  Danny van Dyk [EMAIL PROTECTED] wrote:
   Please re-read the list of packages that fail tests:
* glibc
* autoconf
* gettext
* tar
   That makes _4_ system packages. Before I would consider making
   FEATURES=test a default, I would add least want the system set to
   actually merge with it.
 
  So you're happy to let users install these packages without them
  knowing the tests would fail?
 
 before i added binutils-2.17, i ran `make check` on it for about 25 
 targets ... of those, about 10 failed ...
 
 i checked with upstream and others reproduced it ... i dont know about you, 
 but i dont have the skills to go in and fix the failures for all of those 
 architectures

Then RESTRICT=test, or use a src_test which warns on test failures
rather than aborting, could be used. Or am I missing something?

 while i like the idea of all packages being able to pass FEATURES=test, 
 somethings it just aint gonna happen with Gentoo's available skill set
 -mike
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] atom matching behavior

2006-08-02 Thread Harald van Dijk
On Thu, Aug 03, 2006 at 07:07:35AM +0200, Marius Mauch wrote:
 Repost from gentoo-portage-dev[1]:
 
 Was just brought to my attention that the =* operator doesn't work as I
 thought, as for example =foo-1.2* matches foo-1.20 as well as foo-1.2.3.
 This wouldn't be a bug problem if it could be used as a general glob
 operator like with =foo-1.2.*,

Even if that would be supported, it wouldn't match foo-1.2, unless
the meaning of * changes.

 but it's use is strictly limited to the
 above version (can only be used when a version component separator may
 appear), so atm there is no facility to reliably lock an atom at a
 specific version component when you have to account for multi-digit
 components.
 Now the question is if we want this glob-style behavior or not. From
 the code comments it seems to be intentional, but I'd suspect that many
 people share my original assumption and expect it to only match full
 version components (as that is the much more common use case). Doesn't
 help that the atom description in ebuild(5) doesn't specify the
 behavior for this case either, 
 
 *  means  match  any version of the package so long as the specified
 base is matched
 
 can be read both ways.
 
 Opinions?
 
 Marius

For packages with MMDD versions, =c/p-2005* can make sense, and
I have used this in the past. Please continue to allow that, and
possibly provide an alternative syntax for what you currently expect
=c/p-v* to do (=c/p-v.* -- if it doesn't require the . -- being a
possibility).
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Replacing cpu-feature USE flags

2006-07-25 Thread Harald van Dijk
On Tue, Jul 25, 2006 at 02:14:46PM +0200, Enrico Weigelt wrote:
 * Ned Ludd [EMAIL PROTECTED] schrieb:
 
 snip
 
  Non gcc compilers have never been supported and probably never will be.
 
 If someone decides to work on that topic, IMHO the best approach
 would be providing an gcc-style frontend, so we actually get
 an drop-in-replacement (at least from the command line view).

What would it do if a gcc-specific option is used for which the real
compiler does not provide any option, even with a different name? If
it would ignore it, things would break horribly (just think of
-funsigned-char). If it would error out, are any options other than
those already specified by POSIX (`man 1p c99`) available on all
systems? (If not, no gcc-style frontend is necessary, because the
options are already the same for all compilers intended to be
usable as a (Unix-like-)system compiler.)
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?

2006-07-14 Thread Harald van Dijk
On Fri, Jul 14, 2006 at 09:09:15PM +0200, Paul de Vrieze wrote:
 On Wednesday 21 June 2006 15:45, Donnie Berkholz wrote:
 
  -qt +qt3:
 
  This would only be available in 2 cases:
 
  - Package supports both qt4 and qt3, and they're mutually exclusive
  - Package supports both qt4 and qt3, and they can both be enabled at once
 
  In case 1, -qt +qt3 would enable qt3. In case 2, -qt +qt3 would
  enable qt3.
 
  In other words, as I've been trying to say all along, there is no such
  thing as a preference flag here. That creates a 2-flag combination to
  get a single feature, which is _not_ what we want. There is a qt flag
  to indicate enabling the best available qt for that package, and there
  are qt# flags to indicate enabling older qt for that package.
 
  The downside to this setup is that it's difficult to avoid installing
  certain qt versions when it's unknown which version USE=qt will pull in
  for any given package. This favors an entirely versioned setup instead,
  and we should get rid of USE=qt altogether in favor of only USE=qt#.
 
 Avoiding installation of a package can IMHO better be done by 
 using /etc/portage/package.mask

Arguably better, but sure not easier. It requires lots of entries in
/etc/portage/package.use since portage won't automatically disable the
qt flag if the required qt version is masked, and when packages change
from/to qt3 to/from qt4, there is no way for portage to let the user
know (so that cat/pkg -qt can be removed from package.use again).
-- 
gentoo-dev@gentoo.org mailing list



Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

2006-07-08 Thread Harald van Dijk
On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote:
 On Friday 07 July 2006 19:04, Harald van Dijk wrote:
  I hope this is specific enough: toolchain.eclass revision 1.234
  (separating ssp/... from vanilla) log message:
  ssp/pie/htb have their own USE flags sep from vanilla, so people can
   utilize those
  when in fact the old USE=vanilla behaviour is unavailable now. You have 
  never (as far as I know) answered whether it was intended to keep the
  old behaviour as an option, and if it wasn't, why the log message is
  what it is.
 
 well i cant answer it if you havent asked it ... me not answering you on irc 
 when i'm not around does not constitute being ignored and anyone who relies 
 on irc in this respect really needs to learn more about irc

I also mentioned it in a bugzilla comment, though admittedly not as a
question there. (The gcc 2 bug, I think.) Bugzilla comments are safe to
assume read, right?

 the log message looks pretty clear to me, i dont see this hidden message 
 you're referring to
 
 the ssp/pie/htb patches have their own USE flags so separating them from 
 USE=vanilla makes perfect sense ...

I'm not disagreeing with that, but removing an older option is not just
providing more choices.

 now you can do:
 gentoo patches + ssp
 gentoo patches + nossp
 vanilla + ssp
 vanilla + nossp

gentoo patches + ssp
gentoo patches + stub
vanilla + ssp
vanilla + stub

 whereas before you only had the option of:
 gentoo patches + ssp
 vanilla + nossp

gentoo patches + ssp
gentoo patches + stub
vanilla

 like i said in my previous e-mail, forcing stubs onto people even when 
 USE=vanilla *is by design* because i got tired of people who had no clue 
 about the consequences throwing USE=vanilla into their USE in make.conf and 
 then complaining when the lack of SSP broke things ...

But I'm not asking for USE=vanilla to disable SSP completely, I'm only
asking for USE=vanilla nossp to disable it. nossp is already
explicitly documented as NOT FOR GENERAL USE, too.

this is also the 
 reason i havent added USE=vanilla to glibc, too many users would simply break 
 their boxes

No complaints there. :)
-- 
gentoo-dev@gentoo.org mailing list



Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

2006-07-08 Thread Harald van Dijk
On Sat, Jul 08, 2006 at 11:27:57AM +0200, Martin Schlemmer wrote:
 On Sat, 2006-07-08 at 08:20 +0200, Harald van Dijk wrote:
  On Fri, Jul 07, 2006 at 07:50:27PM -0400, Mike Frysinger wrote:
   On Friday 07 July 2006 19:04, Harald van Dijk wrote:
 
   the ssp/pie/htb patches have their own USE flags so separating them from 
   USE=vanilla makes perfect sense ...
  
  I'm not disagreeing with that, but removing an older option is not just
  providing more choices.
  
   now you can do:
   gentoo patches + ssp
   gentoo patches + nossp
   vanilla + ssp
   vanilla + nossp
  
  gentoo patches + ssp
  gentoo patches + stub
  vanilla + ssp
  vanilla + stub
  
   whereas before you only had the option of:
   gentoo patches + ssp
   vanilla + nossp
  
  gentoo patches + ssp
  gentoo patches + stub
  vanilla
  
   like i said in my previous e-mail, forcing stubs onto people even when 
   USE=vanilla *is by design* because i got tired of people who had no clue 
   about the consequences throwing USE=vanilla into their USE in make.conf 
   and 
   then complaining when the lack of SSP broke things ...
  
  But I'm not asking for USE=vanilla to disable SSP completely, I'm only
  asking for USE=vanilla nossp to disable it. nossp is already
  explicitly documented as NOT FOR GENERAL USE, too.
  
 
 No offence, but you are being very unreasonable in this thread.  The
 fact that you can get what you are after, even though its not entirely
 supported, should be enough for you, especially for the fact that you
 are not clueless.
 
 You should remember that somebody at the end of the day have to
 sacrifice time and effort to fix bugs, and especially with something as
 complex as gcc, the more variables, the more effort it is going to be.
 And as Mike is relatively the only person currently who seems to
 maintain gcc, it should be his prerogative to decided that he get too
 much spam without the stubs.

Sorry, but how much mail he gets does not affect one bit which behaviour
is better, it only helps understand why the lesser behaviour could be
chosen by reasonable people anyway. (Regardless of which behaviour is
the lesser one.) And I don't harass anyone about -- it's been a very
long time since I even mentioned any problems like this, and if nothing
is done after this thread dies, I'll likely be quiet about it for a long
time again -- so please don't act like I do.

 And you should really know by now that being documented as NOT FOR
 GENERAL USE will still not stop more than enough users to waste his
 time in telling them not to disable SSP with vanilla if they don't know
 what they are doing.

I guess that's a fair point.

  Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches
  don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported
  compiler in Gentoo.
 
 For the fact that we do not support vanilla gcc - I assume this is a gcc
 built by yourself -

Actually, I meant gcc built with the vanilla flag here, as opposed to
pure official GCC, which I already stated is unsupported earlier.

 this truly is really unfair of you to expect it.
 The 'contract' we usually have with upstream, is that if we apply
 patches to their software, we will be the first tier in the support
 chain.  Now you want to run gcc which was not modified by us to fix the
 known hangups in how we do things - or save us time for that matter, and
 you still want us to support it - or at least make life easier for us by
 not leaving gaping holes that cost us maintenance time?

Differences between official GCC and Gentoo's GCC are 1) fixed bugs, and
2) added features. (Assuming no patches are broken.) I think it's
reasonable to not rely on the existence of those added features. You
seem to think I think it's reasonable to not rely on bugs being
fixed. No problem there, I don't.

Besides, I said it's unfortunate that vanilla GCC (either one) is
unsupported, not that it must be. My other problem, that vanilla
GCC is different from Gentoo's GCC with the vanilla flag (plus maybe
nossp/nopie/...), can be handled without requiring support for it from
anyone.

 Am I the only one feeling that this is really selfish/absurd thinking
 since you have such an hackle in what we do, to not research, debug, and
 file thus your own bugs with http://gcc.gnu.org/bugzilla/ ?

I actually do file bugs there when I run into them.

 The alternative to this that you seem to ignore, is that you can start
 helping maintaining gcc (I am sure Mike will appreciate help with
 Halcy0n gone as well, and me not having that much time currently).

Since I'm more interested in vanilla GCC, I think there's little to help
maintain from Gentoo's side (support in ebuilds, and possibly the build
process, that's it). If that's something you think help would be good
for anyway, though, sure, if I can.

And
 of course promising so long as the stubs do

Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

2006-07-08 Thread Harald van Dijk
(Not commenting on the whole message, just parts.)

On Sat, Jul 08, 2006 at 03:46:24PM +0200, Martin Schlemmer wrote:
 You can however fix the tree to make sure it will fully build without
 those flags, and then talk to Mike again about removing them.  I am sure
 he might be more willing if it will not steal his time again.

I ask again: would such patches be accepted? (Mike stated he would
remove stubs once GCC 4.1 is stable -- thanks -- so users wouldn't run
into problems often regardless.)

 Vanilla, Gentoo patched - they all have bugs which bugzilla have more
 than enough of in.

Ah yes, I see some that definitely apply to USE=vanilla builds. I'll see
if there's anything I can understand. :)

 OK, maybe I was just too dense to see it before, or maybe you kept
 dancing around the issue.  To put it clear (or try at least), your whole
 issue currently is that you cannot use a 'Vanilla' gcc (ie without the
 stubs) to build everything in the tree ?

No, being able to use vanilla GCC as Gentoo's system compiler would be a
nice addition, and if it's agreed as a good idea I don't mind helping
out with getting it working, but I can live without it.

 And not as much the stubs them selfs ?

Being able to check software for unofficial compiler flags is for some
cases a must.

I repeat: two separate issues. They keep getting mixed up here.

 I think you understood wrongly.
 
 If the stubs were to be just removed say tomorrow, and breakage in the
 tree is still of such an extend that bugs starts to flood in again, its
 not just you that will have to read the mail.  If the user is clueless,
 then Jakub have to reassign the bug to either toolchain or the package
 maintainer.  If he could not determine it was due to the missing CFLAG,

The error is very clear:
 cc1: error: unrecognized command line option -fno-stack-protector

Maybe I have a little bit more confidence in people, sorry if that's
misplaced. :)
-- 
gentoo-dev@gentoo.org mailing list



Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

2006-07-07 Thread Harald van Dijk
On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote:
 On Fri, 7 Jul 2006 07:46:16 +0200
 Harald van Dijk [EMAIL PROTECTED] wrote:
 
  On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
   On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
Gentoo's gcc with the vanilla flag isn't the official GCC. Most
patches don't get appplied, but some do. Plus, gcc[vanilla] isn't
a supported compiler in Gentoo.
   
   you're just griping because i forced ssp/pie regardless of
   USE=vanilla ... 
  
  I didn't mind that you applied ssp/pie patches regardless of
  USE=vanilla, I did mind that you applied the stub patches with
  USE=nossp vanilla, and I also didn't like that this was either done
  accidentally but ignored when pointed out, or that this was done
  deliberately with a misleading cvs log message.
 
 If you take out the stub patches (which incidentally have no impact on
 code generation), many builds will simply fail because they expect the
 additional flags from ssp, htb etc to be there.

That's the point. I mentioned being able to test whether your own
software compiles with a pure GNU toolchain as a desire. Being able to
see whether unofficial compiler options are used is not just a nice
extra, but even necessary for that.

 Since they have no impact on code generation, their presence doesn't
 impact comparisons with a pure upstream release.
 
   since gcc-4.0 and below are on the way out, i have no problem
   changing this behavior
   
   besides, since both of these technologies are in mainline gcc now,
   i really dont see how you can continue to gripe with gcc-4.1.1+
  
  I don't know how much gcc-spec-env.patch can be trusted, and even if
  it is 100% safe, such patches don't belong in anything that would be
  called vanilla. (I have commented on that patch long before this
  thread started, so don't think I'm just looking for something to
  complain about now.)
 
 Again, if you don't gave GCC_SPECS defined in your environment then
 that patch makes no difference to code generation.

Yes, but if GCC_SPECS is defined in the environment, I don't know enough
about it to be sure that it interacts properly with -specs command-line
options. Even if it works perfectly, though, the point remains that it
does not belong in a USE=vanilla build.
-- 
gentoo-dev@gentoo.org mailing list



Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

2006-07-07 Thread Harald van Dijk
On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote:
 Keep pushing this and the only thing you will end up with is the 
 vanilla flag being removed all together..

Is that a threat? If not, is there a reason behind this?

 You want a pure 100% 
 vanilla(POS) non working toolchain then go download it and 
 compile it yourself. You will soon see why things exist the way 
 they do..

If you mean modifying the build system to actually work properly, then I
have no problem with that. USE=vanilla refers to runtime behaviour, not
the build system. (See use.desc.) Specifically, if patches are applied
that make sure GCC compiles, and those patches make sure GCC compiles to
the same program intended by the GCC devs at that release, those patches
are appropriate, IMO. None of the GCC patches I have problems with are
of this nature.

If you mean vanilla GCC + build fixes is unusable, then I'd appreciate
an explanation, because as far as I know, it can work just fine as a
system compiler, and plenty of people, at some times myself included,
use it as one.
-- 
gentoo-dev@gentoo.org mailing list



Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

2006-07-07 Thread Harald van Dijk
On Fri, Jul 07, 2006 at 03:57:51PM -0400, Ned Ludd wrote:
 On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote:
  On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote:
   Keep pushing this and the only thing you will end up with is the 
   vanilla flag being removed all together..
  
  Is that a threat? If not, is there a reason behind this?
 
 Yes.. When users or devs complain non stop when they 
 don't understand something it leaves us with a few choices.
 1) put up with people not having a clue.
 2) remove the option so they can't bitch about it.
 
 Option #1 is not fun as it pushes the hand on #2

Option 3: Enlighten me. I have explained why I feel the way I do, so if
there's some big flaw in my understanding, please do correct it.

   You want a pure 100% 
   vanilla(POS) non working toolchain then go download it and 
   compile it yourself. You will soon see why things exist the way 
   they do..
  
  If you mean modifying the build system to actually work properly, then I
  have no problem with that. USE=vanilla refers to runtime behaviour, not
  the build system. (See use.desc.) Specifically, if patches are applied
  that make sure GCC compiles, and those patches make sure GCC compiles to
  the same program intended by the GCC devs at that release, those patches
  are appropriate, IMO. None of the GCC patches I have problems with are
  of this nature.
  
  If you mean vanilla GCC + build fixes is unusable, then I'd appreciate
  an explanation, because as far as I know, it can work just fine as a
  system compiler, and plenty of people, at some times myself included,
  use it as one.
 
 You use the Gentoo modified one. Regardless of what USE= flags you have
 enabled you are still getting Gentoo behaviors.

Gentoo isn't the only system I use. I have used vanilla GCC + build
fixes, and I have been able to get a working system with it. So I'm
still waiting on your explanation of how it is unusable.

 Think vanilla-sources are pure? They are not. 
 They get patched as well with the minimal amount of patches required.

Interesting, and I did not know that, but looking at kernel-2.eclass
(which appears to be the only thing doing any modifying), the
modifications are all build system fixes, and won't affect the generated
kernel.
-- 
gentoo-dev@gentoo.org mailing list



Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

2006-07-07 Thread Harald van Dijk
On Fri, Jul 07, 2006 at 05:12:21PM -0400, Mike Frysinger wrote:
 On Friday 07 July 2006 01:46, Harald van Dijk wrote:
  On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote:
   On Thursday 06 July 2006 16:14, Harald van Dijk wrote:
Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches
don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported
compiler in Gentoo.
  
   you're just griping because i forced ssp/pie regardless of USE=vanilla
   ...
 
  I didn't mind that you applied ssp/pie patches regardless of
  USE=vanilla, I did mind that you applied the stub patches with
  USE=nossp vanilla, and I also didn't like that this was either done 
  accidentally but ignored when pointed out, or that this was done
  deliberately with a misleading cvs log message.
 
 it was not ignored, i told you the answer was no ... i listened to your 
 request and then i evaluated the situation and deemed at the time to go with 
 what we have now.  see how your usage of ignored is incorrect here ?

Actually, you did ignore. The below text refers to something older.

 as Kevin pointed out, the stubs do not affect code generation so i preferred 
 to keep users from breaking themselves
 
 also, at the time, i told you you could easily work around the stub situation 
 by simply deleting them:
 rm /usr/portage/sys-devel/gcc/files/stubs/*
 and then add sys-devel/gcc/files/stubs/ to your rsync exclude list

Yes, you told me this, before USE=vanilla even existed for gcc. When
there's no implicit claim that installed GCC is official GCC, it's much
less of a problem that it's not. Back then, I never complained that the
installed GCC wasn't the official GCC, only that (a manually installed)
official GCC wasn't a supported compiler. And I did not ask for an
official way to disable the stub patches then, I only asked how I could
do it for my own system.

 once we have 4.1.1 in stable, i'll be happy to update the eclass to not apply 
 the stubs when USE=nossp as the majority of users will no longer be in the 
 situation i referred to earlier

Thanks. I hope that if a similar situation comes up, ebuilds will use
test-flags instead of assuming the option is valid, though.

   since gcc-4.0 and below are on the way out, i have no problem changing
   this behavior
  
   besides, since both of these technologies are in mainline gcc now, i
   really dont see how you can continue to gripe with gcc-4.1.1+
 
  I don't know how much gcc-spec-env.patch can be trusted, and even if it
  is 100% safe, such patches don't belong in anything that would be called
  vanilla. (I have commented on that patch long before this thread
  started, so don't think I'm just looking for something to complain about
  now.)
 
 you never pointed that patch out to me nor did i notice it, so i dont really 
 see how you could have expected this to be fixed already

I didn't point that out to you, I pointed that out to another of the
toolchain guys. I'm not completely sure who, but I think it was
Halcy0n.

 i'll update cvs when i get a chance

Thanks again.
-- 
gentoo-dev@gentoo.org mailing list



Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)

2006-07-07 Thread Harald van Dijk
On Fri, Jul 07, 2006 at 06:13:27PM -0400, Mike Frysinger wrote:
 ignored *what* then ?  you requested USE=vanilla control ssp, i said no and 
 i'll add support for USE=nossp ... you requested USE/stub control, i said no, 
 go delete the stubs

USE=nossp existed before USE=vanilla did. To be sure I'm remembering
right, I checked `cvs log toolchain.eclass`. In order, probably skipping
a few steps:

1- No SSP
2- Choice between SSP [USE=-nossp] and stub patches [USE=nossp].
   USE=vanilla didn't exist.
3- Choice between SSP [USE=-nossp -vanilla], stub patches
[USE=nossp -vanilla], and nothing [USE=vanilla]
4- Choice between SSP [USE=-nossp] and stub patches [USE=nossp]
   USE=vanilla exists but has no effect on SSP.

It was during 2 that I asked for a way to disable stub patches for
myself (and not as part of the official ebuild), and you said to delete
them. That was good enough for me during 2. We are now in 4.

 i dont see what else you're referring to ... be specific, vague claims only 
 lead to wasting of both our times

I hope this is specific enough: toolchain.eclass revision 1.234
(separating ssp/... from vanilla) log message:
ssp/pie/htb have their own USE flags sep from vanilla, so people can 
 utilize those
when in fact the old USE=vanilla behaviour is unavailable now. You have
never (as far as I know) answered whether it was intended to keep the
old behaviour as an option, and if it wasn't, why the log message is
what it is.

 all bets are off now then ... with Halcy0n leaving us, that leaves me as the 
 only person maintaining the toolchain (there are few devs who contribute 
 fixes for their ports and it helps out a ton, but that doesnt really count as 
 being fully responsible for the toolchain packages).

I'll keep that in mind, I wasn't aware that the other toolchain guys
handle specific parts of the toolchain packages only. Even if I disagree
with some specific decisions, nice job overall, then.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Replacing cpu-feature USE flags

2006-07-06 Thread Harald van Dijk
On Thu, Jul 06, 2006 at 02:21:43PM +0200, Diego 'Flameeyes' Pettenò wrote:
 On Thursday 06 July 2006 13:58, Donnie Berkholz wrote:
  Well, there are enough in the tree
 There are ebuilds for non-gcc compilers. There's no support in using them for 
 anything like building stuff. Let's think to all the append-flags there are 
 in the tree.

`append-flags $(test-flags ...)` can be used instead, if the options are
gcc-specific, and I have done that myself in a case where every
supported GCC version supported the specific option. (-fpermissive was
the one.)

 This is not going to make the support any less working. There's 
 no project maintaining support for icc and the like.

When the answer is make icc not suck even when it is capable of
compiling mostly any package if the portage tree would not assume gcc,
that's not going to happen. First, alternative compilers must be
accepted (even when not supported) by package maintainers, and only then
might they ever become supported.

  that you should at least make sure 
  they don't completely break and error out when passing them invalid
  flags, 
 Uhm, If you look at the function itself you can see that I drop the stderr 
 output and I just care about the other part. The flags used are the ones set 
 by the user with the exclusion of -E -dM that are, afaik, standard unix 
 compiler options like -c and -o..

-E is a standard unix compiler option. -dM isn't. What you could do
instead is `$(tc-getCC) ${CFLAGS} -E - /dev/null 21 EOF
#if !($macro)
#error
#endif
EOF` and check $CC's return value. If $macro is not defined, or is
defined to something like 0, preprocessing won't succeed, and $CC will
return nonzero.

 if the compiler does not support those, 
 it's unlikely it can actually do anything useful in Gentoo.
 And anyway it cannot break, it will just report that no extensions are 
 available.

That's sane behaviour regardless. :)
-- 
gentoo-dev@gentoo.org mailing list



  1   2   >