Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
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()
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()
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
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
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
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
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
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
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*
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*
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...
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...
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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.
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.
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.
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.
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
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 ?
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 ?
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 ?
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
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
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
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
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?
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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+
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?
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!
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
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
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
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.)
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.)
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.
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
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
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
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
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?
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
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] Last rites for XMMS
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
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
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
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
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
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
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
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
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)
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
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
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
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
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?
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)
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)
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)
(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)
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)
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)
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)
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)
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
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
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, Jul 06, 2006 at 11:41:26AM -0400, Ned Ludd wrote:
On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
Diego 'Flameeyes' Pettenò wrote:
echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null
Thoughts? Comments?
How will you handle non-gcc compilers?
Non gcc compilers have never been supported and probably never will be.
Gentoo uses the GNU Toolchain.
The GNU toolchain is not supported by Gentoo, and in fact gets actively
broken with unsupported command-line options. Only the GNU toolchain as
modified by Gentoo's toolchain guys is supported, unfortunately.
--
gentoo-dev@gentoo.org mailing list
