Re: [gentoo-dev] [RFC] ban use of base-4 casemods in ebuilds due to locale collation instability
Am 11.11.2015 um 05:16 schrieb Ulrich Mueller:
>> On Tue, 10 Nov 2015, Mike Frysinger wrote:
>
>> Arfrever highlights these are not even safe to use. bash is locale aware,
>> so it'll apply LC_COLLATE rules when processing the ^/, casemods. while
>> you can fix this with external programs ala:
>> LC_COLLATE=C tr ...
>
>> you can't do it with inline code like:
>> LC_COLLATE=C SRC_URI=".../${PN^^}/..."
>
>> On Tue, 10 Nov 2015, Mike Frysinger wrote:
>
>> sorry, i meant char classification here (LC_CTYPE), not collation.
>
> Shouldn't these be safe to use if the string consists purely of ASCII
> characters? I mean, A-Z and a-z should be uppercase and lowercase,
> respectively, in any locale?
Unfortunately, no (have been bitten by this issue already some years ago):
$ echo $LC_ALL
tr_TR
$ f=i; echo ${f^^}
İ
$ f=I; echo ${f,}
ı
- René
Re: [gentoo-dev] multilib amd64 news item for review
Am 17.03.2015 um 16:33 schrieb Michał Górny: However, some users may prefer setting ABI_X86 globally to enable 32-bit libraries in all packages that support building them. This can be done using the following package.use entry: */* abi_x86_32 I'm confused: Has this a different semantics from adding USE+='abi_x86_32' to make.conf? If no, why mention this strange way (which is new to me) for setting default global useflags. And to bring this even further: Wouldn't the nicest approach to add ABI_X86=32 or ABI_X86=32 64 to make.conf? (With the latter being more descriptive, as the first one might suggest that _only_ 32bit should be built). - René
Re: [gentoo-dev] Re: Portage QOS
Am 10.01.2014 13:10, schrieb Igor: Hello Chris, Friday, January 10, 2014, 1:08:39 AM, you wrote: Right here is the big problem: you're not looking at this from the perspective of the average Gentoo developer. We don't care about market share. We don't care whether we're on top for another few years. There are several forks of Gentoo. I doubt most devs care about them. I personally know that we're not going to compete with Debian, which has a huge contributor, or Ubuntu or Red Hat, which have whole companies behind them. You're selling this as if you're selling to a company which wants to be on the top of the market and beating out competitors, and that's not what we are. We are a source-based distro that requires some effort from users, and people want that or they don't want it. What we need is a vote YES or NO. If you against it - vote NO. It's perfectly normal, if there would be no NO there would be no need voting. Thank you for you opinion. The competition in open source world is much harder than with commercial software. 3 commercial systems share 96% of the users. 1,6% of the users are shared by 296 Linux distros You may think that you're outside this rules but the competition is natural on the planet and Gentoo is certainly competing weather you want it or not. Competition was long before a human foot stood on the ground for the first time :-) And suddenly there is no competition in Linux world - do you really belive in it? There is no really competition for the non-enterprise systems. It is a co-existance (one might even call it some kind of symbiosis). Please take your business nonsense somewhere else. Honestly, you sound like some suit with his powerpoint slides talking about buzz-words like 'competitors', 'keeping in power', 'QoS' … There were also numerous threads already about the very same topic. Most came to the conclusions that a) Gentoo is not dying b) the numbers used as arguments are inaccurate at best (how do you count 'Gentoo users'? And do you want users or machines? And what with persons using different systems) - René
Re: [gentoo-dev] Portage QOS
Am 10.01.2014 13:23, schrieb Igor: You could make fast and correct decisions. There is no such thing as the single correct decision. Management people often think there is, but this is because management people often have no clue what they are talking about. Why not to get rid of Python at all. What is so great in Python that Gentoo exists for the sake of it? What is so bad with Python? Also keep in mind: A bad/wrong algorithm does not get better just because you change the implementation language. 300 devs, are NOT ABLE to make portage fast in 8 years. You obviously have no idea how Gentoo works. - René
Re: [gentoo-dev] Re: Portage QOS
Am 10.01.2014 13:52, schrieb Igor: And you belive that you're outside competition. It looks unreal. Gentoo is in competition with other distros - it's real and happens right now. Again, just because this science called 'Economics' believes, everything is in competition, does not change reality. Are you absolutely sure that in the condition when nobody knows how Portage works we may go that far as saying we have a healthy Penguin? If I want to know whether or not a penguin is healthy, I'd ask my mum (she's a vet). - René
Re: [gentoo-dev] Portage QOS
Am 10.01.2014 14:05, schrieb Igor: Hello Patrick, Friday, January 10, 2014, 4:39:59 PM, you wrote: No, Python isn't slow. Bad code is bad. You can write bad code in any language. Are you sure? Take a look here: http://benchmarksgame.alioth.debian.org/u32q/benchmark.php?test=alllang=python3lang2=gppdata=u32q of course these stats are all so fake, and you may not belive them. I've been using C/C++ since school it's fast, even bad code is working fast. I WOULD NEVER BELIVE PYTHON IS AS FAST AS C++ with math algorithms You do realize, that we are not doing math (read: number crunching) here? And again: What is needed is streamlining the algorithms (discussion on that already started as far as I could notice). An algorithm in O(n³) is always¹ worse than O(n). The constant factor added by the language difference is of no interest. It's crazy that you're even trying to state it. Take a look at what Python is producing in disasm and then look at it in G++. For a larger project, it often is more important to have readable and maintable code opposed to getting the last bit of performance. And Python is _far_ more readable and concise than C or C++ (imho). Due to lack of typechecking, I'm not so sure when it comes to maintainability though (there are test suites of course). - René ¹ For a large enough n.
Re: [gentoo-dev] Portage QOS
Am 10.01.2014 19:19, schrieb Ciaran McCreesh: On Fri, 10 Jan 2014 14:18:24 +0100 René Neumann li...@necoro.eu wrote: And again: What is needed is streamlining the algorithms (discussion on that already started as far as I could notice). An algorithm in O(n³) is always¹ worse than O(n). The constant factor added by the Full dependency resolution is NP-hard... Though NP-hard does not necessarily mean 'unfeasible in practice'. If you really wanted to streamline the algorithms, you'd change the inputs slightly. Most of the complexity of doing a decent job of dependency resolution comes from dealing with crap input. My intention really was not to tell anybody how the depres algorithms should be improved. I just wanted to make a point against the 'Python is the root of all the bad performance'. ¹ For a large enough n. ...which could be larger than the number of atoms in the universe. There are real world cases where an algorithm has an O(n^3) step that takes a day, and a O(2^n) step that takes a second for most inputs. You shouldn't be using O() to make performance comparisons. Point taken. I should've use 'in general' instead of 'always'. What I had in mind when writing this were more smaller problems, where a good algorithm exists but people use their own naïve implementation/data structure. - René
Re: [gentoo-portage-dev] [PATCH] make.conf.5: Document PYTHON_TARGETS, bug #493180
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 03.12.2013 17:05, schrieb Mike Frysinger: as for the patch, i'm of the opinion that make.conf is not for documenting random USE_EXPAND-ed variables. this sort of thing should go into the relevant eclass, python-r1.eclass in this case. then people would read about it via `man python-r1.eclass`. I object. As a user you should (most of the time) not need to read eclass-documentation. And even if you'd count this as a necessity: How should a user know _which_ eclass documentation to read? I think such a thing is way too much 'implementation detail'. If you all think, that make.conf.5 is not the right place (which I understand), then there should be another central place where the most important USE_EXPAND-ed vars are explained and/or pointers provided. Perhaps one could make (active) contribution to this place a prerequisite to obtaining a new USE_EXPAND-var. And in make.conf.5 there then can be a pointer to this central documentation. - - René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSnhcNAAoJEC/VbLI/MjXALUEH/iloA1/Pxee/0K3dv3s3P0NO buDmWKLQQ/rtUwlaM3VZj4b71MqHK7zIjumD+9IIq9to4l/ot5Bsx8hUbdcyJtsa wrSPZBKGeYw9m3qYmP9GIr9uKb+/BfUPrfGefSp3rtWPnaAb1clZJbC40Hw+J2Mp rzKWzvmweqVbrzXSg/Dm38+JqBozQFk1cbHshe2d15S/Cem4yCn+NQaPSl7l1hQE eljJ/b5lGbIeF8QxtPJPwSVEv/ohC6nXLK7eKvGDXvV0ZpuDl9KvmeYpc8/40d9n LSzTBB7ENEC34hpTwhoTekufitmFj/IRvN63ekHf6+asjrfhCejFCO6HKZFa3I4= =Rky6 -END PGP SIGNATURE-
Re: [gentoo-dev] Over-reliance of Gentoo projects on overlays
Am 13.06.2013 07:44, schrieb Michał Górny: Dnia 2013-06-12, o godz. 13:23:04 Michael Orlitzky mich...@orlitzky.com napisał(a): We need worse support for overlays, i.e. no. Having to use 3 overlays defeats the purpose of a QA'd tree. Everything in an (official) overlay should be in package.mask instead. The main reason it isn't is because nobody wants to use CVS. For good examples, see sunrise or gentoo-haskell. Sunrise is not that good example. I liked to use it as an example but over time you start to see how degenerated it becomes. It seems that the bond between people is pretty poor there, and many of the packages lack proper maintenance. Some of them simply don't build at all and wait for a random Sunrise user to fix them. Then they lay unmaintained once again, and the story repeats. Then the policies in sunrise need to be more strict: If it is mentioned in the bug, that the version in sunrise does not build anymore, it should be dropped from sunrise if there is no fix in some timeframe [1]. Of course this puts more workload on the sunrise-team as they have to monitor the bugs and respond accordingly. - René [1] Dunno, perhaps two weeks if noone responds will fix it, four weeks else.
Re: [gentoo-dev] New USE_EXPAND flag for www-servers/monkeyd
Am 27.05.2013 22:38, schrieb Anthony G. Basile:
Hi everyone,
I was about to add a use expand flag for monkeyd (a tiny web server) and
there is a notice in base/make.default to discuss use expand flags on
the list first. There are about 9 plugins for monkeyd similar to apache
which can be turned on/off by a configure switch. It makes sense to
follow the same logic as apache here. There are no dependencies on
monkeyd and so no use-deps. Seems very safe. Any objections?
--Tony
Some time ago, Zac proposed a general PLUGIN (or PLUGINS) use-expand,
which could be used for packages with a small amount of plugins to avoid
having a new USE_EXPAND for each and every package. It also has the
advantage, that the resulting useflag 'plugins_foobar' is sane enough
(opposed to 'monkeyd_plugins_foobar'). With this, it serves as a quite
nice compromise for the fraction of USE_EXPAND-dislikers (like me).
Unfortunately this did not get any real discussion. So could this
package be an option to start this? Or do you insist on
monkeyd_{plugins,modules,...}_ ?
Thanks,
René
Re: [gentoo-dev] Re: CPU use flag detection
Am 19.05.2013 18:03, schrieb viv...@gmail.com: On 05/19/13 17:47, Alexis Ballier wrote: On Sat, 18 May 2013 22:31:11 -0400 Walter Dnes waltd...@waltdnes.org wrote: [...] ...shouldn't mmxext be moved out of use.local.desc into use.desc? all the cpu flags should be global IMHO, regardless of how many packages use them: we already mask/unmask them globally on arches where they are irrelevant. Alexis. +1 also +1 they should be easily recognizable as cpu features USE flags, as already mentioned recently by someone (sorry could not search) So this sounds like one of the places, where a USE_EXPAND could really be correct and worthwhile :). - René
[gentoo-dev] USE_EXPAND is not an IUSE replacement [was: New USE_EXPAND: CLAWS_MAIL_PLUGINS]
Am 24.04.2013 11:51, schrieb René Neumann: As more and more packages seem to (mis)use USE_EXPAND: Can we get the possibility to set this directly in package.use? Having to write 'claws_mail_plugins_foo' does not help readability, and setting it in make.conf is also not the right way (as is package.env). I just noted, that USE_EXPAND variables are even worse than I thought... NGINX_MODULES_HTTP=-access emerge -av nginx Invalid '-' operator in non-incremental variable 'NGINX_MODULES_HTTP': '-access In other words: They do not even work from commandline (in a stacking manner). So, what exactly are the use-cases again, and why are normal use-flags replaced by them? I already see a future where packages carry a FOOBAR_CONFIGURE_OPTIONS use-expand ... when IUSE is not hip enough any more. - René P.S.: Using USE_EXPAND for PYTHON_TARGETS or LINGUAS or VIDEO_CARDS is of course good, as I (usually) set this system-wide.
Re: [gentoo-dev] USE_EXPAND is not an IUSE replacement [was: New USE_EXPAND: CLAWS_MAIL_PLUGINS]
Am 03.05.2013 22:20, schrieb Zac Medico: Is it worth changing? Nope. What's worth changing is the excessive use of USE_EXPAND for no reason (your described usecase makes sense for reasonable USE_EXPAND stuff like VIDEO_CARDS). But seems like I'm the only one concerned by this, so I should probably rest my case and switch to silent sobbing instead ;-). - René
Re: [gentoo-dev] Add HEXCHAT_PLUGINS to USE_EXPAND
Am 21.03.2013 14:09, schrieb Denis M.: Hello, I'd want to ask if it's possible and a good idea to add HEXCHAT_PLUGINS to the global USE_EXPAND var. I personally don't think this is a good idea. Imho USE_EXPAND should be used for flags that will be used by multiple (5?) packages -- for the simple reason, that USE_EXPAND somewhat hints for using /etc/make.conf for configuration (yes, you can still use package.use, but this feature is probably not so well known). Also the bug gives no reasoning, why having USE_EXPAND is a good thing here. - René
[gentoo-dev] base.eclass
Hi all,
I'd like just to receive a short clarification about the 'status' of
base.eclass: Is this eclass expected to be available everywhere, i.e.
should each eclass make sure it imports and incorporates it. Or is it
just an eclass like the others and ebuilds should make sure they inherit
it if needed?
In my special case, I discovered that I cannot rely on 'PATCHES' being
honored and hence have to introduce something like:
src_prepare () {
epatch some.patch
distutils_src_prepare
}
And, imho, this is just noise -- having PATCHES=( some.patch ) would
be clearer :)
Thanks,
René
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Undocumented and unused USE variables
* Undocumented use flags: -- pango % euse -i pango global use flags (searching: pango) no matching entries found local use flags (searching: pango) [+ D ] pango app-i18n/fcitx: Enable support for x11-libs/pango 3.6.3 [gentoo] 3.6.4 [gentoo] [+ ] 4.0.0 [gentoo] [+ ] 4.0.1 [gentoo] [+ ] 4.2.0-r2 [gentoo] [+ ] 4.2.1 [gentoo] [+ D ] pango media-gfx/fontforge: Enable pango font rendering [+ ] 20100501 [gentoo] [+ ] 20110222 [gentoo] [+ ] 20110222-r1 [gentoo] [+ D ] pango media-gfx/imagemagick: Enable Pango support using x11-libs/pango [...]
